「Clean Coder」から学ぶプロのエンジニアの思考

【結論】

・プロ意識とは、自分で責任を取ること。バグのないソフトウェアを作るのが難しいからといって、君に責任がないわけじゃない。

・バグが無いか確認するには、あらゆる方法で何度もテストをする必要がある。

・スケジュールや納期がある中でテストを行うには、テストの自動化は必須である。テストを自動化しやすく設計するには、TDD（テスト駆動開発）が効果的である。

【目次】

【本題】

「プロ意識」について

本書では、プロ意識について「自分で責任を取ること」という主張がなされています。

顧客や雇用主が欲するソフトウェアを開発するのがプログラマの責任なので、バグを生み出すことはあってはならない。

バグのないものができないほど、ソフトウェアは複雑なものである。

但し、バグのないソフトウェアを作るのが難しいからといって、君に責任がないわけじゃない。

したがって、プロ意識を高めるために最初に心がけることは、謝罪だ。

もちろん謝罪すればよいのではなく、同じ間違いを何度も繰り返してはいけない。

道を究めていけば、自ずと間違いの割合もゼロに近づく。ゼロに近づける責任がある。

バグを生み出さない工夫

バグを生み出さない為には、主に以下３点に注意する必要がある。

・不具合のありそうなコードを放置しない

不具合のありそうなコードとは、詳細がわからないコードである。

不具合のありそうなコードを、そのままQAに渡してしまうのは、プロ意識に欠けた行為である。

QAやユーザーが問題を発見した場合には、思いもかけないことだと驚き、心の底から悔しがり、次回は絶対に問題を起こさないと決意しなければいけない。

・テストを行う

バグが無いか確認するには、あらゆる方法で何度もテストをする必要がある。

スケジュールや納期がある中でテストを行うには、テストを自動化するしか無い。

テスト範囲に関する著者の主張は、かなり過激だ。

自動ユニットテストって、どのくらいのコードをテストすればいいのか？　その質問に答える必要があるのか？全部だ！ぜ・ん・ぶ。

「カバレッジを100％にしたほうがいいということだろうか？　した方がいいじゃない。そうしろと言っているんだ」

テストしにくいコードもあるという声もあるが、それはテストしにくい設計になっているからである。

テストしやすい設計に変えればいい。いちばんいいのは、最初にテストを書いて、そのテストを成功させるコードを書くテスト駆動開発（TDD）を実践することであるというのが著者の意見である。

・ソフトウェアは柔軟に変更できる状態を保つ

ソフトウェアを安定して運用するには、柔軟に変更できる状態を保つ必要がある。

変更しやすくするには、実施に簡単な変更を行って、思ったより変更が難しければ、次の変更が簡単になる様に設計を改善すればよい。

こうした変更を継続的に行うことで、ソフトウェアの柔軟性は向上する。

但し、多くの開発者がコードを継続的に変更するのを怖がるのはなぜか？それは壊れるのが怖いからだ。

なぜ壊れると思うのか？テストがないからだ。テストがあれば、コードを変更するのを怖れることは無くなる。

心構え

・ドメインを知る

会計システムを作るなら、会計の知識が必要。旅行アプリなら旅行業の知識が必要というように、ドメインを知らないと開発は行えない。

新しいドメインのプロジェクトが始まる時には、関連書籍を１〜２冊読んでみよう。

・雇用主や顧客に対して親身になる

雇用主の問題は自分の問題だ。だから問題を理解して最善の解決策を見出さなければいけない。

雇用主や顧客を敵視するのは簡単だが、プロならば避けたい。

・謙虚

プログラミンは、無から有を生み出す創造的な行為であり、自身たっぷりに機械に正確で詳細な命令を下す傲慢な行為である。

自分が傲慢であり、謙虚では無い事を認識しないと、間違いを修正できない。

プロが備えるべき最低限のこと

・デザインパターン：GOFの24のパターンについて説明できる。POSAのパターンを実際に使える知識がある。

・設計原則：SOLID原則を知っている。コンポーネントの原則を熟知している。

・方法論：XP・スクラム・リーン・カンバン・ウォーターフォール・構造化分析・構造化設計を理解している。

・規律：TDD・オブジェクト指向設計・構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している

・成果物：UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・ディシジョンテーブルの使い方を知っている

「ノー」と言う

「ノー」と言わないことで、対立関係を生み出すことを回避できるが、それが実現できなかった場合、組織に損失を与えてしまう可能性がある。

特に失敗のコストが高く、企業の存続がかかっているのであれば、できる限りの情報を伝えなければならない。

実現困難なことには「ノー」と言う。

その上で、利害関係者全員にとって最善の成果を生み出すような、「イエス」と言える様な創造的な方法を懸命に探さなければいけない。

プロが「イエス」と言う時には、確実に約束したとわかる様な約束の言葉を使っている

やるか、やらぬかじゃ。試しなどいらん

集中力を維持する

コーディングには高いレベルの集中力が必要になる

疲れている時にコードを書いてはいけない

プライベートの問題はオフィスで悩まない様に、心配事を解決する時間を確保する

フロー状態は、生産性が高いと感じるかもしれないが、実際は理論的な能力やスピード感覚が落ちている軽いめいそう状態と言える。

フローに入ると大局観を失い、やり直しの必要な意思決定をしてしまうリスクが高まる。

なので、フローに入ったと感じたら、数分間遠ざかる様にする

気が散ったり時間を失ったりする様な割り込みは避けられない。そういった時に、不機嫌な態度で対応していないだろうか？

これはフローと関連がある。フローから引きずり出された様で不快に感じるのだ。 集中力が必要な事を一人で理解しようとするのが問題

割り込み対策 ペアプログラミング TDD

誰かが自分の作業に割り込んだとしても、自分も同じく割り込むかもしれないと考え、親切に快く手伝おう

TDD（テスト駆動開発）

TDDには効果があり、みんなが取り組まなければいけないというのが著者の主張。

TDDには３つの原則が存在し、それに基づいて実施すれば、大きな恩恵が得られる。

三原則

・失敗するユニットテストを書くまでプロダクションコードを書いてはいけない

・テストを失敗させる目的以外でユニットテストを書いてはいけない。なお、コンパイルできないのも失敗に含まれる

・失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはいけない

TDDによって得られる効果は、以下のように定義されている。

・確実性　テストが成功すれば、他の部分を壊していないことがある程度確信できる

・欠陥混入率　バグの混入率が大幅に減る研究結果がある

・勇気　コードを壊すのを恐れて、変更をしないという愚を犯さずに済む

・ドキュメント　原則に従って書かれたテストはシステムの使い方を説明したサンプルコードにもなる

参考情報

書籍「Clean Coder プロフェッショナルプログラマへの道」

《今日の学習進捗（3年以内に10000時間に向けて）》

Ruby silverの受験に向けて、少しづつ勉強中。

今日は先輩と一緒にボルダリングしたので、勉強時間は少なめ。

学習開始からの期間 ：205日
今日までの合計時間：1986h
一日あたりの平均学習時間：9.7h
今日までに到達すべき目標時間：1872h
目標との解離：114h
「10,000時間」まで、

残り・・・「8014時間！」