既存コードの甘い匂い (悪意なきチグハグコードの誕生) - jfluteの日記
まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
