プログラミングは達成と反省とか言ってみるquneプログラミングは達成と反省とか言ってみる2009/04/13なんだかここのところ,説教くさい話ばっかなんだけれども,こちらの話から。Blog日経パソコン9月25日号の投書欄:大学でプログラミングの授業を受けていて,言われた通りにすれば確かに動くのだけれど,「どうしてそうなるかという理論が理解できないので応用することがなかなかできません」。この学生さんに何かアドバイスしてあげてくださいコメント欄にもあるけれど,少し書けるようになってからならともかく,プログラミングを始めたばっかの時期は,理論よりも実践の方が大事なんじゃないだろうか,とか思ったりします。実践といって堅苦しかったら「情熱」とか「執念」とか「意地」とかでもいいと思う。作るにはどうすればいいのかばっか考えていました。あの頃は,半ば意地になってプログラミングしてた気がする。「ファミコンしたら負けだと思う」みたいな。実務に入ると,「動くからオッケー」みたいな話は通らないわけで,理屈に基づいて実装なり設計なりの趣旨を他人に説明できないといけないんですけどね。少なくともこの業界では,理論と実践が,ピタリとうまい具合にかみ合うことは少ない感じはします。んなもんで,「理屈を身に付けてから実践」みたいな段取りを取ろうとすると,却って遠回りになってしまうんだと思う。ことで,大学の講義はさておき,プログラミングの練習をするにあたっては,こういうことをしてみたらどうだろう。これ,今新人君に振ってるメニューそのまんまなんですが。どんな技術・言語を使うかはさておき,ともかくお題(今どんなソフトが欲しいか)を設定する。それに基づく外部設計を作ってみる(画面とかを絵に描く)。外部設計を実現するのに必要な技術的な要件を洗い出してみる(技術的にできなそうだから外部設計を変える(逆戻りする)ことは許さない)。何があっても作りきる。ウォーターフォールそのままなんですけれど,普通の職業プログラマがあまり経験しないだろうことに,「要件を実現させるためだったら,どんな技術を使ってもかまわない」としているところがあります。アプリでも,何作ってもいい。すれば,当初のモチベーションを実装段階でも維持できるんでねいかな,と。自分で選択したそりゅーしょん(半笑い)ですしね。要件を決めるにあたって,「作りやすいから」という理由はナシということにしました。作りやすいだけで使えないもんを作ったって,仕方ないからです。んなもんで,外部設計のレビューでは,営業さんにも参加してもらって,胸を張ってアピールできるセールスポイントをプレゼンしてもらうことにしました。ちなみに,新人君には,社員名簿の管理システムを作ってもらってます。構成で,画面数にすると20画面くらいあったので,ひとりで(設計から実装まで)やるにはちと規模が大きいんですけどね。ここは意地でもひとりで作ってもらう。できたら自信になると思うから。要件が決まったら,あとは何としてでもそれを完成させてもらうだけです。情報を収集するにあたっては,何を調べてもいいし,誰を使ってもいい。人に聞くときは,ビジネスマナーも身に付くので,一石二鳥です(ややジョークだけど)。こゆ切羽詰った状況を無理にでも作ると,かなり短期間で上達するんだと思う。ない人もたくさんいることは,よく知ってるんですが。趣味でプログラミングをしている方や,まだ学生さんの方は,こゆプレッシャーのかかる場面を設定することは難しいと思います。趣味でやってる人はどんどん自分で作るのが普通だから,特にプログラミング「やらされてる」学生さん。ゆ方は,「これ作れなかったら負け」みたいな一線をどこかに設けておくのがいいのだと思う。いまどきはネットも活用できるし,直接的であれ間接的あれ,作るのに役に立ちそうなことは,いくらでも手に入ると思います。実際作り終わってみると,最初は達成感でご満悦だけれども,次第にあちこちに粗が見えてきます。全力で頭を使って考えたにもかかわらず,「ここはこうしとけばよかった」とか「他の人はもっとうまくやってるな」とか「もっと効率のいい理論があった」とかいうとこが見えてくるんですね。こゆのが見えるようになるってのが,まずひとつの成長なわけで,実装テクニックってのは,こゆ達成と反省を繰り返して積み重ねるもんなんじゃないかと思うわけです。ここら辺を端折って,すべてを網羅した理論から身に付けて......なんて横着しようとすると,却って遠回りになってしまうんだと思う。なんだか精神論になっちゃってるけど,あたしも含めた凡人は,こうやって身に付けるのがなにげに近道なんだよな,と。