もくじ
以下のブログを読みました
以下のブログを読みました。
僕が気になった点をまとめます。
コーディング規約について
まつもと : あまり私自身はコーディング規約を気にするタイプではないですね。でもコーディング規約にこだわる人はいっぱいいますよね。
まつもと : ただ、インデントの幅とかスペースかタブかみたいな話は、修正するとdiffが大量に出てくるのでそれは事前に考えておいたほうがいいと思いますね。
コーディング規約が何故存在するか、それは、プルリクを出した時などに「diffが大きくなるのを防ぐ」ためです。そのために、インデントの幅や、括弧の位置や括弧の前後のスペースなどはコーディング規約で決めておいたほうがいいですね。これは複数人で開発している時に限った話であり、自分しかコードを書かないならこの心配はないので、好きに書いたら良いという話です。
変数のスコープが広い場合は長い名前をつけろだとか、循環的複雑度がどうだとかは、コーディング規約で定めるものではなく、レビューのときに指摘するべきものだというご意見で、これには納得しました。
コードレビューについて
角 : コードレビューをしてくださいと依頼があってコードがあがってきた時、コードの機能要件は満たしているし、ちゃんと動くのだけど、コピペが多いなど保守性が低いコードで困る、というですね。こういう場合、まつもとさんならどう対応しますか？
まつもと : これこれこういう理由で採用できないのでリジェクトという感じですね。パフォーマンス上の懸念がありますとか、コピペによる保守性の低さが気になりますとか言ってリジェクトすることが多いです。
仕事をしていても、レビューを見た時に「うっ」となるコードを持ってくる人がいます。
例えば「タグクラウド」ってありますよね。
こういったものって、やはり生成するロジックが複雑になります。この機能にかかわらず、複雑な計算や仕組みをもつものって、適切に実装しないとメンテナンスが大変になります。
例えば、
- 「人気のタグ」以外にも「人気の投稿者」みたいなページを作りたいんだけど、人気のタグのロジックや設計を使いまわしたりできる？
- エロいタグとか荒らしのタグをタグクラウドから除外できるようにしたい
- タグのジャンルによって色を付けたい
- 内部の計算ロジックを変更したい
こういった要望に答えられますかということです。適切にモジュール化されていたら簡単ですよね。
業務で重要なのは、これを最初に実装した人とこれをメンテする人は必ずしも同じではない（むしろ違うことのほうが多い）。
とはいえ難しいこともあります。
- 設計というのはカンと経験に依る所も大きく実装者のスキルに寄って大きく左右される。
- レビューする人も、「ダメ」という指摘はできるが、他の仕事もあるので「具体的な代替案の提示」まではなかなか行かない。
- 業務の場合「締切」がある。
とはいえやはり長い目で見た時にはちゃんとメンテできるようなコードになっていたほうがいいですよね。
まつもと : そういった場合は情け容赦なくリジェクトするようにしていますね。
これが出来たらいいんですけど、「マトモになるのに3ヶ月くらいかかるなこれは...」と思うことも多々あります。
