「機能する限り」は標準ですか？[閉まっている]

私の最近の質問を参照してください： プログラミングは、底辺への競争における職業としてですか？

私の最後の店にはプロセスがありませんでした。アジャイルは本質的に、彼らが彼らのプロジェクトを開発または管理する方法について全く計画を持っていなかったことを意味しました。これは「やあ、ここにたくさんの仕事があります。2週間でそれをやりましょう。ペースが速くて機敏です」。

彼らは問題があると知っていたものをリリースしました。彼らは物事がどのように書かれているか気にしませんでした。数人の開発者がいるにもかかわらず、コードレビューはありませんでした。彼らはバグだと知っていたソフトウェアをリリースしました。

私の以前の仕事で、人々はそれが機能する限り態度を持ち、それは大丈夫です。基本的に仕様を調査している間に書いたコードの書き直しを要求したとき、彼らはそれを否定しました。コードが複数の場所で繰り返され、カプセル化が行われず、人々がコードを変更するのに長い時間がかかったため、コードを書き直したかったのです。

本質的に、私の印象はこれです：プログラミングは次のように要約されます：

1. 最新のツール/テクノロジーに関する本を読む
2. これに基づいてコードを一緒に投げ、会社が「カスタムコードを維持する」ことを望まないので個々のコードを書くことを避けます
3. それを見せて、「それが機能する限り」次のことに進みます。

次の仕事はもっといい店を手に入れるといつも言ってきました。それは決して起こりません。これなら、行き詰まってしまいます。技術は常に変化します。ここでの唯一の専門的な開発が最新のMS Pressテクノロジーブックを読んでいる場合、10年で何を構築しましたが、さまざまなテクノロジーの表面的な知識ですか？私は心配しています：

1. 専門的な基準を持つ最善の方法
2. この状況で有意義な知識と経験を開発する方法

私は、優れた開発者になるための重要な側面であると思われるものに間接的につまずきました。「機能する限り」と巧妙に設計されたエレガントなコードのバランスをとることです。

政治のように、中間の微妙な位置を取るよりも、スペクトルの一方の端に自分の位置を賭ける方がはるかに簡単です。私が遭遇した開発者の大部分は、コーディングカウボーイハックとアーキテクチャ宇宙飛行士の2つのカテゴリのいずれかに分類されます。両者のバランスをとろうとしています。思ったほど簡単ではありません。

より直接あなたの質問に答えるために、はい、私は「それが機能する限り」がしばしば標準だと思います。しかし、別の見方をしてください。あなたは同僚を教育し、より良い実践を導入しようとする素晴らしい立場にいます。しかし、極端に行かないで、なぜ私たち全員がこれをしているのかを覚えておいてください：顧客の問題を解決するため。

>>私の前の仕事で、人々はそれが機能する限り態度を持っていました、それは大丈夫です。

私はここでは少数派かもしれませんが、私は同じ態度を持っています。何かを書き換えるには、なぜこれが必要なのかという明確な証拠があるはずです。そして、私は「uf、私はそれがコード化された方法が好きではない」というようなことを意味しません-すべての開発者はコードに関する好みを持っています。書き換えたい部分にはいくつかの問題があるはずです。

• パフォーマンスの問題
• システムの他の部分よりも多くのバグが見つかりました
• 開発者は、この部分で作業する際により多くの時間を費やします
• 等

アジャイルは、バグのあるソフトウェアのリリースを決定する人間に対して責任を負いません。人間です。

とはいえ、品質を非常に重視しているので、それは良いことです。あなたは完璧主義者であり、最新の技術に追いついていないなら、あなた自身の価値を心配していると確信しています。

問題は、完全主義が先延ばしになり、先延ばしが平凡につながることです。

そのため、ビジネスは市場投入までの時間などを優先し、アジャイルを使用して、予測可能なペースで迅速に価値を提供します。

あなたはあなたの会社のビジネス戦略を説明しなかったので、あなたはそれについてあなたのマネージャーに質問することから始めるべきだと思います。

彼らの目標と計画（彼らがそれらを達成するのを助けるためにあなたを雇った）に沿って調整することにより、あなたはあなた自身と個人の目標に集中するのではなく、あなたがそれらに貢献する方法を理解するより良い立場になります。

understand彼らの価値に挑戦することで、あなたはあなたのものを共有することができ、それが実りあるコラボレーションの始まりになると確信しています。

そして、彼らが彼らが何をしているのかわからないことがわかった場合、あなたの唯一の選択肢は終了することです。

それはすべてあなたが構築しているものに依存します。1か月だけオンラインになるマイクロサイトを構築していて、構築に9日間ある場合：はい、動作する限り十分です。

FA-18システム用のフライバイワイヤアルゴリズムを作成している場合は、可能な限り完全に構築することをお勧めします。

そのため、ほとんどのテクノロジーの答えの場合と同様に...それは異なります。

会社によって異なります。しかし、多くの企業は深刻な競争と時間のプレッシャーを抱えています。それが典型的な理由です。もう1つは、潜在的に十分なスタッフのいない大きなワークロードです。（人員不足の理由はいくつかありますが、必ずしも会社のせいではありません。）そうは言っても、一部の組織は湿った紙袋から抜け出すことができませんでした。

ここでは80/20ルールが適用されると思います。基本的に、安っぽい80％に耐え、20％に取り組む必要があります。ただし、それらであってもトレードオフを行う必要があることを理解してください。ビジネスでは、通常、それが絶対に正しいかどうかは問題ではありません。あなたが今それを持っていることが重要です。

ここでの唯一の専門的な開発が最新のMS Pressテクノロジーブックを読んでいる場合、10年で何を構築しましたが、さまざまなテクノロジーの表面的な知識ですか？

それはかなり嫌なことですが、その10年で注目すべきいくつかの壮大な失敗があったかもしれません。私はそこで働くことについて好きであったか、楽しんでいないかなり具体的なことを思い出すことができる多くの場所を見てきました。会社がスクラムを実装しようとするか、テスト駆動開発アプローチを採用しようとする場合のような新しいプラクティスがありますが、それらはチャンスかもしれませんが、正式な教室の設定ではないため、必ずしも専門的な開発とは見なされません。

さまざまなカウボーイコーディング戦略とともに「機能する限り」が一般的なさまざまな場所を知っています。いくつかの新興企業で、この種のメンタリティを見てきました。会社がまだ若く、彼らが本当に何をしようとしているのかという考えを洗い流そうとしている場合に意味があります。私が働いてきた他の会社では、プロセスと成熟度が非常に高くなっていますが、必ずしも見つけるのは簡単ではありませんが、恐れています。「好きだ。後の仕事の状況のた​​めにそれを覚えているだろう」と私が行きたいところに、「私は本当にそれが好きではありません。私は注意します。将来的にそれを避けようとする。」

私はこのような店で彼らに追いついたばかりの時点でしばらく働いていました。文字通り解決できなかった既知のバグがある2、3年前のアプリケーションがありました。レイアウトの幅と高さの計算を実行する4,000行のループを考えてください。コードの一部を修正して1つのインスタンスの問題を修復すると、以前の開発者がマジックナンバーを使用して計算結果を任意に調整することで同様の問題を帯域支援していたため、20の問題が発生します。コードは有毒以外のものとは言えません。

最後に、この既存のコードを使用してレイアウトを処理できると上司に言われた新しいプロジェクトを手渡しました。どういうわけか私は彼に私にそれを「変更」させるように説得したので、彼は私に余分な時間を与えました。代わりに、レイアウトを支援するために適切に設計されたライブラリを作成するのに時間を費やしました。この新しいプロジェクトのバグは、文字通り、解決するのに10秒かかりました。問題を特定してからコードを見て、何が問題なのかを確認することさえできました。

私はこれが私のマネージャーにとってターニングポイントになると思ったが、私が得たのは背中を軽く叩くだけで、彼は基本的に「あなたのやり方もうまくいくと思う」と言った。

それ以来、私は別の店で働き始めました。ポイントは、彼らの心を変えることはできないということです。別の場所で仕事をするだけです。

経済には一種の進化プロセスがあり、遅かれ早かれそうした企業を廃業させるという希望がまだあります。しかし、多分、技術進歩のペースが速すぎると、新しいニッチが多くなりすぎるため、弱い競合他社でも十分な「食料」を見つけることができます。

良い場所で働くチャンスを増やしたい場合は、数週間ごとに新しいものを書くのではなく、多くの顧客に販売する製品を持っている会社を探してください。優れたコードベースを持ち、常に既存のコードを壊すことなく新しい機能を追加できることに関心があるはずです。

大学の私の主要な仲間を思い出させます。彼はVLSI設計クラスを受講していましたが、最初の宿題のために、幅約1ミクロン、長さ1マイルのコンポーネントを思いつきました。シミュレーションは完全に合格しました。

彼の批評家に対する彼の返事は、「私のたわごとが機能するということだけです」。

非常に良い規範はパレート原理です

80〜20ルールのプロジェクトの経験があり、非常にうまく機能しました。「完璧主義のためにどこで線を引きますか」というこの質問への答えも役立つと思います。

「パレート原理」という用語は、パレート効率を指すこともあります。 パレートの原理（80-20ルール、極めて少数の法則、および因子スパース性の原理としても知られています）では、多くの場合、効果の約80％が原因の20％から生じると述べています。 経営管理思想家のジョセフ・M・ジュランはこの原則を提案し、1906年にイタリアの土地の80％が人口の20％に所有されていることを認めたイタリアの経済学者ヴィルフレド・パレートにちなんで命名した。彼は、庭のエンドウ豆の鞘の20％にエンドウ豆の80％が含まれていることを観察することにより、原理を開発しました。ビジネスでは一般的な経験則です。たとえば、「売上の80％がクライアントの20％から来ている」などです。数学的には、参加者の十分に大きなセット間で何かが共有される場合、「参加者の（100-k）％がk％をとる」ように50〜100の数kが必要です。数kは、50（等しい分布の場合、つまり、人口の100％が等しいシェアを持つ場合）から100近く（少数の参加者がほとんどすべてのリソースを占める場合）に変化する場合があります。数学的に80％という数値については特別なことはありませんが、実際のシステムの多くは、この分布の中間的な不均衡の領域のどこかにkを持っています。 パレート原理は、同じエコノミストによって導入されたパレート効率に正接的にのみ関連しています。パレートは、人口間の収入と富の分配という文脈で両方の概念を開発しました。

ソースへのリンク

基本的に仕様を調査している間に書いたコードの書き直しを要求したとき、彼らはそれを否定しました。コードが複数の場所で繰り返され、カプセル化が行われず、人々がコードを変更するのに長い時間がかかったため、コードを書き直したかったのです。

違反はありませんが、マネージャーとして、私は次のようにどこかでその声明を読みました。

「すでに書いたコードを書き直すために2回支払われるように頼んだとき、会社は支払いたくなかった。最初に書いたときに作った混乱をきれいにするために余分なお金が欲しかった。同僚は自分の人生を難しくしていることに怒っていました。」

それがあなた自身のコードである場合、あなたは文句を言っています-あなたはあまり立つ必要がありません。

更新

私はこのPOVが人気がないことを理解しています。しかし、私もそれがプロの開発者の責任と態度とまったく矛盾しているとは思わない。

クリーンなコードを作成する場合（そして、これを行うには多くの理由があります-コードが実稼働で使用されるかどうかに関係なく）、この問題は定期的に発生します。

きれいなコードとリファクタリング時間を見積もりに含めると、コードベースを整理するスケジュールもできます。スケジュールのプレッシャーが原因で必要な時間が得られない場合、発生した技術的負債を処理した結果、将来の見積もりが上がるはずです。

ある時点で、将来の推定値（または推定値を取り巻く不確実性）を利用して、書き換えを主張することができます（マネージャーがプロセスの高速化を求めている場合）。そうでない場合は、ビジネスがあなたの見積もりを受け入れて、代わりに交換するよりも継続的なコストを支払うことを受け入れます。これは純粋にビジネス上の決定であり、技術的な決定ではありません。

スケジュールを交渉する時間は、コードを書く前であって、後ではないことを忘れないでください。コードが記述（および「機能」）した後、顧客、管理者、および幹部は、元のコストに近づくかそれを超える「メンテナンス」の別の請求書を見たくありません。あなたがビジネスについて思うほど強くそれを感じるなら、あなた自身の時間にそれを書き直してください-それはあなたがビジネスにそうするように頼んでいることです。

マネージャーの観点からすると、書き換えのスケジュールを設定すると、彼のお尻が一線を画します。あなたが届けることに失敗したとき、またはあなたが言うほどに生産性を上げたとき-彼はバッグを持って残った人です。あなたが不平を言うのは比較的マイナーな不便と比較して、彼がどちらを好むかを推測してください。

それがあなたが得ることができる仕事の種類であるなら、戻って古いコードを書き直すのではなく、毎回より良いコードを書くことに集中してください。サードパーティのパッケージを接着する領域内で移動できる品質範囲はまだあります。

時間があり、メンテナンスしている既存のコンポーネントのコードを改善したい場合、あなたがやっていることが機能する限り、許可を求めずにそれを行うことはできませんか？コンポーネントを使用する次のプロジェクトの見積もりに時間を考慮します。

低レベルのプログラミングの場合、作業から学習の満足度を得ることができない場合は、オープンソースプロジェクトを検討する時が来たでしょうか。

q303、あなたの質問がおもしろいと思ったので、開発者が技術的負債に対処できるようにマネージャーを説得する方法について、このプログラマーの質問を読む価値があると思うかもしれません。

私は一般的に、はい、それが標準だと思います。動作しているが最適ではないソフトウェアは、動作していないソフトウェアよりもはるかに優れていることを理解してください。「働く」の定義は、各個人の認識とバイアスに基づいて変わる可能性があるという議論もあります。新しいシステムを実装するとき、古いシステムの方が優れていると感じたと言う人が常にいます。そして、開発者と話をするとき、彼または彼女はくだらないソフトウェアに取り組んだことを認めたがらない可能性があります。