読んだ本

ベタープログラマ

はじめに

何気なく本屋に立ち寄った時にふと目に留まったこの本。 最近よいコードを書いている気がしなくてもう一回気を引き締めてよいコードを書くぞという気持ちを入れ直すために購入しました。

目次

全38章からなり、大きく分けて5部でされています。

    1.コードを気にかける
# 第I部 you.write(code)
    2.見かけの良い状態を維持する
    3.少ないコードを書く
    4.取り除くことでコードを改善する
    5.コードベースの過去の幽霊
    6.航路を航行する
    7.汚物の中で転げ回る
    8.そのエラーを無視するな！
    9.予期せぬことを予期する
    10.バグ狩り
    11.テストの時代
    12.複雑さに対処する
    13.二つのシステムの物語
# 第II部 練習することで完璧になる
    14.ソフトウェア開発とは
    15.規則に従って競技する
    16.単純に保つ
    17.頭を使いなさい
    18.変わらないものはない
    19.コードを再利用するケース
    20.効果的なバージョンコントロール
    21.ゴールポストを抜ける
    22.凍結されたコードの数奇な人生
    23.プリーズ・リリース・ミー
# 第III部 個人的なこと
    24.学びを愛して生きる
    25.試験に基づく開発者
    26.チャレンジを楽しむ
    27.停滞を避ける
    28.倫理的なプログラマ
    29.言語への愛
    30.プログラマの姿勢
# 第IV部 成し遂げる
    31.一生懸命でなく、賢く
    32.完了した時が完了
    33.今度こそ分かった
# 第V部 人々の営み
    34.人々の力
    35.原因は思考
    36.遠慮なく話す
    37.多くのマニフェスト
    38.コードへの叙情歌

メモ

優れたプログラマは、コードとその書き方に対する態度

コードについて

コードは機械じゃなく人に対して書かれる。 そのため人に読みやすくするのが重要。

• 意図が明らかで優れた表現（命名、レイアウト）
• 文書のように読みやすく（段落、文、章を意識）
• 冗長性をなくす（DRY）
• 無駄をなくす（デッドコード）

バグ・エラーについて

• エラーを見逃さない
• 全コードパスを意識する
• バグの予防=健全なエンジニアリング

 (設計、コードレビュー、ペアプログラミング、テスト戦略、アサーション、防御的プログラミング、コードガバレッジツール)

• テスト=「コードを書く」のメタレイヤー
• テストの書き方はarrange-act-assert（準備-操作-検証）
• テストしやすいコード(DI, インターフェース)
• バグには絆創膏を貼るだけじゃなく根本から直す

コードの複雑さについて

高凝集、疎結合が基本。

ブロブ・線・人々の概念。

• ブロブ（=コンポーネント）

コンポーネントの数、大きさについて。 小さく凝集度の高いコンポーネントが理想的。

• 線（=コンポーネント同士の結びつき）

循環した線は複雑、抽象インターフェースで線を立つ（DIP）。 依存の方向を意識する。

• 人々

複雑さは人々によって生まれる。 プレッシャーと戦いながら、シンプルに保ち続ける必要がある。

ソフトウェア開発について

• 芸術的（美しいコード、設計。美的感覚）
• 科学的（厳密で体系的）
• スポーツ的（チームプレイ、ルール）
• 遊び的（学習、単純、楽しい）

常に頭を使う(思考停止しない)こと。愚かにならないこと。（リリース間際、無駄に巧妙な構造・アルゴリズム）常に変化させていくこと。

開発者として

• 学びを愛しているか？

学ぶ方法・学びを楽しむ方法を学ぶ。学びの定着のために教える&実行が重要。 知識ポートフォリオ（学習＝投資）を組む。

• チャレンジを楽しんでいるか？

情熱的なことに取り組む。ペットプロジェクトとか

• 安全地帯にいないだろうか？

停滞を避け、新しいことを始める

• 倫理的だろうか？

コードに対する態度・法的問題・人に対する態度

• 周りに優秀なエンジニアはいるか？

熱意、モチベーション、責任感に触れる

働き方について

• 人間工学的に正しい・健全な労働環境
• 一生懸命でなく、賢く（戦略的に働いているか？）
• コミュニケーション

コードは他の開発者とのコミュニケーション 明瞭、頻繁、敬意、レベル、媒体を意識する 自分の開発してるときのマニフェストを考える。

まとめ

この本で一番言いたかったであろう文章を以下に引用します。(P.346)

ひどいプログラマと優れたプログラマを区別しているものは、態度です。それが、単なる適当なプログラマと並外れたプログラマを区別するのです。

これは本当にその通りだなと感じました。 ある程度の経験を積んだエンジニアならば、基本的な設計の基礎だったり、優れたコードを書くTipsだったりは習得しているはずです。 ではなぜ、成果物に差が出てしまうのか。それは時間的プレッシャーであったり、外部の圧、労働環境などによって本来よくないとわかっていてもなお、よくないコードを書いてしまうことにあるのではないかと思っています。

もちろんそういった外的要因が少ない環境でコードをかけることが理想ですが、実際にはほとんどの現場でそれは存在してしまうのでは無いでしょうか？

そういった環境下でも、成果物に対する態度を意識し続けるのがプロの仕事なのでは無いかとこの本を読んで考え直しました。

普段のコードを書くという習慣を改めて見直す良い機会になった良い本でした。