コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
依存性反転の原則について
こんにちは、増田です。 今回は"依存性反転の原則"についてObjective-Cで解説します(Objective-Cは筆者が好きな言語です)。 私はこの原則を理解する前は依存関係がスパゲティ状態になったプログラムを書いていました。 プログラムの処理はそうめんのように道筋の立った分かりやすいコードを書いたとしても、依存関係がスパゲティであることがよくあります。そのようなコードを書くと、一箇所を変更するために既に動いているところをいじらなければならず、この際のテストにかかるコストはとてつもなく膨大になってしまいます。 モジュール間の依存は必ずしも悪になるというわけではないですが、「意図して依存を残す」という意識がないと後で痛い目を見ます。依存性を残すところ、断ち切るところを意図してプログラムを組むことができるようになれば、何かしらの変更を迫られた際、変更箇所だけのテストでシステム全体の正常な動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
