10人以下のエンジニアチームでコードの品質を守る為に試した事 - KAYAC engineers' blog
モバイルゲームクライアント開発のテクニカルディレクターなどを最近やっている須藤 崇浩 | 面白法人カヤックと言います。 こちらは 面白法人グループ Advent Calendar 2022 の24日目の記事です。 明日はクリスマスですね。クリスマス翌日に売れ残って割引されたスイーツを買って美味しい思いをするのが好きです 🎂 本記事では表題に関して、昨年から参加しているモバイルゲーム開発案件で立ち上げから試行錯誤してる事について書いていきます。 「何故か開発後半でコードが複雑になってメンテナンスしづらくなる」「人間に書かせるべきでは無いのではないか？」..などコードの品質について悩んだ経験のある方に多少なりとも参考になる内容になれば幸いです。 目次 目次 コードレビュー 開発初期 「チームとして良いとされるコード」とは？ 開発後期 新人のオンボーディング 複雑度の低いシステムから徐々に難易
知らないと恥ずかしいコードレビューで指摘されがちなポイント14選 - Qiita
この記事はNuco Advent Calendar 2022の13日目の記事です はじめに 私は情報系の学部に通う大学４年生です。大学でプログラミングを学んだことをきっかけに、プログラミングを使用した実際の業務に取り組んでみたいと思いました。そして、株式会社Nucoさんで機会をいただき、現在インターン生として実務に参加させていただいています。 自分のように、プログラミングを学び、「実務の経験が積みたい」「インターンに参加してみたい」という方はたくさんいらっしゃるかと思います。この記事では自分が実際にインターン生として実務に参加し、コードレビューで指摘されたポイントを紹介します。 難易度、頻出度の目安を★の数で示しています。 ・難易度・・・それぞれの項目で指摘されないようなコードを書く難しさ。 ・頻出度・・・それぞれの項目のミスの起きやすさ。 難易度(低→高)、頻出度(高→低)の順番で紹介し
コードレビューで普段意識していること、してもらっていること - Qiita
コードレビューで普段意識していること、してもらっていること はじめに こんにちは。 この記事は Spring Advent Calendar 2022 の 19 日目の記事です。 本記事では僕が普段レビュワーとして、コードレビューで気をつけていること。またレビュワーをするようになった経験からレビュイーとしてPullRequestを作る際に気をつけていること、PullRequestを作ってもらう際にお願いしていること、を書きます。 直近では半年で650個ぐらいのPRを見ていて、エンジニアリングをする時間の中でコードレビューの比率が上がってきたこともあり、その中で色々思ったり工夫した点を書いていきます。 なお普段はspring-bootで構成されるアプリケーションのソースを読むことが大半のため、spring-bootに焦点があたった内容に少し偏るかもしれません。悪しからず。 大前提 これはレビ
Pull requestの理想的なサイズとその理由
この記事は、Lancers（ランサーズ） Advent Calendar 2022 の2日目の記事です。 モチベーション 一般的にPull Requestはサイズが小さいほうが良いとされていますが、理想的なPull Requestのサイズは具体的に何行なのでしょうか？ また、なぜPull Requestのサイズは小さい方が望ましいのでしょうか？ 本稿ではPull Requestの理想的なサイズとその理由について、リサーチした内容をまとめます。[1] 本稿で取り扱う観点について Pull Requestのサイズを考察するにあたり、主に注目される観点は以下の2つがあります。 リーン思考に基づいたフロー効率の観点 コードレビューに関する観点 本稿では、理想的なPull Requestのサイズについて具体的な数字を示したいというモチベーションから、コードレビューに関する観点について取り扱うことにし
コードレビューのときに見ているところ - 詩と創作・思索のひろば
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
ソースコードレビューをするにあたって、参加者が心得ておくべきこと | Act as Professional
前回はコードレビューを始めて組織で行うために、具体的にどうやって行くべきか？そして、加速させるためにどのように実施していくべきかについて考えました。 そして、今回はコードレビューという貴重な機会と時間の価値を最大化させるためのポイントがあります。 このポイントを意識して望むことにより、より効果的なコードレビューとなるでしょう。 ぜひ、これからコードレビューを始めるチームは共有してみてください。 懐疑的な視点に立つレビュー対象に対して懐疑的な視点に立って、レビューをおこないましょう。 上司のコードだから、先輩のコードだからといって、楽観的な視点でのレビューは、コードレビューという機会の価値を下げます。 プロダクトの品質が悪くても、レビューに報いるどんなにプロダクト（製品）の品質が悪くても、1人のプログラマーとして、あなたはコードに実直に向かい合い、レビューに対して報いるべきです。 評価しない
これからソースコードレビューをする人達へ向けての心得 動機編 | Act as Professional
コードレビューについて勉強してみた@HIROCASTERでございませう。 コードレビューについて古い資料をあさり、学んで、経験と照らし合わして、書いていきたいと思います。 今回は、これからコードレビューを実施していきたいという人達に向けて、コードレビューをする動機と、どこからやるべきなのかという視点を考えます。 ソフトウェア開発において、多くの問題はコードを起因にして起きます。そのため、多くのプログラマー達がコードレビューをしようと考えます。これは良くある会社の光景ではないかと思います。そして、コードレビューをする出発点となります。 医者が患者に苦悩を伴ってもらわないと、大病が治らないのと同じように、プログラマーが苦悩を伴ってもらわないと、ソフトウェアの大きなバグや致命傷は治りません。 よって、コードレビューは 苦悩が最大と思われるところからレビューを始めよ。 といわれます。 重圧が大きい
はじめてのコードレビューは、どうやって始め、加速させるのか？ | Act as Professional
前回はコードレビューを始める動機や始めるために必要な心得について考えました。 今回はこれからコードレビューを始める組織が、どのようにして具体的にはじめて行くべきなのかを考えます。 コードレビューが定着していない人達がどのようにして、コードレビューを始めるべきでしょうか？ まずは、コードレビューをやってみるまずは、重圧などはかけずに、気軽な気持ちでやってみてください。今回は「はじめること」が目的です。 コストの高い準備や学習はしない使い慣れたコードレビューツールがあるれば、それを利用してやれば良いでしょう。なければ、既存のIDEやエディタをプロジェクタで投影しながらやれば良いです。とにかくツールを覚えるコストや準備するコストは、なるべく省きましょう。フットワーク軽くはじめる事が重要です。 実際にやってみることによって学ぶ姿勢コードレビューをやった経験が十分にないのですから、最初はグダグダにな
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
社内でも立てられるGitHubクローン·GitLab MOONGIFT
GitLabはRuby/Ruby on Railsで作られたGitHubクローンです。 GitHubは有料でプライベートリポジトリが持てますが、それでもセキュリティ上の理由でリポジトリを外だしできないケースはあるかと思います。そんなときに使ってみたいのがGitLab、GitHubクローンです。 ログイン必須になります。 ログインした後の画面です。登録済のプロジェクトが一覧表示されます。 一つのプロジェクトを閲覧しています。ソースツリーが出ます。ソースツリーは右へ右へスライドして表示されます。GitHubに似ています。 ソースコードハイライターも内蔵されています。rawでファイルをダウンロードできます。 タグやブランチを切り替えることもできます。 コミット履歴一覧です。 コミット詳細ではDiffが確認できます。 コミットに対するコメントも確認できます。 チーム設定です。複数人でのコラボレーシ
シンプルで格好いい。親切なコードレビューシステム·Barkeep MOONGIFT
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
mixiのコードレビューについてご紹介 - mixi engineer blog
こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。 mixiの開発フローにはコードレビューという工程が含まれています。 今回はこの工程を行うコードレビューアな人々と、その業務内容、今後（の予定）などをお話しようと思います。 コードレビュー業務 mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。 レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。 開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。 そんなこんなで現在ではアプリ開発者に対して、コードレビ
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
GitコードレビューツールGerrit - プログラマの思索
GitコードレビューツールGerritの情報をリンクしておく。 以下ラフなメモ書き。 【元ネタ】 Gerritを約1年運用してみて | ちとろぐ Lhaz開発課 - ちとらソフト開発部 gerrit - Gerrit Code Review - Google Project Hosting Google製のGit用ソースコードレビューシステム「Gerrit」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ Twiwt:Blog / jugyo : 僕が Gerrit について理解している数少ないこと Jenkins Gerrit Trigger Plugin の使い方 | Aiming 開発者ブログ GerritはGitだけのためのコードレビューツール。 上記の記事の感想で面白い点は、addやcommitのような基本的コマンドだけ
Google製のGit用ソースコードレビューシステム·Gerrit MOONGIFT
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある（Rails製）。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レビューの仕方
Speaker Deck | Easily Share Your Presentations Online
Phacility - Home
