まとめ記事続きです。
個々のエッセイはクリエイティブ・コモンズでライセンスされています。
36.ハードワークは報われない
長時間仕事をすることは、プログラマにとってあまり良いことではない。
もし長時間仕事をしているようなら、効率化する方法を探すべき。
自分が担当しているプロジェクトへの理解を深めるだけではなく、
ソフトウェア技術やプログラミング技術について勉強することで作業を効率化できる。
仕事には長い時間をかけず、集中して短い時間で終わらせるように心がけ、
より効率的な問題解決方法を探す努力を常にすることが大切。
38.余分なコードは決して書かない
面白そうだったり、必要になるかもしれないコードは不要なコードである。
また、必要かどうか判断に迷ったり、要件をでっちあげたりしても不要なコードは増える。
不要なコードは動作速度を落とし、テストや保守にかかる時間を増加させるため、
書くべきではない。
YAGNIをはじめとするエクストリーム・プログラミングのプラクティスに従うこと。
39.最初が肝心
製品で大切なのは、ユーザが使い始める段階で躓かないように十分配慮すること。
簡単な操作で、すぐにその結果が得られるものが望ましい。
クイックスタートなどのガイドを作成するのも良い。
40.プロセス間通信とアプリケーションの応答時間の関係
応答時間が問題になった場合、データ構造とアルゴリズムが影響していることも多いが、IPC(リモートプロセス間通信)の数が
影響している事が最近は多い。
IPCの数を減らすには、プロセス間I/Fを最適化し、必要最小限のデータを取得したり、
IPCの並列化、以前の結果をキャッシュするなどの方法がある。
41.無駄な警告を排除する
ビルド時に警告が1つでも出たら、さほど重要でない警告でも、その場で潰すこと。
どう考えても大した問題にはつながらない警告の場合、警告をミュートすることを検討する。
余計な警告を即座に潰すことを続けていれば、意味のある警告かどうかを考える必要が無くなる。
また、他の人に仕事を引き継ぐのも簡単になる。
「ノイズ」をつぶし続ければ、真に意味のある警告が出たとき、それを見逃さずに済む。
ノイズを排除する目的はそこにこそある。