| プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱います。個人的な... ベタープログラマ - |
もうすでに知っていることが割とたくさんあった。一部リーダブルコードと同じことを言っている箇所もあった。
でもいろいろ気づきもあったのでよかった。
下記はリーダブルコードにも同じようなことが書いてあった。
- 変数名はキー入力を省くために短くする必要はなく、長くてもわかりやすい変数名が良い。というのはリーダブルコードと言っていることは一緒だった。やっぱり理解しやすさよな。
- コードは読むことに最適化されるべき。なので簡潔だが非常に読みづらいコードよりも、読みやすいコードを目指したほうが良い。
業務で学んだことも書いてあった。
- 本の中では「ソフトウェア考古学」と呼ばれるが、疑わしいコードに対してはコミットログを遡ったりして、そのコードが入った理由・背景を調べる。その上でそのコードの取り扱いを決める。
- コードフリーズについて。実際は凍結ではなく意図的な減速をおこなっている。業務のプロセスと照らし合わせて読み進めていけた。
- まだ改善点があるソフトウェアを出荷すること自体は異常or間違いではない。(次のリリースやSWアップデートで改善可能なので)
- 自分の成果物に説明責任を持つことが、コーディングの品質を上げる。「なぜこういう変更をしたのか、こういう方針にしたのか」などを徹底的に説明できるようにすることが、学生のうちはできていなかったと思う。(あんまり他人にレビューしてもらうこともなかったしね)
個人で開発する時についやってしまうこともあったので気を付ける。
- 機能的な変更と表現の変更を同時にコミットしない。それぞれ別のコミットに分ける。
あまり知らない略語もあった。
- DRY(Don't Repeat Yourself)
- YAGNI(You Aren't Gonna Need It)
新しいシステムに取り組む時や、issue解析をするときに役立ちそうなセクションもあった。
また、だいぶテスト駆動開発を推していた印象。
テストを書くことはコードの実装やコードの修正・リファクタリング、はたまたそのインターフェースや利用方法を理解するために役立つということが書いてあった。あまり個人の開発とかでテストを書くことはなかったけど、こうも推されると確かにメリットが大きいように感じてくる。テストも書いてみようかと思った。
教える立場になった時に意識しておくとよさそうな内容もあった。
他者のコード品質を高めるために意識すべきことや進捗管理について、またそれについて取りうる手法を例示してくれていた。
チューターになるときは読み返しても良いのかも。
ソフトウェア開発に関することだけではなく、どういうメンタリティで生きるべきか・キャリアを形成するべきか、みたいなことも書いてあって新鮮だった。
例えば(ソフトウェア関連に限らず)学ぶ努力を止めないこととか、運動したほうが良いとか、つるむべき人の話とか、チームメイトとの付き合い方・コミュニケーションの取り方などなど...
あと、仕事とは無関係の個人的なプロジェクトを始めることを推奨していて、それが退屈な仕事の開発に対する解毒剤になると言っているのは面白かったし、とても納得できた。自分が面白いと思って取り組めるものは何かを考えて、またそういったプロジェクトを持つ意識は忘れないようにしたいと思った。じゃないと廃人化してしまう...