Why Senior Engineers Choose Boring Go Over Exciting Rust
How a $3.2M production disaster taught us that technical excellence doesn’t always align with business success — and why boring… How a $3.2M production disaster taught us that technical excellence doesn’t always align with business success — and why boring technologies often deliver better outcomes Senior engineers learn that the most technically impressive solution isn’t always the best business
人間のコードレビュー力を鍛えるために。AIコーディング時代の「ペアプロ・モブプロの心得」 | レバテックラボ（レバテックLAB）
人間のコードレビュー力を鍛えるために。AIコーディング時代の「ペアプロ・モブプロの心得」 2026年1月22日 IDEO PLUS合同会社代表 加藤 潤一 30年以上のソフトウェア開発経験を持つエンジニア。東芝グループで製造技術・品質保証を経験後、株式会社ドワンゴ、グリー株式会社、Chatwork株式会社(現 株式会社kubell)でテックリードを歴任。自ら設立したIDEO PLUS合同会社にてSaaS企業を中心に、ZOZO、Leveragesなどでも技術顧問・技術支援を行う。ドメイン駆動設計とリアクティブシステム設計が専門。Scala、Rustに精通し、持続可能で耐障害性の高いソフトウェア設計を得意とする。 X：@j5ik2o keyboard_arrow_down はじめに keyboard_arrow_down AIとの協働の難しさと課題 keyboard_arrow_down ペア
Go初学者へのコードレビューでよくあったコメント20選
はじめに こんにちは、ソーシャルベッティング事業本部 海外ベッティング事業部の山崎です。 本記事では、Effective GoやGoogle のスタイルガイド、Code Review Commentsといった公式資料、Future Architectの記事などを参考に、Go を初めて触る開発者を対象にした汎用的なレビューコメントの 20 選を紹介します。 大きく以下の４つのセクションに分けました 言語仕様に関わる内容 標準パッケージの使い方 エラーの扱い方 単体テスト Linter の活用について 可能な限り lint で自動化して人の手が加わる前に静的解析でできればベターです。 特にこの記事で紹介するような汎用的なコメントについてはいくつか反映できる lint もあると認知しております。 そのような設定の lint config サンプルをまとめようとも思いましたが、実際に運用まで至って
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
言葉をどう受け取るかは人それぞれ、かつ、多様ということを学んだ話 - 覚書
はじめに 最初に言っておきますが、とくにスカっと結論が出るような話ではないです。 昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。 わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。 コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな— sat (@satoru_takeuchi) 2019年3月20日 「50-60人くらい答えてくれたら面白いな～」と思っていたのですが、最終的には3705人もの人
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
Explaining Code using ASCII Art – Embedded in Academia
People tend to be visual: we use pictures to understand problems. Mainstream programming languages, on the other hand, operate in an almost completely different kind of abstract space, leaving a big gap between programs and pictures. This piece is about pictures drawn using a text character set and then embedded in source code. I love these! The other day I asked around on Twitter for more example
Code ownership and software quality
Author: Michaela Greiler Collective code ownership has been advocated as a best practice [1]. Is it always? Several studies have shown that code ownership has an impact on software quality. This article outlines code ownership and its impact on quality and shows the results of two studies we performed at Microsoft investigating this topic. What is code ownership? In a traditional sense, ownership
既存コードの甘い匂い (悪意なきチグハグコードの誕生) - jfluteの日記
まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CodeReviewComments