達人プログラマー

imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。

達人プログラマー―システム開発の職人から名匠への道

達人の哲学

割れた窓を放置しておかないこと

悪い設計、間違った意思決定、質の悪いコードを放置すると、そこから崩壊していく。

大きな構想を忘れないようにすること

小さな変化から崩壊が始まる。

品質要求を明確にすること

十分によいソフトウェアを作る。やりすぎない。

伝達しよう

聞き手を理解するための合言葉 WISDOM
W:what         聞き手に何を知ってほしいのか
I:interest     言いたいことの中の聞き手の興味は何か
S:sophisticate 言いたいことはどれくらい洗練されているか
D:detail       聞き手はどの程度詳細を知りたがっているのか
O:own          誰に知ってもらいたいのか
M:motivate     聞いてもらうためにはどうするのか

達人のアプローチ

二重化の過ち

DRY Don't Repeat Yourself 繰り返しを避けること
再利用しやすいようにしておくこと

直交性

関係のないもの同士の影響を排除する
 → コンポーネント間の依存度を下げる

可逆性

DRY原則、結合度の最小化、メタデータの使用ーによって可逆性が高まる

曳光弾

まず最小限度のすべての機能が動作するコードを作成し、修正、肉付けを行う

プロトタイプ

特定の機能についての詳細を作成する

専用の言語

ユーザーの問題領域に近いところでプログラミングを行う。
ミニ言語を作成する。

見積もり

システムをモデル化する → コンポーネントに分割する → コンポーネントを見積もる
コーディングによりスケジューリングを繰り返す

基本的なツール

プレーンテキスト

データはプレーンテキストに保存すること

シェル遊び

コマンドシェルの力を使うこと

パワーエディット

ひとつのエディタを熟知すること

ソースコード管理

常にソースコード管理を使用すること

デバッグ

非難しないこと
パニックに陥らないこと
"select"はおかしくない
仮定せずに、証明すること

テキスト操作

テキスト操作言語を学ぶこと

コードジェネレータ

コードを生成するコードを作成すること

妄想の達人

あなたは完璧なソフトウェアを作ることはできない

契約による設計 Design by Contract(DBC)

事前条件、事後条件、クラス不変表明ーにより、ルーチンの設計を行う
DBCをチェックする → C言語による実装？

死んだプログラムは嘘を付かない

早めにクラッシュさせること
トラッシュ(めちゃくちゃにする)ではなくクラッシュ(停止)

表明プログラミング

起こり得ないことは表明によりチェックする
assertなどを用いる

いつ例外を使用するか

例外は例外的な場合のみに使用すること

リソースのバランス方法

始めたことは終わらせること → リソースを確保した人が解放する

曲げるか壊すか

柔軟性の高いコードを記述する

結合の最小化とデメテルの法則

デメテルの法則により、結合の最小化を実現する
機能に対するデメテルの法則
 オブジェクト中のすべてのメソッドは、以下のいずれかに属するメソッドのみを呼び出すべきである
 ・自分自身
 ・メソッドに渡されたパラメータ
 ・自身が生成したオブジェクト
 ・直接保持しているコンポーネントオブジェクト

メタプログラミング

設定できるものを統合しないこと → システム設定を動的に変更できるようにする
抽象概念はコード上に、詳細はメタデータ上に置くこと

時間的な結合

ワークフローを分析し、並列実行可能なアクションを明記すること
サービス(一貫性のあるインタフェースを持ち、独立した並列オブジェクト)を使って設計を行うこと
常に並列性を意識した設計を行うこと

単なる見かけ

モデルからビューを分離すること

コーディング段階

偶発的プログラミングを行わない

常に何をやっているのかを意識する
完全に理解していないことをしようとしない
明確なプランを持ってすすめる
信頼のおけるものだけを前提とする
仮定をドキュメント化する → 契約による設計を行う
仮定が正しいことをテストする → 表明によるプログラミングを行う
作業に優先順位をつけ、重要なことに時間を使う
過去のしがらみにとらわれない → リファクタリングを行う

アルゴリズムのスピード

アルゴリズムの処理速度を見積もり、見積の検証を行う

リファクタリング

リファクタリングを早めに、こまめに行うこと

リファクタリングのタイミング
・二重化の解消
・直交性の確保
・変更した要求の修正
・パフォーマンスの向上

リファクタリングと機能の追加を同時に行ってはならない
小さな修正を行う
頻繁にテストを行う

テストしやすいコード

契約による設計とし、契約に対するテストを行うこと
テストコードを作成すること

邪悪なウィザード

理解できないウィザードのコードを使用しないこと

プロジェクトを始める前に

要求の落とし穴

要求は拾い集めるものではなく、掘り起こすものである
要求をドキュメント化する
抽象は詳細より息が長いものである
プロジェクトの用語集を作ること

不可能なパズルを解く

制約条件にとらわれずに考えるのではなく、本当の制約条件を見つけ出すこと

準備ができるまでは

心の声に耳を傾け、準備ができてから開始すること

仕様の罠

解説しないほうが良い場合もある → 過剰な仕様書を書かない

丸と矢印

形式的方法論にとらわれない

達人のプロジェクト

達人チーム

システムの機能ごとにチームを編成する

どこでも自動化

手作業は危険である

・プロジェクトのコンパイル
・ビルドの自動化
・最終ビルド
・管理の自動化

容赦ないテスト

早見にテスト、何度もテスト、自動でテスト
テストが全て終わるまでコーディングは終わらない
コードのカバレージではなく、状態のカバレージをテストすること
複数のバグを一度にみつけること

すべてはドキュメント

ドキュメントは組み込むものである

大きな期待

ユーザーの期待をやや上回ること

誇りと愛着

あなたの作品に署名すること