まとめ記事続きです。
個々のエッセイはクリエイティブ・コモンズでライセンスされています。
14.コードレビュー
コードレビューの目的はコードの誤りを修正することだけではなく、チームに同じ知識を共有させること。
自分の書いたコードを他のプログラマと共有することで、「コードの共有所有」が可能になる。
コードレビューは辛辣で辛く、硬い場にするより、砕けた雰囲気で、主な目的を「メンバー内で知識を共有すること」に
すると成功させやすい。
15.コードの論理的検証
コードの正しさを検証するには、コードを短いセクションに分割し、チーム内で話し合うことが有効。
また、下記のコーディングプラクティスを守ることで検証が楽になる。
・セクション内での機能を1つのタスクに絞りこむ。
・goto文の使用を避ける。離れたところにあるセクションに強い依存関係が生まれてしまう。
・変更可能なグローバル変数は作らない。使用するすべてのセクションが相互依存関係になるため。
・変数のスコープは可能な限り小さくする。
・オブジェクトは可能な限り不変オブジェクトにする。
・オブジェクトや関数などには、特性や機能がすぐ分かる、短い名前を付ける。
・セクションを入れ子にする場合には、関数化する。
・関数はできる限り短くし、機能を1つに絞り込む。「24行制限」は現代でも有効である。
・関数のパラメータは最高でも4つまでにする。関数で扱うデータを減らすだけでなく、凝集性、整合性の検証が容易になる。
・インターフェースはできるだけ狭くすべし。getter、setterは推奨できない。
カプセル化を強力にすることで、検証の手間を減らすことにつながる。
16.コメントについてのコメント
「コードは、次に見る人がすぐに理解できるように書く」ことが大切。
コードには、「このコードはどういう目的で書かれたものか」を説明するコメントを入れる必要がある。
コメントは多ければいいというものではなく、必要にして十分な量のコメントを入れること。
ヘッダコメントには「コード本体を全く読まなくても利用はできる」くらいの情報を盛り込み、
インラインコメントには「修正や拡張をする人の助けとなるような情報」を適宜盛り込む。
17.コードに書けないことのみをコメントにする
コメントを入れても、不適切なものであれば意味は無い。
コードに書かれていることをオウム返しにするだけのコードはノイズとなり、プログラマの思考の邪魔をする。
Ver.を知らせるコメントや、変更履歴を知らせるコメントは、バージョン管理システムを導入すれば不要になる。
メソッドやクラス名が分かりにくいなら名前を変える、関数が長いなら細かく分割してそれぞれ名前を付けるなどの
工夫でコメントは不要になる。
コードに「書いていない事」ではなく、コードに「書けない事」のみをコメントにすべき。
18.学び続ける姿勢
今の時代、生き残るためには学び続けなければならない。
・書籍や雑誌、ブログ、Twitterを読んで参考にする。
・本当に身に着けたい技術はコードを書き、手を動かして学ぶ。
・常に自分よりレベルの高い人と仕事をする。レベルの高い人から学ぶことは多い。
・「良き師」になりえる人をネット上で探す。
・自分の利用しているフレームワークやライブラリに対する知識を深める。オープンソースなら
デバッガを使い中身を理解するとよい。
・ミスやバグ修正は解決するだけではなく、深く理解するように努める。
・自分が学びたいことを人に教えたり、話したりする。
・カンファレンスに参加する。
・自分のコードに対して静的分析ツールを実行する。レポートや警告の理由を追及する。
・「達人プログラマ」の教えを実行し、毎年1つ新しい言語を学ぶ。技術、ツールでもよい。
学ぶのはコンピュータ関連技術でなくても、システムが使用される分野や生産性を高める方法でも構わない。
技術はすごい速さで変化していきます。学ばなければ置いていかれるのは確実です。