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
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
タイトル適当。 まともに書いてブロッグにアップしたかっt 必要なもの gitに対する愛 開発プロセスに対する愛(わぁいレビュー あかりレビュー大好き) 前提状況 申し訳ないけど「gerrit の機能が一通り使える」ことが前提のフロー。githubは読み替えて。gerrit 自体の使い方も、正直よい日本語の記事が無いので時間があれば書くかもしれない。 で、以下のような機能を作る 1) Foo 機能の処理モジュール(Service) 2) Foo 機能のHTTPサーバ側エンドポイント(Controller) 3) Foo 機能のブラウザ側の表示(View) 4) Foo 機能のブラウザ側からのサーバ側への連携(Client-side Cooperation) 2 は 1 に、 4 は 1-2 と 3 に依存している。とりあえず上から作っていく。この時点では 2 までできたよ、とする。後、トピッ
現在、私はスタートアップから大企業、さらには個人に対しても色んなアドバイスをすることを生業としている。 アドバイスの多くは私自身の経験に基づくものである。自分で試行錯誤した結果に見出した知見を形式知化し、それをお伝えしている。 そのような経験則に基づくアドバイスだが、後になって、実はすでに確立された知見だったことを知ることがある。 その1つに、自分の中である結論を持っているときでも、相手の口からその結論を言わせるようにするというものがある。誰から見ても正しいことが明確な場合は、そんなまどろっこしいことはせずに指示すれば良い。しかし、説明しても納得してもらえるかわからないものの場合は、いきなり指示を与えても自分ごとにはならない。勢い、上司のための仕事となり、やらされ仕事となる。 そのような場合は、こちらから結論を一方的に伝えるのではなく、自ら考え同じ結論を導き出して貰う方が良い。この方がいわ
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大2時間。それ以上やっても集中力が続かないので。プロジェクタで対象
・画面の遷移が理解できない。 ・ゲームのモチベーションが理解出来ない。 ・何が面白いのか理解できない。 これでは俺がアホのようだ。そこは事実なので否定はしないが。 ・画面の遷移が理解できない。 これに関しては、いわゆる伝統的なソシャゲの操作、遷移にのっとっているものと思われる。 思われるが、伝統を辿らずにいきなり触った身からするとすげぇツライしかったるい。 すぐ慣れるかと思ったけど、結構慣れない。(流石に5日もやってたら慣れた) 回線が重いから、ネイティブアプリじゃないから、旧ガラケの電話テンキー前提だから、と、色々理由があるのは分かるが、これは大変だ。ゲームをやめてしまう理由になり得るレベル。 つーかブラウジングだからなー、ある種の限界もあるだろう。 これは今後の進化の過程でもっと整理されていくと思うのだけど、既にわりと恐竜的進化してるので、このまま突っ走って、ユーザーが慣れるかもしれな
Review Boardならコードレビューを効率良くできる!:ユカイ、ツーカイ、カイハツ環境!(19)(1/3 ページ) “コードレビュー”やってますか? “コードレビュー”は、ソフトウェア開発の重要なプロセスですが、往々にしておざなりにされがちです。 しかし、きちんとコードをレビューすることで、品質向上や、早期のバグ発見による後工程でのコスト削減につながります。また、病気や事故、他のプロジェクトへの突発的な火消し(!)などによる、開発メンバーの長期離脱時のリスク削減にもつながります。さらには、他の開発者が書いたコードを読んで学習することにより、コーディングスキルの向上にも役に立ちます。 今回は、「そうはいっても、現実的にコードレビューなんて無理……」という方のために、コードレビューを効率化する「Review Board」というツールを紹介します。 Review Boardの主な特徴5つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く