適当な設計で実装した結果[仕様変更の闇]

2019年11月9日

今回は業務体験談になります。

エンジニアはただプログラムを組むだけでなく、上流作業として設計があります。

設計とは、要件に合わせたアプリケーションをどんなロジックで作るか、どんなクラスを作るかを決めるフェーズのことです。

でも簡単なアプリケーションなら、設計しないで実装した方が早くねえか?俺っち天才だから頭ん中で軽く設計できるしwwwっうえwwwwっうえww

とか思って設計せずに実装から入っちゃう方いませんか?はい、僕です!

そんな気持ちで実装した場合、どんなことが起こってしまうのか。実際に起こってしまった事実を、ありのままを暴露します。

体験談

作ったのが自社の社内ツールなので、内容はぼかしながら書きます。あと体験談ですが、分かりやすいようにシンプルに改変しました。秘密漏洩とか怖いんでね。

上司

自社APIから受け取ったJSONファイルを、csvとかtsvに変換するツールが欲しいわ〜

ぼく

クッソ楽だったんで、もう作りました!

上司

やっぱAPI廃止するわ。DBから直接データ持ってきてくれや

ぼく

APIの取得処理をDBに変更!ヨユーです!

上司

受け取ったデータはこっちのコンバータで計算したあと、csvとかtsvにしてほしいな🎵

ぼく

え…じゃあデータ受け取る部分と、変換する部分の処理分けなきゃ…

上司

やっぱDBもやめるわ。S3に置いたからそっちで頼む。あと出力ファイルもS3に自動で保存しろ

ぼく

氏なすぞ

実際とは若干違いますが、大まかにはこんな感じです。

一見失敗のしようがないくらい簡単なコンバータに見えますが、油断してはいけません

面倒くさがりなので、使わない変数を消さなかったり、既存の処理を無理やり改変して適用させようとすると、アホみたいなスピードでスパゲッティコードが出来上がっていきます。

原因

いや、それお前、スキル低いだけやん!てかもうちょっと丁寧にやれよwww

と思ったそこのあなた。言葉もありません。

だがね!こんなツールに時間をかけてられないのだよ!てか設計が無ければ、要件を満たすことだけが条件なのだよ?それ以外は早ければ正義なのだよ?フハハハハ!

(ここで上司のゴッドフィンガーが炸裂する)

今回の場合は変更しそうな部分を先に洗い出して、柔軟に変更できるようなクラス設計を考えたり、必要に応じて設定ファイルを作るのが正解でしたね。

結局最後にリファクタ作業とかする羽目になると、なんのためのスピードやねんってなります。

まとめ

エンジニアは面倒臭がりな人こそ成長する!と言われていますが、設計フェーズは面倒臭がっちゃダメなんですね…。

今までは設計なんてしてるよりさっさと実装した方が早いやろwという考えで手を動かしてましたが、実装前に設計をしっかり決めておくことの重要性を、ひしひしと感じたtrs君でしたとさ。

皆さんもぜひ設計スキルを磨いて、仕様変更に耐えられるプログラムを作りましょう!ちゃんちゃん!