やっぱりユーザーが始めに動かすところから順番に作るのが一番かな。。
こんにちは、古賀です！
本記事では、
はてな
「プログラムはどこから作っていくべきなのか？」
「どのような順番で作っていくべきなのか？」
という疑問にお答えしたいと思います。
プログラム開発の「スピード」と「質」を上げるためには、作る順番がカギを握ります！
順番を変えるだけで、ミスなく一気に出来上がる感覚が味わえます！
その作成手順のイメージと具体的な順序について、解説します！
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働きまして、現在フリーランスをしております。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
「一流思考」の記事をまだ読んでいない方は、
本記事の前に、こちらの記事をお読みください！
本記事は、この「一流思考」に沿った具体的行動の１つです。
-
-
エンジニアとして成長するための考え方！一流へ成長する方法とは？
エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。 こんにちは、古賀です！ エンジニア ...
続きを見る
※YouTubeに同内容を公開しております。
プログラムの作成手順の前に「イメージ」が大事！
具体的なプログラムの作成手順の前に、作り方のイメージを伝えておきます。
抽象的なのですが、こういった抽象的なことを理解できるとレベルはグッと上がりますよ！
では、そのプログラムを作る時のイメージですが、
「まず土台を作って、土台ができたらその上を作り上げていく」
というイメージです。
これだけでは伝わらないと思うので、「トランプタワー」を例にして説明します。
つたない図ですが、イメージを膨らまして頂けると幸いです！
「４段トワンプタワー」を作るとします。
タワーを「２段タワー」⇒「３段タワー」⇒「４段タワー」と、
完成品を徐々に大きくしていくのではなく、
まず「４段タワーの土台」一番下の段を作って、
土台の上を作り上げて、タワーを一気に完成させるイメージです。
どうでしょう？伝わりましたでしょうか？
あくまでイメージですので、
「こんな感じね？」
くらいで大丈夫です！
押さえておいて欲しいことは、
ポイント
「完成形の大きさや、必要な材料を最初に把握しておく」
ということです。
徐々に大きくしていって、
「作った結果、これくらいの大きさになりました！使った材料はこれくらいです！」
ではダメなんです。
あらかじめ、
「完成品はこれくらいの大きさで、必要な材料はあれだな。。」
と予測しておくのが重要です。
この意識で経験を積んでいくと、プログラムのスピードと質の他にも、
「工数見積能力」も身に付きますよ！
イメージが付いたところで、
（※ついていない方はスイマセン！）
プログラム作成の具体的手順を説明していきます！
プログラム作成の具体的手順
具体的手順は以下です。
- 全体に目を通す
- 画面デザインを作成する
- 空っぽのイベントと関数を作る
- 関数の中身を作る
- イベントの中身を作る
- 全体に目を通す
まず全体に目を通す
完全にまっさらな状態でプログラム開発するのであれば、本作業は不要です！
次の工程に進んでください！
ただ、プログラムを変更することが目的だったり（いわゆるカスタマイズ）、
他のプログラムをベースにして新たなプログラムを作る（いわゆる流用新規）のであれば、
「プログラム全体に目を通す」
ことから始めましょう。
わたしの場合は、ソースコードの上から下までザーっと目を通します。
深く読まなくても大丈夫です。
「これはあれをしているところで、こことここが繋がっていて。。」
とざっくり理解しておく程度で大丈夫です。
このあたりはこちらの記事で触れてますので、
こちらの記事をまずは読んで頂ければと思います。
-
-
優秀なプログラマーは準備が違う！勝負はコーディング前に決まる！
プログラマーとして働き始めたけど、 まだまだバグも多いし、作業スピードも、周りからの信頼もいまいち。。 なんか効率が良くなる裏技みたいなやり方はないかな。。 こんにちは、古 ...
続きを見る
画面デザインを先に作る
実際のプログラム作成に入りますが、まずは「画面デザイン」を作ってしまいましょう。
各コントロール（オブジェクト）に名前を付けていないと、
コードが書けないので、そのためにも先に画面デザインを作りましょう！
ただし、
注意ポイント
「コードによって、デザインの作りが変わる可能性がある部分は後回し」
です。
具体的な内容を言うと、帳票デザインとかですね。
データ取得の仕方次第で、帳票デザインの作りが変わる可能性があるので、
その場合はデータ取得処理を作成した後に、デザイン作成をしましょう！
必要なイベントと関数を作成（空っぽでＯＫ）
次に必要なイベントと関数を作成していきましょう。
※プログラミング言語やフレームワークによって、
言葉の表現が変わるかもしれせんがご容赦ください。
この時、中身は書かなくても良いです。
やりたいことは、
「必要な処理の洗い出し」
です。
「あの処理が必要そう。。」
と頭の中にあるイベント、関数を全て書き出しましょう。
イベントと関数を作成すると同時に、
頭の中で「完成イメージ」を膨らませましょう！
これこそが、「トランプタワーの土台を作る」作業です。
関数の中身を作る
イベントと関数を書き出し終えたら、
イベントは一旦置いておいて、関数を作っていきましょう！
関数の作成は、
「データアクセス系を先に作る」
※データアクセスしないプログラムは無視してＯＫです。
ことが大事です。
なぜかと言うと、そのプログラムのキモの部分、メインの処理だからです。
ここから作ることで、さらに頭の中で完成イメージが出来てきます。
またデータベース設計にミスがあるのであれば、早めに見つけておきたいからです。
それが終わったら、データアクセス系以外の関数を作りましょう。
難しい関数を作る場合も、同じ要領です。
まず関数全体の土台を書いてから、中身を詰めていくイメージです。
少しずつ動かして確認できるように、
イベント側から作り始めたい気持ちはわかりますが、ここはガマンです。
「ちょっとだけ作ってデバッグ作戦」は時間が掛かりすぎますし、無駄も多いです。
コードを書いた直後は正しく動作しても、
すべてが出来上がったらバグが発生していることもありえます。
デバッグは全体を作り終えてから、集中して行うことをオススメします！
イベントの中身を作り、全体を完成させる
関数が出来上がったら、イベントの中身を書いていきましょう。
材料（関数）はすでに出揃っているので、あとはパズルのように組み立てるだけです。
組み立てていくと、こう思います。
「一気に出来上がる～」
結構気持ち良いです(笑)
イベントを書き終えたら、ようやく動作確認ができます。
作りながら動作確認をしないと、不安になるかもしれません。
そんな方へ１つアドバイスを送ると、
「はじめの内はイベントから作り始めても大丈夫！」
本記事のやり方は、経験を積んでいかないと難しいです。
慣れてきたら、少しずつ土台から作る方法へシフトしていきましょう！
一度でも成功体験を味わえば、この方法しかできなくなりますよ！
最後に全体を読み返す
最後に全体を読み返しましょう！
やることは最初と同じです。プログラム全体に目を通しましょう。
意識して欲しいところは、
「やり残しがないか？」
「目を通してて違和感があるところがないか？」
の２点です。
目を通していて、漏れが見つかったら、その場で書き足しましょう。
「違和感があるな」と感じたところは、そこを中心にデバッグしましょう。
特に違和感がなく、目を通していてしっくりくるところは、
そこまでデバッグに時間を掛けなくて良いです。ちゃんとできてます！
土台から作っていくやり方であれば、出来上がったプログラムに対して自信が持てるはずです！
その自信の大きさと、バグの少なさは比例の関係になっています。
これが「一流思考」の力です！
まとめ：プログラムを作る手順は？
ここまでの話をまとめます。
まとめ
プログラム開発のスピードと質を高めるには、
「まず土台を作って、土台ができたらその上を作り上げていく」
イメージで作る！
具体的手順は、
- 全体に目を通す
- 画面デザインを作成する
- 空っぽのイベントと関数を作る
- 関数の中身を作る
- イベントの中身を作る
- 全体に目を通す
完成形と必要材料をイメージして、土台を作り上げていく意識で作ろう！
プログラムを作る手順について説明してきましたが、
慣れてくると各工程を同時にできるようになってきます。
わたしは、全体に目を通しながら、関数の中身を作り、
イベントを作り、各処理を繋げ合わせたりしてます。
ソースコードを上から順番にザーと見ると同時に、必要な処理を書いていく感じですね。
全体を見るのは非常にめんどくさいんです。
このやり方を後輩に教えても、実際に試してくれる後輩は少なかったです(笑)
でも、これをやるとやらないではミスの数が全然違います！
サボるとあからさまに出来が違うので、必ずやるようにしています。
完成した後の自信も全然違います。
自信は大事です。
その湧きあがってくる自信を一度味わってください！
これが「一流思考」のやり方です！
