インターネット上では、好みに関する議論は避けられないことが多いです。
好みは非常に個人的なものですが、選択が自分だけでなく、チームメンバー、会社の利益、またはユーザーの体験に影響を与える場合は、より多くの考慮が必要です。
どんな選択であれ、ある原則に従うべきです。人によってその原則は異なりますが、私にとってそれは「Worse is Better」です。
Worse is Better：シンプルさの勝利
Worse is Betterは、リチャード・P・ガブリエルによって提唱された哲学です。それは、システムの設計はシンプルであるべきだということを表しています。他の側面の設計がシステムを複雑にする場合、それらを犠牲にすることを考慮すべきです。
彼はLisp/Lisp Machineと同時期のC/Unixを比較しており、以下に示します：
シンプル
- Lispは、設計は特にインターフェースがシンプルでなければならないと考えています。シンプルなインターフェースに複雑な実装が必要な場合でも受け入れます。
- Unixは、設計はシンプルでなければならないと考えています。実装のシンプルさはインターフェースのシンプルさよりも重要です。
正確
- Lispは、設計はすべての面で正確でなければならず、どんな誤りも許されません。
- Unixは、設計はすべての面で正確であるべきですが、シンプルさのためにいくつかの誤りを許容します。
一貫性
- Lispは、設計はすべての面で一貫していなければならないと考えています。
- Unixは、設計が過度に一貫していないことを求めています。時にはシンプルさのために一貫性を犠牲にすることがありますが、それはあまり一般的でない状況を処理する部分を放棄する方が良く、実装の複雑さや不一致を導入するよりも望ましいです。
完全性
- Lispは、設計は重要なケースをできる限りカバーし、すべての合理的に予想されるケースをカバーする必要があると考えています。
- Unixは、設計は重要なケースをできる限りカバーすべきですが、シンプルさのために完全性を犠牲にすることができます。
つまり、シンプルさのために他の側面を適切に犠牲にすることが、Worse is Betterの核心概念です。
これらの比較を見て、多くの人はLispの設計がより優れていると感じるでしょうが、結果としてUnixの方が成功しました。何が起こったのかを振り返ってみましょう：
- UnixとCはシンプルであるため、より安価なハードウェアで実行でき、そのためLispが到達できなかった領域に拡大することができました。
- UnixとCの不完全さにより、複雑なモノリシックシステムを一度に構築することができなかったため、大規模なプロジェクトは再利用可能なモジュールに分解する必要がありました。その結果、ソフトウェア工学の概念が誕生し、プログラムの改良速度が速まりました。
このようにして、「劣った」UnixとCが勝利を収めたのです。
Vue vs React：トレードオフと選択
半年前、顧客のエンジニアと話していたとき、彼はなぜReactではなくVueを使うのかと尋ねました。私は、Vueを使うことで精神的な負担が少なく、例えばHTMLファイルに直接Vueを導入し、Vueをより優れたjQueryとして使うことができるからだと答えました。
そのため、Vueを使用することで、Nuxt.jsを使ってモダンなWebプロジェクトを立ち上げることも、Vanilla Javascriptを書き、それをVueで開発体験を向上させることもできます。
この柔軟性は、私にとって非常に魅力的です。なぜなら、多くの場合、完全なWebアプリは必要なく、その依存関係を維持する必要もなく、その複雑さを扱う必要もないからです。
Golang：シンプルさと効率のバランス
バージョン1.2以前、Goは非常に退屈な言語でした（現在も退屈な言語です）。
例えば、リストに特定の要素が含まれているかどうかを確認する場合、他の言語では if item in list と書けますが、Goでは長い間、完全なループを書く必要がありました。
for _, v := range list {
if v == item {
return true
}
}
Goのエラーハンドリングも明らかにCからの影響を受けています。
しかし、退屈さもGoの利点の一つです。例えば、チームメンバー間でコードスタイルの統一がしやすく、可読性や保守性が向上します（リストに要素が含まれているかの確認は良い例ではないので、slices.Containsがあります）。
Goはシンプルさと機能の間で非常に良いバランスを見つけています。それは最も柔軟でエレガントな言語ではないかもしれませんが、その理念は効率的で信頼性の高いシステムを構築する際に非常に優れています。
Markdown：シンプルさと機能のトレードオフ
Markdownはその誕生以来、常に議論の的となっています。
一部の意見は、Markdownはマークアップ言語としてあまりにもシンプルであり、複雑な要求を満たすことができないとしています。また、標準がないため、異なる実装間で差異が生じることも問題視されています。全体として、ReStructuredTextやAsciidocの方が優れているとされています。
また別の意見では、Markdownは制限が多すぎて、より完全なHTMLのWYSIWYGエディタには及ばないとされています。
しかし、Markdownはちょうど良い位置にあるため、その普及度はシンプルさと機能性のバランスが良いことを証明しています。
Markdownの機能が限られているため、最も学びやすいマークアップ言語であり、「技術オタク」以外の人々が直感的に使うことができます。最も基本的な文法で90%の要求を満たすことができるため、実質的にWYSIWYGエディタ以外の「デファクトスタンダード」となり、ReStructuredTextやAsciidocが成し遂げられなかったことを達成しています。
もちろん、Markdownは正確なレイアウト制御や複雑な表やグラフが必要な文書には向きません。そうした場合、WYSIWYGエディタの方が良い選択です。しかし、大多数の執筆ニーズにおいて、Markdownは非常に良いバランスを提供します。
生物の進化：シンプルさがもたらす可能性
技術産業の外でも、生物の進化はWorse is Betterの絶好の実例です。
シンプルから複雑へ
生命は単純な単細胞生物から始まりました。これらの「粗末な」生命形態は完璧ではありませんが、生き残り繁殖することができ、複雑な生命形態の基盤を築きました。
したがって、ソフトウェア開発では、シンプルだが使用可能なバージョンから始め、それを段階的に改善していくことがよくあります。
高適応の高リスク
生物群集において、遺伝子の多様性
は一見平凡に見えますが、実際には将来の進化に向けたスペースを提供しています。それに対して、環境に高度に適応し、特異性が強い生物、例えば大型捕食動物は、環境変化の際に絶滅しやすいです。
システム設計においても、過度の設計や適応は逆に適応性を低下させる可能性があります。例えば、システムの実装がAmazon Web Servicesにロックインされている場合、AWSに問題が発生した際にはシステムが機能しなくなります。
製品の決定も同様です。大規模なプラットフォームに依存すること、例えばWeChatエコシステムに依存することで、プラットフォームの利点を利用して急速な成長を遂げることができますが、WeChatエコシステム内の予測不可能なリスクに直面する可能性もあり、それによってすべてを失うことになるかもしれません。
欠陥の中の利点
興味深いことに、一見欠陥に見える遺伝子が、特定の環境では利点になることがあります。例えば、鎌状赤血球貧血の遺伝子は、貧血の原因となりますが、マラリアに対する耐性が強いです。
いくつかの選択と決定は不完全かもしれませんが、特定のシーンでは予想外の利点を発揮することがあります。例えば：
- Instagramは初期にはユーザーが正方形の写真しかアップロードできませんでした。この制限は当初は欠点とされましたが、この「欠陥」は逆にInstagramの象徴的な特徴となり、ユーザーがより構図に注力し、独自のビジュアルスタイルを生み出すきっかけとなりました。
- 初期のTwitterではツイートは140文字以内に制限されていました。この制限は最初は欠点と考えられましたが、この「欠陥」はユーザーにより簡潔で創造的な表現を促し、情報の伝播をより速くしました。この特徴は後にTwitterの象徴的な特徴となり、独自のソーシャルメディア文化を形成しました。
したがって、不完全だからといって失敗を意味するわけではありません。むしろ、それは適応性と長期的な生存に対してより多くの可能性を提供するかもしれません。技術の選択と製品設計において、シンプルだが柔軟なソリューションは、完璧だが硬直したソリューションよりも生命力があります。
最高のデザインは、ユーザーが感じないデザインであり、最も実用的なツールは、しばしば目立たないツールです。「大方無隅、大器免成、大音希声、大象無形」とはまさにこのことです。
先日、私のプロダクトマネージャーが、「あなたは以前、設計をする際にはできるだけ包括的で完全に考慮するようにと言っていましたが、なぜまた設計は十分にシンプルでなければならないと強調するのですか？」と尋ねました。
ああ、確かに私は異なる時期にこの二つの言葉を言っていて、それらの矛盾にすぐに気づかなかったのです。
数年前、私はあるプランの完全性を強調していましたが、それは以前、大企業で（特にWeChatやAppleからの影響を受けて）ささやかなことをしていましたが、利用できるリソースは非常に多く、包括的で完全なプランを作成することがコストを心配する必要がなかったためです。上層部の戦略も非常に安定しており、最初から埋没コストを支払う準備ができていました。
その時の私の設計は、「大規模で複雑なシステムシナリオ」—巨大でありながら包括的な機能が必要なもの、または「ダイヤモンドのような宝石のシナリオ」—精緻で優雅に、できるだけ完璧を目指すもののいずれかに属していました。
しかし、小さな会社ではリソースが限られており、変化に直面すると、より多くのトレードオフと放棄が必要です。この時、Worse is Betterの設計哲学がより良い座右の銘になります： シンプルだが使えるものを作り、徐々に改善する。
そのため、私のキャリアの中で、完璧を追求することから、「十分に良い」ことの価値を認識する変化を経験しました。それは妥協やトレードオフについてではなく、適切なタイミングで適切なことを行い、正しい結果を積み重ね続け、余裕を持ち続けることです。