- 技術的センスは技術的な実力とは別の概念であり、優れた能力があってもセンスが悪いことはあり、能力が不足していてもセンスが良いことはある
- ソフトウェアエンジニアのセンスとは、プロジェクトに合ったエンジニアリング上の価値を選ぶ能力を意味する
- どんなコードが見た目に良い／悪いか、どんな設計判断に満足を感じるか、どんな問題に執着するかといった感覚に現れ、それはそのまま自分が重視するエンジニアリング上の価値の集合を反映している
- ソフトウェアエンジニアリングにおけるあらゆる判断はトレードオフの連続であり、未熟なエンジニアは特定のアプローチを絶対的な真理だと考えがちだが、成熟したエンジニアは文脈に応じて柔軟に価値を調整する
- 良いセンスとは、特定のプロジェクトに合った価値の優先順位を選べる能力であり、悪いセンスは「best practice」のような絶対的基準に執着する硬直性として表れる
- センスは多様なプロジェクト経験と開かれた思考を通じて培われ、最終的にはプロジェクトの成功可否を通じて良いセンスの有無が明らかになる
技術的センスと実力の違い
- 技術的センスは優れた実力と必ずしも一致しない
- 誰でも料理の腕前とは別に良い料理と悪い料理を見分けられるように、ソフトウェアでも能力より先にセンスが形作られる
- どんなコードが「良さそうに見える」か、あるいは「いまひとつに見える」かによって、エンジニアのセンスが表れる
- どの設計判断に満足を覚え、どの問題により気を配るかは、センスの一部として機能する
- 技術的能力は反復と学習によって伸ばせるが、センスはそれよりも曖昧で直感的な形で発達する
-
エンジニアリングセンスの指標
- 「このコードは見た目が良い／悪い」と感じること
- 一部の設計判断に対する強い満足感、または無関心さ
- 退勤後も気になり続けるソフトウェアの問題と、そうではない問題
- センスとは、現在のプロジェクトに合ったエンジニアリング上の価値を採用する能力だと考えられる
実力とセンスの区別
- 「良く見えるコード」が実際により良いコードでなければならないのか、という疑問がある
- 例:
map/filter を好む人はコードの可読性や純粋関数を重視する一方、for ループを重視する人は性能や単純な拡張性を重視するかもしれない
- これは正しいか間違っているかの問題ではなく、重視する価値の違いである
- 言語やコンテキストによってそれぞれに長所と短所があるため、どの選択が必ずしも優れているとは限らない
- 各エンジニアが重要だと考える価値は異なり、それに応じて好みも変わる
エンジニアリングセンスとは何か
- ソフトウェアエンジニアリングにおけるほぼすべての判断は、**相反する価値のあいだのバランス（トレードオフ）**である
- 未熟なエンジニアは自分のセンスに過度に固執する
- 成熟したエンジニアは多様な観点から利点を見極め、現在の状況に合った選択を重視する
- 重要なのは X（技術）と Y（技術）のどちらが優れているかではなく、現在のプロジェクトでは X の利点が Y より必要かどうかを判断することである
-
エンジニアリング上の価値の例
- Resiliency: 障害やネットワーク問題があってもシステムがうまく動作するか
- Speed: 理論限界に近い性能を出せるか、不要な処理が多くないか
- Readability: 新しいエンジニアが素早く理解して適応できるか、関数が短く明確か
- Correctness: 不正な状態がモデル化されていないか、テスト・型・assert などが十分か、さらには形式検証まで適用されているか
- Flexibility: システム拡張が容易か、変更を簡単に適用できるか
- Portability: 特定環境に依存していないか、デプロイ環境の変更が容易か
- Scalability: トラフィックが10倍、100倍に増えたときにシステム拡張や自動スケーリングが可能か、ボトルネックはどこにあるか
- Development speed: システム拡張がどれだけ速いか、大多数のエンジニアが作業可能か
- このほかにも elegance、modern-ness、オープンソース活用、保守コストなど多様な価値がある
- すべてのエンジニアが各価値に同じレベルの関心を持つわけではない
- 自分がどの価値を最も高く評価するかによって、使う言語、フレームワーク、設計パターンなどが変わる
悪いセンスの特徴
- 悪いセンスは、自分が好む価値が現在のプロジェクトに適していないときに生じる
- 特定の技術や方法論の利点を、自分のプロジェクトに一貫して押し通してしまう柔軟性の欠如が問題である
- いつも「best practice」だけを掲げる主張には、状況に応じた判断の欠如がある
- 柔軟性のないエンジニアは、ある特定のプロジェクトではうまく合うことがあっても、環境や業務が変わると深刻な問題を引き起こす可能性がある
良いセンスの特性
- 良いセンスとは、問題状況に応じて適切なエンジニアリング上の価値をうまく選ぶ能力である
- 単なる技術力とは異なり、複雑な実際のプロジェクト文脈でのみ検証可能である
- 自分が賛同した設計判断が採用されたプロジェクトがうまく進めば、自分のセンスの適合性を測ることができる
- 多様なプロジェクト経験、そしてある時点で新しい価値に対して開かれた姿勢を持つことが重要な学習要素となる
- 柔軟性を保ち、特定の技術や方法に対する固定観念を避けることが、良いセンスの形成に役立つ
結び
- 良いセンスは実力と同じくらい重要であり、成長の過程で多様性と柔軟性、そして自己省察を通じて伸ばすことができる
- 中には、経験以上に優れたセンスを示す人もいる（プログラミングや他分野のギフテッドなど）
追加の議論
- Hacker News のコメントでは、「センス」というものの存在自体に懐疑的な意見もあった
- 一部には、すべての問題にただ一つの正しい解法があると主張する人もいたが、著者は現実には複数の解法があり得るのであり、最終的には個人の価値観と文脈が選択を左右すると反論している
- 別の意見として、顧客やビジネスの文脈もセンスの一部だという指摘があった
7件のコメント
単に悪いセンスだと片づけるには、チームやプロジェクトにとって害になりうる悪い傾向のようですね。
Hacker News のコメント
未熟なエンジニアは自分の好みにこだわりすぎる傾向があると感じるし、そうした未熟さは経験豊富なエンジニアにもあり得る。以前、友人たちのコンピュータ課題のコードを手伝っていたとき、自分が嫌いだという理由だけでコードを全部書き直したくなる衝動を覚えた。でも結局そうすると時間がかかりすぎるし、友人たちが成果物を理解できなくなると気づいた。だから友人たちのアプローチに少し修正を加える形で手伝ったところ、彼らの満足度はむしろ高かった。こうした経験のおかげでさまざまな視点を知ることができ、自分のコードもより良くなった。むしろ友人たちに感謝すべきだと思った。今でも先入観を捨てるのは難しいが、できる限り相手の観点を真剣に理解しようと努め、ときにはそのやり方のほうが優れていると認めようとしている。原則というものは実際かなり主観的なので、常に原則だけに頼るのは、状況を真剣に考えずに済ませる怠惰なアプローチだと言える
ジュニアエンジニアが非効率に何かをしていたとしても、私は決して「それは最適化が足りないやり方だ」とは言わない。代わりに、なぜそうしたのかを必ず尋ねる。会話が終わるたびに、私たちのどちらかは何かを学んでいる。私が新しいやり方や彼らの理由を知ることもあれば、彼らが長期的にはその方法が通用しない理由を学ぶこともある。どちらにせよ、そうした会話が対立的に終わることは決してない
「良い趣味」は、優れた API や良いコードに触れることで身につくと思う。良いコードは見ればすぐに分かるし、時間が経てば自分でもそう書けるようになるべきだ。ただ、この分野に入りたての頃は良いコーディングの趣味を持つのが難しいし、経験があるからといって必ずしも趣味が育つわけでもない。だから、常に良い趣味を探し、認識し、真似しようとする努力が必要だ
先入観、偏見、硬直した思考様式から抜け出すための解決策は、教育と、それぞれの人が持つ観点の外側にある多様な経験を積むことだ。他人の視点から世界を理解しようと積極的に努力してこそ、人としても職業人としても成長でき、視野を広げられる。私のようにさまざまな分野に関心を持つエンジニアは、別の解決策や視点があると知るだけでも問題解決の仕方が変わり、最初の本能的なアプローチより良い解法を見つけられる
だからこそ、いろいろなプログラミング言語を試してみるのが良い。これまでの自分の視点に絶えず挑戦してくる新しい言語に触れるたびに、「なるほど」と気づく瞬間が何度も訪れる。最初はぎこちなかったり間違っているように見えたりしても、その理由ややり方を完全に理解するまでは、そういうものだと受け入れる過程が必要だ
素晴らしい意見だ。こういう考え方こそ、私が自分で採用する人や、一緒に働くチームメンバーに対して取る姿勢そのものだ。目標や結果が達成されるなら、私のやり方や細部まで必ず一致している必要はない。やり方は一つではないと認めている
ファッションにおける「良い趣味」とは、服一着一着そのものよりも、それぞれ単体では本質的にさほど意味がなさそうな服を組み合わせて、力強く調和の取れた印象を作り出すことだと思う。この記事もそういう方向に進んでくれると期待していた。ソフトウェアエンジニアが趣味で決めるものが、単なる技術的トレードオフではなく、本当に趣味の領域なのかをもっと掘り下げてほしい。ちなみに、この記事自体が趣味の悪い例のようにも感じられる。内容面では各パートは無難によく書けているが、全体として一つの「ルック」を作れておらず、文章が散漫に感じられる。著者への中傷ではなく、テーマが素晴らしいと思うからこそ、もっと改善してほしいという意見だ
服一着がそれ自体で意味を持たないという意見には同意しない。衣服は組み合わせられる前から、文化的・歴史的・象徴的な意味を持っている。ファッションは単なる組み合わせ以上のものだ。また、ファッションにも生産、着用、コーディネートなどさまざまなトレードオフがある
君が知りたがっている「私たちは美しさや優雅さをどう認識するのか」という問いは、古代から哲学者たちのテーマであり、単一の記事で結論づけるにはあまりに大きすぎる。建築分野の Christopher Alexander はこれを深く探究しており、彼の思想はソフトウェアアーキテクチャにも大きな影響を与えている。Alexander は客観的な美が存在すると主張した。彼の OOPSLA 基調講演 や Roy Fielding の 博士論文 は参考になる。この文章で言及されている「価値」は、Fielding の論文では「アーキテクチャ特性」としてより体系的に整理されている
面白いことに、私はこの記事を、主題を深く体系的に扱った、なかなか見つからない希少な名文だと思う
エンジニアにとって、どのような結合で本当の意味で「趣味」が問われるのか、そして単なる技術的トレードオフと区別される「趣味の領域」とは何なのかを知りたい。私には、多くの決定が「技術的トレードオフではあるが、絶対的に証明できないか、差がごく小さくて実質どうでもいいもの」として片づけられているように見える。つまり、厳密に論じにくいなら、単に趣味として扱うということだ
たいていの開発者は、一般にファッションの趣味に乏しく、そのため良い趣味そのものをあまりよく理解していない。そしてテックの世界の大半のものは、非テックの人から見ればまったく格好よくもクールでもない。プログラミング言語は格好よくない。開発の世界では出発点ですら「格好よくない」で、そこからさらに下に向かう構造になっている。たとえば Rust や C++ などは「格好よくない」カテゴリで、見慣れない関数型言語や Bash、Linux などは「本当に格好悪い」カテゴリに入る
良い趣味とは、誰にでも簡単に書けそうに見える、強く単純なコードを書くことだ
別の例を共有したい。72年式 Dodge Challenger を分解して組み立て直していると、この車がいかに単純で直接的で安価でありながら驚くほどよく作られているかにいつも感心する。たとえば計器盤の電源は、自動車全体の電圧（10〜18V）とは別に 5 ボルトが必要だが、5 ボルトを超えると回路を切り、それ未満だと閉じる一種のブザー（電磁石を利用）があり、高速に on/off することで平均的に 5 ボルトを作っている。多くの人はこれを電子式電圧レギュレータに交換するが、そうすると計器盤が動かなくなる。実際には計器盤が機械式なので、5 ボルトの微細なノイズがないと針が頻繁に止まってしまい、むしろこの「粗い」5 ボルトが停止を防いでいる。電子式に置き換えると、その「ノイズ」をわざわざ加えなければならない。こうした簡単な機械式装置が、効果と単純さの両面でどれほど優れているかに感嘆する
こうした単純なコードの本当の価値は、コード保守や作業者の時間を節約してくれるにもかかわらず、たいてい正当に評価されない。KISS（Keep It Simple, Stupid）の原則を実践したコードが、かえって価値が見えないとして軽んじられることすら多い。だから実際には不要な複雑さを管理することだけをしているチームや組織が存在する
ときにはエンジニアが並外れたことをできるのは望ましいが、本当に重要なのは、最初は難しそうに見えても、最終的には平凡で単純な解決策をしばしば見つけ出すエンジニアだ
バレエを見ると「本当に簡単そうだ！」という言葉ばかり聞こえるが、実際には彼らは何万回も練習して、本当に簡単にやってのけているのだ
複雑なものを本当に単純に要約できる人を、私はいつも最も尊敬する。K&R C の例のように明快で、ただしコメントはもう少し丁寧に残してほしい
「一目でコードを理解でき、新しいエンジニアのオンボーディングが容易か」という問いは、思ったほど簡単ではない。新しいエンジニアというのが、経験 0 年の人なのか、10 年なのか、30 年なのかが不明確だからだ。「可読性」もまた、誰かにとっては明確な概念だが、実際には 0 から無限大までの幅広いスペクトラムがある。Maxwell の方程式は、ある人には非常に明快だが、別の人にはまったく不透明だ。だから「コードは読みやすくあるべきだ」という言葉が、いったい誰を対象としているのか、いつも疑問に思う
読みやすいコードとは、読者に配慮して認知的負荷を最小限に抑えたコードを意味する。これはレイヤードアブストラクションやデザインパターンの目標でもある。もちろん、対象読者の専門性やコードベースへの慣れによって変わるので主観的ではある。しかし主観的だからという理由で可読性そのものを否定するのは行き過ぎだ。Joyce の『ユリシーズ』と Seuss の『The Cat in the Hat』が、どちらも同じように読みやすいとは言えないだろう
「可読性は概念ではない」という主張には同意しない。読めないコードは、作者本人（あるいは AI）であっても、もちろん他の誰にとっても読めない。作者だけが読めるコードも、やはり読みやすいコードではない
Maxwell の方程式は当時は本当に難しかったが、今私たちが知っている形は Heaviside らがさらに整えて、可読性を高めた結果だ
コードの一部における「ローカルな可読性」は、あまり意味がないと思う。コードベース全体にわたってパターンが一貫して適用されていれば、そのパターンが多少複雑でも、全体としては十分に読みやすいコードになり得る。一時的な複雑さは、コード全体の品質に影響しないなら問題ない
可読性はたいてい「偶発的複雑性（accidental complexity）」を減らすことを目的としている。映画の脚本のような数式でも、複雑なアルゴリズムでも、記法が悪ければ理解そのものが難しくなる。結局のところ、「コードは誰にとって読みやすくあるべきか」という問いに対しては、その分野をよく知っているエンジニアが、問題には詳しいがコード自体は見たことがない状況でも読めるべきだ、ということになる。これは論文に似ていて、その研究者コミュニティにとって読みやすいべきだと思う。No Silver Bullet の要約
「趣味の悪いエンジニアは壊れたコンパスのように、結局は間違った方向を示す」という比喩が本質をよく表していると思う。こういう「予測可能な壊れ方をした」人は面接で見抜ける。むしろもっと危険なのは「部分的に壊れたコンパス」だ。見た目には少し回っているようで、実は常にきっちり 127 度ずれている、そんなタイプだ
こういう文章は、しばしば二つの問題を混同している。第一に、趣味や原則とは無関係に、客観的に悪い判断（例: リストでの O(n) 検索 vs ディクショナリでの O(1) 検索）は存在する。技術的に明確な優劣があるものはある。第二に、それ以外はすべてトレードオフだ。map-reduce を使うか通常のループを使うか、性能条件、可読性、互換性などを見ればよい。複数の選択肢のうち、理由さえあれば、自分の考えと違っていても構わない。問題なのは、答えが間違っているか、あるいはトレードオフ自体を考慮していないことだ。その場合は保守の領域であり、性能や頻度などの状況によっては、あえて手を入れないこともある。その判断についての「理由（why）」さえ明確なら、私は認める。これを本当に「趣味」と呼べるのかは、よく分からない
この記事の問題は、「人によって重視する価値が違う」という点をあまりにも文脈なしに扱っていることだ。実際には、エンジニアであれば、おおよそどの価値がその問題にとって最も重要か（= hard constraint）を感じ取れるべきだ。この hard constraint を除いた残りの自由度を「趣味」と見るのが適切だろう。アーティストで言えば、指定された素材や規格以外に、自分独自の追加制約や自由が残されている部分にあたる。ソフトウェアエンジニアにおける良い趣味は、「美学的にはミニマルで、自己抑制は最大限」という方向を目指すことに近い。私が考える本当に「趣味が悪い」ケースは、何の理由もなく原則を破っている場合だ。つまり、単純さを「慣れ」と取り違えていることが多かった
文中の「価値」という項目は、Roy Fielding の 博士論文 にあるソフトウェアアーキテクチャの特性とつながっている。Fielding の論文は REST で主に有名だが、実際にはもっと広く堅牢なソフトウェアアーキテクチャ論でもある。複数の「アーキテクチャ特性（拡張性、可読性、保守性など）」の文脈で考えられるようにしてくれるし、私は個人的に、こうした特性に加えて「アーキテクチャ制約」を理解することがどれほど重要かを強調したい
きちんとしたエンジニアリング（Principled engineering）は当然であるべきだ。その上に、趣味が良い場合も悪い場合もあり得る。しかし逆は成り立たない。エンジニアリング自体が悪ければ、趣味は意味を持たない。悪い趣味はエンジニアリングの効率を損なうことはあっても、エンジニアリングそのものを不可能にはしない。エンジニアリングは基本的に趣味を支える役割を持つ。たとえば、完璧にエンジニアリングされたものであっても、不要で望まれていないなら意味がない
悪い趣味は結局、私たちが避けたい不確実な状況（X）へと導く。私に言わせれば、良い趣味とは結局のところ、これからやって来る未来の不確実性に備えて、コードベースに堅牢な基盤と安全装置を用意しておくことだ。そうしてこそ危険に陥らずに済む
本当に良い
原文も良いですが、コメントの内容も本当に良いですね。
「趣味」といえば、トーバルズのTED動画を思い出しますね:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
14:20から、linked listのentry削除コードの実装方法に見る良いセンス
Hacker News の意見で言及されていた「客観的に悪い判断（例: リストでの O(n) 検索 vs 辞書による O(1) 検索）」でさえ、文脈によっては異なる判断をすべきことがあります。
検索を一度しか行わないのであれば、リストで O(n) 検索をするよりも、ハッシュテーブルを作るコストのほうが大きい可能性があるからです。
いいコメントですね。