ベタープログラマ を読んだので自分的に刺さった点をまとめる。

6章 航路を航行する⌗

新たなメンバーが開発チームに参加する際にどのようにすれば速やかに生産的になることができるかについての章。

最善な策はすでにプロジェクトへの理解があるメンバーに導いてもらうこと。もしそれができなければ次のようなことを調べるとよい。

ソースの取得の容易さ⌗

ソースの取得がどれだけ簡単か。健全なプログラムはコードベース全体を得るための単一のチェックアウトのみを必要とする。

コードのビルドの容易さ⌗

  • 一般的でないツールにビルドが依存していないか
  • コード自身に適切で簡単なドキュメンテーションがあるか
  • 手作業なしで1つのコマンドでビルドを行うことができか
  • コードの一部に取り組んでいるときにその部分だけをビルドすることができるか
  • ビルド中に潜在的な問題を曖昧にしているかもしれない無数の警告が出ていないか

テスト⌗

  • 単体テスト・インテグレーションテスト・システム全体のテストがどの程度揃っているか
  • テストは自動で実行されるか。あるいは追加のビルドステップを必要とするか
  • テストはどれだけ頻繁に実行されているか
  • カバレッジはどの程度か
  • テストは適切できちんと作成されているか

コードとテストには普遍的な関連性がある。優れたテストが存在するコードはたいていきちんとリファクタリングされ、きちんと考え尽くされている。

ファイルの構造⌗

  • ディレクトリの構造が領域・サブシステム・コードの階層を明確に表しているか
  • ディレクトリの構造が整っているか
  • サードパーティのライブラリはプロジェクトのコードからきちんと分離されているか

ドキュメンテーション⌗

  • ドキュメンテーションは存在するか。わかりやすく、かつメンテナンスされているか

要件⌗

プロジェクトの要件文書あるいは機能仕様書があるか。

プロジェクトの依存物⌗

  • コードは特定のFWやライブラリを使っているか。それらについてどの程度学ぶ必要があるか
  • コードが言語の標準ライブラリをうまく利用しているか

コードの品質⌗

品質の感触を得るためにざっとを目を通す。

  • コードのコメントの量と質はどうか
  • 多くのデッドコードがあるか
  • コーディングのスタイルは全体にわたって首尾一貫しているか

アーキテクチャ⌗

  • ここまでの項目を通して主となる階層群を特定できるか
  • それらの階層がきれいに分離されているか

上記を実施すれば素早くプロジェクトについて把握することができる。 では実際にプロジェクトに取り組む際にはどのようにすればいいか。

  • やってみて学ぶ
    • コードを読むことは読むことにすぎない。実際に取り組んでみて、間違いを犯すことによってのみコードベースを学ぶことができる
  • 何か単純で小さな修正から着手する
  • コードを点検する
    • コード検査ツールをコードベースに対して実行してみる
    • コンパイルの警告が無効にされいないか調べる。無効にされていれば有効にして警告が表示されないようにコードを修正する。それによってコードベースの構造と品質の理解を深めることができる
  • 調査、そして行動
    • コードの小さな部分を調べ、批評してみる。弱点がないか調べ、容赦なくリファクタリングする。正しい命名に修正したり、長いコードを小さくて適正な命名をもつ関数に切り出す
    • このような作業を数回行うことで、コードにどれだけの柔軟性があり修正や変更に対してどれだけ従順であるかの感触を得ることができる
  • 維持管理
    • ソースファイルを整頓したりディレクトリ階層を正しくしたりする
  • わかったことを文書化する
    • コードに取り組み始める方法を説明しているトップレベルのREADMEは存在するか。しなければ作成してこれまでに学んだことを書く
    • そのドキュメンテーションを経験のあるプログラマにレビューしてもらう

新たなコードベースに取り組むほど、新たなコードを効果的に学ぶことができる。

この章はプロジェクトのキャッチアップに必要な観点が多く記述されていてとても参考になった。

  • 新しくプロジェクトに参加した際(業務・OSS関わらず)
  • 既存のプロジェクトの課題点を整理する際

などのタイミングで特に参考にできそう。

14章 ソフトウェア開発とは⌗

ソフトウェア開発は退屈な仕事⌗

ソフトウェア開発の仕事の多くは、楽しくありません。魅力的でもありません。(中略)有能なプログラマであるためには、退屈な仕事を恐れてはいけません。(中略)時には、私達はソフトウェアの清掃員にならなければならず、次のことが求められます。…

自分が学生のときには想像できていなかったソフトウェアエンジニアの現実、という感じがする。学生のときには毎日コードを書けるなんて夢みたいだ！と思っていたけれど、実際には楽しくない仕事もあるしコードを書かない日もある。ただ、自分が見てきた優秀なエンジニアたちはそういった仕事であっても着実に丁寧に素早くこなしていた印象がある。

あと、このところは

  • チームとして成果を出すためにはどうすればいいか
  • 身の回りの人から信頼される振る舞いとはどのようなものだろう

を意識して行動するようにしていて、自分にとってタスクが楽しいかや成長に繋がるかということをいい意味で意識せずに仕事ができている。この意識を持つようにしてから仕事が楽しく感じられるようになったので自分にとってもかなりいい変化だった思う。

15章 規則に従って競技する⌗

自分達で決めた規則が必要です。私達が所有権を持つ規則です。特定のチームにおける文化、およびうまく開発できる方法を定めている規則です。これらは、大きくて、扱いにくい厳しい規則である必要はありません。新たなチームメンバーがすぐに一緒に開発できるように、単純なものでよいです。つまり、それらは単なる方法やプロセスよりも詳しく何かを記述している規則であったり、コーディング文化を記述している規則だったりします。すなわち、チームで優れた選手になるための方法を記述している規則です。

この 「チームで優れた選手になるための方法を記述している規則です。」 という部分が特にいいなと思った。チームメンバーとして活躍する方法が言語化されていることで、新しいメンバーが素早く立ち上がることができるだけでなく、すでにチームに所属しているメンバーもことあるごとに立ち返ることができて、方向性がずれかけてもうまく軌道修正することができるなどのメリットがありそう。

個人的にチームで共通理解を持つことでチームの方向性がうまく揃い、軌道修正もしやすかった経験を部活のときにしたのでこの章の内容はとても腹落ちした。

18章 変わらないものはない⌗

コードのどの領域も、誰にも「所有」されていません。どの領域でも、誰もが変更を行うことが許されています。コードを所有するといった制度は避けてください。それは、変更を抑制します。

サーバーサイドの開発チームに初めて異動したときは「自分よりもサーバーサイドも経験が長いエンジニアたちが書いたコードだからどの部位も意図があり、設計も練られた上で今の実装になってるに違いない…！だから強い理由がないとなかなか変更を加えるべきではないのではないか」という思い込みがあったが、何ヶ月かサーバーサイドの開発の経験を積んで「なんか全然自分でも修正できそうなところあるぞ・・・！」と感じられるようになった。

いい意味でフラットな目線でコードベースに触れる意識を持てるとよさそう。

28章 倫理的なプログラマ⌗

プログラミングのキャリアの中で、最も頻繁に出会う人々は、チームメイトです。彼らは、毎日一緒に働くプログラマやテスターなどです。倫理的なプログラマは、彼ら全員と一緒に誠実に働き、各チームメンバーに敬意を払って、できる限り最善の結果を達成することに注意を払っています。

どれだけ成熟しているとか経験を積んでいるとかに関係なく、誰もが貢献できる価値を持っていることを常に信じてください。

誠実で信頼されるようになってください。誰にでも誠意を持って接してください。

大事。

倫理的なプログラマは、燃え尽きるような働き方をしません。それは、個人的に不都合であるだけではなく、チーム全体に対しても悪い影響を与えます。毎週、何十時間も残業すれば、疲れ切ったプログラマになり、必ず不注意な間違いを生み出し、悪い結果となります。驚くほど熱心に働く英雄のように思われるのは素晴らしいですが、倫理的なプログラマは、非現実的な期待に応えようとして、自身が燃え尽きてしまうのは悪い考えであることを理解しています。

直感では理解できるが、プロジェクトの種類によっては残業の量が成果に直結することもあり難しい。残業を最後の手段にしつつ必要なときはやる、くらいの感覚がいいのだろうか。(残業前提でスケジュールを組み出すと工夫をする発想がなくなり、効率が上がらず長期的には損だと思う。もちろん燃え尽きリスクが高まるという面でもそう。)

あとは現実的にビジネス的に絶対に守りたい締切があることはあると思う。現場レイヤー目線だと踏ん張りどこは頑張って、乗り切ったら少し休むようにし、マネジメントレイヤー目線だとそうならないように人員計画をいい感じにするとかがいいのだろうか（？）

ただ、チームをマネジメントする立場からみると長期間安定して働いてくれることも一定嬉しいとは思うので無理をしすぎないことも重要そう。

結び⌗

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

態度は、技術スキルに勝ります。プログラミング言語の複雑な知識は、保守可能なコードを保証しません。プログラミングのモデルを多く理解したからといって、必ずしも優れた設計を生み出すとは限りません。あなたのコードが優れているかどうかと、あなたと一緒に働くのが楽しいのかどうかを決めるのは、あなたの態度なのです。

この記述がこの本を通して特に刺さった。シンプルだがとても重要なことだと思う。「何ができるか」も重要だが、それ以上に「どうしたいか」や「どこを目指しているのか」がより重要なのだろうと思った。ついついハードスキルばかりに目がいってしまうがそういった志向性を持つことにも同様に気を配りたい。

自分が見てきた優秀なエンジニアはこれを体現している人ばかりだったように思う。

感想⌗

「優秀なエンジニアはどう振る舞うか」を主題に数多くのトピックが書かれていてとても参考になった。自分がこれまで接してきた優秀なエンジニアの振る舞いとも重なるところが多かった。 優秀なエンジニアがなぜ優秀かをあらゆる角度から言語化していて理解を深めることができたし、自分も真似できそうなことが多くあったので実践していきたい。

次は久々に技術寄りの本を読みたくなったので次はRust関連の本を読んでみたいと思う。1

あとは「プログラマー脳」も気になるのでいずれ読みたい。

  1. 「コンセプトから理解するRust」でRustの理解を深めて「詳解Rustプログラミング」でRustで低レイヤーを学んでいこうと思っている。 ↩︎