CTOのポエム（下記リンク）はどちらかというと「個々人が意識すべき行動指針」という意味合いが強いものです。対して、このチーム指針遍は名前のとおり「チームで技術的な意思決定を行う際の指針」を記したドキュメントです。
tech.commmune.jp も読んでね
安定稼働とパフォーマンス
相反するものを高い次元で両立する、コミューンエンジニアチームの究極目標です。
例）
安定稼働：バグが少ない、サーバの可動率が100%
パフォーマンス：通信時間が短い、サクサク動く
明日のためではなく、２年後のために
チームで技術的な判断をするとき「2年後」を予想して決めましょう。 （下記は一見否定的に見えますが熟考の結果、採用に至る、という結論でももちろん良いのです）
- スター数が50くらいで開発がすでに止まってしまったライブラリを採用したとしましょう。 2年後にどのくらいの確率でそのライブラリが「負債」になっているでしょうか。
- 逆に、1週間前に登場したばかりで今の所評判も上々のライブラリを採用したとしましょう。 2年後にメンテナンスが続いている自信はありますか。 一時の流行で終わってしまいませんか。
- 日本でのみ爆発的に流行したVue.jsを採用したとしましょう。 2年後にNext.jsとVue.jsのコミュニティ、どちらが大きくなっているでしょうか。
- コミューンの新プロダクトを作ることになり、思い切ってGo言語を採用したとしましょう。 TypeScriptとGo言語で知見は共有できますか。十分な人材の確保はできるでしょうか。
これは設計やリファクタリングも同じです。誤解を生まないように但し書きをすると 「２年後に必要になるかもしれない」ものを今作る、ということではありません。それは作りすぎの無駄です。どちらかというと「将来の変化を見越して」今最低限必要な準備をしておく、というイメージです。
どんな技術を使うかより、どう運用するかのほうが10倍大切
エンジニアであれば新しい技術を好むことを私は理解しています。 ここでお伝えしたいのは「いたずらに枯れた技術を使え」ということではなく 「開発はチームで行うもの」ということです。例えば…
あなたは関数型プログラミングが得意。一方チームのメンバーも同じように得意でしょうか。 あなたはユニットテストの識者。一方チームのメンバーも同じように博識でしょうか。
もちろん、新しく世に出てくる技術は良い面も多くあります。 しかし、「技術的に優れていること」とそれを「チーム全体で正しく運用できること」は別物です。陳腐な技術でも正しく運用できることのほうが大切であるし、効果が出ます。
「あなた」にとってベストであるか、と同時に「チーム」にとってベストであるか、 双方の視点から判断しましょう。
大規模開発ではドキュメンテーションが命である
口で説明する暇があるなら、まずteamwikiに書いてからにしましょう。
キャッシュは伝家の宝刀
今のcommmuneはフロントエンドがかなりステートレスに近い構造になっています。 パフォーマンスをある程度犠牲にしてバグの少なさを優先している。という見方も可能です。
例えばページ遷移の際はstoreにデータがあろうが無かろうが、必ず最新の情報をfetchしなおしています。また、API通信のレスポンスも一切ブラウザキャッシュに乗せておらず常に200でデータを返しています。
この辺りは安定性（バグの少なさ）をより重視するという、現在の技術的な戦略故です。 「キャッシュは麻薬」というのは言いすぎですが、安易にキャッシュを導入して パフォーマンスアップを狙うのは木を見て森を見ずに繋がりやすいですし、 本当のボトルネックを隠蔽する危険もあるので意識的に避けています。
