デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
アジャイルなレビューをサポートするツールを5つ
Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie
アジャイルチームにおけるコードレビュー - Sean_SF’s blog
@daipresents さんが「アジャイルなレビューをサポートするツールを5つ」というブログ記事を書かれていました。 コードレビューによりコードの品質を改善することは知られていますが、@daipresents さんのチームのように実際にコードレビューを行っているチームはそれほど多くないと思います。 アトラシアンにおいては、基本的に全てのコードをレビューしています。その方法やヒントなどを説明したブログを以前にいくつか公開しておりますので、参考までに抜粋して下記します。 アジャイルチームにおけるコードレビュー - パートII コードレビューを行う際に留意すべき点として以下の9つを挙げています。 軽量に保つこと 強制しないこと 細かく管理しないこと 非同期のレビューを奨励すること コードレビューを通して、興味深い発見、構成、設計上の決定を積極的に共有すること - チャンピオンになりましょう コ
Review Boardならコードレビューを効率良くできる！
Review Boardならコードレビューを効率良くできる！：ユカイ、ツーカイ、カイハツ環境！（19）（1/3 ページ） “コードレビュー”やってますか？ “コードレビュー”は、ソフトウェア開発の重要なプロセスですが、往々にしておざなりにされがちです。 しかし、きちんとコードをレビューすることで、品質向上や、早期のバグ発見による後工程でのコスト削減につながります。また、病気や事故、他のプロジェクトへの突発的な火消し（！）などによる、開発メンバーの長期離脱時のリスク削減にもつながります。さらには、他の開発者が書いたコードを読んで学習することにより、コーディングスキルの向上にも役に立ちます。 今回は、「そうはいっても、現実的にコードレビューなんて無理……」という方のために、コードレビューを効率化する「Review Board」というツールを紹介します。 Review Boardの主な特徴5つ
米CollabNet、SubversionやViewVCを組み合わせ容易にインストール・管理できる「Subversion Edge」を発表 | OSDN Magazine
米CollabNetは6月17日（米国時間）、バージョン管理システム「Subversion」に「Apache」「ViewVC」を組み合わせたバンドル「CollabNet Subversion Edge」（ベータ版）を発表した。WebベースのGUIでソフトウェアスタック全体のインストールや管理を行える。 Subversion Edgeは、Subversion、コードビューアのViewVCとApacheを組み合わせたディストリビューション。単一のインストーラーでインストール・設定でき、Webベースの管理画面で容易にソフトウェアスタック全体を管理できる。SVNレポジトリの作成・管理、ViewVCでSVNレポジトリのブラウズ、SVNとApacheのログ管理と閲覧などの機能を利用できる。 また、アップグレード機構も組み込まれており、新しいコンポーネントがリリースされている場合は通知が行われるほか、W
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Gitリポジトリにあるコードを追う / コードレビュー - Masatomo Nakano Blog
これまではcommitされたコードを、commit(push時)メールでなんとなく見ていたが、取りこぼしも多いし、忙しいと、つい見なくなってしまうので、なんかいい方法はないかなとここ数カ月くらいぼんやり考えていた。で、簡単なスクリプトでできそうと気づいたのでメモ。Githubに置いてあるようなオープンソースなコードとかも追いやすいんじゃないかなー。 ちなみに、このスクリプトを書く前に、コードレビューシステム的なのを導入しようかとGerritとか、Review Boardを少し試してはみた。でも、うちで使うにはちょっと大げさ過ぎるので、導入してもツールに踊らされる or 使わなくなる、という感じがしたので、とりあえずやめた。 いまいち気に入らない点としては、Gerritとかは完全にcommit単位でのレビューなんで、ちょっとしたパッチレベルならいいのだが、がりがり書いていく中ではちょっと現実
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Something went wrong.
Something went wrong.