よもやま話β版

よもやま話を書きます。内容はぺらぺら。自由に書く。

最高と最低限の開発グラデーション

とある機能を開発するにあたって、最高を目指す開発と、最低限の開発と言うものがあると思う。 ざっくり箇条書きしてみよう。
ただし、 どちらも要件は実現されていて、機能は正しく動いている ものとする。

最低限の開発

  • 設計がちょっとあやしい
  • テストコードがない
  • 命名がダサい
  • 野暮ったい実装
  • コピペコードを含む
  • 見落とされたtypoがある

最高を目指す開発

  • 将来のことも検討されているシンプルで美しい設計
  • メンテしやすいテストコードがある
  • よく検討された分かりやすい命名
  • スマートな実装
  • コードが適切に再利用されていて重複していない
  • typoなどの安易なミスは駆逐されている

開発のグラデーション

何事にもハイとローの2方面があって、そして選択肢はその両極端にあるのではなく、常にその中間のどこかにもたくさん存在する。 以前お世話になった方がよく言っていた「グラデーション」という単語を強く覚えていて、自分も参考にしている。 開発にもグラデーションがあって、時と場合に応じて一部取捨選択をする場合がある。

設計を綺麗にしきれずにある程度で妥協するとか、
テストコードが一部省略されたりとか、
安易なtypoミスを気づいたけど修正する余裕がないとか...。

その時々で納期とかチームの総合力とか、色々な周辺要素に応じて出来る限界は決まってくる。 もちろん最高の開発を目指すことがベストだが、要件の実現に対してかけるべきコストと天秤にかけてうまい具合に妥協点を探り、確実に要件を達成していくほかない。ベストな妥協点を探って実装に落とし込む力というのも重要なのだ。
そう自分に言い聞かせながら、今日も最高と最低の合間の出来の実装をmergeするのだった。

ちなみに

最低限の対義語、一応「最高限」というものがあるようだが、耳慣れない。 人間高みを見るとキリがない(から、限という漢字がつくと違和感がある)ということなのだろうか...。

kotobank.jp