プロジェクトが書き直される理由と失敗する理由

古くからのテーマ-アクティブなユーザーベースで大規模で実用的な製品を書き直すことはできますか、できませんか？一般的に、答えは次のようになります-はい、できます。唯一の質問はどのようにですか？過去にそのような試みをいくつか見てきましたが（成功した場合とそうでない場合の両方）、この記事はこの問題に関する著者の見解です。

悪いコード、過度に複雑なビルドプロセス、時代遅れのテクノロジー、ひどいプログラミング言語-これらすべての問題、およびその他の多くの問題は、十分に成功したすべての大規模プロジェクト、あらゆる組織のあらゆるソフトウェア開発プロセスに付随します。実践が示すように、ほとんどの場合、状況は時間とともに悪化するだけです。小さな不便が不快な「作業の特徴」に発展し、タスクを計画するときにスコアが絶えず増加し、完成品の品質が低下し始めます。この図の最後の仕上げは、デバッグ機能、またはそれを作業環境に配信することさえ不可能であるために、期限と計画を達成できないことです。多くの場合、そのような状況では、技術的負債が蓄積されていると言います。

この負債は完全に自然な方法で発生し、製品自体、そのユーザー、それらとの通信チャネルが存在する場合、どんなに成功したとしても、すべてのシステムを追求します。製品が直接販売されているか、会社の事業の補助的な部分であるかは関係ありません。それが長い間運用されていることが重要です。開発部門は締め切りのプレッシャーにさらされて必要な変更を実装するため、ユーザーは新しい機能を取得したいと考えています（おそらく、料金を支払うこともあります）。このプロセスは何度も繰り返され、遅かれ早かれ誰かが大声で言うでしょう-「私たちは借金を抱えているようです、おそらく技術的なものです！」

新しいタスクはそれぞれ前のタスクよりも難しいことに誰もが気づき始めました。これはもはや偶然ではなく、複雑さが指数関数的に増大しています。コードには触れない方がよい「壊れやすい」場所があり、多くの場合、ユーザーからの欠陥や、作業環境の「到着」を監視するためのシステムからのアラームがあります。第一に、製品全体の品質を向上させるために設計された新しい技術や慣行を導入するためのイニシアチブは延期され、その後完全に忘れられます。何かがうまくいかないという一般的な考えが形成され、何が起こっているのか、誰が責任を負うべきかについての調査が始まります。もちろん、この状況では良いことは何もありません。それ以上に、ネガティブなことがチームの雰囲気を害し始めます。

, , — , , , , , , , , , , .

, , , , , , . , — , ? , .

, . , . , , , - — , ? , ? ? , ? . , , , , — , . — .

— , , , , . , , . — . , IDE , , . .

— , :

• , ? - , .
• - , - , .
• , , .
• , .
• , , , , .
• - , , .
• , - , .

, — , , . . , — , , . , — , , .

. , , . — , . — . — ? .

“ ?”. ! , 100% — , - , , . , , , — 50/50, 60/40, . — , , .

, , — , , . ! ! ! — . .

, , — , .

, — , , , — . , — ? , , . , Flash — , , . , , — . , , , .

. — , , — , . , , . , … , .

, . , , , , , . , , - . , , , — , , , , “ ”, . ? , , . , , , — .

? — . , — . , , , . , .

— , : , , , .. , , . , , , . . , , , , , — , . , — , . — , . — , , , , .

— , , , . . , , , . , , , , — .

, , . — , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .

, , . . , . , API. http- . — , - , offline-, - Selenium-, UI, . , API.

, , . — . , . API , , -, ? , ? , , — , — .

. , , , , — . , , — . , :

1. ,

- ? - — . — , . “, ”: “ , , , , ”. , , “ ” , , , — , “” , . , ?

, — , API, .. — , - . . , , , , , , . , , .

, . — , , , . , , , , , , , , . , — , . , , - , , , , . , , , , , , — , . .

— , , . , , , , : , , . — , .

, , , , — , . , — , .

, , - . . — “”, “”. , , .

, , , . , , web-, , — , . , , , — “”? ? , ? , . , , ?

, , , — . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .

, — , . , , , . , , , , . , (-, ) . , . , .

. , , . — , , , , . , . — , , — .

P.S.

もちろん、上記のすべては、アクティブなユーザーベースを持つ大規模で機能するソフトウェア製品に適用されます。そして、たとえばBasecampやいわゆるすべての製品のように、古いバージョンと一緒に新しいバージョンの製品を単にリリースすることが不可能な場合にのみ。「箱入り」ソフトウェア。