私は PPP (Pseudocode Programming Process) というのをやっています。これはとてもオススメなのですが、日本ではあまり知られてないので是非広めてください。
あともう1つはテストドリブン開発 TDD あるいは、テストファーストという手法です。こちらはかなり広まってますので詳しくは書きません。
業務で書くコードは基本的にすべて、この2つの組み合わせで進めます。 （趣味で書く使い捨てコードの場合はテストなしでPPPだけということも多いです)
TDD+PPPの進め方を具体的に紹介しましょう。
まず、「要求仕様」が上から降ってきますね？
これをテストコードとして実装します。
そして、テストをパスする空っぽのコードを書きます。 (あるいはテストコードに未実装フラグを立てます)
次に「擬似コード」を書きます。
これは日本語でもいいし、慣れ親しんだプログラミング言語に似せてもいいし、完全な自家製言語でもいいでしょう。この時点では「こういう書き方は可能か？」「こういう機能は用意されているか」といったことは全て無視して、とにかく実行すべき処理を最初から最後まで全部書きます。
一通り書いたら、擬似コードをリファクタリングしていきます。共通部分をまとめて関数化したり、複数箇所で参照される定数に名前をつけたりします。
どのようなデータ構造が必要で、どういうメソッドにどんな引数を渡すべきか、この時点でだんだん明らかになっていきます。
クラスやモジュールを作る場合には、「どういうふうにそれを使えたら気持ち良いか？」を優先し、呼び出す側のコードを先に書きます。ついでにテストコードも書きます。テストコードを見れば、そのクラスをどのように使えば良いか分かるように書くと良いでしょう。
テストは適宜グリーンになるように慎重に進めていきます。これは慣れないうちはまどろっこしく感じるでしょうが、長期的に見れば有益です。
テストファーストで開発を進めていくと、要求仕様の不足やバグにいち早く気付くことが出来ます。仕様の詳細を詰めていきます。
動くコードで表現出来た擬似コードは削除します。少しずつ置き換えていくわけですね。
PPPが煮詰まってくると、汎用的な部品がいくつかみえてくることでしょう。そうなってきたらライブラリを検索します。 Javascript なら npm、 ruby なら gem、 python なら pip ですね。あるいはもっとコンパクトなものなら、 stackoverflow や gist からコピペしてくることもあります。
いずれにせよ、個別の要求に固有の問題(いわゆるビジネスロジック)を分解していくと、それは必ずどこかの段階で汎用的なソフトウェア部品の集合になっています。この汎用品を出来るだけ大きなサイズでくり抜けるのが優秀なプログラマの素養と言ってもよいでしょう。
ちょうどよいライブラリが見つかればそれを使います。無ければ自作します。場合によっては自作したものを公開します。公開したものが有用であれば、それは別のプログラマーによって改善されたり、最新のミドルウェアに追従するようにメンテナンスを手伝ってくれる人が現れたりします (そんなにうまく行く事は滅多にないですがそういう夢を見るのはいいものです)
最終的に、
- 要求仕様は細部にわたってテストコードで表現され
- 擬似コードの一部はコメントとして残り
- 大半は可読性の高いコードに変換され
- その過程で作られたソフトウェア部品については、その使用法がテストコードで表現された
という状態になります。これで1つのタスクが完了し、次のタスクへと進んでいきます。
追記:
考えながら書いたのでとりとめのない感じになってしまいましたが、この方法の肝は「トップダウンで書く」ということのような気がします。
普通に言語を学んで書き始めると、どうしても自分が書きやすいところから、書けるやり方で書いていく、というボトムアップのやり方になりがちです。
PPPもTDDも、トップダウンでコードを書いていく手法と言えます。中身のないコードの外側だけを書くことが許されるからです。