読んだ本について
-
著者:上田勲
-
出版社:秀和システムズ
-
本書の概要:(公式サイトからの引用)
一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか? 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました!
感想
- 読書対象は、ある程度プログラミングを経験し、なんか今のコードはビミョーだな~と感じ始めた人向け
- あと、若手の後輩へコーディングをアドバイスする人向け
- 内容的にプログラミング初心者やプログラマ1年目には難しい内容となっているかもしれない
- 初心者にとって、よくわからないカタカナ用語や、理解しがたい概念が頻出する
- たとえば、オブジェクト指向。プログラミング初心者は、用語としてふわふわとなんとなく知っているかもしれないが、業務で扱うプロジェクトではどういう設計になっているか想像しにくいのではないか?
- 改めて「良いコード」とは何かを理解することができたし、「良いコード」を書こうという意識になる
意見?
-
私は、ソースコードには「コメントを書いたほうがいい」派
- 本書では、コメントを書かなくても内容を理解できるようにソースコードを書くべきで、それに入りきらなかった意図などをコメントに残しましょう的なことが書いてある
- 「コメントがないと読めない」ソースコードは書くな!というのは賛成である
- しかし、人によって技術レベルが異なる
- ⇒「コメントがなくても読める」はどの技術レベルを想定しているのか?
- 新人さんが読むかもしれないコードに、なにをしているか意図や説明をサラッと書いておくべきかと思った
- あとからいろいろ質問されるよりも、コメントとして残しておいたほうが親切
- 新人さんにはコメントの日本語部分を読んで概要をつかんでから、デバッグで動かして、処理を理解してもらう
-
ボーイスカウトルールには反対派
- ボーイスカウトには、シンプルな規則があります。「自分のいた場所は、そこを出て行く時、来た時よりもきれいにしなければならない」という規則です。たとえ、自分が来た時には既にキャンプ場が汚かったとしても、たとえ、汚したのが自分ではなかったとしても、きれいにしてからその場を去るのです。この規則を、プログラミングにも当てはめます(本書からの引用)
- ボーイスカウトルールに反対な理由
- ひどいコードのプロジェクトに新規機能を追加するという仕事だった場合、自分が担当する箇所はなるべくキレイに書こうと努力するが、ほかはそのままのほうがいい
- 他の箇所をいじってコミットし、不具合が出たら?デグレが起きたら?
- めんどうなことを避けるために、自分で書く箇所はキレイに、ほかはいじらずにそのままが良いのではと思った
以上です。