「プリンシプルオブプログラミング」を読んで思ったこと、実践していくこと

1. はじめに
2. 本の概要
3. 思ったこと・実践していくこと
4. 余談（読書法について）
5. おわりに

1. はじめに

こんにちは。ゆうすけです。

実はRailsエンジニアとして7月から働くことが決まり（やったー！）、ブログのタイトルもちゃっかりRailsエンジニアに変えてます。

Railsエンジニアへの転職活動についてはこちらのnoteに詳細書きました。

note.mu

現在は1ヶ月の休職期間(!)を満喫するとともに、7月から働く会社のエンジニア兼マネージャーの方からいただいたおすすめの本リストに従って絶賛読書中です。

ただ読んだだけでは忘れてしまうので、ブログに「思ったこと、実践していくこと」としてアウトプットしていこうと思います。

アウトプットの仕方については何がベストか分からないので試行錯誤していきます。

第一弾は、「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」という本です。

プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則

作者: 上田勲
出版社/メーカー: 秀和システム
発売日: 2017/04/27
メディア: Kindle版
この商品を含むブログを見る

タイトルからして、これからエンジニアになる今の僕にめっちゃ必要そうな本ですね〜。

2. 本の概要

プログラミングの原理原則という名前の通り、質の高いプログラミングをするための先人たちの経験・知恵を具体例を用いて分かりやすく解説してあります。

3. 思ったこと・実践していくこと

各項目についてまず自分が思ったこと、実践していくことを書き、四角の枠内に本からの引用を記載しています。

コードを書くときは「コードの読みやすさ」を最重要視する

SIerで働いていた時、既存コードの解読にめちゃくちゃ時間がかかっていました。

（とてもとても分かりにくくてストレスだった、、、）

今後コードを読む人たちの時間・ストレスを考慮すると、コードを書くのに多少時間がかかったとしても読みやすいコードを書くべき、という考え方はとても共感できるので早く身に付けます。

プログラミングにおける1つ1つの判断は、「そのコードが変更される」という前提で行うようにしましょう。つまり、「変更に強いコードを書く」ということです。そして、そのためには「コードが読みやすい」ということが、もっとも大切です。結局コードというものは、書いている時間より、読んでいる時間の方が、はるかに長くなります。変更されるという前提に立つと、書くのにどれだけ時間がかかっても、読む時間を短縮できるなら、十分に元を取ることが可能です。

コードは必要最低限のものだけ書く

「あの機能追加するかもなー、一応このコード書いておこう」とコードを書いて結局使われずに放置、、、というのは僕も心当たりがあるので気をつけます。

コードは「たぶん必要になるだろう」「必要になるかもしれない」で書いてはいけません。本当に必要になった時、必要なものだけを書く、という方針で臨みます。ソフトウェアの変化を完全に予測して、先回りしたコードを書くのは不可能です。そこは割り切って、今必要なコードだけを書くようにします。

変数やメソッド名の命名のチェック法

分かりやすい変数名・メソッド名はコードの分かりやすさに大きく影響します。

変数名・メソッド名を見ただけで何のための変数・メソッドか分かったらすごく楽ですよね。

今までは何となく分かりやすいかなー、くらいの感覚で命名していて、チェックはしていませんでしたが、今後はこの方法でチェックします。

命名について、「名前可逆性」という考え方があります。これは、「名前は、その元となった内容の説明文を復元できなければならない」という命名指針のことです。この条件を満たすために、「ループバックチェック」を行います。内容の説明文から名前を考えたら、今度は逆に名前から推測できる説明文を考えるようにするのです。説明→名前→説明の順で、1周回って元に戻る（ループバックする）ように説明が一致すればよい名前で、一致しなければ要注意となります。

技術はきちんと理解してから使う

当然と言えば当然ですよね。

きちんと理解していないと仕事で聞かれた時に答えられませんもんね。

ググって一番上に出てきたやつをコードだけ見てコピペで動いたからとりあえずOKはやめます。。。

技術を学ぶ時は、動作原理や進化の過程、設計の背景にあるものも同時に知るようにします。これで照準が合い、目的が達成されやすくなります。よいプログラマは、時間がかかっても、言語・ツール・技術・問題領域など、分野を問わず、きちんと理解してから作業に取りかかる傾向があります。特に、プログラミングにおいては、「よくわからないけど、動いたから、これでよし」「よくわからないけど、直ったから、これでよし」とすると、後から必ず品質的な問題が発生します。きちんと理由を説明できるまで、粘り強く理解してから、コードを確定するようにしましょう。

コード内のコメントは「そのコードを書いた理由」を書く

今までは何となく分かりにくいかな、と思ったところにコメントを書いていましたが、コードだけでは表現できない、このコードを書いた理由を書くようにします。

何をしているかについては、きちんとコード書いていればコードを読めば分かるので極力コメントには書きません。

コメントがなくても読めるような、わかりやすいコードを書くのが理想です。ただし、コードはどこまで行っても「What」と「How」、つまり「何をしているか」「どのようにやっているか」までしか表現できません。「Why」、つまり「なぜそれをしているか」を表現するには、コメントを使用する必要があります。コードという文書は、読む人とのコミュニケーションに使用するものです。コミュニケーションを円滑にするのに役立つなら、Whyだけにとどまらず、進んでコメントを手段として使用するべきです。コメントで説明しなくてもよい、わかりやすいコードを目指しつつ、それでも表現できない部分にはコメントを書く、というバランスを持ったコードを書くようにしましょう。

技術的負債も借金の利子のように雪だるま式に増えていってしまう

技術的負債の話は利子の例えがすごい分かりやすかったです。

（元銀行員だからですかね笑）

利子が雪だるま式に増えていくように技術的負債も開発を続けると雪だるま式にどんどん増えてしまいます。

返済不能になる前に、お金も技術的負債も極力早く借金は返すべきです。

実務経験がない中で技術的負債は正直ピンとは来ませんがしっかり覚えておきます。

すぐに返済できなかった場合、「利子」が発生します。汚いコードがソフトウェアに残り続けると、問題が大きくなるのです。負債コードを読むには時間がかかります。そこに修正を加えるとなると、さらに汚いコードになり、ソフトウェアの動作も不安定になってきます。利子は複利となり、指数関数的に膨らんでいくのです。そして、利子が膨らみすぎたり、多数の負債を許容することによって、負債を抱えすぎてしまった場合、返済不能に陥ります。つまり、「機能追加」も「保守」もできない、不安定でアンタッチャブルなコードと化してしまうのです。

人に優しく、コードに厳しく

自分が言われる時のために覚えておきます。

7月から入社して自分のコードをズタボロに言われるだろうけど、これはイケてないコードを恨んで言っているのであって、自分に言われてる訳ではない、はず…

「人に優しく、コードに厳しく」して、人ではなくコードを批評します。

人に聞く前にまずアヒルに説明してみる

わからないことを教えてもらうために、わからない点を説明してる時に「あ！ちょっと待って…！こうかも…なんか分かっちゃっいました、すみません」てのはよくあります。

人に聞く前にアヒルに説明してみることを習慣にしよう。

「説明する」というデバッグ「ラバーダッキング」は、ある種のデバッグ手法です。プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明します。すると、問題の原因に自ずから気付き、自己解決できることがあります。この場合の「誰か」は、バスタブに置いたゴムのアヒル（ラバーダック）のように、話を聞きながら定期的にうなずくだけでよいのです。何かを言う必要はありません。実際にやってみると、効果はてきめんです。場合によっては、説明し始めた途端に気付いて「あ、もういいや、変なところがわかったよ。ごめん、ごめん」ということになり、照れくさい思いをすることもあります。「簡単で」「安い」のに、効果の高いデバッグ方法です。

解決が停滞した場合、「誰か」にそれを説明しましょう。話しかける「誰か」は、それこそ「ゴムのアヒル」のように、無機物でも構いません。「説明する」という行為が重要です。例えば、ある大学の情報系の学部では、ヘルプデスクのそばに「テディベアのぬいぐるみ」が常備されています。そして、不思議な障害に悩む学生は、人間のスタッフに相談する前に、ぬいぐるみに向かって説明しなければならないルールにして、一定の効果を上げています。