達人プログラマー 感想文 第2章

気になったキーワード、思ったことなどをつらつらと。

第2章 達人のアプローチ

7 二重の過ち

信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したりメンテナンス
出来るようにする唯一の方法は、DRY原則に従うことです。

すべての知識はシステム内に置いて、単一、かつ明確な、そして信頼できる表現になっていなければならない。

DRY原則-Don't Repeat Yourselfは聞いたことはありましたけど、
同じコードを2回書いちゃいけないよ、、、的な意味だと思っていたのですが
 「すべての知識は・・・」
知識、つまりコードだけでなくドキュメントに関しても適用されるのですね。

どのように二重化が発生するのか?
・・・

  • 開発者間の二重化

機能全体がプロジェクトで二重化され、何年も気づかれなかったためメンテナンス上の問題を引き起こす

これに対する最善の方法は、開発者間の活発かつ頻繁なコミュニケーションを推奨することでしょう。

1.メンバーの一人を知識交換を円滑にするためのプロジェクト・ライブラリアンとして任命
2.ソース階層中にユーティリティ・ルーチンやスクリプトを保管しておくための場所を作ります。
3.非公式にまたは、コードレビューの場では必ず他人のソースコードやドキュメントを読むというルールを作る。
 お互いに行い合う、他人の意見に対しても真摯に耳を傾けるように。

1.ライブラリアンっていてもいいと思う。
2.これもDRY原則。便利なスクリプトは共有されたほうがいいと思う
3.忙しいを理由にされない場合が多いですね、お互い知識を刺激し合うのは重要。

8 直行性
ヒント13:関係のない者同士の影響を排除すること

さもないと、

  • チーム内でつまらない議論に終始して、生産性が落ちる。
  • メンバーの役割がオーバーラップした状態でチームを編成した時に、自己の責任について混乱してしまう。
  • 何か変更が発生した場合に影響が全員に及ぶ時があるため、全員でのミーティングが不可欠。

コンポーネント、モジュール、レイヤー単位でわけるとよい

テスト

各モジュール自身の単体テストをコード中に組み込んでおき、通常のビルド・プロセスの一部として自動的に実行すること推奨

ビルドの自動化と単体テストコードの自動化も重要

2章まとめ

明日のつもりが一週間すぎてしまった。
頭に入ってこない項が結構あったためだ。