5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。
数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。
ポイントとしては、WEB系にはありがちだと思いますが、下記のように作りたいものがファジーだったりすることが多いです。
- 仕様が不明な点が多い、固まっておらず、質問しても顧客のレスも遅い
- 仕様書がない。あってもあまり機能していない、テーブル定義書やデザインデータがない
- ドキュメント自体残す習慣があまりない
ようは仕様が曖昧なまま「こんなのが作りたい」と言われるケースです。自分の場合は某WEBサービスをベースに作って・・などと言われたので、まだよかった方だったのかもしれませんが・・・
便宜上ファジープロジェクトと定義します。
以下のような点がポイントでした。
常にメモを残す
ドキュメントとかがないので、数ヶ月単位のプロジェクトになると作った意図とかを忘れてしまいがちになるんですね。
最悪なのが間違って作り直してしまうことです。そのためにも自分への備忘録として、常にメモを残すこと。
単純ですが、これがあると上記のようなミスが防げ、地道に効率アップをすることができます。
テーブル設計
何と言ってもデータベースの設計がもっとも影響度が大きいです。しかもテーブル定義書がないので、手探りでこんな感じかな？で作るしかありません。
これなんですが、やはり一般的な業務管理プロジェクトのテーブルをたくさん見ておくことがポイントになります。
いわゆるアンチパターンやグレーパターンなど言語化できる部分もありますが、ステータスはどのように管理するか、正規化をどの程度行うかなどはどうしても経験に寄るところが多いです。
以下のような本で勉強すると言う方法もあります。
グラス片手にデータベース設計~販売管理システム編
コーディングスキル+ユニットテスト
次に大事だと思ったのは常識的なコーディングスキルとユニットテストです。
テストはTDDとかそういった原理主義的なものではなく、粒度を細かくすることで該当箇所の挙動をすぐに確認できることが目的です。コーディング時に気をつけるべき点としては以下のような点。
- メソッドが適切な役割で設計されているか
- メソッドの行数は30行程度か
- メソッドの引数を変数でおくことと、ハッシュやオブジェクトなどでおくことのメリット、デメリットを理解しているか
- クラスが役割に応じて分割されているか
- クラスの行数は多くても300行程度か
- テスト可能なコードか
- (一つ上のものとだいたい同じですが)画面からデータを入れる場合であってもテスト(コマンドライン)により挙動が確認可能か
長くなるので後編へ。
[…] 前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 […]