美しく明確であるべき どんなコーディングスタイルを採用したとしても、全体として美しく明確かどうかをレビューしてください。 平易な表現か？ 平易な言葉で優しく表現されているか？聞き慣れない、わからない表現になっていないか。 重複はないか？ 繰り返し使われているようなコードがないか。 ベストプラクティスがどうか？ プログラミング言語やフレームワークにベストプラクティスがあるはずです。ベストプラクティスに基づいているかをチェックしてください。多くの言語には地雷になる書き方があります。コーディングルールでカバーできる部分もあります。 Ruby on Railsでは静的コード解析で、ベストプラクティスに基づいているかチェックできるgemがあります。 機能が無利益なオペレーションを要求していないか？ 作成された機能が無利益なオペレーションを要求していないか考えましょう。 変更にかかるコスト 例えば、こ
前回はコードレビューを始めて組織で行うために、具体的にどうやって行くべきか？そして、加速させるためにどのように実施していくべきかについて考えました。 そして、今回はコードレビューという貴重な機会と時間の価値を最大化させるためのポイントがあります。 このポイントを意識して望むことにより、より効果的なコードレビューとなるでしょう。 ぜひ、これからコードレビューを始めるチームは共有してみてください。 懐疑的な視点に立つ レビュー対象に対して懐疑的な視点に立って、レビューをおこないましょう。 上司のコードだから、先輩のコードだからといって、楽観的な視点でのレビューは、コードレビューという機会の価値を下げます。 プロダクトの品質が悪くても、レビューに報いる どんなにプロダクト（製品）の品質が悪くても、1人のプログラマーとして、あなたはコードに実直に向かい合い、レビューに対して報いるべきです。 評価し
コードレビューについて勉強してみた@HIROCASTERでございませう。 コードレビューについて古い資料をあさり、学んで、経験と照らし合わして、書いていきたいと思います。 今回は、これからコードレビューを実施していきたいという人達に向けて、コードレビューをする動機と、どこからやるべきなのかという視点を考えます。 ソフトウェア開発において、多くの問題はコードを起因にして起きます。そのため、多くのプログラマー達がコードレビューをしようと考えます。これは良くある会社の光景ではないかと思います。そして、コードレビューをする出発点となります。 医者が患者に苦悩を伴ってもらわないと、大病が治らないのと同じように、プログラマーが苦悩を伴ってもらわないと、ソフトウェアの大きなバグや致命傷は治りません。 よって、コードレビューは 苦悩が最大と思われるところからレビューを始めよ。 といわれます。 重圧が大きい
前回はコードレビューを始める動機や始めるために必要な心得について考えました。 今回はこれからコードレビューを始める組織が、どのようにして具体的にはじめて行くべきなのかを考えます。 コードレビューが定着していない人達がどのようにして、コードレビューを始めるべきでしょうか？ まずは、コードレビューをやってみる まずは、重圧などはかけずに、気軽な気持ちでやってみてください。今回は「はじめること」が目的です。 コストの高い準備や学習はしない 使い慣れたコードレビューツールがあるれば、それを利用してやれば良いでしょう。なければ、既存のIDEやエディタをプロジェクタで投影しながらやれば良いです。とにかくツールを覚えるコストや準備するコストは、なるべく省きましょう。フットワーク軽くはじめる事が重要です。 実際にやってみることによって学ぶ姿勢 コードレビューをやった経験が十分にないのですから、最初はグダグ
こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。 mixiの開発フローにはコードレビューという工程が含まれています。 今回はこの工程を行うコードレビューアな人々と、その業務内容、今後（の予定）などをお話しようと思います。 コードレビュー業務 mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。 レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。 開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。 そんなこんなで現在ではアプリ開発者に対して、コードレビ
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
いくつかの事に気をつけてコードレビューを実施するだけで、効率的にコードの品質を高めることができる。効果的なコードレビュー方法をまとめてみた。 （１）複数の有識者でレビューを実施する レビューアも人間なのでレビューが面倒になってしまうときもある。複数のレビューアが一緒にレビューすることによって、一人だけ「指摘なし」と言うわけにもいかず手抜きし辛くなる。 （２）事前に指摘事項をまとめておく ソースコードを読む速度はレビューアのスキルによって異なるため、レビュー時に読み合わせするのは時間がもったいない。調査が必要となることもあるし、じっくりと考えたいこともある。レビューは前もって行っておく。指摘箇所のフィードバックだけは対面で行うのがよい。 （３）印刷してレビューする エコではないが、指摘箇所を気軽に書き込めるのがよい。書き込み量をみるだけでレビューアがどれだけ丹念にレビューしてくれたのかが一目
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
