開発運用

下っ端から見たとりあえずの開発運用プロセス抑えどころ。基本的に頑張って進めるのが現状。

仕様策定

目的に沿ったストーリーを組み立てる。細かな事よりも、大枠で開発を円滑に進められるようなガイドラインを定める事を心がける。グループでの開発を考えた場合、コード規約を定める事で混乱を防ぎ、必要と思われるルールを定め、円滑なコミュニケーションを実現させる。

後は頑張る。

設計

インターフェース設計に力を入れ、各メソッドなどは大まかな振る舞いを決定するのみにとどめる。振る舞いの利用方法を注意深く設計する事で、ビヘイビア駆動開発を効率よく進める手助けとする。詳細設計は開発状況に従って柔軟に変化させていくべきだが、優れたインターフェースは余程の事が無い限り変更される事は無い。

後は頑張る。

開発

ビヘイビア(振る舞い)駆動開発

テスト駆動開発を、より現実の開発に合わせたもの。ユニットテストの意味合いは、動作品質を保証する物ではなく、振る舞いを確認するためという色が強い。各オブジェクトごとに振る舞いを用意していけば、改めて仕様書を用意する必要がない。文書に起こす必要がある場合にも役立つ。

従来のtest/assertという組み合わせからshould/Verifyとする事で、「試験結果を断言する」から「あるべき振る舞いを確かめる」存在となり、コードがより視覚的になる。文言を変えるだけではあるが、テストのための思考に切り替える必要がなくなるため、不慣れな場合でも利用し易くなる。

アジャイル開発

より迅速な開発を可能にするために考えられた開発手法。

最終目標に至るまでに、仕様は変更している。一定間隔で出来上がりを確認する機会を設ける。繰り返しレビューを行う事で、顧客-開発の擦り合わせを行う。無理の無い継続を前提とした計画立案が肝要。

用意された(した)ビヘイビア(テスト)に従ってコーディングを行い、たびたびこれが実現できているか確認する。進捗状況を管理する上で、毎日の結合は大切。アプリケーションを確認する際、最も簡単で確実な方法は実行。現状把握のためにも、1日単位での確認を怠らない。

振る舞いを確認する時は、一連のフローが自動化されたツールを利用する。確認作業は苦痛な物でなく、楽しい物でなくてはならない。

確認↔実装のサイクルの最中、設計を都度見直す。ビヘイビアが変更される事は好ましくないが、最終目的に至るまでの経過部分であれば影響は微小であると考え、積極的に行う。完成後の設計変更ほど労力を必要とする事は無い。コミュニケーションを積極的に行う事で、開発中の設計変更に対応する。

継続的な開発を行うためにも、無理は厳禁。ペースを保つ事が大事。一般人の集中持続は90分程度が限界。個々に合わせたスケジュール管理を行う。

ほか

後は頑張る

運用

コード管理

グループで作業する場合、コード管理を円滑に進めるツールが必要。CVSやSubversionなどのバージョン管理ツールを積極的に取り入れる。

履歴管理/パッケージング/差分比較/ブランチ(開発本流からの切り離し)など、各ツールの特徴とグループが必要とする機能とをよく照らし合わせ、それぞれにあったツールを採用する。ツールの運用コストを忘れてはいけない。

ほか

後は頑張る

リリース

各モジュールの結合から品質保証試験、リリース(納品)まで出来るところは自動化する。計画を立て、出来る限り定型処理に落とす事で、自動化できる箇所を探る。コストと折り合いがつけば、積極的に一般に出回るツールを導入する。苦労を解消するための労力を惜しんではいけない。

後は頑張る

 
koshigoewiki/開発運用.txt · 最終更新: 2005/10/20 23:46 by koshigoebushou
 
Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki