Clean Craftmanship

https://scrapbox.io/files/636cc317c19f03001d1dfcf2.png

クラフトマンシップとは、何かをうまくやる方法を知っている状態である

規律とは何か？　規律とは「本質的な部分」と「任意の部分」で構成される一連のルールである。

協力的プログラミングとは、ソフトウェアチームが協力する規律と技芸である。サブの規律として、ペアプログラミング、モブプログラミング、コードレビュー、ブレインストーミングなどがある。協力的プログラミングには、プログラマーであるかどうかに関係なく、チームの全員が参加する。知識を共有し、一貫性を確保し、チームを一致団結させるための主要な手段である。

「 動かしてから、正しくする」

作成しているプログラムが有限状態機械だと知っていただろうか？　すべてのプログラムが有限状態機械である。なぜならば、コンピューターは有限状態機械のプロセッサだからだ。コンピューターは実行する命令によって状態を遷移しているのである。

アウトサイドインの設計アプローチに従えば、ユースケースごとにユーザーインターフェイスからビジネスルールへ向かって設計する。使用しているアルゴリズムが内側へ向かうことができるように、すべての境界でモックとスパイを使用する。最終的には、ビジネスルールに到達し、ビジネスルールを実装し、ビジネスルールをデータベースに接続する。そして、やって来た道筋をモックとスパイでテストしながら、ユーザーインターフェイスまで戻る。

シカゴ学派では、ひとつのユースケースが終わるまで次のユースケースに着手しないということがない。ユーザーインターフェイスを使うことなく、値とプロパティのテストを使用して、いくつかのビジネスルールを実装する。ユーザーインターフェイスやビジネスルールとの間のレイヤーについては、必要に応じて実装する。<snip>ビジネスルールをデータベースまで持っていくことがない。

ボブおじによれば全体像が明確になるのでインサイドアウトの設計が良いという意見

データベースのテストの最初のルールは「データベースをテストするな」である。データベースをテストする必要はない。データベースが動作していると想定すればいい。データベースが動作していなければ、すぐにわかるはずだ。<snip>テストしたいのはクエリである。というより、データベースに流すコマンドが適切かどうかをテストしたい。

壊れやすい問題は常に設計の問題である。ひとつのモジュールに小さな変更を加えたときに、他のモジュールにも多くの変更を加える必要があるとしたら、明らかに設計に問題がある。実際、設計が貧弱であることの定義は「小さな変更で多くの部分が壊れてしまう」である

TDDの規律を実践するときには、テストは具体化、本番コードは一般化する

関数の名前の長さはスコープに反比例することを覚えておこう。パブリックな関数の名前は比較的短くしておこう。プライベートな関数の名前は長くしておこう。

プロフェッショナルの誇り

技術的にリリースできる状態とは、ビジネス側がリリースしたい状態であるとは限らない。技術的にリリースできるソフトウェアであっても、ビジネス側が求める機能を満たしていなかったり、顧客やユーザーにとって不適切であったりする可能性がある。技術的に準備ができているとは、ビジネス側がリリースを決めたときに、開発チーム（QAを含む）が反対しないという意味である。ソフトウェアが動作して、テストされて、ドキュメント化されて、デプロイの準備が整っていることである。

自動テストはユーザーインターフェイス経由でビジネスルールをテストしてはならない。ユーザーインターフェイスはビジネスルールではなく、流行、便宜、マーケティングの混乱に関わる理由で変更されやすい。自動テストをユーザーインターフェイス経由で実行していると<snip>テストは非常に壊れやすくなり、保守できないテストとして破棄されてしまう。

車を運転しているときに他のドライバーを怒鳴りつけたことはないだろうか？　これは「フロントガラス効果」と呼ばれる。フロントガラスを挟むと、他人のことをバカ、マヌケ、敵だと見なすようになる。人間として扱わなくなるのである。コンピューターの画面にも（程度は低いものの）それと同じ効果がある。