→読み物
- 開発人生25年で学んだ7つのソフトウェア原則（翻訳）｜TechRacho by BPS株式会社 2025.6
- 1.どんなフレームワークもいつか身の丈に合わなくなる: フレームワークは最初は便利だが、コードの成長とともに限界が見えてくる。独自のアーキテクチャ上の決定を下せるようにする必要がある。
- 2.デザインパターンや方法論は、やがて通用しなくなる: どんなに優れたデザインパターンや方法論も、プロジェクトの成熟や技術的課題の変化によって時代遅れになることがある。
- 3.規模は時間とともに常に拡大する: プロジェクトは肥大化し続けるため、初期の頃の方法が通用しなくなるのは自然なこと。
- 4.「ストーリー」に注目するべし: ソフトウェアの機能が出現するまでのナラティブ（物語）に着目する。全体像だけでなく、個別のストーリーを大切にする。
- 5.目指すべきは「真実」と「明快さ」である: 開発者としての最終目標は真実と明快さを追求すること。そのためには、ストーリーに耳を傾けることが重要。
- 6.孤立を味わう可能性がある: 真実のストーリーにこだわる者は、周囲との意見の相違から孤立感を抱くことがある。
- 7.それでも真実の追求を諦めないこと: どんなにつらくても、知識を追い求め、世界観を修正し、問いを発し続ける。ソフトウェア作者は作家であり、率直にストーリーを伝えることを心がける。
- プログラミング地獄への道は“ベストプラクティス”で敷き詰められている 2013.1.15
- 抽象化や抽出（メソッドやクラスを独立させるようなことでしょうか）、あるいはアーキテクチャー（デザインパターンのようなものでしょうか）といったもので、存在自体がイケてないものというのはほとんどない。「善意」と同じで、「ベストプラクティス」に、それそのものが悪いものというのはない。ただ、必要性がないのに適用されたベストプラクティスは、ほとんどすべて悪である――。これがDHHの指摘です。
RFC†
Podcastコンテンツ†
Last-modified: 2026-05-22 (金) 23:30:11
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
