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

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

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

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

なぜ、彼らはいざというときにソースコードを書けないのか？
それは、主に以下の理由が考えられる。

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

完璧を求めすぎ

プログラミングを始める場合、機能実装をいきなり完璧に仕上げるのは難しい。
その点、家の建築工法が非常に参考になる。

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

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

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

ほうがソースコードを書き始めやすい。
具体的には、

といった方法がある。

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

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

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

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

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

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

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

先ほどの設計書の話に近いが、実際の開発現場では、機能要件を元に設計書が作成される。
ところが、プログラミングを学びたい！といって始めた人ほど、機能要件や設計書から関数やクラスを分解するのに慣れていない。

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

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

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

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

最後に

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

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

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