プログラミング前に設計をしよう【設計なしの実装は恐怖しかない】
プログラミング初心者の方：
プログラミングに興味をもったので、試しにアプリを作成しているけど、コードの修正、追加を繰り返すから、コード全体の内容がわからなくなってきた。うまくいく方法はないかなぁ？
駆け出しエンジニアの方：
プログラミングにも慣れてきたから、設計なんてしなくても、いきなりコーディングから始めてしまっていいと
思っているんだけど、だめなのだろうか？
プログラミングスクールでとりあえずコード書きまくったり、駆け出しエンジニアの方は、
「プログラミング=コードをゴリゴリ書きまくる」
このようなイメージがあるかもしれませんが、これにより、コードを書く中でいろいろと悩みが出ることも事実です。
なので、今回はプログラミング前の”設計”の必要性について解説致します。
ここ数年は、Webプログラミングに興味をもち、フロントエンド、及びバックエンド(Ruby on rails)を勉強中
プログラミング前に設計をしよう【設計なしの実装は恐怖しかない】
プログラミングをする前には、設計をした上でコードを書くようにしましょう。
なぜなら、書いていく度に修正、追加を繰り返すことで、
- コード全体の内容がわからなくなってしまう
- 保守性が落ちる
このようになってしまうからです。
質問：設計なしでいきなり建てたビルに住めますか？
設計なしでプログラミング、つまりはコーディングやコード実装を行うとはどういう意味でしょうか。
それは、設計なしでいきなりビルを作るのと同じです。
ビルを建てる時、いきなり資材とかを運んできて、いきなりトンテンカンと音を建てながら建築を開始しないですよね。
- どんなビルを建てたいかを明確にする（絵をかくとか）
- どのような機能を有するかをきめる
- ターゲット層をきめる
- それを実現するにはなにをしたらいいかきめる
- それを実現すべく人的、物的リソースをきめる
おそらくこのようなことをきちんと決めたうえで、建築の作業を開始しますよね。
このように、どのようなものを作るかをきちんと決めてから実装に入るのは、プログラミングも同じです。
プログラミングにおける、設計の重要性は巷でも言われています。
なので、プログラミングをする前には、必ず設計をした上でコードを書く必要があるのです。
体験談：設計なしで書いたコードにバグがあり、炎上
ここまで偉そうに設計が大事だと言ってきている自分ですが、そもそも自分自身が設計を怠ることで不具合を出した経験があるので、設計の大事さを語るようにしています。
とある、計画段階でスケジュールが破綻したプロジェクトがありまして、そこでコーデイングを担当していました。
上記の通り、破綻したプロジェクトなので、もちろん時間、つまりは開発日程がありませんでした。
なので、じぶんは設計はそこそこに、とにかくコーディングしまくって、とにかく動くソフトを作ることに専念しました。
その結果、
- 消したと思っていた処理が残っていた
- 意図していない処理を行うコードとなっていた
- コードの書き方に一貫性がなく、読みにくいコードとなっていた
このようなこととなり、結果として、
- 量産直前に顧客部門にてバグが発覚
- 工場を止め、急いでソフト修正
- 関係区に平謝り
このような事態となってしまいました。
もし、開発段階できちんと設計をしていれば、ここまでのことにはならなかったでしょう。
なので、プログラミングをする前には、必ず設計をした上でコードを書く必要があるのだとそのときに実感しました。
どんな類のコードでも、必ず設計は必要なのか？
ここまでかくと、
「どんな用途のコードでも設計が必要なの？たとえばじぶんの作業効率化のためのツールのコードとかなら設計っていらないんじゃ？」
このように考える人もいるかもしれません。
確かに、リリース用のコードでなく、デバッグコードや、自身の作業効率のためのツールのコードは、かならずしも設計は必要ありません。
なぜなら、仮にそこにバグがあっても困るのはじぶんだけで、顧客に迷惑がかかることがないからです。
とはいえ、それでも、設計をおこなうことで、
- そのコードを作る際、もっと効率的に作業できる
- 業務としていざ設計をすることになる前に、設計の練習を行うことができる
このような利点があるので、やはりプログラミングをする前には、必ず設計をした上でコードを書くようにするとよいでしょう。
設計時に決めることは3つ【やりたいこと、やること、やり方】
これまで、プログラミング前には設計をすることが大事であることを解説しましたが、具体的に設計とは何をすればよいのでしょうか。
それは、下記の3つを決めることです。
- やりたいこと
- やること
- やり方
なぜなら、やりたいこと、やること、やり方のうち、１つでも欠けると、何をコード化するか決められないからです。
やりたいことは何か
やりたいことを明確にするとは、
- 顧客要求を自分の腹に落とすということ
- 開発工程でいうなら、要求分析工程に該当
このような意味です。
この段階で、「〇〇をしたら△△の動作をするようにする」などのように、操作と、それによりどうなるかを明確にしましょう。
例えば、Twitterを例にするならこんな感じです。
- いまやっていることや思っていることを気軽に外部に発信できるようにしたい
- 発信の履歴をのこせるようにしたい
- 発信内容は気に入ったらお気に入りに入れられるようにしたい
ここをやらないと、
- 顧客に要求されたことが網羅できていない
- そもそも検討違いなものをつくってしまう
- 違うものを作ると、それまでの工数が無駄となってしまう
なので、まずはやりたいことを明確にしましょう。
やることは何か
やりたいことを決めたら、つぎは、やりたいことをするために必要なこと、つまりはやることを明確にしましょう。
やることとは、
- 顧客要求の要件化
- 開発工程でいうなら、要求分析工程の中の要件定義に該当
このような意味です。
たとえば、Twitterを例にするならこんな感じです。
- 要求：いまやっていることや思っていることを気軽に外部に発信できるようにしたい
- 要件①：入力する画面を用意する
- 要件②：入力内容に文字制限をつける
- 要件③：入力した文字を通知するボタンを用意する
こんな感じです。
ここをやらないと、
- 顧客要求を実現すべく、やらないといけないことが漏れる
- 後から、「やっぱこれも必要だった」ということとなり、手戻りが発生してしまう
- 実はそれは社内の別サービスのコードですでに実装されていたコードなのに、知らずにイチから設計、実装して工数を無駄にしてしまう
なので、やることを明確にしましょう。
やることは実現すべくやり方は何か
やることを明確にしたら、あとはその実現手段を明確にしましょう。
やることとは、
- 要件に対する仕様の決定
- 開発工程でいうなら、詳細設計に該当
このような意味です。
たとえば、Twitterを例にするならこんな感じです。
- 要求：いまやっていることや思っていることを気軽に外部に発信できるようにしたい
- 要件①：入力する画面を用意する
- 仕様①：入力画面の遷移は、〇〇ボタンを押した時、及びキャンセル処理がされたときの２パターンとする
- 仕様②：入力画面の大きさは、縦〇px,横〇pxとする
こんな感じです。
ここをやらないと、
実際にコードを組む際、コード実装するネタを思いつきでコーディングすることとなるので、
- 保守性が低いコードを作る恐れがある
- 上記により、知らず知らずの間に、バグを埋め込んでしまう恐れがある
なので、やり方、即ち仕様決めをきちんと行いましょう。
わかりきった内容でも設計は必要なのか？
ここまでかくと、
「すごく変更量が小さく、やることがわかっている変更でも、きちんと設計をしないといけないの？変更量が小さいので納期が短く、そこまでやってる余裕がないんだけど・・・」
と思う人もいるかもしれません。
確かに、このような状態なら設計なしでいきなりコーデイングをすることは可能でしょう。
とはいえ、なにが起こるかわかりません。
たとえばこんな感じです。
- 変更小といっておきながら、いざ設計したら、その変更による影響度が大きく、開発日程がミートしないことがわかった
- いざ設計してみたら、類似の処理があることが判明し、そこと今回変更点を共通処理としてくくりだすため、思ったより工数がかかることがわかった
なので、やはりやりたいこと、やること、やり方の3つを明確にした上でコーディングするようにするとよいのです。
ということで、いきなりコーディングはやめましょう
ここまで解説したとおり、いきなり設計なしでビルの施工に入るような真似は絶対にやめましょう。
きちんと設計して、その通りに実装することで、安心して暮らせるビル、つまりはバグや不具合のないコードを提供できるようにしましょう。
今回は以上です。