まとめ記事続きです。
個々のエッセイはクリエイティブ・コモンズでライセンスされています。
71.パフォーマンスへの道は地雷コードで敷き詰められている
パフォーマンスチューニングを失敗すると、スケジュールなどが大打撃を受ける。
事前に防ぐためには、ソフトウェアメトリクスを利用して、日常的に計測・改善する必要がある。
深刻な悪影響を引き起こす前に、コードの地雷を発見し、排除することが必要。
72.シンプルさは捨てることによって得られる
悪いコードは残していても何の役にも立たないことが多い。
質が悪いコードは無理に残そうとせず、書き直したり、全部捨てて一から書き直したほうが良い。
余計な要素を減らし、必要最小限のコードだけ残すようにすれば、自然とシンプルで分かりやすくなる。
73.単一責任原則
「変更する理由が同じものは集める、変更する理由が違うものは分ける。」はデザインの基本原則です。
システムのコンポーネントがそれぞれ独立してデプロイできるようにしておくと、あるコンポーネントに変更を加えることになった場合でも、他コンポーネントの再デプロイは不要となります。
74.「イエス」から始める
要望を全て「ノー」ではねつけるのではなく、「イエス」という返答から始めるようにすれば、物の見方は大きく変わります。
バカバカしい要望でも、「なぜ必要なのか」を聞けば、理由を聞いてから判断することができ、良い結果に繋がります。
最終的には要望に応えないとしても、きちんと説明をすることができ、実りのある会話となるでしょう。
「イエス」から始めれば、人との対立は生まれず、協力関係が生まれるのです。
75.面倒でも自動化できることは自動化する
作業を自動化することで、面倒から解放されるだけでなく、時間短縮、正確さの向上にもつながります。
常に同じ環境でビルドを行えるようにすれば、環境の違いによる動作差異も無くなります。
学ぶ時間が無くても、自動化を進めながら勉強するとすれば問題ありません。
自動化が1度でもうまくいけば、時間と労力を投資するだけの価値があると理解できるはずです。