■ - ( ・ω・)ノ＜しすてむ開発。
プログラムを組むとき、ソフトウェア開発時に経てきた取捨選択。 ・何はともあれ作り始める事。 作るものの形すら見えずに何ができよう。 仕様書という名の書類にある画面は完成形ではない。 機能を作りながら考えても、作り直す事ができなければ バグが消える事はない。 事前に構築する形を想定し設計し試しようやくプログラミングする。 遠回りだと思えたこの行為が最速と平均値を叩き出せる行為であると実感できた時からやめた。 ・とりあえず動くもので完成と言い張ること。 ちょっと触ればエラーがあふれ、 直しても直しても収束しないｸｻﾚｿｰｽ。 後の改変時にも読むのが辛くなる神経衰弱剤。 目先の納期に合わせようと走り始めても目標は自分で遠くしていと気づいた時にやめた。 ・メソッド分割しない事。 用件を考えながらコード化するとしばしば行が長くなる。 これを分割しないことはその場では楽な選択肢なのだが、後が辛くなる。
■ - ( ・ω・)ノ＜しすてむ開発。
基本設計におけるレビューの勘どころ 「考慮していない外部システムとの連携が詳細設計で見つかった」， 「仕様間の不整合が実装フェーズで発見された」――。 どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。 欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 基本設計でなにもかもすべて決められると本気で思っているのだろうか。 現実問題「要求の変化」が微塵も起こらないとでも思っているのだろうか。 基本設計時に仕様凍結できればちょっとはマシになるが、 それがユーザビリティの向上につながるわけでもないため、 結果的に使いにくいシステムを産む土壌となるもんだ。 レビューを行うことは大事。 結果をフィードバックすることも大事。 ルール付けももちろん大事。 でも現実から目をそむけるのはいかん。 最初から「承認」のために，ユーザーに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
