コードは常に書き換えられているので、コードを書き換える初期の反復の品質について心配することは無意味ですか？
大学では講師の一人が私が奇妙だと思ったアドバイスを主張していました。
この講師は、彼の生徒は、プログラミング言語の選択、ターゲットプラットフォーム、または実際に機能するプロトタイプの作成に必ずしも必要ではないその他の設計の選択などの決定についてあまり気にしないと主張しました。壊れていることがわかっているものを作ることは時間の無駄であり、仕事の無駄であると人々が抗議していたとき、講師は次のように主張しました：
プログラマーが気づいていないのは、コードが常に書き直されていることです。最も成功している企業（Googleなど）や製品（World of Warcraftなど）を見てください。彼らはコードを維持しておらず、書き換えています。 WoWのエンジンが書き換えられて新しいバージョンに置き換えられた回数は、すでにカウントされていません。プロトタイプが機能するようになれば、別のプログラミング言語で、要件が変更された場合でも、コードの書き換えは難しくありません。難しいのは、この実用的なプロトタイプを作ることです。ターゲットプラットフォームの要件を満たし、必要なパフォーマンスを達成するために、プログラミング言語を慎重に選択できます。コードの最初の反復の品質について心配することができます。その後、最初のイテレーションを書くのははるかに困難で時間がかかり、最終的に完了した後は、コードの品質が不十分であるにもかかわらずコードがどのように見えるかを判断することができないため、コードを書き直さなければならないことに気づくでしょう。変更された要件は言うまでもなく、最初にそれを書きます。代わりに、何も気にせずに、機能するプロトタイプを作成することにのみ焦点を当てます。次に、それを入手したら、コードを修正する方法と特定の要件に合わせてコードを調整する方法を情報に基づいて決定し、それに応じてコードを書き直します。今回は、その品質に配慮します。その後、リリースする前にもう一度書き直してください。製品が保守フェーズに入るのに十分成功した場合、比較的大きな変更が必要になったときはいつでも、定期的にコードを書き直すことになります。
特に、これは、プロトタイプのコードの品質をあまり気にしないで、Python好きならPython Pythonはターゲットプラットフォームでは使用できません。
（私は上記の講師の意見を要約しようとしました、私がそれらをよく理解していて、私がそれらを誤って伝えていないことを願っています）。
これは、常にコードの品質に最大限の注意を払うという通常の推奨事項の正反対であり、 この人気のあるエッセイ の正反対です。このアドバイスについて何が言えますか？
大学では講師の一人。
督促クルーガー効果 に苦しんでいる学者のように聞こえます。しかし、あなたは彼の発言のいくつかを誤って解釈したかもしれません。
プロトタイプが機能していれば、別のプログラミング言語で、要件が変更されていても、コードを書き換えることは難しくありません。
onlyが機能するプロトタイプを持っていて、そのプロトタイプがそれほど大きくない場合、コードを書き直します書き直すことはあまりないので、おそらくそれほど難しくありません。ただし、数か月および数年にわたって開発されたソフトウェアが成功し、ユーザーベースが安定すると、完全な書き換えはますます難しくなります。 1k LOC、20kLOC、または400k LOCを書き換えようとすると、違いが生じます。その知恵は、プログラミング言語からほとんど独立しています。そして、GoogleやMicrosoftのような主要なソフトウェア会社は、毎年すべての主要な製品のコードを一気に投入して、すべてをゼロから書き直すことはないと確信しています。それは単に経済的ではないでしょう。
この実用的なプロトタイプを作るのが難しいのは
最初のプロトタイプを作成することは、誰かが second-system effect の罠に陥らない限り、最初に作成したプロトタイプを2回目に作成するよりも確かに困難です。しかし、本当に難しいのはその後です。高品質で安定した製品を作ることです。そして、あなたはジョエル・スポルスキーを引用したので、彼にも引用させてください： 良いソフトウェアは10年かかります 。
代わりに、何も気にせずに、機能するプロトタイプを作成することにのみ焦点を当てます。次に、それを入手したら、コードを修正する方法と、特定の要件に合わせてコードを調整する方法を情報に基づいて決定し、それに応じてコードを書き直します。今回は、その品質に注意します。
もちろん、競合する市場に新しいアイデアを持ち込む場合、コードの品質よりも「市場投入までの時間」の方がはるかに重要であることがよくあります。プロトタイプは、デモ、マーケティング、概念実証のために重要です。最初のプロトタイプを完全に書き直されたバージョンに置き換えることは、最も賢明なアプローチかもしれません。プロトタイピング中にドアから物事を引き出すためにコードの品質が犠牲になったときにそれを書き直さないことは確かに大きな失敗かもしれません-しかし、多くの場合、開発者は上司にそれを納得させなければなりません。別のアーキテクチャに切り替えるチャンス。
製品がメンテナンスフェーズに入るのに十分な場合、比較的大きな変更が必要になったときはいつでも定期的にコードを書き直すことになります。
まず第一に、あなたは常にそのような製品のコードをリファクタリングします。また、小さなステップでそれらを進化させることが不可能または手頃な価格であると思われない場合は、その一部を随時書き換えることもできます。しかし、すべてをゴミ箱に捨てることを避けて、最初からやり直したいはずです。それを試みることは Joel Spolskyのエッセイ で既に述べられた一種のデスターにつながります。
この講師は、彼の生徒は、プログラミング言語の選択、ターゲットプラットフォーム、または実際に機能するプロトタイプの作成に必ずしも必要ではないその他の設計の選択などの決定についてあまり気にしないと主張しました。
この推奨事項は、少なくともこのユーザーにとっては問題ありません。大学では忘れないでください。生徒は通常、一部の商用製品の長期的な開発を開始せず、学習プロジェクトから始めます。それらの99,9％は、コードの品質とは関係なく破棄されます。
だからTLDR; 小さなプロトタイプに適用した場合、講師の発言のほとんどは彼の学術的環境で問題ありませんが、コードの品質を大きくするための推奨または言い訳として誤解しないでください。商用ソフトウェアシステム。
最後のメモ
... Python必要な場合Python対象のプラットフォームでPythonが利用できないことがわかっている場合でも。
Pythonは後者では使用できませんが、=を使用するのが理にかなっているターゲットプラットフォームとは非常に異なるプラットフォームでプロトタイプを作成する必要がある状況にどのくらいの頻度で遭遇しますか？ Python前者については？そのような状況は発生しないというわけではありませんが、これは私には非常に不自然に見えます。
これは私企業では非常に用心深いことです。私は何度も「クイックアンドダーティー」プロトタイプが導入され、その後「プロトタイプ」が完全に機能するソフトウェアとして販売されることに何度も遭遇しました。
多くの場合、このような状況では、最初から書き直すための時間がほとんどないため、プロトタイプに磨きをかけて出荷し、会社の収益に追加します。
簡単に言えば、プロトタイピングは本質的に少々ラフになる可能性がありますが、最終製品が何であるかを常に監視する必要があります。
プロトタイプを、それが出荷されるプラットフォームで利用できない言語で積極的にコーディングすることは、この問題を回避する方法のように思われますが、管理...
私が見つけたのは、2つの極端を提示すると、答えは通常、真ん中のどこかにあるということです。もう1つの優れた読み物は 大聖堂とバザール です。これは、表面的には教授の発言を反映しているように見えます。私はあなたの教授が取り組んでいたことの背後にある意図はこれだと思います：
どのように始めて何かを書くかについて心配するのをやめます。
分析による麻痺は、学生が陥る非常に現実的な問題です。それは彼らがあまりにも多くの理論を持っていて、十分な現実の世界の練習がないからです。実際に実践してみて、実際に機能するはずだと思うことが実際に機能するかどうかを確認します。
もし彼がそこで立ち止まったなら、混乱はなかったと思います。
明確にする必要があるいくつかのステートメントがあります：
- 現実のソフトウェアは定期的に書き換えられますが、教授のコメントが示すように定期的ではありません
- 学生のプロジェクトは、実際には芸術作品を意図したものではなく、放棄されたものであり、課題のために作成され、二度と触れられることはありません。
- 実際の製品にできると思う学校のプロジェクトから良いアイデアを見つけた場合は、それを念頭に置いて書くことをお勧めします
ただし、現実の世界では、他の人が作成したソフトウェアを保守する必要があります。それがあなたがやったであろう方法で行われていないという事実は、それが悪いか、または書き直される必要があることを意味しません。企業がソフトウェアを書き換えようとするとき、それは主に1つの理由によるものです。
現在のニーズを可能にするためにソフトウェアを書き換えるコストは、ソフトウェアに機能を詰め込むよりも少ないです。
私が知っているほとんどの開発者は、彼らが持っているスケジュールとスキルの制約の範囲内で可能な限り構造化および設計されたソフトウェアを書くことに非常に誠実です。彼らは反復的に作業する傾向があり、一度に少しずつ新しい機能を構築します。スケジュールが許せば、彼らは彼らが進むにつれてリファクタリングによってクリーンアップすることを好みます。残念ながら、スケジュールと経営陣からのプレッシャーは、「十分に良い」ソリューションでいくつかのコーナーを切り開くことを余儀なくさせています。スケジュールがなかった場合、リリースサイクルcouldは長すぎて競争力がありません。
あなたはそれを見つけるでしょう：
- あなたがそれを十分に早くやれば、ソフトウェアのほとんどの醜さは小さなリファクタリングで修正できます
- ちょうど十分要件に対応することに焦点を当てている場合は、必要に応じてクリーンアップできます
醜い作業用ソフトウェアは、美しく設計された非作業用ソフトウェアよりも常に優先されることを覚えておいてください。
「コードは常に書き直されている」という講師の発言を誤解されたと思います。
プロダクションコードにバグが見つかった場合、すべてを捨ててやり直すことはありません。バグを見つけ、修正し、テストし、配備します。そして、コードが判読不能な混乱である場合、これを行うのは非常に困難です。
つまり、プロトタイプコードと製品コードを区別することが重要です。概念を探求しているだけの場合は、プロトタイプコードの端が荒くても問題ありません。ただし、そのコンセプトが本格的な製品に変える価値があると判断した時点で、はい、安定性と保守性の観点からそれを書き直す必要があります。
講師の意見はばかげているように聞こえますが、文脈上は理にかなっています。
重要なポイントの1つは、「製品」がビジネス全体ではない可能性があることです。それは、ハックオーバーハックを構築する代わりに、書き換えが良いアイデアであるかもしれないほど小さいサービスの1つにすぎないかもしれません。これは、GoogleとWoWの両方に当てはまります。これらは巨大なモノリスではありませんが、相互に独立して書き換え可能な多数の小さな相互接続サービスで構成されています。これが、最近マイクロサービスが普及している理由です。各マイクロサービスを異なる言語または異なるスタックで構築することは、可能であるだけでなく、推奨されることです。ここでの問題は、ソフトウェアに関する多くの人々の経験が巨大な一枚岩であるということです。その場合、書き直しのアイデアは想像以上にクレイジーです。したがって、このような「必要に応じて書き換える」考え方を実現するには、製品全体を小さな疎結合のパーツに分割する必要があります。これは私たちの業界ではあまり一般的ではありません。
頭に浮かぶもう1つのことは、品質はコードの品質だけを意味するのではありません。ソフトウェアの品質は幅広い概念であり、コード、テスト、ドキュメンテーションなどが含まれます。テストはここで重要な部分です。コードに自動テストの強力なスイートがある場合、コードを書き直すのは簡単です。しかし、これもまた、無料で提供されるものではありません。優れたテストは高価で作成が困難です。しかし、それらを入手すると、コードはPuTTYと同じように柔軟になります。何も壊すことを心配せずに、アプリケーションの一部をリファクタリングしたり、完全に書き直したりすることは非常に簡単になります。そして、私はGoogleとWoWの両方に自動テストの大きなスイートがあると信じています。
要約すると、製品全体を疎結合の小さなユニットに分割し、それらのユニットの自動テストを構築および維持することに多大な労力を費やすことを確認すると、コードを大幅に変更したり、書き換えたりすることができるという考えは有効であり、さらには推奨されます。 。
もちろん、これは私の経験によって色付けされた私の解釈にすぎません。私は間違っているかもしれませんし、講師は本当にクレイジーで、彼の考えは持続不可能です。
彼はおそらく少し怒り狂ったかもしれませんが、それにはsome真実があります。
「分析-麻痺」：何かを開発するには非常に多くの選択肢と方法があり、最適なテクノロジーに適合するには長すぎると生産性が低下する可能性があります。おそらく、最初の「大丈夫」なものを選んだ場合、すべての可能なテクノロジーを評価するのにかかる時間までに、タスクはすでに完了しているでしょう。
「予期しない障害」。あなたはすべてを予見することはできません。また、最適な「ソリューション」を構築するために多くの時間を費やして、後で詳細が実際の問題を引き起こすことを発見した場合、その作業はすべて無駄になるか、非常に時間がかかります。初期のプロトタイピングを行うことは、落とし穴を含め、あなたの前にあるものを探るのに非常に良い方法です。
「早期復帰」。プロトタイプは、概念実証として非常に便利です。おそらく次回はそれをすべて（そしてそれ以上）書き直す必要がありますが、貴重な情報、フィードバック、それを改善する方法を手に入れました。時間がかかりすぎたでしょう。
「老化技術」。特に大規模なプロジェクトの場合、完成するまでに、多くのツール、テクノロジー、API、ライブラリが、現在のソリューションが時代遅れに感じられるところまで進んでいる可能性があります。私はかつて、巨大なコードベースをアセンブラーからC、そしてC++に移行した会社で働いていました。おそらく今はC＃であり、10年後にはそれも変わるでしょう。同様に、Java GUIはWeb技術に移植され、Web技術はネイティブモバイルなどに移植されます。
...だから、まあ、そうです、計画と実行の適切なバランスを見つけることです。
大きなプロジェクトの小さめ部分をプロトタイピングしているとき、講師のコメントは正しいです。
たとえば、次世代の遺伝子シーケンシング会社で働いていたとき、アルゴリズムの多くはpythonで開発されました。これは、データサイエンティストに精通していて、開発のスピードが速かったためです。 I/Oとデータ構造を正しくし、巨大なデータセットの処理速度とスペース要件を満たすために、ハッキングと実験を行いました。RまたはMatLabを使用することもありました。他にも多くのオプションがあります。
プロトタイプが機能した後、プロトタイプへの最初のインターフェースはコマンドラインを介して行われました。徐々に、時間の経過とともに、ほとんどがJavaで記述された「実際の」アプリケーションに変換され、より堅牢で保守可能と見なされ（この点については考慮しません！）、ソフトウェアに確実に馴染みました。エンジニア。
コードは常に書き換えられるわけではないので、すべてがすでに間違った仮定に基づいています。
時々、二度と二度と使用されないコードがある場合があります。結果が正しいことを確認できれば、品質は重要ではありません。ほとんどのコードはそうではありません。
プロトタイプを捨てて後で実際のコードを書くことを意図して、プロトタイプを書く人もいます。そして、ごみのプロトタイプが十分であり、品質が悪いと永遠に悩まされると経営陣が判断します。理論的には、これは起こらないはずです。実際には、理論と実践には違いがあります。
低品質があなたに影響を与えないが、他の誰かの問題であると100％確信していない限り、あなたが行うすべてのことは最初からまともな品質であることを確認してください。その方が安いです。