あるスクリプト書きの考え方

この記事では、スクリプトコードのアウトプットなんぞ書きません。
あと、まだOMENとどいてないので、カッコいい絵もないです。

さて、あるスクリプト書きの御仁は、なにかパラメやSGやトラブルシュート依頼されたり、なんか思いついたら、基本自動化できないか、から考えます。なぜかというと、目的を明確にしておかないと、ファットでツブしが効かないクソコードにしかならないからです。
障害対応手順出すときも同じです。
その、目的を明確にするための手っ取り早い方法が、結果をイメージしてから作ること。
つまり、自動化です。
VBAでも同じです。

ということで、手順もスクリプトも、モジュールを意識して書きます。

モジュールなので、大目的、中目的、小目的とブレイクダウンします。セルフウォーターフォール的な感じです。

大目的とは、目的、前提です。これを満たすために中目的があります。
中目的とは、機能の実装方式です。これで呼び出そう、とか、こうやって使おう、とか。
小目的は実装部分です。

まだコード書きません。設計も書きません。
とにかく目的と前提の整理を徹底的にします。
上司には、なにかかっこいいことを言っておきましょう。

出てきた小目的を分析します。まだ頭の中だけのものです。この小目的は、各スクリプトコードになるものですけど、しっかりと時間をかけて分析します。
分析の目的は、大目的を達成するためではなく、中目的を達成するためのものであり、かつ、誰が見ても無駄なコードを混入させることができるか、という命題を満たすためです。

ここでいう無駄とは、使い回すための余地として、現時点では不要だけど、いつかこういうのにも使えるかもしれない、ということです。

ここまで整理するとわかるはずです。

大目的1に対して、中目的が8つくらいなったとします。そしたら、小目的は2つくらいになります。大抵、やりたいこと、実現したいものよりも作るものは少なくなります。ちゃんと考えたらね。多くなることも多いけど。

ここでやっと書くのがフローです。IOを定義した標準フローです。脳内ですけど。

はい、これでソースできました。というか、できたも同然というか。

ラッパー書けば中目的達成できます。

そしたら大目的を達成したことになるので、設計を書きます。使い方だけの。

少ないソースコードで機能を満たすために、必ずしなければいけないのは目的・前提の整理であり、手法の検討ではありません。
手法は達成するための手段でしかないので、これがブレればブレるほど、珍妙なソースが出来上がります。
変数の数が無駄に多かったり、というのは、手法から検討した、つまり、全体を見失った！ということです。
無理矢理前提を満たすために、力業で戻してみたけど、根元折れちゃってた的な感じ。

ぼくのチームはアジャイルです。そのかわり、前提を必ず持つように指導して、セルフウォーターフォールを徹底させてます。
分析する人格と、SGする人格と、ソース書く人格と、テストする人格と、おひるごはん食べる人格と、携帯いじってサボる人格と、それぞれもたなければいけません。と言ってます。

そうしないと、いま、自分がなにをすべきか、見失うからです。
見失ったらもう、すごいものができちゃう。見てて楽しいけど、PJ的にはアウトなので、ぼくがごめんなさいしに行く。

だから、前提の意識と、フェーズごとに人格を分けるのがだいじ。
べつにやったことは忘れてもいい。むしろ、忘れたほうが固定観念から解放されてるので、さらにいいものができる。でも、前提こそ前提。

前提を満たしているものが、成果物なのです。