どう足掻こうとNULL

nullに対してのメソッドコール？　なんだかしらんがとにかくヨシ！

潔癖症による開発手法について

poem tech

要約

  • これは技術記事でない。
  • 真面目に勉強してきた人物ほど思考停止しやすいことが多い。
  • 費用対効果を考えよう。

目次

始めに

まずもって、今回論じる対象となる人物像は、プログラミングによる開発を仕事にしようとしている、ある程度基礎を学んだ人、としていることを明示しておく。
筆者も過去そうだったし、今でもそういうきらいはあるのだが、いわゆるプログラミング中級者が嵌りやすい状態として、コードの良し悪しに対する過度な潔癖症が挙げられると考えている。そして、特にこれは技術を好む人種に多く見られる傾向がある。更に範囲を狭めるなら、バイブルをリーダブルコードやテスト駆動開発、Effective系列の書籍としている人物たちとも言えるだろう。
彼ら、あるいは読者の諸君に言える共通項は、原理主義と教条主義を兼ね備えているということだ。学んだ書籍によいと書かれていることを目安に、よりよいコードを書こうとする。その精神は諸手を挙げて歓迎すべきものだが、ある種強迫的にコードのクオリティを上げるために、必要以上にクロージャを嫌って関数の透明性を担保しようとしたり、厳密にテストしても効力の薄い部分までもを網羅して書こうとしたりする。
そういった面を修正しないままにしばらくプログラミングを続けた結果、筆者の身に起こった失敗をこの記事では綴っていこうと思う。

では以下からがこの記事の本文だ。

前提

あるプロジェクトにおいて、かなり肥大化したUtilが発生した。
それを、よりよい開発という筆者の中でのクオリティの尺度に従って外部ライブラリとして移行したときに起こったのである。
移行したのは肥大化する兆候が出てすぐだったため、まだ要件は明確に決まっていなかったのも重要だ。

失敗

必死になって肥大化したUtilを外部ライブラリへと移し切り、更に別のライブラリを利用する形でコード量の削減も行った後のことになる。
それを一、二か月ほどかけて作り上げたのだが、メインのプロジェクトに移行してそれを利用したとき、あるエラーがビルド時に起こった。何の変哲もない変数宣言が構文エラーとして検出されていたのだ。それの原因を調べるとどうやら、隔離した外部ライブラリで利用している別ライブラリのコードのバージョンが、メインプロジェクトのコードのバージョンと噛み合っていないことが判明した。
ビルド時に特定のライブラリのみバージョンを下げる、ということが少なくともそのときの筆者には不可能だったため、これの利用を断念した。そして別ライブラリと同一の機能を持つ他のライブラリを利用する形で外部ライブラリを組み上げ、大幅な仕様変更も乗り越えてようやく形にしたところで、今度はそのロジックそのものが必要ないのでは、という結論に至ってしまった。

問題

まず持って言えるのは、事前の要件定義と問題となりうるケースの想定が甘かった、ということだろう。
勿論それも重要だが、今回論じたいのはそこから少し離れた部分だ。
というのも、事前の要件定義が明確となるまで外部ライブラリへの移行は待ってもよかったのではないだろうか。たとえば、外部ライブラリへ隔離してから新たなライブラリを今回導入したのだが、それは別段メインプロジェクトで置き換えて上手くいってから行ってもよかったはずだ。また、そのプロジェクトが完成してから、保守性を上げるためのリファクタリングの一環として外部への移行を行ってもよい。
つまるところ、それらは明確な問題意識無しに、なんとなく悪いと聞いているからその通りに直そう、という風に思考を停止したまま行われたからこそ失敗を生んだのである。
筆者の考える今回の一番の問題は、問題に対して真摯に自ら考えるという当たり前のことを放棄していたことに他ならない。

改善

改善法としては、コストパフォーマンスを重視する、というベクトルの思考を持つようにした。
こう書くと主語が大きくなってしまうが、結局開発とは要件にあったものを仕上げればよいのであって、その手段、経過等は事前に決めたルールに則ってさえいればなんだっていいのである。勿論、その要件にはメンテナンス性であったり、技術的負債を可能な限り取り除くというものは含まれる。そこまで明確に縛りがあるのなら、なんだっていいと言えるかどうか微妙なところではないかもしれないが。
これに最も適合する例としては、コード規約が挙げられる。たとえばPythonで変数名をケバブケースにしたところで、そこにチームの同意さえあれば何の問題もないのだ。ケバブケースで変数名を記述する場合、特殊文字が含まれるからダブルクォーテーションでエスケープするなど、非常にトリッキーな手法を用いることになってしまい、チームの同意が得られる場合はそうそうないので現実味がないかもしれない。
ともかくとして、コードの良し悪しというものは得てして変わるものであり、それを妄信するのは危険なのである。
こうした尺度に比べ、コストパフォーマンスというのは基本的にはあまり変わらない。こういったコードの記述をすれば、こういった動作をして、結果としてバグを潰す。ならばこのバグを潰すための労力はこうで、それなら許容範囲内の比率だから問題ない。このように、やり方がいくつかある上での時間及び労力含む費用対効果を考えるのは非常に建設的である。むしろ教条主義とはかけ離れたリアリズムに位置する手法であり、場合によっては一般的な良し悪しを無視するのも忌諱しない考え方だ。
コストパフォーマンスの重視に関して、出来上がる物の質が悪くなってしまうのではないか、という危惧もあるだろう。しかし要件を満たしている以上、事前に作ると決めたアプリケーションはできているのである。もしそれでも質に関して思うところがあるのなら、そもそも要件に質に関するものを加え入れればよいのだ。
重要なこととして、事前に決められていない、する必要のない努力をしても報酬は変わらない。故に、質に関しても、その他要件に関してもルールを守りさえすればよいのである。

今回の記事は以上である。

終わりに

これを書くに当たって、筆者個人に少なくない影響を与えた言葉がある。筆者がある方に、自分はコードに関して潔癖症すぎるきらいがある、とこぼしたものへの返答だ。
曰く、自分は時間と労力に関して潔癖症なだけだ、ということだった。
確かに言われてみればその通りだし、プロとして労働力を対価に報酬を得ているのであれば、自身の生み出す労働力にはシビアにならざるを得ないと言えた。自分自身は商材であり、安すぎても高すぎてもよろしくないのである。
その場その時ではただ聞いただけだったが、今にして思うとこれが非常に腑に落ちる。有難い言葉だと素直に思う。