プログラマがやるべきことは実はコーディングやデバッグだけではないよという話で、この辺りの話題はコーディングそのもののテクニカルな知見よりも忘れられがちなためか情報の流通も少ないですが、実はとっても大切なことです。
なお、ソフトウェア開発にもいろいろな種類があると思いますが、ここでは一般消費者向けのサービスを細かな開発サイクルを回しながら提供していくような開発体制を想定しています。
| 工程 | ポイント |
|---|---|
| 課題定義 | 利用者の「これがしたい」「これがいまいち」などの要求を定義する。 データに基づいた定量的な課題であれば達成度を計測できるので、なおよい。 |
| 要件定義 | 定義した課題を具体的な要件に落としこんでいく。 「これはやりません」と決めておくのも大事。追加要件に振り回されないためにもやらないことも確定させておく。 この段階だと頭だけで考えていることが多いので意外と要件自体がないことに気づかずにあとで「なんか設計しにくいなぁ」という状態に陥ることもある。 例えば、ある機能を実現するために「どうせなら汎用化させようぜ」みたいな話になったときはその汎用化部分の要件などが抜け落ちていることがあるので注意。 経験がものを言う工程だが、できるだけメタな視点に立つよう努める。 次回の「課題定義」からはじまるイテレーションを意識しよう。「このログは集計できるようにしておきたいね」など。 |
| 詳細設計 | どうやって要件を満たしていくかを考えていくフェーズ。 既存資産に手を入れる際は既存のソフトウェアアーキテクチャがどうなっているか、ソースコードがどうなっているかなどをみながら設計を進める。 どういったクラスがあるか、どういった例外がありうるか。 よいインターフェースを提供しようという強い意志を持ちたい。 設計では引き出しとしてデザインパターンが役立つ。 ただ、ある程度決めた時点でとにかく手を動かすというのも有効。特に経験が少ない場合。 |
| ソフトウェアアーキテクチャ | 負荷の見積もりを行う。サーバのスペックや台数を決める。 |
| コンストラクション計画 | 作業全体のスケジューリングとその自己管理ができるようになると一人前。 ボトルネックとなる工程を事前に把握して手元のタスクに優先順位をつけていく。 例えば他チームへ Pull request を出す場合はチーム内レビューも含めて時間がかかったり、チームごとにリリーススケジュールが異なったりする。サーバの調達期間も考慮すべし。 |
| コーディングとデバッグ | 実装。前準備がうまくいっていれば楽しい作業時間となるはず。 |
| 単体テスト | 品質と開発効率の両立には欠かせない工程。 テストコードがあれば自信を持ってリファクタリングできるようになる。そして他の人が自分のコードに改修を加えやすくなる。 テストコードの無いコードは生まれた瞬間からレガシーである。 代表的なツールは xUnit 系。 実装に対するテストはもちろんだが、要件を満たせているかという観点のテストまで書けるとよい。 |
| 統合テスト | 自分の変更と関係のない部分とも協調してテストを通す。 Pull request を投げた時点で Jenkins が自動でテストを走らせて、コーディングスタイルのチェックやテストカバレッジなども計測してくれるとレビュアーの負担も軽減できてよい。 |
| 受け入れテスト | 利用者に使ってもらってフィードバックを得る。 段階的に一部のユーザーに機能を開放することで施策の効果を計測したり、予想できなかった不具合などを発見したりできる。 |
| 保守 | 最初にマージされてデプロイされた瞬間から保守ははじまっている。 一概には言えないこともあるがここの手間がないほどよい設計ができたといえる。 |
メモ
おおむね時系列順になるように工程ごとのポイントをまとめてみました。自分用のメモを転載したので雑記的に大事だなと思っていることが書き連ねてあってコメントの粒度がバラバラになっていますがその点はご了承くださいませ。
