StiLLはコーディングせずにプログラムが作れるので、気力の消耗が少なく、ついつい懲りすぎてしまう。作っている最中は思いついた必要性に基づいて機能を強化していくわけだが、総体として見た場合のシステムの規模が大きくなりすぎ、トレースする人の立場に立つとやり過ぎ感がハンパないことはしばしば。
ユーザーが自分一人だったり、自部署限定のシステムの場合はそこまでひどい複雑な状況にはなりにくいが、不特定多数のユーザー、役割の違う複数のユーザーが共同作業することが前提のシステムの場合、どうしたって必要な機能・制御が増えてしまう。
そこの手を抜けば、お守りが大変なシステムに成り下がるし、想定外の使われ方によって不具合が頻出してしまうから、怖さが勝ってどうしてもガチガチな方向に引きずられる。
更に、開発は試行錯誤の連続だから、あとから見ると分かりにくく、無駄も多い。試行錯誤の結果、不採用としたプログラムを残したままにしたら、トレースする人を混乱させてしまう。
これは凝り性ゆえの悩みのような気がする。では凝り性じゃない人はプログラマーになれないのだろうか。
凝り性でない人のプログラムとは
自分が凝り性であることを自覚しているため、凝り性でない人の立場でプログラム作成することをイメージすることが難しい。凝り性でなければしっかりしたシステムを作れないのではないかとも思ってしまう。
でも、技術的な壁が下がっているので、凝り性でなくともスキルは身につけられるし、どうしても必要なシステムで、作ることでの自分に対する見返りが大きい場合、やりとげるだけの気力は維持できるだろう。
性格上、大抵は機能不足でスタートし、使いながら必要な機能を追加するスタイルになるだろう。トレースのしやすさという視点では案外評価が高いかもしれない。
凝り性のプログラマーの心構え
プロトタイプを作ってリリースしたあと、半年、一年を過ぎて、清書をする的な感じで作り直すべきだろう。
更なる苦労を背負うことにはなるが、凝り性でなければできない芸当だし、清書して初めて凝り性なプログラマーが真に高評価を得られることになる。
作ったばかりでは気力が萎えているし、使ってみて、恐れていたような使われ方は起き得ないことが分かって、やり過ぎな機能部分がどれなのかを特定できたり、使われ方をみて、構造的に再設計した方がいい部分が見えてきたり、時間が経過した間に身に付けた新しいノウハウを駆使すればよりエレガントなシステムに仕上がる目処がついたりとか。
果てしないわ。
コメント