コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
レビューを楽にするたった1つの方法 - だいくしー(@daiksy)のはてなブログ
photo by AstroSamantha こんな勉強会に参加してきた。 devlove-kansai.doorkeeper.jp ワークショップですごく学びがあったので共有しようと思う。 レビュー対象の価値を考える ワークショップでは、参加者に某システムの設計書（抜粋版）が配られ、それをレビューしてください、というところから始まった。 仕事の後で疲れていることもあるし、どこのものとも知らない設計書を突然渡されてもちゃんとレビューなんかできるわけない、と一瞬思ったのだが、ここにある観点を1つ差し挟むことで劇的にレビューがやりやすくなった。 それは、レビュー対象の価値を考えてみようというもの。 具体的にはこうだ。 まず、レビュー対象となる機能が実現されることにより、どのような価値が生まれるかという物事を、価値の高いと思われる順に列挙していく。 たったのこれだけ。 対象の価値を基準に考えると
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
Heroku Review Apps Beta
Today we’re announcing a feature that is going to change the way teams test and evaluate code changes. Continuous delivery works best when all team members — designers and testers included — can efficiently visualize and review the result of proposed changes. With Review Apps enabled, Heroku will spin up temporary test apps for every pull request that’s opened on GitHub, complete with fresh add-on
Dokumi (日本語) - クックパッド開発者ブログ
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
Swift のコードレビューで気をつけていること - jarinosuke blog
Swift での iOS アプリ開発 徐々にですが、でも確実に色々な場面で Swift のコードを見る機会が増えてきたことを実感します。 iOS の設計思想など大枠の部分では Objective-C での知見は生きてきます。 しかし Swift の言語仕様についても知っておかないと ついつい低きに流れて Objective-C ぽい Swift になってしまいがちです。 Swift のコードレビュー そこで Swift らしく Swift の良さを活かしたコードにするためにコードレビューの話になるわけです。 iOS 開発全般におけるコードレビューについては以下のブログにまとまっているので省きます。 iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary また本記事を書くにあたって Swift コードレビューを調べていて良いものがまとまっていた
「えっ！？これスピッツの曲なの？？」って思わず言っちゃうスピッツの名曲ベスト - シン・くりごはんが嫌い
以前こんなことがあった。洋楽好きな後輩にいろいろなバンドを聴かせていたときのことだ。スマパンの“Siva”のイントロを流したあと「あ、これってスピッツの“センチメンタル”って曲にすごく似てるんだよ」と、すぐにその曲をかけたら「えっ！？これスピッツなんですか？ちょーかっこいい！」と言われたのだ。 そのときぼくは思った「そうか、世間的なスピッツのイメージってまだまだ“ロビンソン”や“空も飛べるはず”なんだ」と。 “ロビンソン”はスピッツを国民的なバンドにおしあげた超名曲であり、この系譜の曲は“春の歌”や“君は太陽”など、そのあとも作られているが、実はスピッツはディストーションギターが鳴り響くハードなロックテイストの曲も多い。特に『ファイクファー』以降はロックバンドとしてのアイデンティティを模索するような実験作も意識的につくられてるのである。 というわけで今回は、思わず「え？これスピッツなの？」
中規模iOS開発とコードレビュー
フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
まちむすめさんのトップページ [食べログ]
たまに辛口なこともあるけれど、あくまで正直に。 これをモットーに書いています。 旅が好きなので旅先で出会ったお店も書いています。 詳細を見る 口コミ数 ？ お店に掲載された口コミ数を表示しています。 1,642件 写真 11,972枚 54,876 訪問者数 32,046人(先週85人) いいね！ ？ 「行った」にいいね！された合計数を表示しています。 115,823
![まちむすめさんのトップページ [食べログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/52c801d520d02e25145027342840668a76cc2335/height=288;version=1;width=512/https%3A%2F%2Ftblg.k-img.com%2Fimages%2Frst%2Farea%2Ficon_fb_tabelog.gif)
iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
Clang-FormatでObjective-Cのコードを整えたらレビュー捗る - ainameの日記
最近Objective-C書いてるのでClang-Formatというツールを試してみた。 些末なコードレビュー - naoyaのはてなダイアリー にもある通り、コードレビューするときにいちいちソースコードのフォーマットを指摘し続けるのはアンチパターンで、人間以外がやるべき仕事。 PerlならPerltidyというツールがあるけど、Objetive-C（C, C++）にはclang-formatというコマンドがある。暇なので社内で導入出来るように調べた。 ClangFormat — Clang 3.5 documentation 使い方 CLIの場合は以下のように実行する。-iで指定したファイルを上書き、-styleでフォーマットを指定する。 $ clang-format -i -style=Google Hoge.m これだけで既存のコードがフォマッターの設定通りに整えられる。 2014年
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
艦隊これくしょん （PCブラウザゲー） 感想 島国大和のド畜生
勉強用にはじめて放置してたら、結構人気がでててあわてて再開。現在Lv62少将。 以前はゲームはちゃんとエンディングまで遊んでから感想を書くようにしていたが、もう最近のゲームでは無理なので、キリのいいところ、これ以上はやりこまないだろうって辺りで書くことにした。 それゆえ間違った事を書いてる場合もありえます。 ■艦これについて 微エロ、DMM、webブラウザゲと、上手いところを突いて、結構変わった仕様を導入してある。 あたるも八卦、あたらぬも八卦のところ、上手く当たったゲームで羨ましいし、リスペクトしたい。 「集客目的だから、無課金でもソコソコ遊べるゲームにしてね」 というのは、一度でいいから出されてみたいオーダーではある。羨ましい。 時々書いているが、ゲームは「システム」「フレーバー」「ボリューム」で考えると説明しやすいという持論に従い、今回はその3つにわけて適当に感想を書いてみる。 ■シ
「HK 変態仮面」は想像以上にすごい映画だった
今から20年ほど前、1992年は週刊少年ジャンプの黄金期と呼ばれた時代のまっただ中にあった。 当時の主な連載作品はこんな感じ。 ・ドラゴンボール ・ジョジョの奇妙な冒険 ・DRAGON QUEST ダイの大冒険 ・ろくでなしBLUES ・SLAM DUNK ・花の慶次 ・幽☆遊☆白書 その、化け物まみれの週刊少年ジャンプに新連載として飛び込んだ漫画があんど慶周によるギャグ漫画「究極!!変態仮面」だ。 刑事の父とSM嬢の母の血を受け継ぐ高校生がパンティを顔にかぶって変態仮面に変身し、悪人を懲らしめるという、黄金期の少年誌に載せる必要があったのか疑問に思えるぶっ飛んだ作品で、案の定1年で雑誌からは綺麗サッパリ消えてしまったが、ジャンプ少年たちの脳裏にその後の人生で決して消えることのない大きな傷跡を残していった。 その作品を20年もたってから、何かの間違いで実写映画化してしまったのが「HK 変態
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Phacility - Home