You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
The code review tool with static code analysis and code-aware navigation.
Facebook、静的コード解析ツール「Infer」を公開。Objective-C/Java/Cコードのバグを指摘してくれる Inferが対応するコードはAndroidのJavaとiOSのObjective-C、およびC。現時点ではAndroidとJavaではNullPointerExceptionおよびリソースのリーク。iOSとCコードではメモリーリークを発見してくれます。 実際にプログラムを実行することなくバグを発見しようとする静的コード解析は、コードをビルドしてテストプログラムなどを実行するよりも迅速にバグを発見できる方法として期待されています。 Inferも、Facebookがより早く高い品質のソフトウェアをデリバリする目的で開発されたものです。下記はInferを発表したブログ「Open-sourcing Facebook Infer: Identify bugs before y
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
DevLove甲子園 東日本大会でお話した内容です。 http://devlove.doorkeeper.jp/events/11792 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
伊藤直也さんをゲストに迎えて、JAWS、Vagrant Share、CoffeeScript、コードレビューなどについて話しました。 スポンサー: Idobata 0:00 miyagawa: 昨日何かイベントがあったらしいですけど。 naoya: そうそう。JAWS DAYS っていう、AWS の。 miyagawa: JAWS っていうのは？ naoya: JAPAN AWS、かな。Amazon の会社の方じゃなくて、ユーザーが集まってやってるほうですね。 miyagawa: ユーザーコミュニティみたいな？ naoya: そうそう。もう1つ AWS Summit ってすごいでっかいイベントがまた夏にあるんですけど、そっちは Amazon 主催でやってるから、結構 Enterprise track とかもたくさんあってっていう感じで。JAWS の方は本当にユーザーコミュニティが主体なんで
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
