#note > プログラマがドメインに興味を持っていなければ、プログラマはアプリケーションが何をすべきかだけを調べ、その背後にある原理には注意を払わない。そうしたやり方でも、使えるソフトウェアを構築することはできるが、そういうプロジェクトは、既存機能の必然的な帰結として強力な新機能が現れるという段階には、決して到達することができない。 [[ドメイン駆動設計]] 第一章 「知識の噛み砕き」 > ソフトウェアを書き始める時、我々は対象を十分に理解しているわけではない。... つまり我々は、自分たちがどれほど理解していないかを認識していないのだ。こうした無知のせいで誤った想定をしてしまうのである。 [[ドメイン駆動設計]] 第一章 「知識の噛み砕き」 > 発見の旅はどこかから始めなければならないのだ。 [[ドメイン駆動設計]] 第一章 「知識の噛み砕き」 > コードがひどい状態のため、本来なら数時間で終わるような仕事に数週間かかった経験がありませんか？1行変えればよいことなのに、数百モジュールの変更が行われているのを目にしたことはありませんか？こうしたことはとてもよく目にします。 > どうしてコードには、このようなことが起きるのでしょう？洗練されたコードは、どうしてこうも早く粗悪なコードへと変質してしまうのでしょう？いくつもの言い訳があるでしょう。元々のデザインが想定されていないような要件の変更が行われたとか、開発作業をまっとうに進めるにはスケジュールがきつ過ぎるであるとか。我々は、まぬけな管理者と、頑ななお客様、無駄なマーケティングタイプや、電話消毒について嘆くのです。しかしディルバートよ、間違っているのは、我々の星廻りではなく、我々自身なのです。これでは我々はプロとは呼べないのです。 > … > 我々はプロジェクト開始時点から共犯者であり、あらゆる失敗に対して共同責任があります。特にその失敗が、粗悪なコードによるものだったら！ [[Clean Code]] > 短期的にも長期的にも崩壊したコードを書く方が常にクリーンなコードを書くよりも遅い [[Clean Code]] > Good intention doesn't work , only mechanism works. Amazon > "Two-way-doors" > Some decisions are consequential and irreversible or nearly irreversible -- one-way doors -- and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before. We can call these Type 1 decisions. > > But most decisions aren't like that -- they are changeable, reversible -- they're two-way doors. If you've made a sub-optimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups. > > As organizations get larger, there seems to be a tendency to use the heavyweight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We'll have to figure out how to fight that tendency. > One-way door decisions are irreversible, so make them slowly. Two-way door decisions are the opposite. Since you can go back on them, you should make them quickly. ref: [https://www.inc.com/jeff-haden/amazon-founder-jeff-bezos-this-is-how-successful-people-make-such-smart-decisions.html](https://www.inc.com/jeff-haden/amazon-founder-jeff-bezos-this-is-how-successful-people-make-such-smart-decisions.html) > When you're driving any technical practice, any technical change, focus on the problems first, and make sure you can lead by example, make sure that you know what you're talking about. Because if you are not good at what you are trying to convince other people to do, that's a very big chance that you're going to fail. [https://techleadjournal.dev/episodes/25/](https://techleadjournal.dev/episodes/25/) > Software that fits in your head [[Software that Fits in Your Head • Dan North • GOTO 2016]] > ベストな「How」は「Why」でしか規定できない [https://speakerdeck.com/mercari/0924-bold-challenge-at-deeeet](https://speakerdeck.com/mercari/0924-bold-challenge-at-deeeet) [https://logmi.jp/tech/articles/322218](https://logmi.jp/tech/articles/322218) > よい設計は悪い設計よりも変更しやすい > 我々が知る限り、この世のあらゆる設計原則は ETC (Easier to Change) 原則を特殊化したものとなっています 達人プログラマ第二版 Tips14 > ソフトウェアは「変化し続ける要求」と「戦略的ではない依存の追加や変更」によって腐っていく [[Design Principles and Design Patterns]] > ソフトウェアの複雑性は、「依存」と「曖昧さ」によって引き起こされる [[A Philosophy of Software Design]] > 理想的な構造的な設計は、結合度を低くし、凝集性を高めることである [[Comparing techniques by means of encapsulation and connascence]] > 複雑な問題を完全に詰め込めるほど大きな脳を持った人はいない by Edsger Dijkstra [[Code Complete]] 上 第7章 高品質なルーチン > これらの意見はどちらも短絡的で、ルーチンのインターフェイスが表す抽象概念とは何かという最も重要なポイントを見逃している。 > ルーチンは３つの要素が渡されることを期待していて、それらがたまたま同じオブジェクトによって提供されることが抽象化であるというなら、3つのデータ要素を個別に渡すべきだろう。 > しかし、常に特定のオブジェクトが存在し、ルーチンがそのオブジェクトを使って何かをすることが抽象化であるというなら、3つのデータ要素を公開した時点で、抽象化を崩壊させることになる。 [[Code Complete]] 上 第7章 高品質なルーチン > パターンがより最悪の自体を招いたケースをある。 > 人々が本を読んで紹介されているパターンにワクワクしてまるで適用すればするほど良いソフトウェアになる魔法のように感じてしまった。 > 本来であれば、それらのパターンがどこで使用されるべきか、それらを使用する正しい方法は何か、そしてそれらをどのように適応させるかを理解する必要があるにも関わらず。 [https://www.se-radio.net/2014/11/episode-215-gang-of-four-20-years-later/](https://www.se-radio.net/2014/11/episode-215-gang-of-four-20-years-later/) > あるプラクティスがなぜワークするのかを理解することなく、耳かきをしながらプロジェクトが無事に成功することを願っているだけである。 > カーゴカルト な ソフトウェアエンジニアは、「我々はいつもこのやりかたでやってきた。」、「我々の会社の標準はこの方法であり。」と言って意味のないようなプラクティスを正当化する。 [https://stevemcconnell.com/articles/cargo-cult-software-engineering/](https://stevemcconnell.com/articles/cargo-cult-software-engineering/) > "ジョシュアツリーの法則" > 名前を言えるようになったとたんに、いたる所でそれを見るようになりました [https://ktr-05.hatenablog.com/entry/2019/07/07/184436#ジョシュアツリーの法則](https://ktr-05.hatenablog.com/entry/2019/07/07/184436#ジョシュアツリーの法則) > 若かりしころすべての業務で統一されたモデルを作ることとアドバイスされた。しかし DDD でわかったことは統一されたモデルは大規模なシステムにおいて不可能か費用対効果に見合わないことがわかった。 [[ドメイン駆動設計]] > Don't present a question without an answer. > A frequent piece of advice given to new leaders is to "never bring your manager a problem without a solution." That's not generally great advice, but if you present a problem to an executive without a proposed answer, then in the back of their mind, they're wondering if they need to hire a more senior leader to supplement or replace you. You can't create alignment in the room unless you have a proposal for folks to align behind. [https://lethain.com/present-to-executives/](https://lethain.com/present-to-executives/) > Hyrumの法則 > あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様としてなにを約束しているかは重要ではない。作られたシステムがもつあらゆる観察可能(observable)な挙動に関して、それに依存するユーザーが出てくるものである。 [[Googleのソフトウェアエンジニアリング ――持続可能なプログラミングを支える技術、文化、プロセス]] > (実験) には2つの結果がある。もし結果が仮説を確認したなら、君は何かを計測したことになる。もし結果が仮説に反していたら、君は何かを発見したことになる。 エリンコ・フェルミ ( [[イシューからはじめよ]] の P140 に掲載 )