みなさんこんにちは。最近運動不足だなぁということで『リングフィット アドベンチャー』を再開したら、調子に乗ってやり過ぎて膝に違和感を覚え、そこに追い打ちで子供の抱っこ抱っこ攻撃が入り、完全に両膝がやられてしまいました。とはいっても抱っこ抱っこ攻撃もあと数年でしょうし、まぁがんばろうかなぁと思って、毎度毎度、出かけるときは玄関から抱っこでがんばっています。いくらなんでもちょっとくらいは歩いて欲しいんですが.........。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
より良いプログラムを書く
これまでの連載では、映像制作を行うためのシステム構築やデータ管理をどのようにするかというお話をしてきました。このようなシステムを構築する際にプログラムを書くことは決して避けて通ることはできない上に、作成されたプログラムはプロジェクトの寿命よりも長く、場合によっては複数人の手によって10年以上も生き続けます。ただ目の前にある問題を片付けるためにプログラムを書いているだけでは、これだけの寿命を獲得することができません。長期間の運用に対応するためには、日々より良いプログラムを書き続けることが大事です。そのため、今回から数回にわたって、より良いプログラムを書くために普段私がどのようなことに気を付けているのかをご紹介していきます。
プログラミングのガイドラインを決める
複数人で協力して開発を行う場合や、個人でも長期にわたって開発を行う場合、それぞれがその時々に好き勝手なスタイルでプログラムを書いてしまうと、後からコードの読み書きに支障が出てしまいます。さらに悪いことに、プログラマ同士でコーディングスタイルの齟齬が発生すると、それを発端とした殴り合いの喧嘩が始まってしまうため、大きな問題の火種となってしまいます。これは結構冗談ではなく、本当に起きるんですよ.........。インデントをTABで行うか、スペースで行うか、カッコの前後にスペースを置くか置かないか等々、プログラマはそれぞれこだわりをもち、信念や宗教と言えるレベルまで昇華していることが往々にしてあるため、プログラマ間でコーディングスタイルに関する話題はご法度なのです。
コーディングスタイルが揃っていないと先のように問題が多発するため、ガイドラインを決めます。Pythonでコードを書く際は、PEP8に準拠するのがスタンダードになっています。また、GoogleがまとめたPython Style Guideも参考になるでしょう。さらに、PEP20もとても良いドキュメントです。
・PEP 8 -- Style Guide for Python Code
・Google Python Style Guide
・PEP 20 -- The Zen of Python
とても大事なこととして、これらはあくまでもガイドラインであり、絶対的なルールではないです。また、PEP8に沿っていたとしても、細かい部分で異なったスタイルになる場合もあります。さらに、古いコードであれば現在のガイドラインと異なるスタイルで書かれている場合もあるでしょう。そのような場合は、まず第一に既存のコードのスタイルを優先します。決して、自分が正しいからといって古いコードのスタイルを無暗に変えてしまうようなことをしてはいけません。
よくあるのが、ほかの人が書いたコードなのに、TABで書かれたインデントをスペースに置換してコミットしてしまうケースです。これは上書きをされた側としてはかなり気分を害する原因になる上に、ほかのコードとの整合性も危うくなってしまいます。動いているコードは変更しない、必要な部分のみ手を加える、手を加える場合はきちんと理解して行うというのが大原則です。どうしても必要な場合に限り、細心の注意を払って変更を行います。このとき役に立つのが、後でご紹介するテストコードです。
同様な理由で、読み込んだコードを機械的に整形するフォーマッタを使って、人のコードを整形するのも気を付けた方が良いです。前述のようにPEP8も必ずしも解釈はひとつではなく、使用するエディタによってフォーマッタの挙動も微妙に異なります。そのような状況下で、各自がコードを手当たり次第にフォーマッタにかけたらどうなるか.........。流血沙汰が起きるのはそう遠くない未来でしょう。もちろん、チームで使用するフォーマッタを決めて、必ずそれに通すというルールにすれば良いです。このあたりはどこまで縛るかという匙加減の問題です。
ガイドラインに沿っているかチェックを行う
ガイドラインを決めただけでは、守るのは難しいです。特に、チームに参加したばかりのメンバーはルールに慣れていないために凡ミスも犯すでしょう。そのため、誰でも簡単に自分が書いたコードをチェックできるようにすることが大事です。アセットの品質チェックについて解説した第30回でも同じようなお話をしましたね。
チェッカーもいくつか種類があるので、好みのものを使用します。ほかの人が書いたコードを修正してからチェッカーにかけることもあるので、チェッカーは統一しておいた方が良いかなと思います。ここでも「エラーは出ないものの微妙だなぁ」と思うケースでは、既存のコードを尊重するようにします。"間違っているものは修正、間違っていないものはそのまま" というのが基準です。
グレーゾーン対応
チェッカーではエラーにならないものの、コードの綺麗さや可読性に問題があるような場合はPEP8対応とは別の事柄として議論をします。この際も、PEP8やPEP20の精神を尊重します。
ここまではコードの形に関するお話です。プログラミングをする際にある程度基準となる形を決めておくことで、余計な軋轢を未然に防ぎ、将来的にもメンテナンスしやすいコードにすることができます。
繰り返しになりますが、プログラミングのガイドラインというのは、あくまでも "ガイドライン" であって、"ルール" や "教典" ではありません。細かい部分でAを取るかBを取るかというのはどっちでもよく、どちらかに決まっていることが大事です。ガイドラインはそれを決めるためのものです。PEP8も、これが完璧で全てにおいて同意できるかといわれると、意外とそうでもない部分があったりしますが、Pythonでコードを書く人は大体これに準拠しているため、これに乗っかっておくのが無難なのです。
コード品質
ガイドラインをつくってコードの形が決まったからといって、自動的に良いコードがつくられるというわけではないです。良いという言葉だけでは主観的すぎて基準にならないので、もう少し内容を詰めた方が良いでしょう。まついのぶゆき氏のスライド「良いコードとは」はとてもわかりやすくまとまっています。
O'Reillyの『リーダブルコード――より良いコードを書くためのシンプルで実践的なテクニック』は良いコードを書くために身につけるべき習慣を簡潔にまとめた良書です。この本の内容を一般教養として身に着け、これをベースとしてコードの品質に関する議論を進めていくのが良いでしょう。
そのほかにも、コードや成果物の品質について議論している名著は沢山存在します。ただ、個人で技術を高める目的で読むのは良いと思いますが、チームで最低限守るべきガイドラインを決めるのであれば内容を絞って共有した方が良いでしょう。前述の『リーダブルコード』はそのような目的に良い本です。
テストコードを書く
作成したコードにはテストを用意し、いつでも簡単にコードが壊れていないことを確認できるようにします。プログラムを書いたらその都度動作確認を行うかと思います。テストがなければ手動で気になる部分をいくつか動かして確認するだけに留まってしまいますが、テストを用意しておくことで、プログラム全体を自動的に動作確認できます。これにより、ある変更が思いもよらないところに影響を及ぼして問題を引き起こしてしまうような場合にも対応できるようになります。
テストコードを書くことは、自分がつくったプログラムのユーザーになることでもあります。自分で使ってみて使いやすいかどうか、テストが書きやすいかどうかを確認できるのもテストを書くメリットです。ただ、プログラムの性質上テストが書きづらいものも存在します。特にGUIまわりはテストが書きづらい上、GUIを更新するとこれまで書いたテストも大幅に更新しなければいけなくなることが多いです。
パッケージ化と配布
作成したプログラムの配布方法も整備し、最小の労力でユーザーに届けることができるようにします。Pythonで作成したソフトウェアの配布はwheel形式を使用するのが良いでしょう。wheel形式はPythonのパッケージで標準的に使用されているため、この仕組みを用いることで、pipやvirtualenvといったPythonで使える強力な機能を使用できます。
テストとパッケージ化・配布は直接コードの品質に影響するところではないものの、開発を進めると思った以上に対応に時間をとられる部分になってきます。ここでリソースをもっていかれると開発が進まなくなり、コードの品質にも影響が出てきてしまいます。そのようなことがないよう、体制を整えていく必要があります。
このあたりのお話はCEDECのTechnical Artist Bootcamp 2017 vol.1 「Automation for TA」でご紹介しているので、そちらも参考にしてください。
まとめ
今回は良いコードを書くためにどのようなことをすれば良いか、全体を俯瞰してみました。こうやって見ると、パイプラインやアセット管理のルールを決めていったときと同じようなことをしているのだと気付きます。ガイドラインを決め、ガイドラインから外れていないか手軽に確認できるような仕組みを決めることや、成果物が壊れていないか確認するためにテストを用意することは、アセット管理でチェックツールを導入したときと同じです。パッケージ化や配布も、外部の会社とどのようにしてスムーズにデータをやり取りするかを考えたときと似ています。このように、一見関係なさそうな事柄でも、上手く応用することでより良いものをつくることができるのは面白いですね。
第34回の公開は、2021年6月を予定しております。
プロフィール
