ベテランエンジニアが考えを改めたソフトウェア開発の話題が興味深い
引用元：https://news.ycombinator.com/item?id=42946281
クラフトにこだわる人なんて少数派だよね。こだわる人を大切にして、そうでない人には相手のレベルに合わせるのが大事だね。
コードスタイルとかlinting rulesにこだわる人は、相変わらず変なやつらだと思っちゃう。もっと重要なことに集中すべきだよ。
あんたが”些細なことにこだわる”って言うことを、他の人は”クラフトを大切にする”って言うかもね。職人は細部にこだわるもんじゃん？”ストレス”ってのはあんたの価値観であって、真実とは限らないよ。
＞要するに、自分が主観的に正しいと思うレベルまでこだわる人は大切にして、それ以上にこだわる人は優先順位をつけられない変人だって切り捨てるってことだよね。
別の見方もできるよ。コードは設計そのもので、コンパイルは建設プロセスだって考えるなら、コードスタイルにこだわるのは、構造とか材料費とかスペースの有用性じゃなくて、設計図の形式とか慣習にこだわるのと同じことだよね。
コンパイルで消えるものは設計じゃなくてコード整理だっていつも言ってるんだ。設計っていうのは、どのデータ構造を使うか（list, map, arrayとか）、どのデータをメモリに残すか、いつデータをロード・保存するか、どのアルゴリズムを使うか、並行処理をどうするか、みたいなことだよね。コード整理は大事だけど、クラフトの決定的な特徴とは言えないよね。
＞設計図の形式とか慣習
形式的な慣習の中には、血で書かれたものもあるんだよ。安全に関わる情報を伝えるとき、設計図のわかりやすさはすごく重要になるんだ。
コードの形式がそこまで重要だとは思わないけど、認知負荷を減らすって意味では大事だよね。何行も繋がったコードなんて誰も見たくないし。どこまでやるかはリターンが減っていくけど、少なくともdiffをするときに困るような変更は避けるべきだよね。
マジで同意。問題は、半世紀経ってもソフトウェアエンジニアリングの世界で、グローバルな慣習や標準が合意できてないことだよね。最近、家の修理業者がコンクリートの梁の配置が変だって心配してたんだ。設計図を見せたら、すぐに梁と柱の表を見つけて、”ああ、そういうことね。〇〇すればいいんだ”ってなったんだ。そのとき、CRUD APIでRDBMSを使った普通のビジネスアプリでも、同じことができないってことに気づいたんだよね。
だって、守らなきゃいけないルールが少ないし、大したことないことが多いんだもん。建築だと、重さとか材料の劣化とか法律とか気にしないといけないけど、ソフトウェアにはそういう制限がないから、LSDトリップから生まれたようなものでも動いちゃうんだよね。
共通の概念はあるけど、それは理論的なものだから、本を読んだ人しか専門用語を知らないんだ。
そもそも、softなウェアにhardなルールを期待するべきなの？柔軟性こそが大事なんじゃない？
建設や土木工学だって、グローバルな慣習や標準で合意できてないよ。ソフトウェアエンジニアリングより何千年もの歴史があるのにね。アメリカは”International Building Code”に従ってるって言ってるけど、それはアメリカ大陸のいくつかの小さな国が採用してるからそう呼ばれてるだけで、実質的にはアメリカの標準だよ。世界的に見ると、単位系すら合意できてないんだから、もっと重要なことなんて無理だよ。
いや、グローバルでは単位系は合意できてるって言うべきでしょ。アメリカといくつかの発展途上国が従わないだけだよ。
＞問題は、半世紀経ってもソフトウェアエンジニアリングの世界で、グローバルな慣習や標準が合意できてないこと。
それは無理だし、これからも無理だよ。常に”唯一の真実”を直接編集して、それをプレーンテキストで表現することに固執してる限りはね。消費者が同時に抱える全ての懸念を包括的に表現するには、それじゃ不十分なんだ。抽象化とかエラー処理とか関数のサイズとか変数の命名とか、何がよりクリーンで読みやすく保守しやすいかっていう不毛な争いを永遠に繰り返してるんだ。なぜなら、業界はまだ答えに気づいてないからだよ。それは、何をしてるかによるんだ。一番良い表現とか関数サイズなんてないんだよ。今は理想的でも、5分後には逆になるかもしれないんだ。たとえば、モジュールを理解するところから、特定のバグをデバッグするところに切り替えるときとかね。
プログラミングパラダイムの表現力は飽和状態なんだ。パレートの境界線上を行ったり来たりしてるんだよ。まるで酔っ払いが壁に寄りかかって、転ばずにパブに戻ろうとしてるみたいにね。数学的に複雑な魔法の圏論を持ち込んでも無駄だよ。それは複雑さを別の場所に押しやるだけで、パレートの境界線の別の場所にたどり着くだけなんだ。
ヒント：建設では、誰もが同じ設計図を使ったりしないよ。ジオメトリ、構造特性、材料特性、インテリア、配管、電気、断熱材、HVAC、地質条件、水文条件、税務条件の情報を1枚の平面図に詰め込もうとしてごらん。それは今のプログラミングのソースコードとそっくりになるはずだよ。
今はどんな言語でも自動フォーマッタに任せられるから助かるよね。
まだ自動フォーマッタのパラメータで揉める人もいるけど、そういう人はいつだってどうでもいいことで揉めるんだよ。
コードフォーマットの新しいパラダイムとしてローカル限定ってのはどうかな？エディタが自動で好みのスタイルに整形して、pushする時に元のコードベースのスタイルに戻すんだ。こうすれば、変更がコードベースのスタイルに合うじゃん。
最低限、フォーマット変更でdiffが複雑になるのは避けるべきだよね。もしコードの整形が必要なら、別のcommitでやるべき。幸い、一部の言語には構造的／意味的なdiffツールがあって、フォーマットとロジックの変更が混ざってる時に役立つんだ。
ソフトウェアの価値って、今の動作と、将来できること（構造）の両方にあると思うんだ。設計とかartifactは動作にあたるよね。重要なのは、将来の変更に対応できるようにすること。だから、読みやすさ、テスト、アーキテクチャを気にするのは、要件が変わった時に対応しやすくするためなんだ。ソフトウェアは家とは違って、建てたら終わりじゃないんだから。
経験から、将来の使い方を予測できることもあるけど、長い目で見ると、正確に予測できるなんて幻想だと思うようになった。予測を試みるのは大事だけど、昔ほど正しさにこだわらなくなったかな。例えば、インターフェースのシンプルさと実装のシンプルさで、考えが真逆になったよ。家っていうのは悪い例えだよね、人が住めないようなソフトウェアでも”住める”んだから。
＞(土木工学のたとえを使うなら)設計図のフォーマットや慣習にこだわること
これってめちゃくちゃ重要だよ。これがないと、チームの半分がmetricを使ってて、もう半分がimperialだと思ってたり、完璧な設計をしても、メーカーが勝手にミラーバージョンを作ったりするんだ。
imperialとmetricは単なる慣習じゃなくて必須要件でしょ。うちの同僚に、何でもかんでも一行で書きたがる人がいて、if/else文が嫌いで、例外処理はダメだって言うんだ。変数名の大文字小文字が気に入らないだけでコードレビューを落とすんだぜ？レビューが遅くてマジ勘弁。重要なこと（コードが実際に何をするか、要件を満たしているか）に集中できないんだよ。
解決策は、コンピューターにコードスタイルを強制させることだよ。linterを選んで、ルールを決めたら、あとは気にしない。PRでコードスタイルにケチつけてるならtoolchainが時代遅れ。
毎月lintingルール変えてるなら、大事なことを見失ってる。
完璧なスタイルより、一貫性のあるスタイルの方が良い。
マジそれな。gofmtに設定がないのが最高。こういう風にしたいんだろ？OK、じゃあ最適化とか考えなくていいや。偶然にも、gofmtの選択は俺がする選択と一致してたけど、結局どうでもいいんだよね。
gofmtはまだ不十分だと思うな。importのソートとか、自動で改行すべきだよ。そうしないと、人によって改行の好みが違って、スタイルに一貫性がなくなるじゃん。gofumpt + golines + goimports みたいなのがもっと良いと思う。Pythonのruffとかrustfmtを使ってるからそう思うのかも。手動で改行とかスペースでフォーマットしてるなら、toolingで自動化すべきだよ。 pre-commit hookとCIで実行するべき。
猛反対。goの慣習が自分の好みと合うのは良いけど、そうじゃない時はイライラするんだよね。例えば、Dartがついに”tall”スタイルに賛同し始めてるけど(https://github.com/dart-lang/dart_style/issues/1253)。でも、言語を使ってる全員に影響するスタイル慣習を委員会とかに変更されるのを待つ必要ある？事前に”tall”スタイルでコード書かせない理由は何？Formatterがそんなに
強要的
である必要ある？
フォーマッターがなんでそんなにうるさいんだって？そりゃ、こういう会話を避けるためだよ！tall formatにしたけりゃ、最後にダミーのコメントでも足しとけば？ 設定できない融通の利かないフォーマッターが、まさにこの会話を引き起こしてるんだよね。 1人で開発するなら何でもありだけど、チームだと摩擦が起きるし、スタイルにこだわりすぎると問題になるかもね。Goはチーム向けの言語で、考えることを最小限にするように作られてる。Rustとは真逆。シンプルすぎて、ほとんどミスできない。ロゴもそれを表してるんだぜ。だからGoのフォーマッターは厳格であるべき。いつまでも議論できるけど、フォーマッターには逆らえない。”コンピューターがNOって言ってる”ってこと。 誤解してるみたいだけど、俺はフォーマッターに反対してるんじゃないんだ。プロジェクトでスタイルを統一するのは全然OK。俺が反対してるのは、設定できないフォーマッター。それだと、tall styleを使いたくても’The Committee’にお伺いを立てなきゃいけないような、おかしなことになるんだよ。 設定できるってことは、設定について無限に議論できるってことだ。tall styleを使うかどうか迷うってことは、使う可能性を考えてるってことでしょ？もし赤い車しか作れないなら、次の車の色を議論したりしない。赤しかないんだから。気に入らなくても、それしかない。コードがひどくても、それでおしまい。 うちのコードベースではclang-formatを使ってるよ。たまにイケてないコードになるし、100%満足してる人はいないけど、少なくとも一貫性はある。 自分より遅い車はアホ、速い車はマニアックって思ったことない？ 君の主張を要約すると、タイポグラフィは執筆の一部だってことだよね。そんなこと考えてる作家に会ったことないな。コードも同じだと思う。みんな重要だと思ってないわけじゃなくて、特定のやり方にこだわるのが本質じゃないってこと。タブvsスペースとか、昔からネタにされてるし。 タイプライターが好きでコンピューターを使わない作家もいるよ。Harlan Ellisonは、修理してくれる人がいなくなってから、自分でタイプライターを修理する方法を学んだんだ。Stephen KingはDreamcatcherを万年筆で書いた。 それは全然OK！でも、タイプライターや万年筆を使うことと、文章の質には全く関係ない。プログラミングも同じ。フォーマットにこだわる人もいるけど、ひどいレイアウトのC言語のコードベースが、トラフィックを処理して金を稼いでることもある。エディタを好きなように使えばいいけど、フォーマットだけのPRを4回も出してたら、パフォーマンスレビューで何を言われるか考えた方がいいかもね。 コードスタイルにこだわる人って色々いるよね。どうスタイルするか議論したい人と、共通のフォーマッタ使って終わりたい人。 編集：親コメントを読み間違えた。残しておくけど、もっと注意すべきだった。 職人と比べるなら、客が見る部分にこだわるのはわかるけど、見えない部分は手抜きするでしょ。 ゲームのロジックみたいだな。自分より下手な奴は初心者。自分より上手い奴は廃人。 細かいことと職人技の境界線は、成果物に与える影響で決まると思うな。メソッドの長さはコードを管理しやすくするけど、改行の位置はそうでもない。 違うね。Eclipseで80文字で改行することにこだわるのは、昔も今もこれからもバカげてる。画面が大きくなってもこだわってる人が結構いたけど、意味不明（俺には）。2スペースvs4スペースとかタブとか。今より酷かった。 長い行を避けるのはマジで大事。ファイルを2～3個並べて開くから、横スクロールしたくない。 関数型コードはチェーンしやすいからスペースが必要。 それな。 50歳になって目が悪くなったら同じこと言えるかな？ 25歳の時は、19インチのモニターを高解像度にして小さいフォントで表示するのが好きだった。今はパソコン用のメガネかけても小さい文字は見えない。 ほとんどのプログラミングは一行のコードを書く前に終わらせるべきだって？ 大規模なレガシーコードベースでは、反復作業がマジで重要。 Greenfieldも長くても2年か最初のリリースまでだよね。その後はレガシー化するし。 ＞後悔するような選択をしてるかもって？ レガシーコードベースで12年働いてきた経験から言うと、これには猛反対。 ＞フロー図を作ったり、ホワイトボードで議論する方が良い結果が得られるって？ ＞最終的な形が決まったら全部捨てることになる そんな風に考えたことなかったけど、確かにそうだね。 ＞レガシーコードの地雷に顔面パンチされるまでは、みんな計画がある 今日のGreenfieldは明日のレガシー。結局は同じってことだね😉 Greenfieldプロジェクトなら、最初にガッツリ設計するのはマジで羨ましいけど、そうじゃないならイテレーティブに進めるのが正解だよね。Greenfieldプロジェクトは、使うもの全部にめっちゃ詳しい経験者がいる場合にしか通用しないんだよ。それ以外は、進めながら学ぶしかないし、計画も設計も何度も見直してアップデートする必要があるってこと。 どの開発現場にも必ずDaveみたいなヤツがいるよなー。 俺（開発歴16年以上）は、コーディングと設計をイテレーティブに行き来するのが好きなんだよね。 DRY原則とYAGNI原則の違いは経験値だよね。どっちも未来を予測してるんだけど、コードがどう進化するかを見てきた経験がないと無理ゲー。 こんなことわざあるよね？「一度目はミス、二度目は偶然、三度目はパターン」って。 俺はこう言いたいね。 ＞- Ten hours of programming saves one hour of planning… プログラミングって、実際には何がすでに存在してて、要件が何なのか（もっと重要なのは：なぜそうなのか）を理解することなんだよね。これはコードを一行も書く前にやるのがベスト。 で、どうやって要件を理解するのさ？10年以上のプロとしての経験で、要件を尋ねて教えてもらったことは一度もないよ。ほとんどの場合、俺が思う要件の解釈を示して、もらったフィードバックを使って実際の要件を定義する必要があった。そこにたどり着く一番早い方法は、イテレーションを繰り返すこと。 要件を聞くんじゃなくて、何がしたいのか、どんな問題を解決しようとしてるのかを聞くんだよ。場合によっては”このデータはどこに行くの？”とか”これの最終的な結果はどうなることを期待してるの？”って聞く必要があるね。 反対するわけじゃないんだけどさ、どんな質問でも、最終的な答えは実装した後、ほとんどの場合、何回か繰り返した後にしか出てこないんだよね。 ＞ほとんどのプログラミングは、何が既に存在していて、要件が何なのか（そしてもっと重要なのは：なぜなのか）を把握することなんだよね。 ＞要件が何なのか（そしてもっと重要なのは：なぜなのか） 深く掘り下げると、詳細な要件がいくつか判明するけど、抜けも多いんだよね。この新機能は今回限りなのか、それとも今後オプションが増えるのか？本当に使われるのか？使われない機能に力を入れて、テスト環境以外で使えないバグに誰も気づかず4年後に発覚、なんてこともあったし。こういう事が設計に影響するんだよ。 コードとSlackとかの会話、メールを結びつけたらマジで面白いと思うんだよね。コミットメッセージはあるけど、なぜそうなったかの決定はSlackにあることが多いじゃん？Slackのスレッドからコードへの影響を要約するAIツールとか試してみたい。 俺はいつもJIRAとかのツールに全部入れるように頑張って、すべてのコミットにJIRAのIDを含めるようにしてるよ。 動いてるうちは良いけど、使わなくなったら終わりだよね。うちは3つ目のシステムで、最初のと2番目のシステムのデータはほとんど消えちゃった。でもコミットメッセージはCVSからSVN、SVNからgitへの移行でも生き残ってる。 「プログラミングは理論構築」っていう考え方が、ここ数年でしっくりくるようになったんだよね。 ＞プログラミングは理論構築 20年以上開発やってるけどさ、コード書かないと何もデザインできないんだよね。 それって、まだ見たことない家のバスルームのリフォームの見積もり出すみたいなもんじゃん。まずは中に入ってみないと。 さらに言うなら、見たことない家のバスルームのリフォームの見積もりだと思ったら、実はガレージのリフォームだったみたいな。 ほんとそれ。 OPは何をコード書く前にやるべきかって言ってないよね？ だったら、著者は“ソフトウェア開発のほとんどは、コードを書く前に終わらせるべきだ”って言うべきだったね。プログラミングはコードを書くことなんだから。 コード書く前に“ユリイカ！”ってなる人もいるんだろうけどね。俺はコード書きまくって最終的なデザインを見つけるタイプだけど、もっとデザインすべきだとは思ってる。 他の意見は納得できるけど、これには同意できないな。事前に考える時間は必要だけど、実際に手を動かすことで見えてくることもあるじゃん。 この態度には驚き。すべてを見通せるエンジニア気取りか。ベイエリアのミッドレベルならまだしも、実績のある人が言うことじゃないよ。記事の他の部分には同意できるんだけどね。 それってヤバくない？デザインに戻れるオプションは必要だよ。でも、問題に気づいたタイミングによっては、無駄になる時間も変わってくるよね？ ただの個人的な意見だと思うけど、ほとんどに同意するよ。でもいくつか反対意見があるかな。もっとコメントを表示（1）
例えば、rustfmtのデフォルトスタイルに文句あるけど、rustプロジェクトでそれを変えようとか絶対言わない。でも、rustfmt使ってない人には、マジで使ってってお願いするかな。
いつも自分だけ違うスタイルでいたいんだね。どのプロジェクトでも毎回議論してルールを変えなきゃいけない。
デフォルトのスタイルに慣れてる人が入ってくる時の負担が増えるし、あなたが他のプロジェクトに参加するときも、デフォルトスタイルが多いから負担が増える。
デフォルトスタイルを受け入れないから摩擦が生まれるんだよ。
C#のデフォルトルールでelseブロックの前に改行が入るのが好きかって？ 嫌いだけど、慣れたから、毎回スタイルで悩まずに色んなプロジェクトで作業できる。
デフォルトのルールに従えば、タブvsスペースみたいな終わらない議論をしなくて済む。（スペースが勝って、タブ派はほぼ全員諦めた。）
コードのインデントで騒ぐのは職人じゃない。ただのヤバい奴か、無知で幼稚なだけ。
結局、コードを作るのが仕事じゃなくて、今動いて明日も簡単に変更できるソフトウェアを作るのが仕事。
そんなことに時間使うのは無駄だし、会社の金も無駄。個人の自己満足にしかならない。
職人って言うなら、アーキテクチャとかデザインパターンとか、最新ツールセット（でも最先端じゃない）とか、モノリシックなスパゲッティモンスターを作らないとか、そういうところにこだわるべき。
この違いが分からなかったら、筆者の言いたいこと分かってないと思う。
80文字は短すぎるけど、縦に長くなる方がマシ。120～150文字くらいが妥当かな。深いネストをしなければ余裕だし、深いネストは見たくない。読みにくくなるから。
説明的な名前は長くなる。
ウルトラワイドモニター買え。
80文字は小さいノートPC使ってそれを人に押し付ける奴の言い分。
120/150文字は妥当。
200文字は最高。
ノートPCの言い訳も通用しない。11インチのMacBook Airを10年使ってたけど、80文字はキツかった。
試したら、VSCodeで+1ズームしてミニマップ開いても140文字入るぞ。横スクロールなしで。
80文字にこだわる奴は、IDEの編集画面が小さすぎるんじゃないの？ Osbourne 1みたいに。
おっと、若いの！ そこをどけ！もっとコメントを表示（2）
んなこたーない。
16年以上の開発者だけど、コーディングと設計を繰り返す方が好きだな。コーディングしてると「マジかよ、これ絶対無理じゃん」ってなって、アプローチを根本的に変えざるを得なくなることがよくあるんだよね。
コードを書いてるからこそ「これだ！」って解決策が浮かぶこともあるし。それもまた、アプローチを変えるきっかけになるんだよ。
コードに足を踏み入れた瞬間、計画なんて無意味になる。表面下には何が潜んでるか誰にもわからないんだから。
Greenfieldなら、最初に設計するのは全然ありだけど、それ以外は反復作業一択でしょ。
今のプロジェクトで言うと、俺がまさにその”Dave”なんだよね。最初期からいるエンジニアの一人で、他の人たちはとっくにマネジメントに移っちゃったし。コードのこと全然わかってないことも多いし、30年前に書かれたコードを流用したヤバい場所もあるし。よくあることだけどね。
書き直すための資金を要求したくないから、必死にコードを維持してる。後悔してる選択もたくさんあるし、15年後に誰かが後悔するような選択をしてるかもしれない。それまでに引退したいなー。
若手「この古いコード、マジクソじゃん。昔のやつら仕事できなさすぎ」
5年後「まあ、ひどいけど、何か理由があったんだろうな…」。大体、実装者に相談もせずに新機能が売られたか、影響を確認してないのが原因。だから昨日までに用意しないといけないし、リファクタリングとか整理とかの許可は絶対に出ない。壊れるまではね。
大規模なレガシーコードベースでの反復作業は、レガシーコードベースをさらに大きく、理解不能にするだけだよ。
計画は最初からコードに深く入り込むべき。フロー図を作成したり、プロセスの変更をホワイトボードで議論したりする方が、手探りで変更するよりもずっと良い結果が得られる。
むしろ、Greenfield開発では逆だと思う。反復作業で新製品を構築し、必要に応じて変更を加える方が、ビジネスニーズに結びついたものを理解せずにいじるよりも理にかなってる。
でも、多くの人にとっては大差ないと思うよ。ホワイトボードでアイデアを繰り返すか、コードでアイデアを繰り返すかの違いで、目的は同じ。どっちにしても、最終的な形が決まったら全部捨てることになるんだし。
結局は、どこで自分のアイデアを表現するのが一番快適かってこと。図が好きだったり、コードで考えるのが楽だったり、文章で書き出すのが好きだったり。やり方は人それぞれだけど、最終的には全部同じなんだよね。
これ、マジで強調されるべきだと思う。みんな暗黙の了解だと思ってるけど、忘れられがち。
テストが通ればOKって雰囲気のせいで、コードベースが肥大化することが多すぎるんだよね。ある意味、それが正しい判断なのかもしれないけど。
最終的に大事なのは変更セットそのもの。どうやってそこにたどり着くかは、マジでどうでもいいんだよね。
昔のメンテナーがすぐに対応してくれるわけじゃない限り（何年も前に会社を辞めてる場合が多い）、ゆっくり進むしかないよね。テストスイートがあればそれに頼る。テストに通る小さな変更を提出する。
それにしても、ナイスなユーザー名だね。
俺より10年ベテランのあんたに激しく同意。
ジョークが２つあってさ。
・数ヶ月のプログラミングで数週間の設計が不要になる。
・数ヶ月の設計で数週間のプログラミングが不要になる。
どっちか片方だけが真実だと思ってるのは経験不足。
どっちの状況にいるかを完璧に見抜くのは難しいから、設計と実装を交互に進めるのが一番安全なやり方だよね。
一回だけ書く必要があるなら、書くだけ。
二回書く必要があって、ちょっとだけ違うなら、考える。
三回書く必要があるなら？リファクタリングを検討する。
・１時間の計画で10時間のプログラミングが節約できる…
・そして、１時間の調査で10時間の計画が節約できる。
逆にすることもできる。
・10時間のプログラミングで１時間の計画が節約できる…
・そして、10時間の計画で１時間の調査が節約できる。
もし計画を５人以上で会議してやるなら、時間節約になるかもね…
作者は、成果物としてのコードを書くことよりも広い意味で”プログラミング”を捉えてると思う。俺がやってきた重要な仕事のいくつかは、そもそも何かをやる必要がないってことを主張するために時間を使ったことだったりする。もっとコメントを表示（3）
＞これは、コードを一行も書くずっと前にやるのがベスト。
要件定義を”プログラミング”って呼ぶのは、理由もなく言葉を誤用してるだけだと思うな。ソフトウェア開発に含めるのは全然良いけど、”プログラミング”じゃないじゃん。
スタートアップならそうかもね。大企業だと、要件は指示されるものだよ。誰かが顧客の要望を注意深く考えてて、君の仕事は実装すること。無理な要件なら少し反論するくらいかな。
最初の草案はMVPだけど、最終的な製品の理論に過ぎず、何度も構築する必要がある。
ビジネス要件が変わる可能性もあるから、コードと設計を行ったり来たりしないわけにはいかないんだよ。
Curry–Howard correspondenceに似てるね。
https://en.m.wikipedia.org/wiki/Curry–Howard_correspondence
ソフトウェアエンジニアリングとアーキテクチャでPh.D.取って、実践してるんだけど、デザインは常に実装に遅れてるって気づいたんだよね。アジャイルが主流になってからはデザインツール使う人も減ったし。実際に手を動かす方が早いし、ホワイトボードはUndoないし、自動補完もないし、マジで使えない。詰まっても、とりあえずコード書くと意外とシンプルにできることに気づくんだよね。完成したコードが完成したデザインで、一緒に進化していくんだよ。橋とかロケットとかと違って、ソフトウェアはコンパイルして実行できるコードになるから、デザイン変更も簡単だし。
＞There is no blue print for the blue print for either bridges or software. Not a thing, generally.
＞”橋とかソフトウェアの設計図の設計図なんてないんだよ”
デザインのことかもしれないけど、問題の理解も重要だと思う。理解が深まれば、デザインも自然と良くなるし。ステークホルダーがどう見てるか、何が問題なのか、どんな解決策が受け入れられるのか、将来のステップは何なのか、そういうのを理解することが大事。
- 複雑さを管理したり理解したりすることに誇りはない
複雑さは存在するし、なくすことはできない。管理して理解するしかないんだよ。単純なシステムは複雑さを置き換えるだけだよ。
- Javaは退屈だからこそ素晴らしい言語だ
それは退屈な書き方をした場合の話。多くのJavaのコード（特にSpring）は全然退屈じゃないし、楽しくもない。
- プログラミングのほとんどは、コードを書く前に終わらせるべきだ
僕は逆の極端な考え方をしてる。コードを書いていないなら、プログラミングをしているとは言えない。最初の日からコードを書かないのは時間の無駄だよ。個人的な意見だけど、具体的なことをしないと、現実を見失いやすいと思うんだ。最終的には、機械で動くプログラムを作るんだから。もちろん、そのコードを使い続ける必要はないけどね。
- 正式なモデリングと分析は必須のスキルセットだ
それが最後の点についての僕らの違いを説明するのかもしれないね。機会があれば、形式化するよりも試してみる方が好きだな。形式的なモデリングが役に立たないわけじゃないけど、僕にとっては実験よりも重要じゃないんだ。Don Knuthの言葉を引用すると、”上記のコードにはバグがあるかもしれないので注意してください。正しさは証明しましたが、試してはいません。”
- テストコードにコメントを付けすぎることは絶対にない（誰か試してみてほしい）
time++； // 時間を増やす
