コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
クソコードにならない為に、これだけは守って欲しい７つのこと - Qiita
まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので１つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
