プログラミングの学び方(7) – ソースコードの書き始め方のコツ

プログラミングの学び方(7) – ソースコードの書き始め方のコツ

最近、お悩み相談の1つとして、

プログラミングを始めたけど、どのようにして書いていけばよいかがわからない!

というお話を頂いた。

今回は、実際にプログラムを書くときに、素早く簡単にソースコードを組み立てるコツについてお伝えする。

いざとなるとプログラミングできない人達の共通点

いざとなるとプログラミングできない!というお悩みを抱える方々の共通点として、こんなケースが多く散見された。

  • プログラミングや言語の基礎知識はある
  • 設計書やフローチャートは読み書きできる
  • 実際に手を動かしてソースコードを組み立てられない

なぜ、彼らはいざというときにソースコードを書けないのか?

それは、主に以下の理由が考えられる。

  • 完璧を求めすぎ
  • 設計書を1から順番に書こうとする
  • 機能の中身から、関数や役割を分解するのに慣れていない

では、実際に上記の対策について解説していこう。

完璧を求めすぎ

プログラミングを始める場合、機能実装をいきなり完璧に仕上げるのは難しい。

その点、家の建築工法が非常に参考になる。

もし、あなたが家を作る大工になった際、柱を立てた後すぐに壁の取り付けや壁紙の貼り付けを行うだろうか?

そんな人はいないだろう笑

柱を取り付けたら、梁(はり)や屋根、外装工事を先にするはずだ。

つまり、

ソースコードを書く際は、いきなり完璧を求めようとしない

ほうがソースコードを書き始めやすい。

具体的には、

  • 処理フローの概要を把握し、ハリボテクラスや関数を作っておく。
    ただし実装忘れがないように、Todo管理を合わせて行う。
  • 変数の型を決めるのが難しい場合、いったんオブジェクトを渡す。
    変数の型が決まったらあるべき変数の型に変更する。

といった方法がある。

設計書を上から順番に読んで、その通りに書こうとする

大抵のプログラマは、設計書を渡されると、上から順番に読んで、その通りに書こうとする。

実はそのやり方が通用するのは、非常に処理が少ない機能までだ。

特に、複雑な機能になるほど、機能の影響を考える必要が出てくるし、そういったところは実装中にソースコードの変更が発生しやすい。

中~上級プログラマやリードプログラマなら、影響が大きい機能の実装を先に行ってメンバーに実装方針を共有するが、初級プログラマはそうもいかない。

つまり、

できるだけ機能間の影響が少ない部分から実装したほうが、手戻りや変更が少なくなり効率が良い

ということを知っておいたほうが良い。

機能情報や設計情報から、関数やクラスを分解するのに慣れていない

先ほどの設計書の話に近いが、実際の開発現場では、機能要件を元に設計書が作成される。

ところが、プログラミングを学びたい!といって始めた人ほど、機能要件や設計書から関数やクラスを分解するのに慣れていない。

○○○○というサービスを作りたい!

という動機であれば、作りたいものが明確なので、インプットやアウトプットも想像しやすいだろうし、機能要件から関数やクラスに落とし込みやすい。

ところが、実際の現場では、自分が想像もつかないビジネスモデルから要件が決まり、機能要件が決定されている。

もし、貴方が、機能情報や設計情報から、関数やクラスを分解するのに慣れていないのであれば、

  • 自分で作りたいものを考えて機能要件を決定し、実際に作ってみる
  • 設計書に書かれた機能の目的は何か?をSEやPL、PMに聞いてみる

といった意識を持つほうが良いかもしれない。

最後に

プログラミングは、結局のところソースコードをどれだけ書いたか?どれだけ手を動かしたか?で、上達のスピードは異なる。

だが、実際のところは、こういった細かい工夫で上達のスピードや実装スピードをコントロールすることも可能だ。

これからプログラミングを始める方は、参考にしていただければ幸いである。