デキるプログラマーが絶対にやらないこと判明！一流エンジニアの共通点とは？
引用元：https://news.ycombinator.com/item?id=43629307
ビジネスで一番大事なのは、多分、当てずっぽうでやらないことだよね。半導体製造で問題解決能力をめっちゃ鍛えたんだ。ここでは、悪い仮定を置くとコストがマジでヤバいことになるから。原因を100%特定できないと、すぐ全てがダメになる。もし原因が特定できないなら、解決しなきゃいけない問題が2つになっちゃうんだ。
原因分析を邪魔するような不透明さがあると思ったら、すぐに全部捨てちゃう。だから、標準じゃない技術スタックは極力使わないようにしてる。サードパーティのGitHubリポジトリに深入りするのはマジ勘弁。プロジェクトのスタイルとかモチベーションとか規模感が違いすぎて、マジでサイケデリックな体験になるからね。
常にめっちゃ正確であることが、評判を築く一番の近道かも。担当する問題の価値が高ければ高いほど、その効果は指数関数的に上がっていくよ。
フレームワークとかライブラリを使わないで、ほとんどのものを自分で作ると、いつもめっちゃ反発されるんだよね。
でも、ほとんどのフレームワークとかライブラリって、監査に耐えられるほど堅牢じゃないし、エンタープライズレベルの互換性も保証されてないし、想定外のパフォーマンス問題が起きないとも限らないし。
たまに、SQLiteみたいなサードパーティのライブラリは使うけど。「依存しないよりも依存した方が complications が少ない」ってレベルに達するフレームワークとかライブラリってマジで少ないんだよね。
それ賢いね。
もし、キミがそういうレベルの堅牢さがマジで必要な会社で働いてるなら、ね。でも、ほとんどの会社はそうじゃないし、そういう会社で働いてる人の多くは「もっとマシな」「もっと重要な」会社で働きたいと思ってるから、必要でもないのに必要だってフリをするんだよね。
キミみたいな人が、最先端企業のミッションクリティカルなチームにいたらマジで神。プロジェクトとか会社の成功に大きく貢献するだろうね。でも、誰も知らない会社のCRUDアプリのために独自のORMを作ろうとするヤツは、みんなの時間を無駄にしてるだけ。
＞「誰も知らない会社のCRUDアプリのために独自のORMを作ろうとするヤツは、みんなの時間を無駄にしてるだけ」”
昔、オフザシェルフのORMが採用されたプロジェクトに参加したんだけど、開発が進むにつれて、深刻な設計上の欠陥が明らかになったんだよね。API互換性を保った独自のORMを作ろうとした人がいたから（別に喜んでやってたわけじゃないと思うけど）、プロジェクトは救われた。
昔の話だけどね。今のORMライブラリはもっとマシになってると思う。でも、SQLiteレベルのライブラリであることを確認してから使うっていうアドバイスは、シンプルなCRUD ORMにも当てはまると思うよ。特にね。
キミの例みたいに、ORMの特定のエッジケースに遭遇して、それが完全に合理的だと思えるケースもあるけど、実際には「ライブラリを使えば数週間か数日で実装できるものを、何か月もかけて構築する言い訳」として使われるケースが95件くらいあるんだよね。しかも、そういうエッジケースに遭遇すると、「ORMを捨てる」んじゃなくて「そのクラスのクエリにはORMを使わない」ってことになる。
昔.NETを使ってた頃のEntity Frameworkで気に入ってたのは、ORMの機能を簡単に抜け出せること。EF固有の関数の中からでも抜け出せるし、少しずつ設定が違うインスタンスを複数持つこともできたんだ（やったことはないけど）。
俺が一番使ってる製品の最初の設計者はEntityFrameworkを選んだんだ。SQL文を見るまで1年半くらい使ってたんだけど、ひどいUNIONの塊だった。簡単なはずのことが10倍も複雑になってた。
Dapperと手書きSQL、シンプルなマイグレーションバージョン管理システム、検証付きのデータベースシードに徐々に置き換えていったんだ。それが終わったら、標準的なSSDで起動時間が10秒以上、CFastで約30秒短縮された。データベース接続をSQLite標準ライブラリに置き換えるだけでも2秒短縮できた。
EntityFrameworkは便利かもしれないけど、ソフトウェアの起動時間が重要な場合はパフォーマンスが不足してる。
Entity Frameworkは他のORMとは別格で、例外はほんのわずかだね。RailsのActiveRecordすらおもちゃみたい。EFは登場時から今ある多くの成熟したORMよりずっと先を行ってたと思うし、95%って数字も納得。でも、EFとかごく一部の成熟したORM以外だと、95%は50%くらいに見えるかも。新しいORMはCRUD以外ほぼ役に立たないし、CRUD部分もPostgREST/Supabase/Hasuraで置き換え可能だと思う。全体的な感覚には同意するけど、最近のORMとかライブラリを過信してる気がする。Entity Framework、ASP.NET、Rails、Postgres、SQLiteの1%にも満たないものばかりだよ。
Supabaseで対応できない簡単なCRUDのユースケースはまだ見つからないな。ほぼ設定なしで使えるよ。高度な使い方にはPostgresの知識が必要だけど、全体的には素晴らしいプロダクトだよ。authとかblob storageもSupabaseに任せればさらに良いね。Clerkをauthに使ってるけど、他のSupabase製品も使ってて、小規模なユースケースには最適だよ。細かくデータベースの権限を設定する必要が出てきたらどうなるかはわからないけど。
それな、うちの会社でもSupabaseをいくつか使ってるよ。Supabaseをそのまま受け入れれば、かなり楽できるし、時間もお金も節約できる。ORMの話と同じで、エッジケースはSupabaseを捨てずに、個別に処理すればいいんだよね。
話が逸れるけど、ORMって設計上の欠陥の塊だよね。技術的負債そのもので、PoCには使えるけど、目標スケールに達したら作り直す必要がある。リレーショナルデータとオブジェクトベースのデータの間には根本的なミスマッチがある。ORMはいくつかの問題を解決できるけど、他の問題を無視する必要がある。ORMは難しいトレードオフについて意見を持つのがせいぜいって感じ。
現実的には避けられないよね。アプリ全体でリレーションを維持してたとしても、サードパーティのAPIとかネットワークサービスを呼び出す必要があって、リレーションとオブジェクトのマッピングが必要になる。特にネットワークサービスはn+1問題を避けるためにオブジェクトを優先するからね。アプリでオブジェクトとリレーションをマッピングするかどうかは、多くの場合選べない。自分でやるか、ツールキットを使うかって話になる。
ORMなしのDBクエリは事実上サービスだよね。DBレイヤーでリレーションを隠蔽して、オブジェクト指向のコードでリレーションをモデル化する必要をなくす。つまり、ORMを完全に避ければ、オブジェクトとリレーションをマッピングするかどうかの問題はなくなる。その質問をしてる時点で詰んでるかもね。
クエリとORMは全然違う概念だよ。Object-relation mappingは、リレーション（またはテーブル）とオブジェクトのマッピングに関すること。ORMとActiveRecordパターンを混同してるのかな？ActiveRecordはクエリビルディングとORMを組み合わせたものだよ。
ORMとActiveRecordで混乱してたけど、DDDを学んでエンタープライズアーキテクチャにたどり着いて、データの操作に関するデザインパターンを理解できた。多くのWebフレームワークはQuery BuilderとActiveRecordしかないよね。
まず定義だけど、ORMとActive Record PatternはWikipediaを見てね。
Active RecordはORMの一種だと思う。Active Recordの話は置いといて、オブジェクトのマッピングとリレーショナルデータベースのマッピングには根本的なミスマッチがある。データベースをサービスとして使えないってことだよ。データベースとのやり取りはORMを通して行う必要がある。APIがSQLで動いてると、データベースが変わってもAPIを使う側は変更しなくていい。でも、ORMがオブジェクトを公開してると、属性のロードが変わると、それを使う全てに影響が出る。ORMの世界ではN+1問題とかNullPointerExceptionが起きやすい。
＞Wikipediaにも書いてあるけど、オブジェクトとリレーショナルデータベースは違う。
つまり、オブジェクトの世界でできることをデータベースで全て1:1でできるわけじゃない。だからORMはデータベースを単なるデータストアとして扱う必要がある。クエリで例を示すね。
Hibernateのクエリコードを見てみよう。
ORMだと全てのMoviesをロードして繰り返す必要があるかも。最高収益の映画監督を取得したいなら、ORMはオブジェクトじゃなくてAPIコールとして扱う必要がある。
＞ To illustrate, let’s pull some query code [3] from Java’s Hibernate, a prototypical ORM.
ORMとentity managerは違うよ。entity managerはquery builderといくつかの機能が組み合わさったもの。あなたのコードはquery builderに焦点を当ててるね。entity managerはactive recordとは違うけど、query buildingとORMの境界はもっと明確だよ。ORMは名前の通り、Object-Relation Mappingだよ。
マジそれなー。ほとんどのデータベースとプログラミング言語の間にある、めっちゃ大きな溝を埋めてくれてるんだよね。ただ、根本的に妥協の産物ってのがネックなんだよなー。規模が大きくなったり複雑になったりすると問題が出てくるのは当然。違う妥協点を探すために一から作り直すのも、現実的じゃないし。
＞根本的に妥協の産物ってことだよね”
だから最近のアプリは、できるだけリレーションを使い倒して、どうしても必要なとこだけオブジェクトにマッピングする傾向にあるんだな。
＞違う妥協点を探すのは現実的じゃない”
マッピングを遅らせるメリットはそこだよなー。マッピングが必要な範囲が限定されて、特定しやすくなる。全部に対応できる巨大なフレームワークを作る必要がなくなるし。必要なものだけ作ればいいから、トレードオフも最適化しやすい。ORMライブラリを使うのは時間の無駄になるかもね。
＞リレーショナルデータとオブジェクト指向データの間に、根本的なミスマッチがたくさんある”
経験上、一番の問題は、OOP言語が循環参照を表現できないことだと思うわ。シリアライズが必要になるまで、みんな気づかないんだよね。
https://github.com/dotnet/runtime/issues/29900
どっちもアリだと思う。状況によって最適な解は違うし。プロジェクトが始まったばかりの頃は、ざっくりとしたアイデアしかないから、パフォーマンスよりも変更のしやすさが重要になる。でも、プロジェクトが進むにつれて、一番の問題点が見えてきて、ORMレイヤーで解決できるって結論になることもあるよね。最初から分かってたとしても、初期段階の開発者は、理想のデザインについて違う考えを持ってる場合が多いし。
＞最近のORMライブラリは、昔より良くなってる” SQLiteレベルのオープンソースプロジェクトって、マジで少ないと思う。ハードル高すぎ。 ORMは信用できない。シンプルなCRUDプロジェクトなら、DALを用意して、明示的にメソッドを書いた方が絶対良い。 ＞DALを用意して、明示的にメソッドを書いた方が良い” オブジェクトって、単なるデータコンテナ以上の意味があるよね。言語によってはクラスとかオブジェクトで表現されてるけど、属性を持つこと以外は、オブジェクトっぽい機能は必要ない。マップとかハッシュとかの方が使いやすい場合もある。クエリビルダーとネイティブなデータ型を組み合わせるのが理想。 ＞オブジェクトは単なるデータコンテナ以上の意味がある” 安全第一の組み込みソフトで1～2年働くの、マジでエンジニアのためになると思うんだよねー。ミスったら命に関わるレベルのやつ。全員が気に入るかは知らんけど、経験にはなるっしょ。そーゆー経験したら、もうちょい普通のソフト開発でもYOLO精神なくなるんじゃね？ 若手の頃に止まっちゃいけないシステムに関わったのが、良い習慣につながったなー。品質がそこまで求められない場面でも役に立ってるし。基本的なことだけど、リターンコード毎回チェックしたり、全ての分岐をテストしたり、外部環境がちゃんと動くか確認したり。今じゃもう体に染み付いてるから、適当なpythonスクリプト書くときでもやっちゃうんだよね。デバッグ時間も考えると、YOLOしてる人より効率良いと思うし。データ基盤でも同じようなことあるよね。 マジで同意！有名なアルゴリズムの実装とかは信用できるけどね。でもね、意外と自作した方が安く済むこと多いんだよね。何年か経ってからシステム見直すと、パッケージ使ったコードの方がバグとかセキュリティの穴が多いんだわ。修正コスト考えると、マジで自作の方が安いこともある。専門的なことでも、ベンダーに頼むより自作の方が安いとかあるしねー。機会費用もあるけど。 最近のライブラリ、マジで質低すぎてもうビビるわ。ライブラリ業界も競争激化してて、ビジネスになっちゃってるからね。正しさとか品質よりも、とにかく早く出して、チュートリアルとか本とかGitHubのスポンサーシップとかで稼ぐのが目的になっちゃってる。セキュリティもそうだけど、開発体験もクソ。ドキュメント少なすぎ、基本的なケースすらカバーしてないとかザラ。新しい開発者は新しいライブラリしか知らないから、基礎がなってないんだよね。React使いなのにHTMLフォームをライブラリなしで使えないとかありえん。 ＞最近のライブラリの質の低さにショックを受けてるって？ それ言い過ぎじゃね？結局、みんな積み重ねでしょ。Math.Abs()とかソケットライブラリとか、信用して使ってるわけだし。フレームワークはできるだけ避けるけどね。スクリプト言語で自分で書いた方がマシなやつとか。RESTの呼び出しとか非同期関数とかの裏にある、何層ものソフトとかハードは？PixijsとかChart.jsとかJqueryとかMoment.jsとかBootstrap 4とか、良いライブラリもあるし。自分で作ったことあるやつもあるけど、使い慣れたツールキットがある方が時間節約になるよ。問題は、もう死んでるか、開発が活発なライブラリにハマることかな。 Momentはブラウザのタイムゾーン以外をコントロールできるからまだ使うけどねー。Momentの代わりになるおすすめある？JavaScript Temporalに期待してる。 ＞非標準技術は使わないってのは共感できる。 リファレンス読めってことね！でもいきなりガッツリ読むより、まず1時間くらい試行錯誤するのが好きなんだよね。Stackoverflowとか見て、ちょこっと触ってからリファレンスに戻るみたいな。なんでかって言うと、実際に触ってみないとリファレンスのコンテキストが理解できないことが多いから。特に新しい言語とかAPI学ぶ時はそう。チュートリアルとか quickstart やって、自分でちょっと変えてみて、それからリファレンス読むと理解度が全然違うんだよね。Intellisenseみたいな機能があるとマジ助かる。お試し段階でドキュメントがチラッと見えるのはホント便利。 ＞リファレンス読めってことね！ 良いインターフェースを設計できる人と、良いドキュメントを作れる人って、すごい相関関係があるんだよね。つまり、推測がうまくいかない時、リファレンスも不正確だったり、必要な情報が伝わらなかったりしてダメなことが多いってこと。ユーザーがどう製品を認識するかを考えるスキルが必要だから当然だよね。実際に、リファレンスを理解できないと思ってたら、バグだったり、変更でリファレンスが無効になってたりすることってよくあるんだよな。最近は、ユーザーのこと考えてない人が作った製品は、推測がダメならソースコード見に行くか、コードがなかったらシステムを直接調べるようにしてる。そっちの方が早いし、自然言語で説明するよりも、何が起きてるか良く理解できる。 Windows開発について色々言いたいことはあるけど、90年代のMSDNリファレンスはマジで良かった。Win32とかMFCとかね。PetzoldとかProsiseの本もあれば、オンラインに行かなくても大体のAPIの疑問は解決できた。なのに、それでも適当に探り当てようとしたり、先輩に聞くエンジニアもいたんだよね（先輩はいつも「ドキュメント読んだ？」って聞いてたけど）。言い訳できないレベルでドキュメントが優秀だったんだよな。Win32の闇の部分もあったけど、99%のdeveloperはそんなとこ触る必要なかったし。 良かったけど、完璧ではなかったよ。「MSDNにはXって書いてあるけど、実際の挙動はYだから、コードにはZがある」みたいなコメント残した記憶あるもん。毎日そんなことがあったわけじゃないけどね。 ＞良いインターフェースを設計できる人と、良いドキュメントを作れる人って、すごい相関関係があるんだよね。つまり、推測がうまくいかない時、リファレンスも不正確だったり、必要な情報が伝わらなかったりしてダメなことが多いってこと。ユーザーがどう製品を認識するかを考えるスキルが必要だから当然だよね。 ＞ネットで拾った”何か”を理解せずに試すみたいな。 ＞＞ネットで拾った”何か”を理解せずに試すみたいな。 ＞ありえないでしょ。 ＞＞ありえないでしょ。 ＞最高のプログラマーって実はそこそこのプログラマーだったりするよね。 わかる。まず仮説を立てて、コードで確認して、また繰り返す。これって当たり前だと思ってたけど、意外とそうでもないんだね。エンジニアリングって科学的な方法論に従うはずなのに。仮説を立てて検証しないと、科学的じゃないじゃん。まあ、仮説と推測の違いを細かく言うなら別だけど、推測ってプログラミングのめっちゃ大事な要素だよ。 コードを書く前に仮定を立ててチェックすることで、後から都合の良いように解釈することを防げるんだよね。間違った予測は理解を深めるのに役立つし、学びに繋がる。 だから、何でもchatGPTに聞くより、Googleで検索するんだよね。Stack Overflowとかのコメントやスレッドで、面白い情報が見つかることが多いんだ。 最近は、まず自分でやってみて、それをLLMに批評してもらうのが好きだな。その方が、学ぶのに良いと思うんだよね。外国語学習と一緒で、間違えて修正される方が、毎回正解を見るより身につくと思うし。それに、LLMがでたらめなことを言わないか心配する必要もないし。自分で調べるきっかけにもなるし。 知らない言語やライブラリを使うときは、ブラウザのタブをたくさん開いてるな。ドキュメントには注意点とかコツが書いてあることが多いけど、LLMには載ってないことが多いからね。それに、本を読むと基礎がしっかりするし。 なるほどね。最近swiftを勉強し始めたんだけど、最初はLLMを頼ったよ。「JavaとPythonは知ってるんだけど、swiftの構文を教えて」みたいな感じで。それはすごく良かった。アーキテクチャについては、方向性だけ決めて、あとはGoogleで調べた（例えば、swiftData、coreData、sqliteのどれを使うべきかとか、会話スレッドで色々調べた）。 新しいことを学ぶには、真ん中から始めるのがいいよね。概要を見て、他の人がどう考えているかを見て、それからマニュアルに飛び込む。 「推測するな」って言葉を、非現実的な意味で解釈する人が多いと思うんだよね。最高のプログラマーはそうじゃない。 リファレンスに集中するのがマジで無理なんだよね。子供っぽいけど、どうしてもできない時がある。コードをいじくり回して今の自分があるんだよ。 正直言って、参照がマジで分かりにくい時あるよね。全部説明してる’つもり’でも、理解するための背景が足りてないんだよ。だから例が超大事。 マジそれな。良いドキュメント書くのってマジ難しい。特に作者がデザイナーも兼ねてる時。コンテキストがありすぎて、当たり前だと思っちゃって省いちゃうんだよね。 あなたのやり方は悪くないと思うし、少なくとも精神的には記事のアドバイスと矛盾してないと思うよ。テストされてない推測が製品に入ったり、根拠のないアドバイスを同僚にしたりする状況を言ってるんじゃないよね？仮説を立ててテストするのは価値があるけど、根拠のない前提に基づいて構築するのは全然違う。 面白いね。俺も哲学勉強してた時に似たようなことしてたわ。読むより考える方が好きだから、まず哲学的な問題を自分で考えて、それから他の人の意見を読むんだ。そうすると理解が深まる気がしたんだよね。プログラミングでも同じことしてるかは分からん。 これ同意。新しいツール使う前に色々学ばないと、ドキュメントを効果的に使えないんだよね（Getting Started以上は）。すでに詳しい分野ならすぐ飛び込めることもあるけど、大抵は試行錯誤が大事。 実は、”まず自分でテストしてから学ぶ”アプローチは、研究によると、ただ学ぶよりも学習効果が高いらしいよ。 ＞“Stack Overflowに行くな、LLMに聞くな、推測するな、ソースに直接行け。意外とアクセスしやすくて、よく書かれてる。” ＞“Stack Overflowに行くな、LLMに聞くな、推測するな、ソースに直接行け。意外とアクセスしやすくて、よく書かれてる。” Haskellはもう何年も使ってないけど、何使っててもHoogleが恋しくなるんだよね。’X型の値が欲しいけど、どの関数がX型を返すんだ？’って検索できるのがマジ便利。Scalaも同じように型シグネチャで検索できるドキュメントがあった気がする。 これはワークフローを円滑にするツールを使うことにも繋がると思う。ライブラリコードの定義にジャンプできると、自分のコードから関数にすぐに移動できる。コードエディタのサポートがあれば、シームレスにできる。そうじゃないと、エディタから離れてGoogleで検索して、GitHubで探して、プロジェクト検索して、大量の結果から探さないといけない。 意外とアクセスしやすくて、読みやすいんだよね。この人が質の高いソフトウェアに関われてて良かったじゃん。俺はいつもラッキーとは限らなかったけどね。 リテラシープログラミングの強力な主張じゃん。http://literateprogramming.com/ 俺が一緒に働いた最高のプログラマー2人は、クヌースのTAoCPを読み込んでたよ。 ほとんどのプロジェクトはdiataxisに従うべきだし、そうすれば苦労することも少なくなると思うぜ。 最高の開発者は、プリンシパルエンジニアともジュニア開発者とも話すんだよね。ヒエラルキーなんてないんだ。若い人も年配の人も、みんなから学ぼうとする。新参者はまだオフィス政治に染まってないから、新鮮な考えを持ってるんだよね。物事が難しい理由を知らないから、創造的な解決策を提案してくれる。過去の障害はもうないかもしれないし、彼らは素晴らしいインスピレーションの源になるんだ。 個人的には、新しい人の方が良い質問をすると思うな。経験豊富な人は、いつ慣習に従わないかを知ってる。 この記事に欠点が見つからないな。ほとんど全部に同意できるけど、一点だけ例外がある。 俺もほとんど同意できるけど、それ以外はね。このアドバイスは、人それぞれの学習方法から来てると思うんだ。もし作者とは違う学び方をするなら、このアドバイスは間違ってて、不快に感じるだろうな。 人の学び方や創造の仕方はそれぞれ違うよね。他のクリエイティブな分野にもそういう二面性があるけど、俺たちは数学に近いから、常に物事の「正しいやり方」を見つけようとする。でも、俺たちの分野は実際には非常に柔軟で、多くの自己表現を許容しているんだ。 マジでLLM最高だわ。200ページとか100ページ超えの13FのファイリングレポートをGeminiにぶち込んで10分後にはアノマリー見つけてくれるんだぜ。これマジありえないっしょ、今まで。だってこんなレポート、全然標準化されてないんだもん。 ログでも同じことやってる。ちゃんとfield by fieldでdiffとるのがめんどくさい時に。 いや、全然一貫性ないドキュメントだよ。13Fファイリングの内容に関する要件はあるけど、フォーマットについてはあんまないんだよね。しかもPDFだから、従来のスクリプトで解析するのがマジ難しい。 めっちゃわかる。俺も同じような使い方してるわ。回りくどい言い方しかできなくて、言いたいことがうまく言えない時に検索で使う（昔読んだ本の超曖昧な記憶しかない時に、検索エンジンじゃ無理だったのに見つけられた）とか、”フレームワーク”に関する質問とか。例えば、これ何？とか、各要素の関係は？みたいな。ある意味これも検索問題だと思ってる。ゼロから始める検索みたいな。鵜呑みにはできないけど、情報の”ランドマーク”を把握して、そこから理解を深めていくには十分。 ＞キャリア始めた頃は、質問するよりStack Overflowで質問に答えるのに時間を使ってたな。 まさに今のLLMの使い方それだわ。どんな分野でもキックスタートできるし、このレベルの使い方ならエラーもほとんどない気がする。 最近絵を描き始めたんだけど（ちょっとした中年クライシス）、全然わからなくて、何ができるのかすら理解できてない。ネットにはゴミみたいなチュートリアルばっかだし。LLMが俺の意図を解釈して、キーワードとか名前を教えてくれるのはマジ助かる。もちろん、詳しい人に聞くのが一番いいんだろうけど、いつも都合がいいわけじゃないし。LLMの一番いいところは、ソフトなインプットができるってこと。ソフトなアウトプットは問題ない。 絵を描くなら、本とか講座を買うのが普通は良いと思うよ（New Masters Academyみたいな良いプラットフォームで）。あとは練習あるのみ。もっとコメントを表示（1）
そうは思わないなー。昔のORMは機能豊富だけど、最近のORM、特に新しい言語のORMは、ActiveRecordとかEntity Frameworkに比べると、機能が少ない気がする。
それってちょっと違う気がする。ORMライブラリを使う場合でも、DALは必要でしょ。DALから独自のオブジェクトを出力すれば、それってORMの発明だよ。リレーションを出力するのもアリだけど、結局オブジェクトにマッピングする必要がある。例えば、サードパーティとの連携とか。複雑なアプリケーションでは、ORMは避けられない。
確かに。厳密に言えば、リレーションはタプルの集合だけど、SQLデータベースを使ってる時点で、その考え方はもう古い。クラスのインスタンスも、基本的なプロパティを持っていれば、リレーションとみなせる。データの意味は変わってないからね。でも、オブジェクトへのマッピングは必要になる。複雑なアプリなら、サードパーティとの連携で絶対に必要になる。
そりゃそうでしょーよ。医療とかDoD以外のソフト業界は、品質なんて気にせずにとにかく早く機能提供することしか考えてないんだから。
最後の行まではね。Not Invented Here症候群で、根本原因の解析を邪魔するようなスタックになったコードベース見たことないわ。昔、C++の会社で、自作のスレッドセーフな文字列クラスがあって、ひどいことになったけどね。成熟した技術はたくさんあるし、自分の発明が、何千もの目が入ったフレームワーク/ライブラリ/データベースと同じくらいバグがないなんてありえないでしょ、どんなにスキルがあっても。
＞推測すんなって！
＞新しいもの使うとき、まず1時間くらい推測するのが好きなんだよね。Stackoverflowとか見て、ちょこっと触ってからリファレンスに戻るみたいな。
”それは確かにそうだね。ダメなプログラマーはStackoverflowだけ見て永遠に推測してるイメージ。何が起きてるのか全然わかってないのに、とりあえず色々試して、たまたま上手くいくまでゴチャゴチャにする。この記事はそういう人たちへのアンチテーゼだと思うよ。
話してる推測の種類が違うと思う。俺が言ってるのは、何も知らないのにネットで拾った”何か”を理解せずに試すみたいな、アホな推測のこと。そういう人は、どんなに優れたインターフェースと最高のドキュメントがあっても同じことするんだよね。それに、最高のインターフェースでも、全部が見つけられるわけじゃないし。もっとコメントを表示（2）
最初はそれもありだよね。でも、それで上手くいかなかったらそこで止まっちゃダメ。次はインターフェースをよく見て、ヒントがないか探すべき。良い設計なら大抵ヒントがあるはず。
＞最高のインターフェースでも、全部が見つけられるわけじゃないし
テストスイートがあるじゃん。ユーザーへの完全な意図と使用方法をドキュメントするためだよ。そのためにリファレンス見ないでしょ。それに、自己検証できるから、「俺のせい？リファレンスが間違ってる？」みたいなことにならない。
＞最初はそれもありだよね。でも、それで上手くいかなかったらそこで止まっちゃダメ。
ありえないでしょ。コピーペーストコーディングのこと言ってるんでしょ？Google検索して、Stackoverflowで一番最初の回答をコピペ。その後で、そのdevに何をしたのか、なぜ動くのか聞いても、本人もわかってないから答えられないんだよ。
＞インターフェースをよく見て、ヒントがないか探すべき。
そういう人は絶対にそれやらない。
＞テストスイートがあるじゃん。
「コードはself-documentingだからコメントなんていらない」みたいな雰囲気を感じる。賛成できないな。コードやテストよりも、文章の方がコードに関する多くのことを表現できると思う。
確かにコードは実装されたことを知るには一番信頼できるけど、理由とかコンセプトを知るには向いてない。
なんで？動けば良くない？みんながみんな最高のプログラマー目指してるわけじゃないし。
＞本人もわかってないから答えられないんだよ。
特定の人のことを考えてるのはわかるけど、大体どう実装するか知ってるから、大体どう動くかくらいわかるでしょ。誰かのコードが既にやってくれてるなら、それ以上考える必要ないし。最初はそこから入っても全然アリ。
＞理由とかコンセプトを知るには向いてない
テストで”why”を捉えてないなら、一体何をテストしてるの？”what”は実装で既に捉えられてるじゃん。それを二回書く必要ない。それよりも、変更するたびにテストが壊れる状況の方が最悪。テスト書くのはマジで難しいけど、リファレンス書くのと同じくらい難しい。でも、スキルのない人が作ったものを使うしかないなら、どうしようもない。
＞なんで？動けば良くない？みんながみんな最高のプログラマー目指してるわけじゃないし。
なるほどね。ドキュメント読まずに推測したり、Google検索してStackoverflowの最初の回答をコピペするようなプログラマーは、まあまあなプログラマーってことね。良いプログラマーになりたくないなら、今のままで良いんじゃない？
＞テストで”why”を捉えてないなら、一体何をテストしてるの？
コードで”why”を捉えることはできないよ。テストは”what”のデモンストレーションでしょ。
まあ、それは人によるんじゃない？「最高の」プログラマーを決めるために、自分がやってることをリストにして当てはめようとする人は、当てはまらない人を排除しがちだよね。
ビジネスの人は、誰かのコードをうまく使って早く製品を届ける人を「最高」って思うかもね。
＞コードで理由を説明できないなら、言葉でも無理じゃん。意味なくね？
いや、そんなことないと思うよ。
＞テストは「何」のデモだよ。
確かに、APIドキュメントに入れる「例」テストみたいなのはあるけど、それは一部でしょ。ほとんどのテストは違うよ。もしそうなら、やり方が間違ってるか、後でテストを使う人に不親切だよ。
俺のリストでは、次の人のことを考えるのが「最高」のプログラマーとそこそこのプログラマーの違いかな。
Peter Naurの「Programming as Theory Building」ってエッセイがめっちゃ参考になるんだよね。40年前のだけど、プログラミングの本質を捉えてる。プログラミングで作られる価値って、ソースコードじゃなくて、システムについての共通の理論なんだよね。仮説なしに十分な理論を構築できるとは思えない。
ツールやライブラリがどんなモデルを提供しているか、ちゃんと把握しておくべきだよね。そして、そのモデルを使ってツールの挙動を「推測」するべき。推測が当たりやすいツールを選んで、特殊なケースが多くて推測しにくいライブラリは避けるべきだよね。
最高のプログラマーは、関数を呼び出すたびにドキュメントや実装を確認したりしない。一度にたくさんの仮定をチェックできるテストを書くのが得意だし、信頼できるツールを選ぶのが上手い。そして、間違った推測をさせるようなツールは避ける。
プログラミングのレバレッジは、理解しなくてもいいこと、読まなくてもいいコードから生まれるんだ。もっとコメントを表示（3）
なんか数学の本みたい。工学部の時、形式的な数学を読むのがマジ嫌だった—いつも分かりやすいテキスト読んでた。修士でちょっとマシになって、要点を手短にまとめた章を読めるようになった。少なくとも今は、なんでみんな簡潔な参考文献を書くのか理解できる。rust cratesはいつもdocs.rsに行くし最高。Haskellのhoogleも好きだった。Cpp referenceも結構良い。
今日boto3 python libraryのドキュメント読んで、docs.rsが恋しくなったわ！
＞なんか数学の本みたい。工学部の時、形式的な数学を読むのがマジ嫌だった—いつも分かりやすいテキスト読んでた。修士でちょっとマシになって、要点を手短にまとめた章を読めるようになった。
それってアドバイスの意味と違うと思うな。体系的な知識と断片的な知識の話だと思う。LLMやStack Overflowで’学ぶ’人は、ツールの全体像を把握してないから、ステレオタイプな使い方しかできないし、無駄に難しいやり方でやる羽目になるんだよね。体系的な知識は分かりやすいテキストでも得られる。
最近Zig触ってるんだけど、ドキュメントシステムがマジ良い。見てるものの実装ソースが埋め込まれてて、使い方の例も載ってるのが良い。Hoogleみたいに型シグネチャで検索できたら最高。
＞それが逸脱の正常化に対抗する方法だよ。新しい人が間違っていることを指摘しても、理由もなく無視しちゃダメ。そう、あなたはXをいつもと違う方法でやってきたし、何も問題は起こらなかった。でも、そうすべきでない理由があるかもしれないし、経験することによってそれを学び直すには多くのコストがかかるかもしれない。
誰にも存在理由がわからないけど、まだ守られている古いルールも同じこと。どんなルールにも存在理由の説明が必要だし、その関連性は定期的にチェックされるべき。
変化は本当に速いし、AIツールを使えばなおさらだ。だから、なぜ特定のやり方をするのかを問い続ける人がいることが重要なんだ。
＞「Stack Overflowに行くな、LLMに聞くな、推測するな、まっすぐソースに行け。多くの場合、それは驚くほどアクセスしやすく、よく書かれている。」
俺がプロとして積極的にコーディングするようになってから、もう15年以上になると思う。常に学んでるよ。キャリアを始めた頃は、Stack Overflowで質問するよりも、質問に答えることにかなりの時間を費やした。誰かの問題を解決するのは“Real-World challenge”みたいで、すごく役に立ったんだ。だから、Stack Overflowの使い方次第だと思うよ。
LLMについては、最近の若者がやってるような“vibe coding”には使わないな。これは間違った使い方だと思う。LLMは、リアルタイムイベントを分析して要約を作成したり、退屈なことを自動化したりするために、構築中のソフトウェアに統合するには最適だ。でも、プログラマーの代わりには絶対にならない。少なくとも今のところはね。LLMの使い方は、理解したい/探求したいトピックについて、鳥瞰図/10,000フィートの視点を提供するように依頼することだ。なぜかって？用語がわからないから、何がどう機能するのかわからないこともあるからね。そこでLLMが役立つんだ。用語がわかったら、LLMに頼るよりも、公式ドキュメント/論文を参照できる。これは過小評価されているLLMのスーパーパワーだと思うよ。
俺は読んで学ぶより、やって学ぶタイプ。何かを読んでも、実際に使わなかったら忘れちゃう。俺の脳はそれを“実用的じゃない、必要ない”と分類するみたい。でも、実際に使えばすぐに覚えるんだ。
だからドキュメントはひどいと思うし、何かがどう機能するかを読んでも役に立たない。例を見る必要があるんだ。何かが動作しているのを見れば、実際にそれを学ぶことができる。コピー/ペーストでも、コピーしたコードをいじったり、変数を変えたり、パラメーターをいじったり、コメントを追加/削除したりするから効果がある。コードは決してただコピーされるだけでなく、常に操作され、クリーンアップされ、不要なものが削除されるんだ。
例がないドキュメントや、使い方の関係のない貧弱な例がたくさんある。
APIに「意味」がないと、覚えにくいんだよね。たとえばSQL Serverの“OVER”句は、長年使ってきたけど、使うたびにまた覚え直さないといけない。そういうAPIは本当にイライラする。
今はSOの質問に趣味で答えるとか無理だと思う。昔は朝のコーヒー飲みながらやってたけど、いつの間にかプロの評判稼ぎみたいなのが湧いてきて、投稿される30秒前に全部答えちゃうんだもん。それに、やっと回答されてない質問見つけても、”魚の釣り方を教える”みたいな回答するとモデレーターに怒られるし。コピペできるコードじゃないとダメみたいな。
