はじめに
この記事は、Lint Advent Calendar 2016 21日目の記事です。
誰が書いても同じコード
前提として、メンテナンス性の高いコードにするために「誰が書いても同じ」ようにすることが大事だと考えています。
これに関しては昔から「幻想だ」「そんなことは大事ではない」など色々な批判がありますが、「Zen of Python」を守るPythonistaはこだわっていきたいところです。
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Style Guide
「誰が書いても同じコード」にするためには、チームでStyle Guideを決める必要があります。
PythonにはStyle GuideであるPEP8があるので、これをベースにして各々が状況に応じてカスタマイズしていくとよいです。
Google Python Style Guideなども参考になります。
コードレビュー
「Style Guide」が決まれば、それをコードレビュー時に適用できます。
ただコードレビューでは「シングルクオートに統一してください」「importの順番を整えてえてください」などに時間をかけるのではなく、もっとより本質的な議論をすべきです。
これに関してnaoyaさんがちょっと昔にブログで語っていました。
些末なコードレビュー - naoyaのはてなダイアリー
コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい議論が紛糾しているのは「コードのインデント幅が違う」とか「return が省略されてる。俺は return があったほうが好み」とか「その場合は字下げをした方が綺麗にみえるんでは」とか、そんな些末なことばかりである、ということが多い。必ず一度は通る道である。
そんなことを延々議論していたって、はっきり言って何の意味もない。何の意味もない、は言い過ぎにしても、そんなところを改善したところで実質的な品質は何ひとつ上がらないわけだし、どうしても揃えたいなら lint ツールか何かで機械的にチェックすればよいことであって人間がやることではない。
やらなければいけないのは、「その設計は拡張に対して開いていないから開くべき」とか「これではエッジケースが想定されていないからこういう不具合につながるのでは」とか「そのテストでは後日見返したときに第三者が要求仕様を解釈しづらい」とかそういう指摘である。これらはちゃんとコードを読んで、コードの構造を把握して、そこに書かれているコード以外のシステムの全体感が頭に入っていて、初めてできる指摘である。
ここで大事になのは、
- Style GuideによるチェックなどのLintは機械がやる
- それ以外のコードレビューは人間がやる
という分業です。
人間が使える時間は有限なので、できることは自動化していきましょう。
Lintツール
PythonにおけるLintツール(flake8やpylint)については、以下の資料を読むと理解が深まるのでお薦めです。
リファクタリングツールあれこれ
ここでは普段業務で使っているものを紹介しておこうと思います。
おわりに
「Zen of Python」にある
- Readability counts.
- There should be one-- and preferably only one --obvious way to do it.
の精神を実践していくために、Lintをうまく活用していきましょう。