gogoLabyrinth

より良いコーディングを目指した様々な良い本を読んでいますが、今回は、プログラマーのバイブルの一つである新装版の『達人プログラマー』を読んでみました。

『リーダブルコード』に比べると、結構読みにくい本ですが、著者は「身につけた解決策を数年間かけて書籍にした」と言っており、凝縮されたノウハウを学べると思います。

直交性

• 「直交性」とは幾何学の分野から拝借してきた用語
• グラフの座標軸のように直角に交わる2つの線分
• 2つの線分はベクトルの分野では独立している
• 片方の線分を伸ばしていっても、もう一方に射影された位置は変わらない
• コンピューティングの分野では、ある種の独立性、あるいは分離性を表している
• 2つ以上のものごとで、 片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶ
• うまく設計されたシステムでは、データベースのコードはユーザーインタフェースと直交している
• つまりデータベースに影響を与えることなくインタフェースを変更したり、インタフェースを変更することなくデータベースを交換できたりする

ドキュメント

• 直交性という考え方はドキュメントにも適用できる
• 軸は記述内容とその表現
• 本当に直交しているドキュメントでは、記述内容に変更を加えることなく、その見栄えを劇的に変更することができる
• スタイルシートやマクロ機能によってそれを可能にする

直交性とのつきあい方

• 直交性はDRY原則と密接に関係している
• DRY原則は、システム内の二重化を最小限に抑えることを目的とする
• 直交性は、システムのコンポーネント間の依存関係を最小限に抑えることを目的とする
• 直交性の原則とDRY原則を緊密なかたちで結合すれば、システムはより柔軟で、より理解しやすいものとなり、デバッグ、テスト、維持もより容易なものとなる

見積もり

• 見積もりは、使用する単位によってその精度が異なって感じられる
• 約130日かかると言うと、それが当たらずとも遠からずという印象を人に与える
• 約6ヶ月かかると言うと、ほとんどの人は5ヶ月から7ヶ月かかると感じる
• どちらの見積もりも同じ期間を表しているにもかかわらず、130日は思っている以上に精度の高い見積もりになる
• 伝達したい誤差に見合った単位を選ぶ

解説しないほうがよい場合

• 靴紐の結び方を説明するのは難しいが、意識することなしに靴紐は結べる
• マイクロマネジメント効果にならないようにする
• マイクロマネジメントは、部下の主体性を奪い、上司と部下の信頼関係を損ない、組織全体のパフォーマンスを低下させるという大きな弊害がある
• コーディング担当者による知的活動を拒否してしまうような設計は、スキルや技芸といったプログラミング努力を奪い去ってしまう
• 「仕様書にはこうしろと書かれていたけれど、別なやり方だと同じ結果を半分の時間で実現できるのに」といったことを考えるはず
• 過度に規定された設計があると勝手に変更することができないため、さまざまな機会を逸してしまう
• 仕様書の記述をこれ以上詳細にしてもメリットが生まれない、あるいはメリットが失われる
• 仕様書を長くすればするほど、柔軟なコードの製造が難しくなる

要求の洗い出し、設計、実装という作業は単一のプロセス

• 要求を洗い出し、仕様を記述した後で、コーディングを開始するというすべての工程を独立せず、シームレスなアプローチを採用すべき
• 仕様書の作成と実装は、要求を洗い出して体系化していくという、一つのプロセスが持つ異なった側面を見ているに過ぎない
• それぞれの作業は人為的な境界を設けることなく、そのまま連続していくべきもの
• 健全な開発プロセスでは、実装やテストから仕様化プロセスへの自然なフィードバックが生み出される

職務権限ではなく、機能によってチームを編成する

• プロジェクトの諸活動 (分析、設計、コーディング、テスト）を別のものとして独立させるという考え方は誤っている
• 同じ問題でもさまざまな違った観点があるため、それを人工的に分割してしまっては問題を発散させてしまう
• 実際のユーザーから数階層離れたプログラマーは、自分たちのコードが実際に使用される際のコンテキストについて、あまり注意を払わないようになる
• 機能によってチームを編成するほうが優れている

内部向けドキュメントと外部向けドキュメント

• 内部向けドキュメントには、ソースコードのコメント、設計、テストドキュメントといったものが含まれている
• 外部向けドキュメントとは、ユーザーマニュアルのような外の世界に向けて出荷あるいは公開されるすべてのドキュメント
• 想定される読み手や書き手の役割 (開発者やテクニカルライター) にかかわらず、すべてのドキュメントはコードを反映したものになっているはずであり、矛盾があったとしたら、どんな場合であれ、それはコードの問題へとつながっていく

すべてはドキュメント

• 達人プログラマーはドキュメントを開発プロセス全体と切っても切れないものとして捉えている
• ドキュメントを手近なところ (つまり可能な限りコード自身の中）に置いておく
• ドキュメントすべてに対してもコードと同じ様な達人の原則を適用できる
• 日本語をもう一つのプログラミング言語として扱うこと
• すべてはドキュメントは付け足すものではなく、組み込むものである

コード中のコメント

• コメントが多すぎるというのは少なすぎるのと同じくらい有害
• コメントは「なぜ」それを行うかという目的やゴールを記述すべき
• 既にコードが「どのように」それを行うかということを表しているため、コメントでそれを記述するのは無駄 → DRY原則に違反する行為
• ソースコードへのコメントは、技術上のトレードオフ、意志決定の理由、却下された代替案といったような、プロジェクト資料のどこにも記述されない難解なポイントを記述するためのもの
• モジュールの見出しとなる簡潔なコメント、重要なデータやその宣言型についてのコメント、クラスごとやメソッドごとの簡潔な見出し、その機能がどのように使用されるかといった記述、その他明快でないものすべてをコメントとして提供するべき

変数名

• 意味のある名前をつけなければならない
• 例えば、foo、doit、manager、stuff は無意味な変数名
• 意味のない名前よりも始末に負えないのが誤解を招く名前
• つまり cp ではなく connectionPool と記述すべき
• ハンガリー記法 (変数名自身にその変数の型情報を埋め込む表記法) も、オブジェクト指向システムではまったくといっていいほど意味を持たない
• コードを書くのはわずか数回で済むが、その後そのコードを何百回も読むことになるはず