- The Eternal Enemy: Complexity
- Saying No
- Saying ok
- Factoring Your Code
- Testing
- Agile
- Refactoring
- Chesterton's Fence
- Microservices
- Tools
- Type Systems
- Expression Complexity
- DRY
- Separation of Concerns (SoC)
- Closures
- Logging
- Concurrency
- Optimizing
- APIs
- Parsing
- The Visitor Pattern
- Front End Development
- Fads
- Fear Of Looking Dumb
- Impostor Syndrome
- Reads
- まとめ
モンタナ州立大学ソフトウェア工学教授であり、htmx の開発者である Carson Gross (カーソン・グロス)氏のエッセイ。
Grug とは、現代社会の複雑さを嫌い、シンプルで野生的な生活を好む架空の原始人としてミーム化したキャラクター。
高度で複雑な技術を使う Big Brain ではなく、原始的ながらもシンプルで堅実な方法を好む自身を Grug brain と揶揄して、その経験知を語っています。
わかりみが深いのですが、日本語話者には伝わりにくいので、意訳した要点としてまとめました。
The Eternal Enemy: Complexity
複雑であることは、とても、すごく、まったく悪いことである。
複雑さは、経験不足な開発者やプロジェクトマネージャーを通じて、彼らの善意によってでありながらも、コードベースに侵入してきてしまう悪霊である。 彼らは複雑さの悪霊を恐れず、時にはそれについて知らないことすらある。
複雑さは目に見えずに忍び込み、すべてを困難にしてしまう。
Saying No
複雑さと戦うための魔法の言葉は 「No」 である。
「No」。その機能は作らない。その抽象化は不要だ。
「ok」と言う方が昇進しやすい。しかしエンジニアとして「No」と言う勇気を持つべきだ。
Saying ok
時には仕事のために「ok」と言わなければならない。「ok その機能を作りましょう」。
その場合は80/20の法則を時間をかけて検討するべきだ。 つまり20%のコードで80%の価値を出す解決策だ。
その解決策は、マネージャーを大満足させないかもしれないし、少し醜いかもしれない。
だが動くし、生産性が高く、複雑さの負債をほとんど持ち込まない。
Factoring Your Code
コードベースを適切に分割することは非常に難しい。すなわちアプリケーションを早すぎる段階で分割してはならない。
プロジェクト初期は全てが抽象的で水のように流動的だ。 だから、ある時点でコードベースから適切な切り分けポイント(Cut points)が現れるのを待ち、徐々にリファクタリングするのだ。
賢いやつらは、プロジェクトの初期に多くの抽象化を考案してくることがある。 そんな時には、明日の朝までに動かせるデモを依頼するなどしてみよう。 実際に動くものを作らせて、そのコードを見たり話し合ったりすることで、現実の理解を促進さるのが肝要だ。
デモをプロトタイプと呼べば、マネージャーは満足するかもしれない。
Testing
「コードを書く前にテストを書け」と主張する過激なテスト信者(テストシャーマン)には懐疑的だ。 ドメインを理解していない段階でテストを書くのは無理だろう。
テストシャーマンは単体テストの重要性について説くが、経験上、理想的なテストは単体テストでもE2Eテストでもなく、その中間のテストだ。
それぞれのテストが無価値とは言わないが、カットポイントが出現しシステムが安定するにつれて、Integration Test が理想的になってくる。 テストの価値が長期間にわたって保たれ、デバッグも簡単であり、もっともバランスが良い(モックは極力使用しないのが望ましい)。
Agile
アジャイル自体は悪くないが、アジャイルシャーマンがプロセスを過剰に崇拝することは危険である。
アジャイルシャーマンは、アジャイルプロジェクトが失敗する度「アジャイルを正しくやらなかった」と言うのだ。
Refactoring
リファクタリングは、プロジェクトの後半でコードベースが固まり始めた時の良い活動だ。
しかし結局は、良いことよりも悪い結果をもたらす場面を度々目にした。 この原因は正確にはわからないが、リファクタリングが大きくなるほど失敗する可能性が高いことは言える。
リファクタリングを比較的小規模に保ち、過度な抽象化を導入しないように注意する必要がある。
Chesterton's Fence
どんなに醜いように見えても、むやみにコードを切り裂き始めてはいけない。
システムを改善するなと言っているわけではない。 特に大規模なシステムの場合は、まずシステムを理解するために時間をかけた方が良い。
Microservices
複雑さを劇的に増やす。これには大いに疑問がある。
Tools
デバッガやIDEの補完機能など、脳を助ける重要な道具であり、深く学ぶべきだ。
Type Systems
型システムには価値がある。 IDEでドットをタイプすると、ポップアップでメソッドがリストされるからだ。
それ以外の利点には大きな価値を感じない。
Expression Complexity
かつてはコード行数を可能な限り短くすることを好んでいたが、それは誤りだった。
デバッグしやすいことが第一だ。
DRY
Don't Repeat Self は強力な格言だが、物事にはバランスが必要だ。
経験を積むにつれ、繰り返しコードを気にしなくなった。繰り返しコードが十分に単純で明白である限り十分だ。
コールバック/クロージャに引数を渡すより、複雑すぎる精巧なオブジェクトモデルを使うより、単純なソリューションの方が優れていることが多いのだ。
Separation of Concerns (SoC)
関心の分離(Separation of concerns)よりも、振る舞いの局所性(Locality of Behavior)を支持する。
関連するロジックは近くに置き、コードを見ただけで何が起きているかわかる方が安心できる。
Closures
クロージャは少量なら効果的だが、過剰な使用は逆効果だ。
Logging
ログの重要性は軽視されがちだ。 これは本番システムでバグと戦うときの要であり、授業でこのことについてもっと教えるべきだ。
Concurrency
同時並行性は恐怖だ。可能な限りステートレスなシンプルな並列処理を選ぼう。
Optimizing
最適化をはじめる前に、特定のパフォーマンスの問題を示す具体的な実際のパフォーマンス プロファイルを用意すること。
APIs
残念ながら、多くの API は非常に悪い。 APIの使用という観点ではなく、APIの実装やドメインという観点で作成されたり、抽象的すぎるのが大抵である。
シンプルなAPIでシンプルなケースを設計し、複雑なケースは異なるAPIで提供するのが良い。
Parsing
パーサージェネレータツールのようなものは使わずに、再帰降下法パーサーを書いた方が良い。
The Visitor Pattern
ビジターパターンは良くない。以上。
Front End Development
フロントエンド開発者は非常に複雑なことをすぐにやってしまい、たくさんのコードと複雑性を簡単に導入してしまう。
Fads
開発、特にフロントエンド開発には多くの流行があることに注意しなければならない。
リサイクルされた悪いアイデアに時間を無駄に費やしたり、無計画にコードベースに組み込むべきではない。
Fear Of Looking Dumb
多くの開発者は「バカに見られる恐怖(FOLD）」を抱えている。
上級者が「これは複雑すぎて理解できない」と公言するのは最高だ。
Impostor Syndrome
しばしば自分が何をしているのか全く理解していないと感じる。 今でもミスを恐れ、皆のコードを壊して他のグルグを失望させるのではないかと不安だ。
このように感じるのはプログラミングの本質であり、皆がインポスター症候群なのであれば、誰もインポスター症候群ではないということだ。
Reads
以下を読もう。
まとめ
あなたは言うはずだ。複雑さは、とても、すごく、まったく悪いことであると。
