ボクココ

個人開発に関するテックブログ

ソースコードに「愛着」はあるか?

ども、@kimihom です。

f:id:cevid_cpp:20171015162220p:plain

今回はちゃんとしたソースコードを運用し続ける上で大切な考え方について記す。

あなたは読み直せるソースコードを書いているか

ハッカソンや 0->1 のフェーズの何が楽しいのかというと、真っ白なキャンバスに思いっきり絵を描いていけることだ。これから作ろうとしているのが自分の頭の中にあって、それを具現化していくステップってのはワクワクするし、完成した時の満足感もひとしおだ。

さて、そんな急ピッチで作り上げたソースコードってのは、大抵はひどく醜いものだ。ぐちゃぐちゃなソースコードに対してテストケースを書いていくのも大変だし、何しろバグも多く存在することだろう。しかし、それは最初のフェーズでは認めるしかない。どんどんと変わっていく仕様に対して柔軟にソースコードを変えていくのだから、当初考えていた設計と異なっていくことなんて日常茶飯事で、未来のことを見据えた完璧なソースコードを最初から生み出すなんて不可能だ。

だからこそ、唯一ソースコードを改善し続けることこそが、いいプログラムのコードを保ち続ける方法だ。そして、ソースコードを綺麗にし続けるには、ソースコードに愛着があるのか が重要となってくる。

ソースコードに愛着を保ち続けるってのは本当に難しくて、一度でも愛着がなくなってしまうと、自分や誰かの書いた酷いコードをそのまま放置したままの状態になってしまったりすることが頻発する。すると、「あの部分のソースにはもう手をつけたくない」となって、その部分のサービスの改善が困難となり、やがて開発スピードが劇的に落ちる。 最初作り始めていた頃に比べて明らかに開発速度が落ちている という感覚を感じ始めた頃には、もう手遅れだ。

エンジニアがそのプロダクトやソースコードに愛着がわかなくなるターニングポイントってのが存在する。

  • システムに関わるエンジニアがどんどん増え、"自分が書いた" という感覚が薄れていく
  • ある日誰かが書いたとんでもなく汚いソースコードを発見してしまい、メンテ不能であることを悟る
  • 周りのエンジニアのレベルが率直に低い、成果物の手戻りが多い
  • エラー通知やテスト失敗通知が来すぎて通知を無視するようになった
  • 不本意な機能開発を命じられてサービス自体に愛着が沸かなくなった
  • しばらくしてもサービスがそもそも使われていない

こうしたタイミングで、一気にソースコードに対しての愛着が薄れていく。流行りのクールな開発手法を取り入れたところで変わらない。むしろ、ソースコードに愛着を保ち続けることが、最も大切な開発手法 ではないだろうか。

なぜソースコードを美しく保ち続ける必要があるのか

こんな話はエンジニアにとっては至極当たり前なんだけど、「ソースを綺麗に保つことに時間を使ってビジネスにどう寄与するの?」みたいな、目の前のカネ儲けにしか目がない方々に向けて書いておきたい。

まずソースコードを美しく保ち続けるだけで、開発スピードは劇的に上がる。なぜなら、不用意なバグに悩まされ続ける時間を無くし、設計/実装時に悩む時間を無くすことができるからだ。誰かの書いた酷いコードに対して機能追加/修正/削除 するには、まずその酷いコードを理解しなければならない。それが複雑であればあるほど、最初のステップで大きくつまづいてしまう。んであまりに酷いと作り直しっていう荒技に出るしかなく、誰かのコードを書いたその時間は完全に無意味なものとなってしまう。

おっと、ここで大金で優秀なプログラマを雇えば OK とか言っても無駄だということを付け足しておきたい。途中でどんなに優秀なプログラマが入っても、最初にとんでもなく酷いメンテ不能なコードが目の前にあれば、それだけで開発者のやる気を失わせる。以前の負債を返済することがその人に仕事となってしまい、その人の持つ能力を最大限発揮することができない。酷いコードを整備していくだけで半年や1年はかかるので、それまではどんな優秀なプログラマが入っても開発が遅くなってしまう。それだけ「誰かが書いたコードを読んで修正する」って作業は難しいのである。

だから、最初から綺麗に保ちつづけようという意識が大切だ。最初ちょっと強引に書いちゃったコードがあれば、その後にちゃんと時間をかけて修正して改善していかなければならない。そんな地味な改善を繰り返すことで、初めてソースコードに愛着が持てるようになる。そんなソースコードが書かれたプログラムは、何かしらの修正に非常に強くなる。だからこそ、どんなビッグチャレンジでも受け入れられる開発体制ができあがる。

1つのシステムで人数をかければその分開発速度が速くなるってのが誤りであるのは、まさにこのことだ。人が多くなればなるほど、1人1人がソースコードに愛着を保ち続けるのを難しくさせる。「どうせ自分はそのうち辞めるし」とか「どうせ自分は雇われ給料もらってるだけだし」とか、そんなことをちょっとでも思っているエンジニアがいれば、愛のないコードが生まれ、一気に開発効率を落とす悲劇がいとも簡単に生まれてしまう。

だからこそ、1つのシステムで担当するエンジニアが少なくさせるのが重要だ。そうすれば、ソースコードに愛着のある割合が増え、結果的に開発速度が上がる。人月とか工数を計算したり、エンジニアの替えが利くようなマネジメントをしている人がいつまでたってもいいシステムが作れないのは言うまでもないだろう。

終わりに

あなたの書いたソースコードに愛着はあるか。

私の書いたソースコードには愛着がある。私がシステムの全てを知っているし、どこをどう修正しなければならないのか、機能修正や追加の時にどこを追加/削除しなければならないのかが全部わかる。そして何より私の書いたソースコードに根拠のない自信がある。常にコードを良くし続けているという自負があるからである。そんな状態だからこそ、愛着を持って開発することに幸せを感じている。 これをチームとしてキープできれば、最高のエンジニアチームが生まれ、劇的な開発効率の中でクールなサービスを保ち続けることができるかもしれない。

なぜ10人の中途半端なエンジニアより、1人の優秀なエンジニアなのか。本記事で少しでも理解いただけたら幸いだ。