Building for the Long Term

長期的な構築

枠組みも変わっていきます。データベースが変更されます。生き残れるのはあなたの思考の明晰さです。

数年ごとに、業界は私たちが行ってきたことはすべて間違っており、より良い方法があると集団的に決定します。新しいフレームワーク、新しいパラダイム、新しい構築ツール。チャーンは容赦なく行われるため、注意しないと構築よりも移行に多くの時間を費やしてしまいます。

私はソフトウェアを長く書いてきたので、こうしたサイクルをいくつか経験してきました。 jQuery、Backbone、Angular を経て、次に来るものに反応します。当時はそれぞれの移行が緊急に感じられました。振り返ってみると、実際に重要なことはフレームワークに関するものではありませんでした。

何が生き残るのか

クリーンなデータ モデルは生き残ります。システム間の明確な境界は存続します。良いネーミングは生き残る。物事を賢くすることもできたにもかかわらず、物事をシンプルに保つという決断は、間違いなく生き残ります。

生き残れないのは、印象を残すために書かれたコード、実現しなかった問題のために構築された抽象化、ドメインの現実ではなくフレームワークの意見に基づいて設計されたアーキテクチャです。

私が書いた最高のコードは退屈です。散文のように読めますが、1 つのことをうまく実行しており、理解するのに圏論の博士号は必要ありません。私が書いた最悪のコードは、当時技術的には印象的でした。

💬 Discussion 1
Guest
Avatar
  • 池田 直樹 (collapsed)
    「長期的な構築」の解説記事をリードエンジニアに見せたら、画面を20s間無言で見つめたあと、何も言わずに本日4杯目のコーヒーを淹れに行きました。これは承認と受け取っていいのでしょうか、それとも助けを求めているサインでしょうか??
    0