@634

メモ - ソースコード

Advertisement

コード共有の難しさ

ある日いつものように出社して、CVSから最新コードを取得した。
なんてこった!プレゼンテーション層で使用していたクラスがサービス層に移動されているではないか。聞けば、現在の和暦をデータベースから取得するように変更したから移動したらしい。
500行のプレゼンテーションロジックと15行のビジネスロジック… あぁ、リファクタリングしないと。

コード共有を謳う(うたう)上で注意しなくてはならないのは、コード共有の前提にはコミュニケーションときちんと考えられた設計方針が必須だということ。もちろんコーディング基準は絶対必要。
仮に、各自が統一されていない考え方でコードを修正するのなら、いろいろな思想・思惑がごちゃまぜになったシステムになる。

設計方針に対する理解の食い違いはバグや品質低下を招く原因になるため、早めに対処すること。

コードの可読性

開発初期の時点から継続してキレイなコードを書くように心がけることは重要だが、それでも結合や修正を進めていくうちに歪みが発生してしまう。
この歪みを可能な限り低くするために、継続的にコードの可読性向上を行う。業務終了前の30分間は可読性向上のための時間とするなど、きまった時間を割り当てることが望ましい。

コードの可読性向上は、システムの保守性向上・品質向上につながる。

おこさま用コメント

コードとコメントが1対1のプログラムに出会った。
そういえば、意味のないコメントってよく見るなぁ。
if(goodsId == null) {
    // パラメータがNULLの場合
    return null;
}

みればわかる。
// 数量の取得
String number = ParameterDTO.getNumber();

みればわかる。
// 名前
String name = null;
// 価格
BigDecimal price = null;
// 数量
BigDecimal number = null;

みればわかる。
// リストが6件であることを確認
assertEquals("", 6 ,list.size());
あほか。

クラス名、変数名、メソッド名にはわかりやすい名前を付けること。利用側から名称だけで、意味や動作が理解できるようにすること。コメントだらけのコードは読みにくくてしかたがない。

他人のソースコードにはなるべく目を通すこと。

Advertisement

ショートカット

634
634ブログ
このカテゴリのトップページに戻る
Incubator(Pukiwiki)
634ラボ
   UIコレクションギャラリー
   ZO-3ジェネレーター

サイト検索


Y!ログール