先日、リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないかというエントリを書いたのですが、こんなことを思ったのもある思い出話があったからでした。
「どうしたらこんなコードを納品できるの！？」
僕にとってのはじめてのオフショア。外部設計書を書いて「これ作ってねー」と海の向こうへ投げるだけの簡単な仕事を引き受けまして、設計書を投げた後、いい感じの時間が過ぎた頃に「どれどれ」とコード（PL/SQL）を見てみたのですが、
「このプロシージャ、すごく・・・長いです・・・」
・・・うーん、外部設計書の章単位でプロシージャが区切られています。
確かにまぁ、設計書通りっちゃ設計書通り。
しかしいろんなプロシージャ間での処理が書かれていてDRYじゃない。共通の設定を読み出すところもハードコードされているので、仕様変更したいときに死んでしまいそう。
「どうしたらこんなコードを納品できるんじゃい！？ 海の向こうのプログラマは頭おかしいんちゃうか！？」
と、一人ブチ切れていたのを今でも思い出すのですが、しかし思い返すと、海の向こうの人的には何らおかしくない出来事だったのではないか？と、今なら思えます。
- そもそもコードを書いた人自身がメンテする訳ではない。
- 外部設計通りのコーディングをするな、と言われても、設計書通りに作らないことで文句を言われるリスクの方が高い。
- いざメンテをする、という仕事が回ってきて、保守性が低いせいで工数がかかったとしても、その分の工数を見積もって上乗せすればいい。
コードを綺麗にする、リーダブルにするモチベーションって、あくまで自分がそのコードにずっと関わっていくから生まれるもので、「このコード書いてね、書いたらあなたの仕事は終わりだよ！」という単発の仕事から生まれるものではないよなーと、はっきり分かるんですよね。
「プロとしての誇りがあればメンテナブルにするでしょ」というのも、どうでしょう。逆にプロだから、こういうことが起こるのかもなー、とも思います。
良いチームづくり・コードづくりのためには、体制・文化から考えないと良い結果が生まれない、ということを痛感する出来事でした。
