サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは！サービス開発部でAndroidアプリの開発をしているこまたつ（@k0matatsu）です。 みなさんコードレビューしていますか？ 最近ではとりいれているチームも多いと思いますが、良い効果をもたらしてくれる一方で、負荷の高い作業でもあります。 また、コードレビュー自体に馴染みの薄かった人はなにをどうしたらいいのか難しいですよね。 同僚から得たアドバイスと自分なりのノウハウをあわせて、コードレビューの指針を考えていたので公開してみようと思います。 前提として、クックパッドではGitHub Enterpriseとプルリクエストを使った開発プロセスを採用しています。 また、コードレビューの前には自動テストと静的解析ツールによる単純なフォーマット、コードスタイル、頻出バグのチェックは行われているものとします。 静的解析による機械的なチェックはコードレビューよりも低コストで有効な方法ですの
このドキュメントはコードレビューを支援するツールについての調査を行った結果を記述する。 ツールの紹介Redmine Code Review プラグインRedmineのプラグインとして動作する。 http://www.r-labs.org/projects/1/wiki/Code_Review インストール方法 通常のRedmineのプラグインと同様 使用方法 リポジトリ―でコミット済みのリビジョンの差分を取り、レビュー用のコメントを記述する。 作成したレビューはプロジェクトのコードレビュータブで一覧として表示される。 記述したレビューはチケットとして登録される。 そして、レビューで作成したチケットはリポジトリから返信とステータスの遷移が行える。 Trac Peer Review Plugin Tracのプラグインとして動作する。 http://trac-hacks.org/wiki/P
はじめに# Subversion をつかっていて, ソースコードレビューでコードにコメントを書きたいと思った. なにか, お手軽にためせるツールはないか探して見たところ, Codebrag というものを見つけたので試す. Codebrag - your daily code review tool Codebrag とは# オープンソースのコードレビューツール. サーバにインストールして, Web 画面からコードレビューができる. Git と Subversion に対応しているようだ. Subversion は, git-svn をつかって使えるようにしているようだ. インストール# インストール手順は以下にある. https://github.com/softwaremill/codebrag/wiki/Installation 以下から, ダウンロード. ダウンロードでメールアドレス
Discuss code Read old and new versions of files with syntax highlighting and colored differences. Discuss specific sections with others to make the right changes. Manage and serve Git repositories Gerrit includes Git-enabled SSH and HTTPS servers compatible with all Git clients.Simplify management by hosting many Git repositories together. Schedule git gc over all managed repositories and replica
ソフトウェア開発の現場では、「高品質」「低コスト」「短納期」が要求され、そのための取り組みが行われている。テスト工程においてもこれらの条件を実現するため、ツールを導入が進んでいるが、思ったよりも効果が出ていないという声も多い。ではどのようなツールをいかに運用すれば、高い品質のソフトウェアを低コスト、短期間で開発できるのか。「開発現場の意識が変わる！ 品質向上を実感する『仕組み』作りとは？」と題して、20年以上のテストツール販売実績を誇るテクマトリックス主催のセミナーが開催された。 ツールの導入に加え、メンバーの育成、開発チームの活性化に注力 テスト工程にツールを導入したものの、品質の向上、開発の効率化が図れていない──。こんな課題を持っている開発現場は多い。そんな課題解決のヒントが得られるセミナーが、静的解析、動的解析の両方をサポートしたC／C++言語対応のオールインワンテストツール「C+
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? mixi Advent Calendar の17日目です。 今までまともにコードレビューをしたことがなかったエンジニアが、半年前からコードレビューを経験し始めて、チームの雰囲気が良くなった（と思っている）レビューの仕方をご紹介します。 私は株式会社ミクシィのグループ会社である株式会社 Diverse へ出向して、そこでデーティングサービス YYC のAndroid クライアントを開発しております。 現在、 YYC のAndroid クライアントは大規模な改修を行っていて、それに合わせて開発チームの再編成・開発フローの改善などいろいろ
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多いUIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Search
