Clear Architecture

前章は匿名会社のデータを示しています.
データから見ると、時間が経つにつれて、ソフトウェアエンジニアの数は増加していますが、生産性はますます低くなっています.
ロバートC.Martin(ボブおじさん)はウサギとカメの寓話を例に愚かで、現代の開発者もウサギのような迷信を示しているという.
遅くても、根気よく続ければ勝つ.

足の速い人は試合に勝てないし、力の強い人が試合に勝つわけではない.

急いで

に戻ります
ボブおじさんは現代の開発者と寓話のウサギは変わらないと言った.

どうしてこんなことになったの?

コードは後で整理すればいいです.今では「まず上場する」というよくある嘘にだまされている.

私もそんな経験をしたことがありますか?→最初のプロジェクトの時最終期限になると、コードを先に配置すべきだと思います.だから、コードを曖昧に処理し、

をスキップしました.

の乱雑なコードを記述することは、短期的に迅速に完了することができ、長期的に見てこそ、生産性が低下する.
それをめちゃくちゃにすると、いつもきれいに保つより遅いです.→プロジェクトをしているときに見逃す.しかし当時はクラスメイトとのコラボレーションを学ぶという理由で開発され、結果的に二人が合わさって非常に悪いコードになった.そのため、ミスを解決するのに想像以上に時間がかかったのを覚えています.

実は、今回のEasterEgg機能も最初は汚いコードだったと思います.EliとBartのフィードバックはコードをより簡潔にし,TimerもActivityで処理したものをTimerクラスで処理し,Activityでのコードは非常に簡潔になった.

開発Jason Goldman(TDD)→テスト主導

以前入社初期にBartとEliがTDDについて話していると聞いたことがありますが、その時探してみましたが、

のテストを先にして、テストに合格するために書いたのを覚えています.

Clean Architectureを読んで再びTDDに向かいます

表を見せて例を挙げると、結果は面白いです.
言い換えれば、TDDを採用した開発方式は、TDDを採用しない開発方式よりも早く任務を遂行した.
ボブおじさんが例を見せてくれて、こんなことを言いました.

💡 빨리 가는 유일한 방법은 제대로 가는것.

二つの価値

最初の価値は「行動」です

プログラマーは、利害関係者が機能リストまたは要求ドキュメントを具体化するのに役立ちます.

2つ目の価値は「ソフトウェア」です

の本意を追求するには、ソフトウェアが「ソフト」でなければならない.→変更しやすいようにする.

アーキテクチャの特定の形式に対する好みは他の形式に対する好みより大きい→新しい機能を構造と一致させるのはさらに難しい

.

アーキテクチャは、形式から独立し、実用的である必要があります.

より高い価値?

機能ですか、アーキテクチャですか.

管理者に聞くと、動作が重要だと言います.
→ここで、私は、、、私は賛成して、しかし背後の誤った態度で、私は事例を聞いた.

変更できないコードは最終的に生成できないため、プログラムは役に立たない.

実際には,全く修正不可能なコードは存在しないが,実際には修正不可能なプログラムが存在する.
→修正費用が創造した収益を上回った場合.

アーキテクチャのために戦う

ここで、ボブおじさんは責任を果たすには戦いに入ると言った.
私は戦場に行ったことがありますか?うん、答えてないよ.
私もソフトウェアのセキュリティを保護する責任があることを覚えておいてください.
アーキテクチャが上位にランクされ、開発コストが高くなります.
実際には、システム全体を変更することは不可能です.