プリンシプルオブプログラミング ー 5 ~ 7 章 ー

第5章 習慣 〜プログラマのルーティーン〜

 

■三大美徳

・「怠慢」全体の労力を減らすために手間を惜しまない気質

 ー手動部分を自動化、手順を知って効果の大きいところから。

 ードキュメントはフォーマットを残す。検索にかかりそうなワードを入れる。

・「短気」コンピュータがサボっていることに怒りを感じる気質

 ー起こりうる問題を想定

・「傲慢」プライドを持って人に対して恥ずかしくないコードを書く

 

ボーイスカウトの原則

・担当した箇所のリファクタリング

ユニットテスト、目的に見合ったシステムのみ流用、不適切なライブラリの入れ替え

 

■パフォーマンスチューニングの箴言

・まずはいいコードを書く。その後、最適化を考える。

・いいコードは可読性が低かったりといいことばかりではない。

・コードよりまずは実行環境、デプロイまたはインストールの設定、ミドルウェア、ライブラリ、アーキテクチャを見直すべき。

・最適化する時でも、ホットスポットのみ直す。

 

■エゴレスプログラミング

・プライドを捨てて、ちゃんとレビューしてもらう。

 

■一歩ずつ少しずつ

・複数の作業を同時並行しない。こんがらがってしまう。

リファクタリングも複数をいっぺんにやらない。名前変更、場所の移動とか一つずつやっていく。

 

TMTOWTDI

・ツールを設計する場合には、やり方の選択肢を多く用意する。

 

 

 

ーー 第6章 手法 〜プログラマの道具箱〜 ーー

 

■曳光弾

・プロトタイプは作って捨てる

・曳光弾はその後も使われる土台を作る。

 

■契約による設計

・呼び出し側と呼び出される側の取り決め

・関数側では、引数の調整、ユーザーの入力チェックを行わない。

 

■防御的プログラミング

・外部ソースからのデータ入力の値を確認する。

・関数の入力引数の値を確認する。

 

ドッグフーディング

・ユーザー視点で使う。継続的に使う。

 

■ラバーダッキング

・問題解決が停滞したら、「誰か」にそれを説明する。無機物でもよい。

 

■コンテキスト

・コンテキスト ー 周りの状況や背景、文脈

・コードの読み書きと思考のツールにコンテキストを利用

・コードの読み書き

 ー モジュール名などの大きなくくりの名前で何について責任を持っているかを示す。その中に含まれている関数についても、そのモジュール名を文脈として、さらにその中で何について処理しているかを名前にする。

・思考のツール

 ー 細部にとらわれず大きな枠の中で把握する。

・コード共通化はコンテキスト志向で行う。同じコードでもコンテキストが異なるのであれば共通化しない。

 

 

ーー 第7章 法則〜プログラミングのアンチパターン〜 ーー

 

ブルックスの法則

・期日が迫っても要員追加しても解決しない。リスケしよう。

 ー教育に時間取られたり、依存関係によるオーバーヘッドが発生するから。

 

コンウェイの法則

アーキテクチャは組織の構造に従ってしまうので、アーキテクチャを決めた後に組織編成しよう。

 

■割れた窓の法則

・コードの良くない部分が放置されると、コードの腐敗が進む大きな要因になる。

・割れた窓はすぐに直すか、コメントしておこう。

 

エントロピーの法則

・コードは無秩序へ向かう

・コード腐敗の兆候を掴んで修正しよう。

 

■ 80-10-10 の法則

・高水準のツールや言語でソフトウェアを開発すると、ユーザーの求める80は短時間で実現できる。残りの10は骨をおって実現できるが、最後の10は実現できない。

・ツールは適材適所に用いる。

 

■ジョシュアツリーの法則

・チーム内共通言語であるユビキタス言語を使う。普段の会話にもコードにも用いる。

 

セカンドシステム症候群

・2番目のリリースは機能過多になりがち。ユーザー視点になって、本当に必要な機能を追加しよう。基本機能の改善を求めていることも少なくない。

 

車輪の再発明

・標準ライブラリ、オープンソースライブラリ、標準プロトコルがないか調べる聞く。

・ただ、ビジネス目的や学習目的であれば再発明はおっけー。

 

■ヤクの毛刈り

・問題を解決しようとすると、芋づる式に問題が現れ根本問題にたどり着けないことが少なくない。

・この状態になったら、目的を思い起こすこと。時間に見合うのかを考えること。