システム開発において、コードの品質をどう考えるべきかという議論に出くわすことがしばしばあります。
理屈の上ではコードが綺麗なことに越したことはないので綺麗なコードを書くべきではあるのですが、そこに納期やメンバーの能力・人数等の要素が加わってくると途端に話が複雑化します。
特によく見かけるのが、「綺麗なコードを書くべき」と主張する人と「動けば良いじゃん」と主張する人の対立です。
趣味のシステム開発であれば好きな方で進めればよいですが、仕事のシステム開発で好みで済ませるわけにはいきません。
長期的な保守・運用のコストを下げるために高い品質のコードを書くか、早急なリリースが必要なのでまずは最低限動くコードで済ませるかはなかなか悩ましい問題です。
どちらにもメリット・デメリットがあり一概にどちらが正解と言い切れないことも多いです。
そんな訳で今回は「綺麗なコードを書くべき派」と「動けば良いじゃん派」、そして僕おすすめの両者の折衷を目指す「バランス派」の3つのスタンスのメリット・デメリットを解説していこうと思います。
綺麗なコードを書くべき派
ここで言う綺麗なコードとは、保守や拡張がしやすいコードのことです。
コードが綺麗であれば、他の人が読んでも理解しやすいので保守性に優れ、拡張を考慮した作りになっているので拡張性も高いという考えです。
システムがリリースされてから時間が経てば経つほど保守や拡張をする機会は増えていくため、「長期的な目線でシステム開発を考えている」と言い換えることもできます。
技術力の高いエンジニアや、システムの設計についてしっかり勉強しているエンジニアがこの派閥に属していることが多い印象です。
メリット
綺麗なコードを書くことで得られる最大の利点は、長期的なメンテナンス性の向上です。
新しいメンバーが入って来ても、きちんとコードが整理されていればキャッチアップのコストが少なく済みます。
また各コードの責務がしっかり分担できていることが多いので、バグが出ても原因を特定しやすかったりします。
デメリット
比較的、実装に時間がかかることが多いです。
通常の実装時間に加えて設計をきちんと考える時間も必要なため、どうしても初期開発の工数は多くなりがちです。
またコードの品質を保つため、定期的なリファクタリングも必要となり、それも時間がかかる要因になります。
また、複雑な設計であればあるほど学習コストがかかってしまうこともあります。
特にまだ技術力の低い新卒メンバーや、環境に慣れていない新人メンバーがいる場合は要注意です。
動けば良いじゃん派
「とにかく動くものを作ることが最優先」という考えです。
リリースのスピードや市場への適応力を重視する考え方です。
将来のために時間をかけてコードを綺麗にするより直近のリリースのために動くコードを素早く作ることを重視しており、「短期的な目線でシステム開発を考えている」と言い換えることもできます。
ビジネス寄りの考えを持つエンジニアあるいはシステムの設計についてあまり詳しくないエンジニアがこの派閥に属していることが多い印象です。
色々な経験・知見があるエンジニアから経験が浅いエンジニアまで幅広い層がいることが多いです。
メリット
このスタンスの最大の強みは、開発スピードが速いことです。
必要最小限の機能がとにかく動くことだけを目的に実装を進めるので、綺麗なコードを意識した実装よりかなり早く実装が進みます。
特に、スタートアップ企業等の市場参入が急務の場合や運用を気にする必要のないプロトタイプの開発の場合は非常に効果的です。
デメリット
このスタンスで最も深刻なデメリットは、技術的負債が蓄積しやすいことです。
コードの品質が低い状態でリリースを繰り返すと、後々のメンテナンスが非常に困難になります。
運用が続けば続くほど、スパゲッティコードであったり同じ処理のコードがいたるところにあったりといわゆるシステム開発のアンチパターンが積み重なっていってしまいます。
最終的には何をするにも時間がかかるようになり、そもそものメリットであった開発スピードが見る影もないという悲惨な事態になりかねません。
バランス派
「綺麗なコードを書くべき派」と「動けば良いじゃん派」のどちらの言い分も一理あるのだから、どちらか一方に偏らず状況に応じて適切な判断をしようという良いとこ取りを狙った考え方です。
素早いリリースが求められるタイミングでは「動けば良いじゃん派」になりスピード重視の実装、開発が落ち着いてきたタイミングでは「綺麗なコードを書くべき派」になりリファクタリングを行う、というのがよくあるスタイルです。
メリット
最大のメリットは何と言っても状況に応じた最適解を選べる柔軟性にあります。
「綺麗なコードを書くべき派」と「動けば良いじゃん派」は基本的にメリットとデメリットがあべこべになっています。
「綺麗なコードを書くべき派」はメンテナンス性が良くなるが、開発スピードが遅いです。「動けば良いじゃん派」は開発スピードが速いが、メンテナンス性が悪いです。
これらのスタンスを適切に切り替えることで、ある程度の開発スピードを保ちつつメンテナンス性も確保する、みたいなことができます。
デメリット
「綺麗なコードを書くべき派」と「動けば良いじゃん派」のスタンスの切り替えの判断が難しいです。
誰が見ても「こっちのスタンスが最適じゃない？」みたいになるタイミングももちろんありますが、多くの場合は「どちらのスタンスでも一長一短かも？」みたいなタイミングが多いです。
判断を誤ると、最悪の場合は両方のスタンスの悪いとこ取りになりかねません。
また、チーム開発の場合はどういう時にどちらのスタンスで行くかの判断基準を明確にしておかないと、無駄に混乱を招いてしまうので注意が必要です。
どのスタンスで行くかの判断基準
ここまでで3つのスタンスを紹介しました。
ここで重要なのはどれが一番優れているかを決めることではありません。
開発するシステムに対してどれが適切かを判断することが重要なのです。
以下に判断基準の例を載せます。
緊急性の高い対応か？
納期直前にどうしても対応が必要な仕様変更や、運用中に重大な不具合が見つかって急ぎの対応が求められる場合があります。
そういった緊急性が高い場合は、スピード重視の「動けば良いじゃん派」が最適な可能性が高いです。
システムの運用期間が長いか？
長期運用前提のシステムであれば、コードの修正が発生する回数はかなりの数になります。
であればメンテナンス性が高い「綺麗なコードを書くべき派」が最適な可能性が高いです。
スキルレベルの低いメンバーがいるか？
スキルレベルの低いメンバーがいるのであれば「動けば良いじゃん派」で行くとものすごいコードが出来上がる可能性が高いので、「綺麗なコードを書くべき派」が最適な可能性が高いです。
さらに言うと綺麗なコードの中でも複雑な設計のものではなく、シンプルでわかりやすい設計を採用するとより良いでしょう。
修正・変更が発生しないか？
システムのプロトタイプだったり、非常に稀なケースでのみ発生するデータ不整合の修正バッチ等の、1度作ったらその後に修正や変更が発生しない(しにくい)システムというものがあります。
そういった場合は「動けば良いじゃん派」でさくっと作ってしまうのが正解の可能性が高いです。
まとめ
今回は「綺麗なコードを書くべき派」「動けば良いじゃん派」とその中間を取る「バランス派」の3つのスタンスについて紹介しました。
先ほども述べましたが、大事なのはどのスタンスが優れているかを決めることではなく、システムに対してどのスタンスが有効かを判断することです。
そしてその判断はあなた個人で完結させるものではなく、チーム全体で統一された基準であるべきです。
ぜひとも周りのメンバーとしっかり議論を交わし、適切なスタンスで効率的なシステム開発を進めてください。
コメント