スポンサーリンク
概要
オライリーの「ベタープログラマ 〜優れたプログラマになるための38の考え方とテクニック〜」を読んだので感想を書こうと思います。
技術書のセールとおすすめ書籍を紹介しています。合わせてご覧ください。
スポンサーリンク
書籍概要
どんな本？
プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。
本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。
はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。
次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱います。
個人的な活動として、継続的な学習方法と停滞を避けるための課題の見つけ方など、自らを成長させる方法も紹介。
さらに組織の中で他の人とコミュニケーションを取りながら、効果的に働くための習慣を解説します。
『Code Craft』の著者Pete Goodliffeが、自らの経験を元に「優れたプログラマ」になるための考え方と習慣をまとめた本書は、プログラミングを愛し、長く続けながら、優れたプログラマになりたいと思うすべての人に必携の一冊です。
- Pete Goodliffe 著、柴田 芳樹 訳
- 2017年12月 発行
- 376ページ
- 定価3,300円(税込)
スポンサーリンク
スポンサーリンク
内容のまとめと感想
副題にもあるように優れたプログラマになるためのノウハウ集となっています。
基本に細かいプログラムや手法に関しての説明はなく、考え方や習慣を説明している本になっています。
コードの書き方や構造に関しての言及もありますが、あくまで考え方がメインなので、具体的なコードの例等はあまりありません。
(ただし、前半は比較的サンプルのコードがあります。)
良かった点
翻訳は良好で読みやすい
オライリーの翻訳書籍でよく見受けられる、わかりにくい表現等はあまり見受けられず読みやすい書籍になっています。
こういったコードではなく、文章がメインの書籍においては読みやすい文章というのはかなり重要なファクターだと思います。
また各章の最後には、その章で取り扱った内容のアンチパターンとしてまとめた皮肉的なイラストが載っているのが面白いです。
(おおよそ一万匹のモンキーという、ダメなモンキーエンジニアを皮肉った内容)
幅広い内容
ソフトウェアエンジニアにとって必要となる知識や考え方を幅広く、網羅的に説明しています。
DRYや、KISS、YAGNIなどこの書籍以外でも頻出する開発おける考え方や、ドキュメンテーション、ソースコード管理、テストなどなど、１つ１つの説明は少ないですが網羅されている幅は非常に広いです。他の様々な本でテーマごとに深掘りされている内容を網羅的に集めて、理論を簡単に説明しているイメージになります。
技術的な側面だけではなく、コミュニケーション手法やエンジニアとしての姿勢や健康管理などこれでもかといった形で網羅的に説明があります。
ある程度他の専門書等で学んだ事があるエンジニアであれば、この一冊でそういった内容を思い出す事ができて便利な１冊になるかと思います。
要約やまとめが多い
本書が非常に幅広い内容を扱っていることは先ほど説明しました。
このように非常に数多くの内容が取り上げれられていてると、煩雑になりがちであったり混乱しがちになりますが、説明の節々に要約が記載されていて非常に理解しやすくなっています。
また、章末にもまとめがあったりと非常に丁寧に作られていると感じました。
スポンサーリンク
気になった点
抽象的な内容や概要レベルの説明が中心で初心者にはきつい
文章でのこうあるべきといった論が中心であって、具体的にそれを実現するためのコードや手法等の説明はあまりありません。(序盤は比較的コードの例はある)
あまり経験の無い人が読むと、どうすれば良いのかは分かりにくいのではないかと思います。
エンジニアとしてのある程度の経験や知識を持った人が読むと、イメージがつきやすかったりあるある的なもので思い出したりといった事はあると思います。
スポンサーリンク
総合的なまとめ
前述の通り、非常に幅広く網羅的なテーマでエンジニアとしてのベストプラクティスを取り上げています。
その代わりに、個々の説明はあっさりめとなっているので、書かれている内容を自分の過去の経験やナレッジから補完する事ができる、中級者以上の向けの書籍にはなるかと思います。
そういう意味で、期間を置いて何度も読み直すことで、また新しい発見が期待できるような書籍になっていると思います。
自分も１周目にさらっと読んだ時は、う〜んと思ったのですが、個人メモを残すために2周目を読むことで改めて良さがわかったりした点が多々ありました。
様々なテーマを取り扱ってはいますが、全体を通して感じるのは、悪いコードが生まれるのは技術的な側面からではなく、コードを書く人間的な側面(考え方、他者とのコミュのケーションなどなど)が大きく影響を与えていて、それを目指すためのヒントが書かれているのが本書になるのではないかと感じました。
その他のオライリー本の紹介をしていますので、合わせてご覧ください。
【オライリー本感想】Seleniumデザインパターン&ベストプラクティス はUIの自動テストのガイドとして良くまとまっている良書
個人的なメモとまとめ
第1部 you.write(code)
コードの読み書き、設計などにおけるあるべきプラクティスをまとめている章です。
本書の中で一番技術的な内容を書いている章で、コードを書くエンジニアにとって一番身近なテーマかもしれません。
設計、製造、テストなど開発における全てのフェーズにおいてコーディングに必要とされるプラクティスを網羅しています。
筆者が過去に経験した問題PJを例に問題点を説明していたりと、興味深く読む事ができます。
コードの表現
コードのフォーマット(レイアウト)重要だが、議論すべきではない。プロジェクトで共通の規約を決めて従う。ただし、何が優れたレイアウトなのか根拠のある意見を持つべき。
タブや余白等、コードのレイアウトの細かな部分だけに注目したコードレビューは権威的で機能していない。
おおざっぱに表面的に読むだけであれば、取り上げるのはレイアウトだけになり、有益なコメントを行った気になってしまい本質的な内容に関するチェックが見落とされる。
コード自体が明解で首尾一貫していれば、そういったレイアウトはほとんど気にされない。(コード自体がひどいと、そういったレイアウトの問題しか見れない。)
誰のためのコード？
読むのが困難あコードを扱うのは難しい。誰のためにコードを書くのか？それは他の人たちのため。(理解できる明解で意図のわかるコードを書くこと。)
少ないコードを書く
たくさん書かれたコードは大概、不必要なコードを多く含んでいる。多いコードは悪である。
(コードのコピペや不要になった処理が残っている。冗長でたるんだロジックなど)
- コードを読んで理解するのに時間を要す
- コードが多いほどバグが隠れる場所が多くなる
- 保守コストが高くなる
汚いコードへの対応
汚いコードを修正すべきかどうかは、投資に見合うかの判断が必要(ほとんど修正されずに、長く動いているならば安定してるならば修正はコストに見合わない)
汚いコードを修正するタイミングが発生したならば、そのコードを見つけた時よりも綺麗にする。（ボーイスカウトルール）
何をテストするのか？
アプリケーションに重要なことは何でもテストすべき。そのためにアプリケーションの要件が重要。
(性能要件があるならば、その要件を満たすような自動テストコードを単体〜インテグ〜システムのいずれかのレイヤで書く)
カバレッジを追い求めると、全ての行を網羅することに苦心してしまいがち。重要なのは、ふるまいとシステム特性に対するテスト。
第2部 練習することで完璧になる
1部はコードを中心にした視点でのプラクティスが中心でしたが、2部はより上位の視点から良いコードを書くためのプラクティスをまとめています。
コード開発における設計的な視点でのあるべき姿から始まり、リリースにおける必要な考え（コードの管理やQAを巻き込んだ品質、ソフトのリリース）など、ソフトウェアのライフサイクルを意識した視点も多く含んだ説明になっています。
ソフトウェア開発は芸術、科学、スポーツ、子供の遊び、退屈な仕事
優れたコードを書くために、芸術家のような美的感覚が必要とされる。
また、優れた科学者は芸術的な観点も持ち合わせている。科学的な観点もソフトウェアには必要。
チームワークやコーチング、規律などスポーツにおける特性も必要とされる。
子供の遊びのような、学習、成長、単純さ、楽しさを持つべきでもある。
プログラミングの大部分は退屈で単調な仕事(バグ修正、古いコードの保守)であり、その部分に関しても責任を持って取り組める必要がある
単純な設計
単純な設計は手短に明瞭に説明でき、容易に理解できる。
使うのが容易で、誤用を防ぎ、小さすぎない粒度となっている。
単純と愚かさ
KISS原則(愚鈍で単純なコード)に従い、単純にコードを保つ必要性があるが、愚鈍ではダメである。
十分な考慮の元の単純性が必要となる。そのために書くコードには十分は思慮が必要となる。
QA部門との関係
QA部門への尊敬が必要。最新のテストされた正しいソフトをQAに渡すべき。障害報告に対して真摯に取り組む。
QAが品質に唯一の責任を持つのではなく、開発プロセスの早期段階から協業して、全員で取り組むものである。
第3部 個人的なこと
3部は優れたプログラマになるために、個人的な活動として取り組むべき考えが説明されています。
学び方や振る舞い、健康などこちらも非常に幅広い内容を取り上げています。
この章の内容は以前紹介した、リファクタリング ウェットウェアに通じるものが多くありました。
より深い内容なこの本を読んで学ぶと良いと思います。
プログラマの姿勢といった章では、各作業の時のあるべき姿勢や目の疲れといった健康に関してまで説明していて面白いです！
継続的な学習
継続的に学習を行い、新しいものを学び続ける必要がある。それを楽しんで取り組むべき。
知らないとわかっている事象、知らないことすらわかっていない事象を調査して見つけて取り組む。
視野を広げ、ソフトウェアに関係ない領域を学ぶことも重要(外国語、科学領域、芸術、哲学など)。これらは世界観を広げてくれる。
他に人に指導することも学習で重要である。他人に教える事ができて、初めて「わかっている」こととなる。
チャレンジを楽しむ
新しいことへの挑戦を続けることでモチベーションを維持する事ができる。
こういった活動は、ビジネス価値を生み出さないかもしれないので、個人的な副プロジェクトとして取り組むのが最適。
倫理的なプログラマ
コーダーの質は技術的な技量ではなく、態度に依存する。
汚かったり、不必要に巧みなコードを書いて、自分自身を不可欠にしてしまうのは悪い例となる。
チームメイトから誠実で信頼されるように振る舞うようにする。
第4部 成し遂げる
4章も「最善の方法で仕事を成し遂げるか？」といった仕事の進め方に関する姿勢に関してまとめている章です。
車輪の再発明をせずに既存のライブラリを使用するといった事や、詳しい有識者に話を聞く等、開発一般における取り組み方が説明されていますね。
アジャイル開発的(スクラム的)でよく見かける内容を多く見受けられました。
第5部 人々の営み
3~4章で自身の姿勢に関する考えを示していましたが、5章は他者との協調的なコミュニケーションに主点を当てています。
オンラインでの会話や、チーム、顧客との会話など、スクラムの考えやプラクティスに近いものを感じました。。
優秀なプログラマ
優秀なプログラマたちがいる環境で働き、協力関係を築くべきである。下記のようなメリットが得られる。
- 熱意
- モチベーション
- 責任感
コーディングは人の問題
多くの場合、ソフトウェアの開発で扱いにくいのは技術的な問題ではなく、人間の問題である。