プログラミングの tips と refactoring

プログラミングのルール

自分で使っているプログラミングのルールの例プログラミング作法などにも、さまざまなルールが載っているが…

     教条的にルールを使わない

例えば、class を

    必ず実装(implementation)とインターフェースに分ける

とかは間違った選択になりやすい。

第三者に自分のコードを見てもらう

コードレビューは、実行しながら行うほうが良い。

一つの基準は「依存性を下げる」こと。

    同じものを複数書かない
    大域変数を使わない ( Singleton Pattern を含む )
    Transactional に書く

処理の成功失敗の単位。プログラムの動作の論理的な関係の単位。

永続的(あるいは一時的な)データのatomic なupdate

あとで後始末を要求しない。その場で成功失敗が決まる。

可能ならば lock ではなく atomic update とする。

    不要な変数の除去
    setter/getter の使用
    コピペコードの除去
    extract method
    extract interface
    ad-hoc な port の除去

使われてない大域変数は除去する。

オブジェクトの状態以外の変数をメソッドの引数に変更する。

オブジェクトの method を続けて呼び出す時に、パラメータを大域変数などに置かない。同時に呼ばれても干渉しないように引数渡しとする。

インスタンス変数の変更は transactional に行う。

他のオブジェクトのインスタンス変数に直接手を出さない。そのオブジェクトには、そのオブジェクトが想定したインスタンス変数の整合性がある。

setter/getter 経由でアクセスすることにより、並行制御したり、整合性を管理することができる。

C++ や Java では継承により、同じようなことを複数書くことになる。このままでは、変更や拡張する場合に、その複数の部分をすべて変更する羽目になる。

インスタンスを分離して、別なインスタンスに処理を渡すことで継承を避けることができる。しかし、処理を渡す部分が増えてしまう。

Interface ではなく、Abstract class を使って、重複した getter/setter をひとつにする。

大きくなりすぎた method は、これを使って分割する。

複数の実装が必要になった場合は、これを使う。

port 上に複数のプロトコルが走るようにする。

    コマンド長
    コマンド種類
    コマンド引数

のようなパケットを(MessagePack などで)作成する。