バグを増やさないためにコードレビューのチェックリストを使う | Yakst
チーム内で良くある間違いなどをチェックリストにし、それをコードレビュー時に使う事で、コード自体のレベルを上げつつコードレビューの品質のばらつきをなくす取り組みについて。Trelloなどを開発するFog Creek社のブログの翻訳。 効果的なコードレビューについて書いた我々のブログ記事の中で、チェックリストを使う事を推奨した。チェックリストを使う事で、レビューが継続的にチーム全体でうまくはたらくようにできる。また、ありがちな問題を見つけたり解決したりするのを確実にする、簡単な方法でもある。 ソフトウェア工学研究所の研究によると、プログラマは15から20の良くある間違いをしてしまいがちだという。そういった間違いをチェックリストに追加しておく事で、問題が起こった時にそれを特定し、確実に駆逐するようにできる。 チェックリスト作りに取り掛かるに当たって、一般的な項目は以下のリストのようになるだろう。
コードレビューの際によく指摘するポイントについて - Qiita
このドキュメントについて レビューポイントっていうのは周囲のレベルや使っている技術によりまったく異なるのですが、割と汎用的に使えそうな部分について今の開発チーム向けに書いたドキュメントを共有 レビューチェックポイント(機能) 仕様と実装が合っているか 仕様が不明瞭な部分について勝手な仕様で実装をしていないか 違和感のある実装になっていないか ロジック・アルゴリズムが合っているか そもそも論理構造が破綻していないか 画面表示に違和感がないか 奇妙な文言、ユーザ視点で奇妙な動きになってないか 不正なユーザ入力で問題が発生しないかFatalErrorにならないか 入力に対し適切なvalidationが行なわれているか レビューチェックポイント(コード) 意味の無いロジックが含まれていないか コピペでコードを持ってきた場合にコピペ元の不要なコードが入っていないか そもそも基本コピペはNG コピペで
コードレビューの基準
コードレビューの基準 コードレビューの主な目的は、Google のコードベースにあるコードの全体的な健康状態を時間をかけて改善することです。 コードレビューのすべてのツールとプロセスは、その目的のために設計されています。 これを実現するには、さまざまなトレードオフのバランスを取る必要があります。 まず第一に、開発者は自分のタスクを進めることができなければなりません。 コードベースに改善を提出できなければ、コードベースは改善しません。 また、どんな変更に対してもレビュアーがいちいち難色を示して変更を取り入れずにいると、早晩、開発者は改善を行う意欲を失います。 一方、CL の品質を確認するのはレビュアーの義務です。CL を取り入れてコードベースのコードの全体的な健康状態 (code health) がだんだんと悪化するのは問題ですから、きちんと確認しなければなりません。 これは骨の折れるやっか
コードレビューの観点
コードレビューの観点 （注）以下のポイントを検討する際にはつねにコードレビューの基準を忘れないでください。 設計 レビューで確認すべき最も大切なことは、CL の全体的な設計です。 CL のコードの各部分は相互にきちんと連携するでしょうか？この変更はコードベースに属するものでしょうか、それともあるライブラリに属するものでしょうか？システムの他の部分とうまく統合するでしょうか？この機能を追加するタイミングは今がふさわしいでしょうか？ 機能性 この CL は開発者の意図通りに動作しますか？開発者の意図はこのコードのユーザーにとって適切でしょうか？「ユーザー」とは普通、エンドユーザー（その変更によって影響を受ける場合）と開発者（将来このコードを「使う」必要のある人）の両方を指します。 通常、CL がコードレビューに至るまでには、コードが正しく動作することを開発者が十分にテストしていると期待できます
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
エンジニアの不安と壁 - naoyaのはてなダイアリー
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
0xとは : JavaA2Z
整数リテラルで16進数表記を使用する時に、頭に付ける文字。 整数リテラルの頭に「0x」もしくは「0X」を付けると、その値は16進数と見なされる。 たとえば「int i = 0xA;」と記述した場合、変数iに16進数の「A」、つまり10進数の「10」が格納される。 頭に付ける文字は「0x」「0X」どちらでも構わない。 また、16進数表記内のアルファベットは大文字でも小文字でも構わない。 つまり「0xa」「0xA」「0Xa」「0XA」はすべて同じである。本辞書では見やすさを考えて「0xA」の形式で統一してある。 16進数表記内のアルファベットは、16進数であるため当然「A～F」「a～f」しか使用できない。「G～Z」「g～z」を使用するとコンパイルエラーとなる。また「0x」「0X」のみでもコンパイルエラーとなる。 整数リテラルを16進数で表記したとしても、内部的には2進数の形式で保存されている点
ビット演算
たとえば、ビットごとの AND は、ビットレベルで論理積を求めます これはどういうことかというと、数値を2進数として考え 二つのオペランドの各ビットに対し双方が 1 であれば 1、そうでなければ 0 という結果を出します 論理積の演算は、あるビットを削除したりする場合に便利です alert(0x57 & 0x0F); スクリプトを実行 これは、二つの16進数の数値 57 と 0F を論理積で演算しています これらの16進数は、2進数に変換すると 0101 0111 & 0000 1111 という計算になっています この形で、コンピュータはビット演算を行います 0000 0111 というように、左辺と右辺のオペランドが演算されています 論理積は双方のビットが 1 でなければ 0 となるので、0x0F と演算させた場合 必ず上位4ビットは 0 となるため、上位4ビットを論理演算で削ることができ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本人が間違いやすいコーディング上の英語 - Qiita
CSSを書く、設計する時に参考にしておきたいCSSのガイドライン・スタイルガイドのまとめ
オブジェクト指向できていますか？