この半年、私は5年前に作成したTasmapの商品化に多くの時間を費やし、また5年前の自分がどのようにアーキテクチャを設計し、プログラムを実装したかを見直しました。ここに私の考えをいくつか記録します。
メタは非常に重要
今から見ると、私の原則と考えは正しかったと言えます。より洗練させ、細分化できる部分はいくつかありますが、核心的な思考の信頼性のおかげで、5年経った今でも「え？なんだこれ？何やってたんだ？」と疑問に思うことはありません。自分自身のメタを整理することは非常に重要だと考えます。これは、困難に直面した際に安定した核となり、新たに学んだ経験に基づいて一歩一歩それを拡張していく助けとなります。
あなたも自分自身のメタを持つべきです。
時代における「ベストプラクティス」は重要ではない
今振り返ると、5年前に書いたコードは当時の「ベストプラクティス」でしたが、現在の視点から見直すと、もはや「モダンなパターン」ではありません。「ベストプラクティス」と呼ばれるものを使用する際には、「なぜ？」を明確に理解しなければなりません。そして、他人の言葉ではなく、自分の直感とセンスを信じるべきです。近年（特に2020年以降）、技術界は非常に商業化し、あらゆる種類の誇張、誇大広告、マーケティングが非常に深刻になっています。選択を行うためには、優れた「技術リテラシー」が必要です。投資と同様に、他人の言葉に踊らされて行動すれば、大抵はカモにされるのがオチです。
私はバフェットの原則の一つである「私は理解できないものには投資しない」という言葉がとても好きです。これは技術選定においてはさらに重要です。なぜなら、技術環境はより閉鎖的で理性的な環境であり、ファンダメンタルズの要素が認知面よりもはるかに大きいからです。二つの原則があります：
理解していない技術は使用しない。それがどのように動作するのか大体理解していなければ、使わないでください。 原理的に問題があれば、実際にも問題があります。コンピュータサイエンスに黒魔術はありません。
「Dirty digest is fine」という言葉を覚えています。Angular 1は、私に輝かしく見える技術の権威たちを疑うことを教えてくれました。
ファンダメンタルズと市場面
投資にはファンダメンタルズと市場面がありますが、技術選定、フレームワーク、ライブラリ、アーキテクチャ設計、コードスタイルにも同じ判断枠組みを適用できます。ファンダメンタルズとは、物事の技術的原理や、いくつかの客観的指標（例えば時間計算量、空間計算量、限定的な状況でのテスト結果）を指し、市場面とは、チームリソース、人材市場、作者、人気度などを指します。ファンダメンタルズが市場面をはるかに上回る場合、成長の余地は限られています。市場面がファンダメンタルズをはるかに上回る場合、それは誇大広告（バブル）です。
バランスとトレードオフが重要です。
車輪を再発明しよう
以前は「車輪の再発明をするな」とよく言われましたが、現代においては、車輪を自分で再発明すべきだと考えています。最大の理由はAIです。多くの確立され安定した実装（例えばインメモリキャッシュ、画像コンポーネント）は、以前はベテランにとっては骨の折れる作業であり、新人にとっては訓練の場でしたが、今ではAIによって簡単に完成させることができます。自分で車輪を再発明する利点は、100%のコントロールと100%のカスタマイズ能力です。このライブラリが完全に自分のニーズに合わせて作られていることを保証でき、欲しいものは何でも追加でき、おかしな理由（ライセンスがプライベートになったり、奇妙なものが仕込まれたりするようなこと）で問題が発生することもありません。
公式見解に対する私の不信感がAngular 1から来ているとすれば、オープンソースプロジェクトに対する不信感はAnt Designから来ています。その日の朝食のおにぎりを半分しか食べずに、半日かけてダッシュボードに「ささやかなおまけ」を仕込んだのは誰かを探していたのを覚えています。
防御的モジュール設計
長期的なプロジェクトにとって、モジュール設計の重点は拡張性や再利用性ではなく、防御性かもしれません。ここでの防御性とは次のことを指します：
- 将来の変更を予防する。
- 制御不能なエラーを予防する。
大原則は：モジュールは常に予測可能な結果を出力すべきです。モジュールの境界は、モジュール内部の制御不能なエラーや変更を効果的に制御できるべきです。この目的が達成されれば、モジュール間の実装の不一致は許容可能であり、時にはリスク分散の手段となることさえあります。
一貫性は有害である
近年、「一貫性」が非常に人気のあるバズワードになっていることに気づきましたが、それが肯定的な効果をもたらしているのを見たことがありません。ほとんどの場合、いわゆる一貫性は「お前はこうやれ」というやり方を押し付けるために使われています。
いつもの言葉ですが、まず「なぜ？」と問いかけてください。なぜ一貫性が必要なのか？一貫性はどのような肯定的または否定的な結果をもたらすのか？この一貫性はこの環境に適しているのか？完璧で欠点のない理想的なコードベースを追求し、「一貫性」に強い欲求を持ち、最終的に製品とチーム全体を破壊する多くの「アーキテクト」を見てきました。アーキテクトだけでなく、支配欲の強い多くの管理者もこの欠点を持っており、そのような場面では一貫性が攻撃の「大義名分」となります。
いくつかのものには一貫性が必要です：企業の文化的原則とビジョン、製品の北極星。しかし、その他のもの、特にコードスタイルなどの下層の実装については、過度な一貫性の要求はチームに無意味な束縛を負わせ、争いを引き起こすだけです。あなたが使うべきものは「原則」、あるいは私が最初に述べた「メタ」であり、一貫性ではありません。
私は数年前の自分とさえ一貫性を保てません。
技術的負債は負債ではない
技術的負債は非常に一般的な概念であり用語ですが、これは実際には誤った類推的認知を引き起こします：「借金」は良くないものであり、返済しなければならない、と。その結果、チームはいわゆる「技術的負債」をめぐって多くの紛争を引き起こします：いつ借金を返すのか、誰が借りたのか、誰が返すのか、など。実際には、プログラム上のトレードオフは負債とは異なり、むしろ戦略的な配置に近いです：人的資源、タイミング、投入期間などの要因です。重要なのは、この選択がどの時点でどのような結果をもたらすかを明確に理解しているかどうかです。
技術的負債が負債ではないもう一つの理由は、多くの場合、技術的負債は返済する必要がないということです。あるモジュールが常に正常に動作するならば、その中身がどうであろうと、王重陽が書いたのかゴブリンが書いたのかは気にしません。「返済不要な技術的負債をどう活用するか」は非常に興味深い考え方です。
AIの邪魔をするな
Tiatには、「描画による画像検索」という機能があります。簡単に言うと、キャンバスが与えられ、ペイントソフトのように落書きをし、その落書きによって画像を検索するというものです。この機能を実現するために、私はCV（コンピュータビジョン）分野の関連知識を研究するのに多くの時間を費やしました。昨年、「苦い教訓」という記事が最近のCVの発展について論じていました：人間の専門知識が訓練時の障害となり、全てをモデル自体に任せた方が効果的である、と。
これは私にあることを考えさせました：私たちのプログラミングスタイル、アーキテクチャ設計、ベストプラクティスもまた、障害になるのではないでしょうか？AIは本来より良い実装を生み出せたかもしれないのに、私たちが加えたいくつかの制約や指導に合わせることで、かえってその能力の発揮を制限してしまったのではないでしょうか？
現在の主流意見は、人間はより高レベルのアーキテクチャ設計や要求変換に長けており、その後、下層の実装をAIに任せるというものです。しかし私が考えているのは、この前提は人間が不平等な入力情報量を持っているということに基づいているということです。入力情報量が同じであるか、AIにとってより効果的な入力方法が見つかれば、人間の高レベルなアーキテクチャ設計は依然として優位に立つのでしょうか？
数ヶ月前に「AI優先のアーキテクチャ設計」を試みましたが、結果は失敗でした。しかし、その過程は非常に興味深かったので、機会があれば皆さんと共有したいと思います。
現実を拡張する魔法
アプリケーションは一種の魔法であり、現実を拡張する魔法です。魔法の本質は「心の中の考えを実現する」ことです。百万枚の画像をスムーズに閲覧したい、全てのファイルを全自動で整理したい、MarkdownでMediumの記事を書きたい、美しい地図を作成したい。アプリケーションは魔法であり、魔法はあなたの内なる考えを実現するためのものであり、考えは生活の中で育まれます。体験し、感じ、考え、交流すること。そうして初めて、退屈な火の玉の術を、感動的な花火に変えることができるのです。