ソフトウェアプロジェクトの偶発的な複雑さを管理する方法

Murray Gell-Mannが、Richard Feynmanがどのように多くの困難な問題を解決したかを尋ねられたとき、Gell-Mannは、Feynmanにアルゴリズムがあったと答えました。

1. 問題を書き留めます。
2. 真剣に考えてください。
3. ソリューションを書き留めます。

ゲルマンは、ファインマンが別の種類の問題解決者であり、彼の方法を研究することから得られる洞察がなかったことを説明しようとしていました。中規模/大規模のソフトウェアプロジェクトの複雑さを管理することについても、同じように感じています。優れた人々は本質的にそれが得意であり、何らかの方法でさまざまな抽象化を積み重ねて積み重ねることで、無関係な問題を引き起こすことなく全体を管理可能にします。

ファインマンアルゴリズムは偶発的な複雑さを管理する唯一の方法ですか、それともソフトウェアエンジニアが偶然の複雑さを抑えるために一貫して適用できる実際の方法がありますか？

良い動きを見つけたら、より良い動きを探します。
—エマニュエルラスカー、27年の世界チェスチャンピオン

私の経験では、偶然の複雑さの最大の要因は、プログラマーが最初のドラフトに固執することです。これは、英語の作文クラスから学ぶことができるものです。彼らは、教師のフィードバックを取り入れて、課題のいくつかの草案を時間通りに作成します。何らかの理由でクラスをプログラミングすることはできません。

次善のコードを認識、明確化、および修正するための具体的かつ客観的な方法が満載の本があります。 クリーンコード、レガシーコードを効果的に使用する、および他の多くのコードです。多くのプログラマーはこれらの手法に精通していますが、必ずしもそれらを適用するのに時間がかかるとは限りません。彼らは偶然の複雑さを完全に減らすことができますが、試してみる習慣にしただけではありません。

問題の一部は、初期段階で査読を経ていない限り、他の人のコードの中間的な複雑さをあまり見ないことです。クリーンなコードは簡単に記述できるように見えますが、実際には通常いくつかのドラフトが含まれます。最初に頭に浮かぶ最善の方法を書き、それがもたらす不必要な複雑さに気付いてから、「より良い動きを探して」、それらの複雑さを取り除くためにリファクタリングします。それから、あなたは1つを見つけることができないまで「より良い動きを探して」続けます。

ただし、その解約までコードをレビュー用に公開しないため、外部的にはファインマンのようなプロセスである可能性があります。あなたはそのように1つのチャンクすべてを行うことはできないと思う傾向があるので、あなたはしようと気にしませんが、真実はあなたが読んだばかりの美しくシンプルなコードの著者であり、通常は1つのチャンクですべてを書くことはできませんそのように、または可能であれば、それは以前に何度も同様のコードを書いた経験があり、中間段階なしでパターンを見ることができるからです。いずれにしても、下書きを避けることはできません。

「ソフトウェアアーキテクチャのスキルを教えることはできません」というのは、広まっている誤りです。

多くの人々がそれを信じる理由を理解するのは簡単です（それが得意な人は、自分が神秘的に特別であると信じたい、そして、そうでないのは自分のせいではないと信じたくない人）。それにもかかわらず、間違っています。スキルは、他のソフトウェアスキルよりもやや実践的です（たとえば、ループの理解、ポインターの処理など）。

大規模なシステムを構築することは、偉大なミュージシャンや公の講演者になることと同じように、繰り返し練習し、経験から学ぶことができると強く信じています。ほとんどの開業医のリーチ。

複雑さへの対処は、何度か試して失敗することで大部分を獲得するスキルです。コミュニティが大規模なプログラミングのために発見した多くの一般的なガイドライン（レイヤーを使用し、頭の後ろで複製と戦い、宗教を0/1 /無限に固執する...）は、明らかに正しくなく、彼らが実際に大きな何かをプログラムするまで初心者。ほんの数か月後に問題を引き起こした重複に実際に噛まれるまで、そのような原則の重要性を単に「得る」ことはできません。

Andy Huntによる実用的な思考がこの問題に対処しています。これは、さまざまなスキルに5段階の習熟度があるDreyfusモデルを指します。初心者（ステージ1）は、何かを正しく行うために正確な指示を必要とします。反対に、専門家（ステージ5）は、特定の問題に一般的なパターンを適用できます。本を引用して、

専門家が自分の行動を細かいレベルで説明するのは難しいことがよくあります。彼らの反応の多くは非常によく実践されているので、彼らは意識不明の行動になります。彼らの広大な経験は、脳の非言語的で無意識の領域によって採掘され、それによって私たちが観察するのが難しくなり、彼らが明瞭に表現するのが難しくなります。

専門家が自分のことをすると、他の人にはほとんど魔法のように見えます-奇妙な呪文、どこからともなく見える洞察、そして私たちの残りがあまり確信がないときでも正しい答えを知る一見不思議な能力質問について。もちろん、それは魔法ではありませんが、専門家が世界を認識する方法、問題の解決方法、使用するメンタルモデルなどは、すべて非専門家とは著しく異なります。

さまざまな問題を見る（および結果として回避する）この一般的なルールは、偶発的な複雑さの問題に特に適用できます。この問題を回避するには、所定のルールセットを用意するだけでは不十分です。これらのルールでカバーされない状況は常に存在します。問題を予測したり、解決策を特定したりするには、経験を積む必要があります。経験は教えることのできないものであり、絶え間ない挑戦、失敗、成功、そして間違いから学ぶことによってのみ得られます。

Workplaceからのこの質問は関連性があり、私見はこの文脈で読むのが面白いでしょう。

あなたはそれを綴りませんが、「偶発的な複雑さ」は、「本質的な」複雑さと比較して、問題に固有ではない複雑さとして定義されます。「テイミング」に必要なテクニックは、どこから始めるかによって異なります。以下は、主に不要な複雑さをすでに獲得しているシステムを指します。

私は、「偶発的な」要素が「本質的な」側面を大きく上回り、そうでないものも含めて、複数の大規模な複数年のプロジェクトで経験を積んでいます。

実際、ファインマンアルゴリズムはある程度適用されますが、それは「真のハードを考える」が成文化できない魔法だけを意味するという意味ではありません。

取るべき2つのアプローチがあると思います。両方持ってください-彼らは代替ではありません。1つは断片的に対処することであり、もう1つは大幅な修正を行うことです。確かに、「問題を書き留めてください」。これは、システムの監査の形式を取る場合があります。コードモジュール、その状態（匂い、自動テストのレベル、それを理解すると主張するスタッフの数）、全体的なアーキテクチャ（「問題がある」場合でも1つ） ）、要件の状態など。

「偶発的な」複雑さの性質上、対処する必要のある問題は1つもありません。そのため、トリアージが必要です。システムを維持し、その開発を進める能力の面で、どこが痛いですか？いくつかのコードは本当に臭いかもしれませんが、最優先事項ではなく、修正を待つことができます。一方、リファクタリングに費やされた時間を迅速に返すコードが存在する場合があります。

より良いアーキテクチャとなる計画を定義し、新しい作業がその計画に準拠するようにします。これは漸進的なアプローチです。

また、問題のコストを明確にし、それを使用して、リファクタリングを正当化するビジネスケースを構築します。ここで重要なことは、適切に設計されたシステムがはるかに堅牢でテスト可能であり、その結果、変更を実装するための時間（コストとスケジュール）が大幅に短縮されることです。

大規模な手直しは「真剣に考える」カテゴリに含まれています。正しく行う必要があります。これは、「ファインマン」を持っていること（まあ、1つのうちのわずかな部分で十分です）が大きな成果を上げる場所です。より良いアーキテクチャをもたらさない大規模な手直しは災害になる可能性があります。これについては、システム全体の書き換えが有名です。

どのようなアプローチでも暗黙的に「偶然」と「必須」を区別する方法を知っています。つまり、システムとその目的を本当に理解している優れたアーキテクト（またはアーキテクトのチーム）が必要です。

そうは言っても、私にとって重要なことは自動テストです。十分な容量がある場合、システムは制御されています。そうしないと。。。

「すべてをできるだけシンプルにする必要がありますが、シンプルではありません。」
—アルバートアインシュタインによる

偶発的な複雑さを処理するための個人的なアルゴリズムをスケッチしてみましょう。

1. ユーザーストーリーまたはユースケースを作成します。製品所有者に確認してください。
2. 機能が存在しないために失敗する統合テストを作成します。チームにそのようなことがある場合は、QAまたはリードエンジニアに確認してください。
3. 統合テストに合格する可能性のあるいくつかのクラスの単体テストを作成します。
4. 書く最小限のユニットテストに合格し、それらのクラスの実装を。
5. 仲間の開発者とユニットテストと実装を確認します。ステップ3に進みます。

設計全体の魔法は、ステップ3にあります。これらのクラスをどのように設定しますか？これは、次の質問と同じ質問になります。問題の解決策を得る前に、問題の解決策があるとどう思いますか。

驚くべきことに、あなたが解決策を持っていると想像することは、問題解決について書いている人々の主な推奨事項の1つであるようです（コンピュータープログラムの構造と解釈、およびPolyaのHow toそれを解決する）

一方で、誰もが同じ「想像された解決策の好み」を持っているわけではありません。あなただけがエレガントだと感じる解決策があります。そのため、コードを仲間の開発者とピアレビューする必要があります。パフォーマンスを調整するためではなく、理解されたソリューションに同意するためです。通常、これは再設計につながり、いくつかの反復の後、はるかに優れたコードになります。

テストに合格するための最小限の実装の作成に固執し、多くの人々に理解されているテストを作成する場合は、軽減できない複雑さのみが残るコードベースで終了する必要があります。

偶発的な複雑さ

元の質問（言い換え）は：

アーキテクトは、ソフトウェアプロジェクトの偶発的な複雑さをどのように管理しますか？

プロジェクトを指揮する人々が一時的なテクノロジーを追加することを選択し、プロジェクトの元のアーキテクトの全体的な戦略がプロジェクトに持ち込むつもりがなかった場合、偶発的な複雑さが生じます。このため、戦略の選択の背後にある理由を記録することが重要です。

戦略からの意図的な離脱が明らかに必要になるまで、元の戦略に固執するリーダーシップにより、偶発的な複雑さを抑えることができます。

不要な複雑さの回避

質問の本文に基づいて、次のように言い換えます。

アーキテクトはソフトウェアプロジェクトの複雑さをどのように管理しますか？

この言い直しは、ファインマンアルゴリズムが持ち込まれた問題の本文により適したものであり、問​​題に直面したときに最高のアーキテクトが解決策を巧みに構築するゲシュタルトを持つことを提案するコンテキストを提供します。私たちの残りはこれを学ぶことを望んでいないことを。理解を得るかどうかは、対象の知性と、対象の範囲内にある可能性のあるアーキテクチャオプションの機能を学習する意欲に依存します。

プロジェクトの計画プロセスでは、組織の学習を使用してプロジェクトの要件のリストを作成し、すべての可能なオプションのリストを作成してから、オプションと要件を調整します。専門家のゲシュタルトにより、彼はこれを迅速に、そしておそらくほとんど明白な作業をせずに行うことができ、彼に簡単に来るように見えます。

彼の準備のために彼に来ることをあなたに提出します。専門家のゲシュタルトを得るには、すべてのオプションに精通している必要があり、プロジェクトが提供する必要があると判断された予測される将来のニーズに対応する簡単なソリューションを提供する先見性と、変化するニーズに適応する柔軟性が必要ですプロジェクト。ファインマンの準備は、理論と応用数学と物理学の両方でさまざまなアプローチを深く理解していたことでした。彼は本質的に好奇心が強く、周囲の自然界について彼が発見したことを理解するのに十分な明るさ​​でした。

専門技術アーキテクトは同様の好奇心を持ち、基本の深い理解だけでなく、多種多様な技術への幅広い露出を利用します。彼（または彼女）は、ドメイン（Unixプログラミングの原則など）で成功している戦略と、特定のドメイン（デザインパターンやスタイルガイドなど）に適用される戦略を活用する知恵を持っています。彼はすべてのリソースを熟知しているわけではありませんが、リソースの場所を知っています。

ソリューションの構築

このレベルの知識、理解、および知恵は、経験と教育から引き出すことができますが、偶発的で不必要な複雑さを回避する方法で連携するゲシュタルト戦略的ソリューションをまとめるには、知性と精神活動が必要です。これらの基礎をまとめるには専門家が必要です。これらは、最初に用語を作り出したときにドラッカーが予見した知識労働者でした。

特定の最終質問に戻ります。

偶発的な複雑さを抑えるための具体的な方法は、次の種類のソースにあります。

• Unixプログラミングの原則
• デザインパターン
• およびスタイルガイド（PythonのPEP 8など）

Unixプログラミングの原則に従うと、よく機能し、一般的なインターフェイスで堅牢なシンプルなモジュール式プログラムを作成できます。次の設計パターンは、必要以上に複雑ではない複雑なアルゴリズムの構築に役立ちます。以下のスタイルガイドは、コードが読みやすく、保守しやすく、コードが記述されている言語に最適であることを保証します。専門家は、これらのリソースに見られる原則の多くを内部化し、それらをまとまりのあるシームレスな方法でまとめることができます。

これは数年前には難しい質問だったかもしれませんが、最近では偶発的な複雑さを排除することはもはや難しくありません。

ケント・ベックサイは、ある時点で、「私は素晴らしいプログラマーではありません。私は素晴らしい習慣を身につけた優れたプログラマーです」と言っています。

IMOを強調する価値が2つあります。彼は自分をアーキテクトではなくプログラマであり、知識ではなく習慣に焦点を当てています。

難しい問題を解決するファインマンの方法は、それを行う唯一の方法です。説明は必ずしも理解しやすいとは限らないため、詳しく説明します。ファインマンの頭は知識だけでなく、その知識を応用するスキルもいっぱいでした。知識とそれを使用するスキルの両方がある場合、難しい問題を解決することは難しくも簡単でもありません。それが唯一の可能な結果です。

偶然の複雑さを含まない、完全に非魔法的なクリーンなコードの記述方法があります。これは、ファインマンがやったこととほぼ同じです。脳のどこかで、きれいなコードを書いてください。

現在、多くのプログラマーは、クリーンなコードを書くために必要なすべての知識さえも認識していません。若いプログラマーはアルゴリズムとデータ構造に関する知識を捨てる傾向があり、ほとんどの古いプログラマーはそれを忘れがちです。または、大きなO表記と複雑さの分析。古いプログラマーは、パターンやコードの匂いを無視する傾向があります-または、それらが存在することさえ知りません。世代を問わず、ほとんどのプログラマーは、パターンについて知っていても、使用するタイミングとドライバーの部分を正確に覚えることはありません。世代を問わず、SOLID原則に照らしてコードを常に評価するプログラマーはほとんどいません。多くのプログラマーは、あらゆるレベルの抽象化をあらゆる場所でミックスしています。現時点では、リファクタリングの本でFowlerが説明しているステンチに対して自分のコードを絶えず評価しているプログラマーの仲間はいません。プロジェクトによってはメトリックツールを使用するものもありますが、最もよく使用されるメトリックは何らかの複雑さです。一方、他の2つのメトリック（結合と結合）は、クリーンなコードにとって非常に重要であっても、ほとんど無視されます。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。最もよく使用されるメトリックは、ある種または別の複雑さです。一方、他の2つのメトリック（結合と結合）は、クリーンなコードにとって非常に重要であっても、ほとんど無視されます。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。最もよく使用されるメトリックは、ある種または別の複雑さです。一方、他の2つのメトリック（結合と結合）は、クリーンなコードにとって非常に重要であっても、ほとんど無視されます。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。一方、他の2つのメトリック（結合と結合）は、クリーンなコードにとって非常に重要であっても、ほとんど無視されます。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。一方、他の2つのメトリック（結合と結合）は、クリーンなコードにとって非常に重要であっても、ほとんど無視されます。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が困難であることを認識している人はさらに少なく、これは通常、悪いファクタリングを示しています。わずかな少数派は、矛盾が今後問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。ほとんどすべての人が無視するもう1つの側面は、認知負荷です。単体テストをドキュメントとして扱うプログラマーはほとんどいません。また、単体テストの記述や命名が難しいことを認識している人はほとんどいません。わずかな少数派は、矛盾が将来的に問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるためのドメイン駆動設計のマントラを知っています。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。矛盾は今後の問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるというマントラ。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。矛盾は将来的に問題を引き起こす可能性があるため、コードモデルとビジネスドメインモデルを可能な限り互いに近づけるというマントラ。コードをきれいにしたい場合は、これらすべてを常に考慮する必要があります。そして、私が今思い出すことができない多くのこと。

きれいなコードを書きたいですか？魔法は必要ありません。必要なものをすべて学習し、それを使用してコードのクリーンさを評価し、満足するまでリファクタリングしてください。そして、学習を続けます-ソフトウェアはまだ若い分野であり、新しい洞察と知識は速いペースで獲得されます。