シェアしました。
開発スタイルは人それぞれ。場所が変われば中身は別物。進め方だってバラバラです。
それでも共通して言えることは、プログラムという「血」の一滴を絞り出すのに、その元になる材料は呆れるほど多いという事実です。
開発プロジェクトを進めていると、とにかくデータが増えてたいへんです。しかも、捨てたら大変なことになります。とくに、慎重かつ誠実に仕事をしていれば、消せないデータが大量にたまりがちです。このデータはいまの段階では無駄かもしれない。でも、そのデータを取っておかなかったら取り返しのつかないことになるかもしれない。
自動車の運転時に「あの角から子供が出てくるかもしれない」と心配するのと同じぐらいあたりまえに、「このデータをとっておかないと困ることになるかもしれない」と心配するのがプログラマーという仕事につく人の本能的な反応です。
■仕様書/仕様メモ
画面図を入れて開発内容をメモしているだけでも、容量は相当なものになります。仕事の進め方次第ですが、バージョン違いの仕様書も念のために残しておきます。差分チェックを取りやすいので。
■顧客との間で取り交わした資料
自分はPDFでやりとりしますが、この資料もすべて取っておきます。なくすと致命的に社会的な信用を失うので、バックアップをとりつつ手元に置いておきます。
■アイコン案
アイコンを決めるのに、関連するアプリケーションの画像などを大量にインターネット上で検索して探してきます。落としてきた画像にも著作権があるため、そのままでは使いませんが、最終候補案をしぼるために無作為にかき集めまくります。
■サンプルコード
OSメーカーやフレームワークの提供元、書籍の付録DVDや、Github上のオープンソースプロジェクトの内容などなど、参考にしたいプログラムをどんどん集めてきます。こういうのは、処理内容の参考にする資料なので、手元にないと困るんです。
■調査データ
プログラムを作るにあたって、プログラムコードだけ書いているわけではありません。コードを書くにあたって、あらかじめ調査を行なったデータも必要です。色関係のプログラムを作っている場合には、国内外の主要インクメーカーの色見本帳データが入っているかもしれませんし、プログラムコードの中に書くデータの元になるデータを幅広く集めていたりするでしょう。
■テストツール、補助ツール
仕事をすすめていると、「プログラムを作るためのプログラム」が必要になったりします。また、納品プログラムには含まないものの必要になる補助プログラムも出てきます。なにがしかのパラメータをもとにデータ出力を行うGUIアプリケーションの場合、パラメータの全パターンの組み合わせを試し、そのパラメータをファイル名に入れたデータを出力させる外部Scriptが必要になりました。開発作業の効率化のためには、時としてそういうものも必要になります（作り込みがすすんで機能が結合されまくっていて、部品単位に分解して単体でテストできない状況だったので、外部からGUIをScriptで操作しました）。
実際に開発中のアプリケーションが更新されるのに合わせて、iPhoneの画面スナップショットを画面フロー図に反映させるScriptも作って運用していました。iPhoneのアプリケーションをシミュレータごしにシナリオどおりにコントロールして画面のスナップショット撮影し、それを画面フロー図に反映。こうした報告用の資料作成のためのプログラムも時として必要になります。
しまいには、仕様書の変更を明確にするために（想定外の箇所が変更されていないことを確認するために）、PDF同士の差分チェックツールも作りました。これは、いまMac App Storeで実際に販売しています（Adobe Acrobatがあんまり役に立たなかったので）。
■デバッグ時のダンプデータ
プログラムが原因不明のクラッシュを頻発？！ そんな時におもむろに開発環境の、メモリリークを検知するツールを起動！ プログラム実行中のコンピュータのメモリの状態を詳細に記録して、分析できるようにファイル保存。数GBのファイルがあっという間にできてしまいました。さまざまな条件を変えてモニタリングを行い、顔色が変わるぐらいSSDの容量が逼迫してしまいました。これは、調査が終わればすぐに削除できますが、なかなかスリリングでした。
■テスト/検証用データ
プログラムが仕様どおりに動いていることを証明するために、事前にお客様から支給された処理データが大量にあったりします。このテストデータを所定の状態に処理できれば、納品を認めてもらえる大切なデータです。
テストデータを処理してチェックプログラムでチェック。そんなもの、１回で終わるわけがありません。何回も処理を行って、どこがダメだったのかをその都度チェック。どこで間違ったかという情報も、問題解決のために重要なので、まともなプログラマーなら必ず手元にとっておきます（多分）。
■ビルドした実行バイナリ
作るものによりけりですが、ビルドした結果（動作するアプリケーション）については、バージョンごとにアーカイブして保存しておきます。バイナリが大きければ、それなりの大きさになります。ここで注意すべきは、グラフィックなどの要素が増えているので、予想外に大きくなってしまうということです。
なので、その「ディスク容量が足りない」と言っているプログラマーの方は、慎重かつ誠実に、未来において所属組織が不利益を被ることがないように努力しているものとお見受けします。
納品したプログラムが想定していなかった不具合を起こして、血相を変えたお客が大挙して押しかけてきたとしても、途中のテストデータをとってあれば「仕様どおりの処理でそうなったなら仕方ない。善後策を検討しよう」という話に持っていけるんです。証拠がないとわかってもらえないんです。
そこで、「ディスク容量が足りないなんて、悪いことをしているに違いない」と思わずに、「どのぐらいあれば大丈夫そうか？」「内蔵ドライブの交換と、外付けドライブのどちらが効果的か？」「足りないのはわかるが、バックアップ体制はきちんとしているのか？」と言えたら、あなた自身が未来のヒーロー（ヒロイン？）になれるかもしれませんよ？
0 コメント:
コメントを投稿