Bel*log

プログラミングと読書たまに麻雀。

案件に配属され1ヶ月間詳細設計書を書いて思うところ

  • 品質と生産性

この2つを高めるために何を考え、やるべきなのかを常に考えていく必要がある。
詳細設計書の内容や体裁を高めることは納品物の品質向上につながる。
生産性とはつまりどれだけ成果物を生み出せたか。いかに効率よく作業を進めるられるか。

  • 内容の話
    • とりあえずCODE COMPLETEを読め。話はそれからだ。
    • 一週間後に読み返すと修正点が見えてくる。
    • 反復する必要性。
    • 完璧主義に陥らずとりあえず書き上げてからブラッシュアップする。
    • これ以上単純にできないというレベルでちょうどいい。
    • 使い捨てのコードを書いてみる。
    • 画像やファイルを扱う際はDBの型やDTOの型に気をつける。コードを書いてみて実際にできることの確認が必要なこともある。
    • 単体テストがしやすいコードを意識する。
    • メソッドに使わないパラメータは渡さない。必要なものを渡す。
    • メソッド名はよく考えて名が機能を表すようにする。
    • 例外処理についてはよく考える必要がある。システムエラーと業務エラー。基本設計した人もよくわかってないことがあるので、仕様がはっきりしていない場合は確定してもらう。
  • 体裁の話
    • チェックリストを作って手元に置いておく。
      • 印刷プレビューで文字が潰れていないか。
      • 番号が合っているか。
      • 文言が統一されているか。
      • 基本設計書と矛盾するところはないか。
      • 罫線はちゃんと表示されているか。
    • 上記のチェックをサボる方法としてはまず書式が完全なサンプルを作成し、それをコピペして使う。
    • Excelの場合パーツをコピペしていくと文言の統一につながる。
    • 最低限はもちろんやるべきだとは思うけどプロジェクトやPMによってブレるので内容:体裁が8:2くらいがいいと個人的には思っている。どう考えても体裁より内容のほうが大事だろ。。
  • 生産性の話
    • 内容のところと被るが、最初から完璧なものなんて書けやしないんだから、さっさと書いてしまってブラッシュアップしていくほうがいい。最初のうちは詳細設計書を書くためのルールも曖昧で、徐々に規約や体裁も定まってくる。
    • テスト仕様書やテストデータを作成しているときに間違いに気づくこともある。早く進めていればその分早く気付ける。


んで、今月から実装に入りました。コード書くのは楽しい。