グラグ脳の開発者 (2022)

342日前原文(grugbrain.dev)

概要

Grug Brained Developer は、シンプル思考でソフトウェア開発に向き合うためのユーモラスなガイド。
複雑性 は最大の敵であり、「NO」と言う勇気が重要。
80/20ルール や適切な テスト戦略 で、実用性と保守性を両立。
早すぎる抽象化やリファクタリング は避け、システムの形が見えてから対応。
Agileや他の流行手法 も万能薬ではなく、現場に合った方法を選択。

Grug Brained Developerとは

Grug Brained Developer は、自分の頭が良くないと自覚しながらも長年プログラムを書き続けてきた開発者
難しい理論よりも、 実践的な学び を重視したアドバイス集
若手や物忘れが激しくなった自分自身のための 備忘録
Big Brained Developer （理論派）とは異なる現実的な視点
間違いも多いが、その経験を活かして 分かりやすく伝える ことを目指す

永遠の敵：複雑性

複雑性 はGrugにとって最大の敵、T-Rexよりも恐ろしい存在
複雑性は 見えない悪霊 のようにコードベースに忍び込む
最初はシンプルだったコードも、気付けば手に負えない状態に
複雑性 は修正が他の場所に思わぬ影響を及ぼす
Grug自身も複雑性を招くことがあり、常に警戒が必要

NOと言う勇気

複雑性 への最強の武器は「NO」と言うこと
「その機能は作らない」「その抽象化は不要」と断る姿勢
キャリア的には「YES」が昇進や報酬に繋がるが、 エンジニアとしての誠実さ を重視
最初は難しいが、慣れれば自分の shiney rock （報酬）が少なくても納得できる
本当に必要な時だけ「OK」と言い、 80/20ルール で最大効果を狙う

80/20ソリューション

全ての要望を満たす必要はない
80%の価値を20%の労力で実現 するアプローチ
機能や見た目が多少不完全でも、 実用性を優先
マネージャーには細かく説明せず、 結果で納得させる
プロジェクトの現場では、 許可よりも許しを得る 方が効果的な場合が多い

コードの分割とファクタリング

システムの「形」が見えるまでは 早すぎる抽象化や分割を避ける
適切なカットポイント （分割点）が現れるまで待つ
カットポイントは インターフェースが狭く、内部の複雑性を隠す 役割
早期抽象化は失敗リスクが高く、 Big Brain の罠となりやすい
プロトタイプ やデモを活用し、実際に動くものを早期に作る

テスト戦略

テスト はGrugにとって愛憎半ばする存在
テスト原理主義者（Test Shaman）は「まずテスト」と言うが、 理解できないドメインでは非現実的
プロトタイプ段階後にテストを書く のが現実的
単体テスト（Unit Test） は初期だけ、長期的には価値が薄れやすい
エンドツーエンドテスト は重要だが、壊れると原因不明で放置されがち
統合テスト（Integration Test） が最もバランス良い
モック（Mock）は極力使わず、必要最小限に留める
バグ発見時は 回帰テスト を最初に作成

Agileについて

Agile手法 自体は悪くないが、過信は禁物
Agile Shaman （アジャイル原理主義者）は失敗時に「やり方が悪い」と言いがち
プロトタイピング、適切なツール、良いメンバー選び が成功の鍵
万能な開発手法は存在しない
流行に流されず、 現場に合った方法 を選択

リファクタリングの注意点

リファクタリング は有用だが、規模が大きいほど失敗リスク増加
小さく分割して進める のが安全
抽象化のしすぎ は破綻の元
失敗例： J2EE や OSGi 導入で複雑性が逆に増大
エンドツーエンドテスト がリファクタ時の命綱

Chesterton's Fenceの教訓

古いコードや仕組みを 理由も分からず撤去しない
なぜ存在するのか理解してから変更 を検討
安易なリファクタや削除は危険

まとめ：Grug流開発の心得

複雑性を常に警戒し、シンプルを貫く
NOと言う勇気と、OKの使い分け
80/20ルールで現実的な成果を出す
テストはバランス重視、統合テストを主軸に
流行よりも現場に合うやり方を選ぶ柔軟性
古いものを壊す前に、理由を理解する慎重さ

Hackerたちの意見

自分が賢いと思うと、C++を使ってそれを誇りに思ったりするようなトラブルがいろいろ起こるよね。でも、自分の知恵が限られた資源だと思えば、それを大切に使うようになるし、ツールやプロセス、間違ったデザインに無駄遣いしなくなるんだ。

└

このエッセイのスタイルが一番魅力的な部分だね。

└

一番人気で実績のある言語を使うのは、めっちゃ恥ずかしいよね。たとえ全部Zigを使うって決めても、ZigやLua、Rustみたいなあまり人気のない言語での採用はかなり難しい。Zigで20年の経験がある開発者なんていないし。

└

C++から電話がかかってきて、いきなりのサッカーパンチに文句言ってたよ。

HTMXのクリエイターからのメッセージ。

└

でかいグルグ。

今まで見た中で、訪問者パターンについての議論が一番良かった。

└

その部分を探しに行ったら、「Bad」って書いてあった（笑）

└

普通のOOコードベースで働いてないから、ビジターパターンが何かも知らなかったんだ。でも、解釈器（とVM）を作るための素晴らしい本があって、「Crafting Interpreters」っていうんだ。その中にビジターパターンを使うセクションがあるよ。https://craftinginterpreters.com/representing-code.html#the-... 読んでて、なんでこんなに複雑にしなきゃいけないのか理解できなくて、結局タグ付きユニオンを使ったんだ。もしかしたら、俺はOOには向いてないのかも。でも、グルグの記事のポイントもそれだと思う。もっとシンプルな方法があるのに、なんで間接的で複雑なことを自分に課すんだろう？

ここにはたくさんの宝石があるけど、マイクロサービスについてのこのコメントが特に好きだな。「グルグは、なぜ大きな頭が一番難しい問題、システムを正しくファクタリングすること、そしてネットワークコールを導入することを選ぶのか不思議に思う」

└

ちっちゃい開発チーム（1〜2人）にこれを説明しようとしてるんだけど、彼らは「微サービス」に分けちゃうんだよね。たぶん5つぐらいのフォームがあるだけの簡単なウェブアプリを、データベースを共有して、API管理層を作って、バッチ処理用のキューを用意して「大きな」データ（メガバイト）を処理して、メール通知システムを作って、観測プラットフォーム（オーダーメイド！）を作って… それから… その簡単なウェブフォームをSPAアプリにしちゃうんだよね。「それが簡単だから」って。今は「アーキテクチャ」と「パターン」が無駄な開発者のための仕事プログラムだってことがわかったよ。これがなかったら、彼らは路上で「サンドイッチのためにJavaScriptを書くよ」って看板持ってるだろうね。

これが、ソフトウェアを作ることについての私のお気に入りのエッセイだと思う。スタイルが魅力的で（嫌いな人がいるのもわかるけど）、内容はいつも関連性がある。

カーソン教授、もしコメントを見ていたら、心から感謝の気持ちを伝えたいです。大学でHTMXを学んでいたとき、なぜそれを学ぶのか、教授がそんなに興奮していたのか理解できなかったけど、何年も経った今、やっとわかりました。HTMLがワイヤー越しにあるのはすべてです。私はスタッフRuby on Railsエンジニアとして、Hotwireでのあなたの仕事を見てきました。時々Hacker Newsに現れるのを見るのも、GitHubでHotwireの開発者たちと話しているのを見るのも本当にクールです。プログラミングコミュニティの光でいてくれてありがとう。あなたはとても尊敬され、感謝されています。

└

泣いてるのはお前だろ、俺は泣いてないよ。

└

HTMXってただのミームじゃなかった？ポーの法則のおかげで、これが本気かどうかわからないんだよね。

複雑さとティラノサウルスとの一対一の選択があったら、グルグはティラノサウルスを選ぶよ。少なくともグルグはティラノサウルスを見るから。このセリフは週に一度は考えてる。

悲しいけど真実だね。「はい」と覚えて、失敗したら他のグルグのせいにするのが理想のキャリアアドバイス。最初に企業の世界に入ったとき、これは本当じゃないと思ってた。技術チームのコミュニケーションが悪かっただけだって。でも、俺が間違ってた。グルグが正しい。

グルグユーザーはキーワードリサーチツールが欲しい。グルグユーザーはそれを含むプログラムを見つけた。グルグユーザーはメニューに混乱している。グルグユーザーはツールがキーワードリサーチだけをしてくれればいいのにと思っている。

有名な技術に関するエッセイにグルグスピークを適用して遊んでるんだ。https://docs.google.com/document/d/1emldq9MovfYshOSkM9rhRUcl... 元のやつには及ばないけど、知ってるよ！

ハクソク