まとめ記事続きです。
個々のエッセイはクリエイティブ・コモンズでライセンスされています。
65.バージョン管理システムを有効に使う
プロジェクトを構成する要素は、とにかく何でもバージョン管理の対象にすべきです。
タグ付けしておけば、環境をそろえることが容易になり、アップデートもコマンド1つで済みます。
有効に利用する為には、次のルールを開発メンバー全員が守る必要があります。
・コードに意味のある変更を加えるたびに逐一コミットを行うこと。後で個々の変更を別に扱うことが難しくなるからです。
・コミットをする際は、必ずコミットについて説明するメッセージを添えること。変更理由も書いておくとよいでしょう。
・ビルドを壊すようなコードは絶対にコミットしないこと。全メンバーに恨まれたくなければ。
66.いったんコンピュータから離れてみる
脳の論理を司る部分と創造を司る部分は違うため、考え込んで詰まってしまったら、一旦気分転換をすることも大切。
じっとコンピュータの前に座って考え込んでいるより、その方が良いアイデアを思いつく。
67.コードを読む
他人のコードを読むときは、いろいろと考えながら読むようにするとよい。
良くない所があれば、自分が同じことをしないよう心掛けるようにする。
良いところがあれば、積極的に取り入れるようにするとよいでしょう。(名前の付け方、実装方法、デザインパターン、etc...)
自分が昔書いたコードを読み返すのもよい勉強になります。
プログラムの腕を磨きたいと思っているのなら、本を読むのも大切ですが、一番いいのはコードを読むことです。
69.車輪の再発名の効用
既にあるコードを流用せず、一から開発することは、一般的にはあまり良いことではない。
もしそれを行うとなると、膨大な知識やテストを行う必要が出てくる。
だが、ソフトウェアの核になる部分を学ぶことで、「ブラックボックス」となっている部分の中を知ることができる。
本を読むことで知識を頭に入れることも大切だが、実際に手を動かして経験を積むことも大切。
70.シングルトンパターンの誘惑に負けない
シングルトンパターンは、多くの問題の解決に役立つデザインパターンであるが、短所も多い。
テストの妨げになり、保守性も悪いため、使いたい誘惑に抵抗しなくてはならない。
具体的には以下の短所がある。
・「必要なインスタンスは1つだけ」という要望は、多くの場合推測に過ぎず、後々問題を引き起こす。
要件は変化するものであり、シングルトンパターンは変化を織り込んでいるとは言えない。
・本来不要な暗黙の依存関係を生んでしまい、ユニットテストの妨げになる。
また、グローバルにアクセス可能かつ永続化された状態が暗黙の内に起こる為、コードから状態の推測が困難になる。
・マルチスレッドでの使用は特に危険。
DCLPパターンを用いてロックを行うが、完全とは言えない。
・明示的に殺す方法が無く、全オブジェクトをクリーンアップするまで安全にアンロードできない。
・複数のシングルトンがあった場合、クリーンアップ順序が決まっておらず、別のシングルトンにアクセスしようとすると、
既にクリーンアップされている恐れがある。
シングルトンパターンは、必要なインスタンスが絶対に確信できるクラス以外では使うべきではない。
また、グローバルアクセスポイントにすることは避け、インターフェースを通じてアクセスするようにすること。