きっかけ
- Amazonで半額セールをしていたので技術書を何冊か購入していたがじっくりと読む機会が無かった。
- 私が勤めている株式会社gumiでは勤続数年毎にリフレッシュ休暇というものを5日間とる事ができ、今年2回目のリフレッシュ休暇が貰える年だった。
- ずっとアプリの開発や運用に追われて、それなりに頭の中がごちゃごちゃしていた。
- よし、リフレッシュ休暇取ろう！（先週金曜日）→上司に理解してもらえ、休暇を取る事ができた！
- ただ観光にふけってるだけと思われたらなんか悔しいので、ちょっとは向上しようとしてますよアピール。
という思考の流れで、「プリンシプルオブプログラミング」を読んで共感を得た内容や、得られない内容をまとめてみようかと思いました。
この本を選択したのはアプリ開発・運用でおかしくなった自分の実装スタイルを、この本を読んで修正したいな、というのが理由です。
でも観光もしてたので全部読めたわけではなく、気が向けば続編を書こうと思います。
プログラミングは製造ではなく設計
なんかかっこいいと思った。
プログラミングは設計行為であり、その設計に沿って、ビルド（製造）されたものは動く。
コードはできるだけ早く書き始めるべき
コードを書かないと不明確な部分だらけだからだそうです。
実装時に疑問が出るのは実装前にそれらを洗い出せていないからだと思ってた。
コードはシンプルに
はい。
つい色々な機能を詰め込んでしまいます。
そういうコードは読みにくく、修正しにくく、修正に時間がかかり、もしくは手をつけたくないと、悪い事だらけになりますよね・・・
コードは頭の良さをアピールする場ではない
トリッキーなコードを書かれても困ります。
今不要なら今書くな
「将来使うかもしれないから〜」という機能を実装したものの、日の目をみた記憶がない私としては凄く分かりますw
今必要なことに時間を割こう。
コードのコピペ厳禁
はい・・・。
複数箇所に似たようなコードがあると、修正が必要な時に修正漏れが発生する危険がありますし、「似たような」コードなので、どこに修正を入れるべきか全部きっちり把握して修正しなければならないという疲れる作業を強いられてしまいます。
意図が伝わるようなコードを書く
コードは一度実装したらそれっきりということはなく、修正や機能追加が必要となる時期が必ずあります。
そのとき必ず人がそのコードを読むので、動作を把握しにくいコードはその作業の妨げになってしまいます。
コードは読みやすさ優先
読みやすければコードの改善もしやすいという事です。
（そういうコードを書ける人のコードに改善する余地があるのかは別ですが）
コメントは書く
理想はコメントが無くても理解できるコードを書く事。
だが、コードは「what」「how」があっても「why」は表現できないため、後でそのコードを読む人のためにもコメントを書きましょう、ということ。
コメントで説明しなくてもよい、分かりやすいコードを目指しつつ、それでも表現できない部分にはコメントを書く。
適切なメソッド名をつけられたということは正しく設計されている証
これ、苦手なので毎回頭を悩ませてます。
書籍の中で、どうすればいいか書かれてましたので、今後取り組んで行きたいと思ってます。
- 名前にはより多くの情報を詰め込むようにする。
- 複数の名前の候補を挙げて、そこから選んでみる。
- 命名後、「他の意味と間違えられる事はないだろうか？」と何度も自問自答してみる。
- 名前は「効果」と「目的」を説明する。「手段」には言及しない。
- 名前は検索可能なものにする。極端な例でいうと、英数字1文字の名前は検索した時にコード全体にヒットしてしまうのでNG。
以上！
現時点で2章まで。残りはまた読みつつ書いてみたいと思います。
温泉に入ったり、お城を見て回ったり、マッサージしてもらう隙間をぬって何度か読み返しましたが、それなりに頭がスッキリした気分になれました（身体もすっきり）。
全部で7章まであるので、続きはまた後日あげれたらいいなと思い、そろそろ寝たいと思います（2017年12月20日 23:50）。