はじめに
『プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則』という本を飛んだのでアウトプットします。以降記事内では『プリンシプル オブ プログラミング』や『本書』と省略します。
どんな本か
内容や目次は↓に記載されています。
www.shuwasystem.co.jp
なぜ読むのか
最近業務でコードの読み書きやレビューすることが増えており、その中で「良いコード」とは何なのか、「良いコード」で書いていくためにできることは何なのか、改めて知識を深めたいと感じて本を探しました。書籍紹介系の記事ではよく見かける『プリンシプル オブ プログラミング』は自分が調べた限りだと評価も高く、関連書籍を複数読む場合の入りとしても良さそうだったため選びました。本の紹介に書かれている以下の文が自分の状況に合っているのも決め手の1つでした。
一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？
ざっくり感想
本書は言語や分野を問わず「コードを書く人」に向けて書かれています。内容は抽象的で、コードのサンプルはありません。そのため本のタイトルに『3年目までに身につけたい〜』とありますが、プログラミング始めたての人やこれからエンジニアを目指す段階の人だと読んでもあまりピンとこなさそうだなと思いました。なので個人的には最低でもコードを書く経験を数ヶ月してから読むことをオススメします。
内容は「確かにその通りだな」と共感できるものが多く、その中で新たな学びもあり良かったです。1つのプリンシプル(=原則)についての説明が大体2〜5ページ、長くても10ページぐらいで読みやすいのも、一気に読んだわけではなく隙間時間を使って少しずつ読んだ自分にとっては有り難かったです。
学びになったプリンシプル
SLAP
「同じ関数に属するコードの抽象レベルを統一しよう。」という内容のプリンシプルです。このプリンシプルは初見だったのですが、普段コードを読んでいて感覚的に「ここに書いてあるよりこっちにこう書いた方がわかりやすいのでは？」と思ってたものが原則として説明されていてスッキリしました。他人に説明するときに使えるので知ることができて良かったです。
参考記事
・コーディング原則の一つSLAP – 株式会社シーポイントラボ ｜ 浜松のシステム・RTK-GNSS開発
ボーイスカウトの規則
「自分のいた場所は、そこを出て行く時、来た時よりもきれいにしなければならない。」という内容のプリンシプルです。自分はコードを書くことも、コードを書いてもらってレビューすることもやってきましたが、今までこれをやっていた人は記憶にないです。自分もほとんどできてないことです。必要な箇所だけコードを弄って終わりになっていることがほとんどです。キレイなコードでプロダクトを作って行くためには必要な意識だと思いましたので、肝に銘じたいと思います。
曳光弾
「ソフトウェアを開発する際に検証しておきたい機能などを先行して作ることで、様々なメリットがある。」という内容のプリンシプルです。これを読んで最初は「プロトタイプのことかな？」と思ったのですが、ちゃんとプロトタイプとの違いを説明してくれています。今まで勘違いしてたので本書を読んで良かったです。簡単にいうとプロトタイプは使い捨てで成果物のコードとして使っていきませんが、曳光弾は成果物のコードとして使っていくという違いがあるそうです。今後は作る際や会話の中で曳光弾とプロトタイプを使い分けていこうと思います。
ラバーダッキング
「発生している問題を誰かに説明すると、自ら原因に気付き自己解決できることがある。」という内容のプリンシプルです。実例として、とある大学の情報学部のヘルプデスクのそばにぬいぐるみを置いておき、質問者はスタッフに相談する前にぬいぐるみに向かって説明しなければならないというルールがあるそうです。可能なら同僚のプログラマに話すのが良いとしています。
話してるうちに自己解決するのはエンジニアをやっていたら誰もが経験するのではないでしょうか。自分は質問するためにチャットで文章を作っていたら自己解決することがたまにあるのですが、これもラバーダッキングだと思います。要は一回人に説明できるように整理することが大切だということだと思います。初心者に教えたいプリンシパルです。
割れた窓の法則
「割れた窓=悪いコードを放っておくとそれが広がっていくので放置するな。」というプリンシパルです。「割れ窓理論」という呼び方の方がメジャーなのかもしれません。Wikipediaにもページが存在しています。
これはコードに限った話ではなく、ドキュメントや開発環境周りの設定など、あらゆることに言える話だと思います。開発の進行に支障をきたさないことだと後回しにしてしまいがちですが、見つけたらすぐに何らかのアクション(全てをすぐに対応するのは非現実的なので課題としてどこかに書くなど)をしていくように心がけたいですし、そもそも割れた窓を作らないような意識や仕組みを大切にしたいです。
ジョシュアツリーの法則
「人は名前を知った途端、それが見えるようになる。逆に、名前がなければ(知らなければ)、それが見えない。つまり、名前を知ることで存在を知る。」という内容のプリンシプルです。SLAPのところでも書きましたが、本書を読んだことにより、何となく感覚的に行なっていることや知っていることの名前を知ることで、頭の中が整理され引き出せるようになりました。これはまさにジョシュアツリーの法則によるものだと思います。
プロジェクト・チーム内で表記や言葉の揺れが内容にユビキタス言語を定義することも大切であるということも書いてあります。自分はユビキタス言語が定義されているチームに参画したことがあるのですが、参画後最初の方はユビキタス言語の一覧が非常に有り難かった覚えがあります。広まってほしい文化ですし、自分も機会があれば提案・定義を推進していきたいです。
名前を知ること・付けることの大切さがわかる良いプリンシプルだと思います。
参考記事
・Chatwork WebのUIに1つ1つ丁寧に名付けをしている話（ユビキタス言語検討会について） - Chatwork Creator's Note
