noob log.

組み込みSE兼プログラマの備忘録。

プログラマが知るべき97のこと まとめ 10

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

71.パフォーマンスへの道は地雷コードで敷き詰められている
パフォーマンスチューニングを失敗すると、スケジュールなどが大打撃を受ける。
事前に防ぐためには、ソフトウェアメトリクスを利用して、日常的に計測・改善する必要がある。
深刻な悪影響を引き起こす前に、コードの地雷を発見し、排除することが必要。

 

72.シンプルさは捨てることによって得られる
悪いコードは残していても何の役にも立たないことが多い。
質が悪いコードは無理に残そうとせず、書き直したり、全部捨てて一から書き直したほうが良い。
余計な要素を減らし、必要最小限のコードだけ残すようにすれば、自然とシンプルで分かりやすくなる。

プログラマが知るべき97のこと まとめ 9

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

65.バージョン管理システムを有効に使う
プロジェクトを構成する要素は、とにかく何でもバージョン管理の対象にすべきです。
タグ付けしておけば、環境をそろえることが容易になり、アップデートもコマンド1つで済みます。
有効に利用する為には、次のルールを開発メンバー全員が守る必要があります。
・コードに意味のある変更を加えるたびに逐一コミットを行うこと。後で個々の変更を別に扱うことが難しくなるからです。
・コミットをする際は、必ずコミットについて説明するメッセージを添えること。変更理由も書いておくとよいでしょう。
・ビルドを壊すようなコードは絶対にコミットしないこと。全メンバーに恨まれたくなければ。

 

66.いったんコンピュータから離れてみる
脳の論理を司る部分と創造を司る部分は違うため、考え込んで詰まってしまったら、一旦気分転換をすることも大切。
じっとコンピュータの前に座って考え込んでいるより、その方が良いアイデアを思いつく。

 

67.コードを読む
他人のコードを読むときは、いろいろと考えながら読むようにするとよい。
良くない所があれば、自分が同じことをしないよう心掛けるようにする。
良いところがあれば、積極的に取り入れるようにするとよいでしょう。(名前の付け方、実装方法、デザインパターン、etc...)
自分が昔書いたコードを読み返すのもよい勉強になります。
プログラムの腕を磨きたいと思っているのなら、本を読むのも大切ですが、一番いいのはコードを読むことです。

 

69.車輪の再発名の効用
既にあるコードを流用せず、一から開発することは、一般的にはあまり良いことではない。
もしそれを行うとなると、膨大な知識やテストを行う必要が出てくる。
だが、ソフトウェアの核になる部分を学ぶことで、「ブラックボックス」となっている部分の中を知ることができる。
本を読むことで知識を頭に入れることも大切だが、実際に手を動かして経験を積むことも大切。

 

70.シングルトンパターンの誘惑に負けない
シングルトンパターンは、多くの問題の解決に役立つデザインパターンであるが、短所も多い。
テストの妨げになり、保守性も悪いため、使いたい誘惑に抵抗しなくてはならない。
具体的には以下の短所がある。
・「必要なインスタンスは1つだけ」という要望は、多くの場合推測に過ぎず、後々問題を引き起こす。
 要件は変化するものであり、シングルトンパターンは変化を織り込んでいるとは言えない。
・本来不要な暗黙の依存関係を生んでしまい、ユニットテストの妨げになる。
 また、グローバルにアクセス可能かつ永続化された状態が暗黙の内に起こる為、コードから状態の推測が困難になる。
・マルチスレッドでの使用は特に危険。
 DCLPパターンを用いてロックを行うが、完全とは言えない。
・明示的に殺す方法が無く、全オブジェクトをクリーンアップするまで安全にアンロードできない。
・複数のシングルトンがあった場合、クリーンアップ順序が決まっておらず、別のシングルトンにアクセスしようとすると、
 既にクリーンアップされている恐れがある。
シングルトンパターンは、必要なインスタンスが絶対に確信できるクラス以外では使うべきではない。
また、グローバルアクセスポイントにすることは避け、インターフェースを通じてアクセスするようにすること。

プログラマが知るべき97のこと まとめ 8

まとめ記事続きです。

個々のエッセイはクリエイティブ・コモンズでライセンスされています。

 

60.真実を語るはコードのみ
ソースコードは一目見ただけで理解できるよう、できるだけ簡潔に書くべきである。
コメントを逐一書いても、実装との同期が切れたり、余計なコメントのせいで見にくくなっては意味がない。
コメントが無ければ分かりにくいコードの場合、コメントを書くよりリファクタリングしたほうが賢明です。
分かりやすいコードを書くには、見て意味がすぐ理解できるような名前を付ける、
部分同士の依存関係をできるだけなくし、直行性を高めることが大切です。
コードが分かりやすければ、保守がやりやすくなるだけでなく、あらゆる作業が円滑に進むようになります。

 

61.ビルドをおろそかにしない
実行ファイルを実際に作成するのはビルドスクリプトなので、時間をかけてでも学ぶべきである。
ビルドについて正しく理解すれば、手順を簡潔化して新人に担当してもらうこともできますし、
自動化することでマシン環境による差異をなくすことだってできます。
ビルドにかかる手間を省くことでコーディングに集中できるようになり、作業はより楽しいものになるでしょう。

 

62.プリミティブ型よりドメイン固有の型を
言語が提供する型(int、floatなど)を使うより、そのドメイン(使用する目的)固有の型(km/h、cmなど)を使用する方がよい。
具体的に次のような利点がある。
・コードが読みやすくなる。単位が意味をそのまま表すため、分かりやすい。
・テストがしやすくなる。機能が独立する為、1つ1つのテストがしやすくなる。
・コードの再利用が容易。同じコードを複数のシステムに使いまわせる。

 

63.ユーザの操作ミスを防止する
ユーザーの入力が指定のフォーマットと少しでも違っていればエラーにするようにすれば、
作り手としては楽だが、ユーザーとしてはなぜエラーなのかわからず、ストレスが溜まってしまう。
欲しいのはあくまで情報であり、データではない為、多少の違いは許容できるよう設計すべき。
この種のエラーを防止するには、指定のフォーマットをユーザーに知らせる、リストから選択させるといった方法を取るとよい。
「戻る」機能を搭載し、その時の操作をログに残せば、どのようなミスをする傾向があるのか分析し、改良できる。

 

64.プロのプログラマとは?
プロのプログラマの最大の特徴は、「自分が責任を取る」という態度、責任感にある。
・自分の意志で新たな知識、技術を習得し、常に最先端にいられる努力をすることで、キャリアに責任を持っています。
・間違いなく正しく動くと確認できるまでリリースしない姿勢により、コードに責任を持っています。
・プロはチームプレイヤーであり、「お互い様」の姿勢でチームメイトと助け合い、学びあい、補い合います。
・バグリストが一定以上の規模にならないよう、常に注意を怠りません。巨大なプロジェクトでなければ、本来不要なものだからです。
・プロは自分の誇りにかけて、美しく、完璧な製品を作ろうとします。時間が無くとも、決して間に合わせのいい加減な仕事はしません。
プロであるということは、責任を負うということです。
余裕が無くとも、常に最善の努力を尽くす姿勢こそがプロなのです。

created by Randy_Hoo.