1．今回読んだ記事
No.91 良いプログラマになるには
著者: Pete Goodlife
2．記事の概要
知識や技術よりも取り組む姿勢が大事
- 「とりあえず動きそう」というだけのコードは書かない
- わかりやすいコード、保守しやすいコード、正しいコードを書く
- 同じチームのほかのプログラマと強調する
- 自分が扱ったコードは、最初に見た時より少しでもよいコードにする
- 積極的に新しい言語、イディオム、テクニックを学ぶ
3．この記事を選んだ理由・感想
理由
良いプログラマになりたかったから
自分の思っている良いプログラマ像と、他の人の考えているよいプログラマ像がどれだけ違うのか知りたかったから。
感想
「自分が扱ったコードは、最初に見た時より少しでもよいコードにする」はとても共感できた。
「最初からこうだった」などと言って何もしない人もいるけれど、もう少し責任を持ってほしいと思う。
しかし、関係ないところは変更すべきではないと思う。
試験とリスクが増えるので、自分が扱った範囲で改善していくにとどめた方がよい。
コードレビューをしてもらうときも「動くか」以外に「わかりやすいか」「保守しやすいか」の観点でお願いしてみるとよい。
4．議論
各自はどやって良いプログラマになろうとしていますか
- 「自分が扱ったコードは、必ず、自分が最初に見た時よりも少しでも良いコードにする」という部分は同意している。自分が触ったところで解りにくいところは直している
- （別意見として）自分は改修・リファクタリングは行うが、バグなどを考えて極力直さない派です
「最初からこうなっていた」といって何もしない人が結構多い
- 確かにそういう人は多い気がする
年上の人だとレビューの指摘をしにくい
- 直接の対面だと言いにくいので、回覧とか記録表とかにしてもらうといいかもしれない
- 回覧だと、「わかりにくいコード」のやり方を伝えるのが難しい場合がある
若手の意見を聞きたい
- 気を付けていることはありますか
- インデントとか、読みやすい読んでいてわかりにくいという指摘を受けたので気を付けている
- どういうコードがわかりやすいと思いますか
- 順番とか、法則性をもって書くようにしている
- 「とりあえず動きそう」は若手の方は気を付けたほうがいいかも
- ネットから持ってきて「とりあえず動きそう」で使ってしまうことがよくありました
長いコードをになってしまった場合
- メインのロジックが見やすいように分ける？
- テストがしやすいコードを書いたほうがいいと思う
- テストが自動化・充実していれば、「最初より良いコードにする」という改善がしやすい
- 「保守しやすいは」重要
ソースコードは個性が出る
- 人の個性があっても、統一されていれば読みやすい
- 理解せずにコピペの組み合わせだと、統一感がなくなって読みにくいコードになる
命名
- 「何とかフラグ(例えば、削除フラグ)」などはあまり良くないと思う
- isDeleteFlgとかにしたほうがいい
- ぱっと見てわかりやすい変数を付けたほうがいいと思う
- 変数名を考えるのが一番大変
まとめ
いろいろな意見が出て、普段一緒に仕事をしない人たちの意見を聞けて面白かった。
次回も引き続き同じ形式で続けてみる。