適当な設計で実装した結果[仕様変更の闇]
今回は業務体験談になります。
エンジニアはただプログラムを組むだけでなく、上流作業として設計があります。
設計とは、要件に合わせたアプリケーションをどんなロジックで作るか、どんなクラスを作るかを決めるフェーズのことです。
でも簡単なアプリケーションなら、設計しないで実装した方が早くねえか?俺っち天才だから頭ん中で軽く設計できるしwwwっうえwwwwっうえww
とか思って設計せずに実装から入っちゃう方いませんか?はい、僕です!
そんな気持ちで実装した場合、どんなことが起こってしまうのか。実際に起こってしまった事実を、ありのままを暴露します。
体験談
作ったのが自社の社内ツールなので、内容はぼかしながら書きます。あと体験談ですが、分かりやすいようにシンプルに改変しました。秘密漏洩とか怖いんでね。
自社APIから受け取ったJSONファイルを、csvとかtsvに変換するツールが欲しいわ〜
クッソ楽だったんで、もう作りました!
やっぱAPI廃止するわ。DBから直接データ持ってきてくれや
APIの取得処理をDBに変更!ヨユーです!
受け取ったデータはこっちのコンバータで計算したあと、csvとかtsvにしてほしいな🎵
え…じゃあデータ受け取る部分と、変換する部分の処理分けなきゃ…
やっぱDBもやめるわ。S3に置いたからそっちで頼む。あと出力ファイルもS3に自動で保存しろ
氏なすぞ
実際とは若干違いますが、大まかにはこんな感じです。
一見失敗のしようがないくらい簡単なコンバータに見えますが、油断してはいけません
面倒くさがりなので、使わない変数を消さなかったり、既存の処理を無理やり改変して適用させようとすると、アホみたいなスピードでスパゲッティコードが出来上がっていきます。
原因
いや、それお前、スキル低いだけやん!てかもうちょっと丁寧にやれよwww
と思ったそこのあなた。言葉もありません。
だがね!こんなツールに時間をかけてられないのだよ!てか設計が無ければ、要件を満たすことだけが条件なのだよ?それ以外は早ければ正義なのだよ?フハハハハ!
(ここで上司のゴッドフィンガーが炸裂する)
今回の場合は変更しそうな部分を先に洗い出して、柔軟に変更できるようなクラス設計を考えたり、必要に応じて設定ファイルを作るのが正解でしたね。
結局最後にリファクタ作業とかする羽目になると、なんのためのスピードやねんってなります。
まとめ
1 2 3 |
<span style="color: #000000; font-size: 18px;">_人人人人人人人人人人人人人人人人_ > 仕様変更に耐えられる設計をしろ <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄</span> |
エンジニアは面倒臭がりな人こそ成長する!と言われていますが、設計フェーズは面倒臭がっちゃダメなんですね…。
今までは設計なんてしてるよりさっさと実装した方が早いやろwという考えで手を動かしてましたが、実装前に設計をしっかり決めておくことの重要性を、ひしひしと感じたtrs君でしたとさ。
皆さんもぜひ設計スキルを磨いて、仕様変更に耐えられるプログラムを作りましょう!ちゃんちゃん!