works4Life

GTDメインのタスク管理と生息してますログを記載しています。

トップ > アーカイブ > プログラミングの時間がかかる作業手順

プログラミングの時間がかかる作業手順

アーカイブ アーカイブ-昔の雑記

http://blog.shibu.jp/article/28983162.html

上で渋川さんがプログラミングについてまとめてたので、何かしらプログラミングで言いたいなーと思ってしまったので、今やってるプログラミングの作業順番をまとめておきます。

私はもともとjavaのプログラマでした。ブログのタイトルはその名残です（小文字始まり・4使用）。プログラムめんどいよ～仕様決める仕事がいいよ～、と思ってPMにジョブチェンジしました。粒度が合わなかったんですね。それはさておき、今回の自動化作業のだいたいの作業の順番について。

今回のお仕事

お題：ウェブサービスの運営で、定常作業を自動化するのに、perlでプログラミングを組むこと。

ゴール：他の人がそれを使って作業を実施できること。問題があっても他の人がメンテナンスできること。何かあったら他の人が改変しやすいこと。

とゆーよーな感じのお仕事です。

作業手順

  1. 定常作業から作業項目を洗い出す
  2. できるところからプロトタイプ
  3. ２を繰り返す
  4. 標準化
    1. conf設定対応
    2. IF統一
    3. ログ追加
    4. 定数化作業
  5. 資料作成

以下詳細。

１．定常作業から作業項目を洗い出す

もともと手作業でやってたのを自動化するので、もとあった手順書からプログラミングすべき作業を洗い出します。この時点で作ろうと思う関数は洗い出しされてます。設計がないと、ここで抜けもれが発生しました（例：conf設定対応とログ）。

２．できるところからプロトタイプ

プログラミングも久しぶりだし、perlも手馴れてないんで、できるところから書いては実行です。動いているので安心感があります。この時は面倒なのでファイル1枚で実行し、関数を増やすといった感じ。

３．２を繰り返す

必要な関数を増やします。で、一通りできたら、それを使って手順書通りに実行する関数を作ります。正直ここで終われるものなら楽です。

４．標準化

私のやる気ナッシングな領域に。

４．１．conf設定対応、テンプレート対応

設定ファイルは外部化します。xxx.confとかそんなファイルから読み込めるようにしておきます。使いまわしする予定があるのでー、ファイルと同化してるとダメなんです。

テンプレート対応とは、conf設定やtmplファイルに、テンプレート変数を使っていたので、それの対応もしました。これは、confファイルで、出力ファイル名を”xxxx-$today_yyyymmdd.xls”とか設定しておくと、自動的に”xxxx-20090511.xls”とかに変更してくれるような仕組みです。

ここらへんで、ファイルを分割してライブラリ専用ファイルを作りました。

４．２．IF統一

上記との兼ね合いもあり、再度関数のインタフェース（引数とか返り値とか）を見直しです。

４．３．ログ追加

ここでようやくログ追加。

４．４．定数化作業

文字列排除。今作業はここらへん。今思ったけどやっぱり徹底的に文字列は排除しよう。。

５．資料作成

で、上記の設計をまとめた資料を作る予定。

  • 概要設計 - ツールの目的、ゴール、ユースケースがあると便利（使い方のイメージつくから）
  • 外部設計 - 枠決め。関数のインタフェースと機能を決める。シーケンス図があると便利。
  • 内部設計 - 中身決め。関数の中身を説明する。アクティビティ図。
  • 実装設計 - 実装決め。どのファイルにどの関数を入れるか。設定ファイルはここら辺で書くと思う。
  • 使い方説明 - 使い方。修正方法等。

後残ってるのが、ログの説明ぐらいか。。どこに組み込もう。

総論

perlもプログラミングも昔とった杵柄レベルであまりに慣れてないので、今回はプロトタイプの作成から始まりました。しかし、時間がかかりすぎるのが難です。

なぜなら、あとから追加項目が多いから。毎回変更したら、ちゃんと動くかどうかテストするのが面倒だから。なんにせよ、手戻り作業が多すぎるです。

今回は、プログラム自体は2ファイル程度（設定ファイルは10ファイル前後）の成果物でしたのでなんとかなってますが、時間のことは関係しなくても、他人が使うことを想定すると、やはり設計は必要です。とはいっても、自分が使うにしても、やっぱり設計は必要だと思います。なぜなら、3ヶ月前の自分も赤の他人だから。

でもね、プロトタイプは最初は楽しいんだよねー。

まぁあれですね、他の人に共有すること前提なら、プロトタイプからのプログラミングは、あんまり合わない、ということでした。

ソースがきれいとか構造がきれいとか

ソースがきれいとか構造がきれいとかありますが、私の昔の感想は以下のような感じでした。

作った直後の私は、自分のソースはきれいと思ってました。他人のはきれいかそうでないかというか、読みにくいな、と私は思うのでした。理解の粒度は違うのでそれはしょうがないんですな。そして、数ヶ月後の私は、自分のですら汚い読みにくい何コレサイテー！と本気で思うのでした。

 

自分コメント

  • 勢いでやった。後悔はしてないけど、文章に責任はもてずにすぐお蔵入り。
  • ていうのと、どのライン用なのよ、というのがあって、やっぱりお蔵入り。