チームが成長しても、アプリケーションアーキテクチャ全体で一貫性を保つにはどうすればよいですか？
スタートアップの唯一の開発者として、私はアプリケーションのアーキテクチャとフレームワークで多くの決定を下すことができるという贅沢を持っていました。
4年間早送りし、その後買収しましたが、5人のチームがあり、多くの場合、それは野生の西のように感じます。設計上の決定を下す人は誰でも喜んでいます。ある場所でのDBタイプの整数と列挙型、別の場所での文字列、問題に対するこのフレームワーク、それから他の場所での同じ問題に対する異なるフレームワークなど。
一貫性を強制するにはどうすればよいですか？それは私にとって重要だと感じていますが、私のチームメンバーは、「うまくいけばうまくいく」方法論に同意しているようです。
私の質問の大部分は次のとおりだと思います：このような標準を期待することは非現実的ですか？私は独創者として出会い、創造性を阻害するが、彼らがやりたいことを何でもすることはスケーラブルではないようだという考えに苦労しています。
あなたは何がそんなに特別なのですか？
私のCPUはそれが機能し、家に帰りたいと言っています。なぜ私を悩ませているのですか？
この態度に対処するには、全員にプルリクエストを発行させる必要があります。しかし今、締め切りが迫っています。悪いコードがあなたの手つかずの城の門を押しつけ、ついにあなたはそのプレッシャーに屈します。または、誰もが去ったことを発見して、誰もあなたの手つかずの城を使用しないことだけを勝ち取ります。
この問題に役立つツールはたくさんあります。ソース管理、コードレビュー、コーディング標準などですが、問題の核心は、何が適切であると見なされるべきかについての主観的な意見です。そのためには、彼らの尊敬を獲得し、維持する必要があります。それをすれば、これはずっと簡単です。それを怠ると、ツールや練習があなたを救うことはありません。
そのための最善の方法は、早期に連絡することです。アイデアが決まった6か月後、「このショップではDBタイプに文字列を使用しません」と言わないでください。ドキュメントに2年間埋め込まれていると言っても、私にそれを許可する正当な理由はありません。
なんらかの理由で気になることがある。それらに関心があり、ポイントがある場合は、すべてのモジュールのコーディングの前、最中、直後にそれらのことを明確に伝えます。
コードストーカーは素晴らしい習慣です。必要なツールやプラクティスに投資して、コードが記述されてから数分以内にコードを確認できるようにします。ペアプログラムとツールは、単なるゲストチェアです。
どうして？コードを書いてから1秒ごとに指数関数的にコードを変更するコストが増加します。それは私のコードの記憶が半減期を持っているからです。私の膀胱が休憩を要求した瞬間、私はそれを忘れ始めます。
あなたが気にしていることをその根本的な原則にまで減らしてください。従うべき101のルールのリストで私を攻撃するのではなく、違反している10の原則を教えてください。自分でルール102がどうあるべきかを理解できます。
私があなたのビジョンを見るのを手伝って、自分のビジョンを押し付ける力を与えてください。
このような標準を期待するのは非現実的ですか？私は独創者として出会い、創造性を阻害するが、彼らがやりたいことを何でもすることはスケーラブルではないようだという考えに苦労しています。
次に、口述しないでください！これを前向きな体験にしてください。これはいくつかの新しい時代のヒッピーナンセンスではありません。それは基本的な心理学です。あなたは人間の行動を修正しようとしています。ランダムでポジティブなものが最も強力です（ラスベガスに聞いてください）。ネガティブになる場合は、補強と一致している必要があります。それは手に負えない痛みです。あなたが知恵を広め、あなたはそれについて何気なくすることができるので、前向きになってください。
私が行ったことがあるので、あなたがどこから来たのか知っています。あなたがコントロールしていて、今ではなくなっています。あなたはそれを取り戻したいです。まあそれを乗り越えます。これでチームができました。それらを制御する必要はありません。彼らに必要なのはリーダーシップです。必要なのはコントロールではありません。それは影響力です。それはよりよく機能し、はるかに少ない作業です。それをマスターしてリラックスしてください。これは楽しいはずです。
それを正しく行うと、休暇に行くことができ、これはまだ機能します。どうやって？リーダーになるだけでなく、他の人たちもリーダーになることによって。チームにビジョンを浸透させれば、あなたが行っていることを真似するだけで、去っていく間に彼らは働くことができます。初心者をメンターし、ステップアップして他の人にも影響を与えるように促します。
私はそれが難しいことを知っています。私たちは人とのやり取りが得意なので、この職業に就くことはしませんでした。コードとのコミュニケーションが最適です。それはいいです。迅速かつ頻繁に実行してください。あなたのほうがいい理由を教えてください。そうでない場合は聞いてください。私がまだ考えている間にこれをしてください。私はコーディングが大好きです。地球上で私が話せる人はほとんどいません。それらの1つになります。
まず、人々が書いていないものを維持するようにしてください。開発者が慣れ親しんだフレームワークや手法を使用する習慣を身に付けるのは非常に簡単です。フレームワークと方法を切り替える必要があるのは不快です。誰かが自分のコードのコーナーの外に移動することを余儀なくされ、それを頻繁に経験する場合、それはいくつかの不満を促し、うまくいけば、何かを標準化しようとする人々につながる可能性のある生産的な議論になります。
次に、プルリクエストとコードレビュー。最初にコードレビューを行わずに、コードをメインブランチにマージしないでください。誰でもできます。繰り返しになりますが、誰かが自分のしたこととは異なる何かを見たとき、より良い解決策にたどり着くために、議論とチームワークを促すことができます。それはまた、誰もがコードベースの世話人になり、（できれば）人々がコードベースとそれに入るコードの状態を気にかけるようになるでしょう。
最後に、設計について話し合います。彼らは公式でも非公式でもかまいませんが、持っています。参加したい人はそうしてください。使用したいフレームワーク、列挙型と整数型の長所と短所などについて話し合います。次に、決定を下し、どこかに文書化します（標準文書など）。次に、問題が発生したときに指摘する必要があります。また、標準の決定を再検討することを恐れないでください。テクノロジーは（迅速に）変化するため、チームや会社としてのニーズも変化します。
人々があなたが見ているものを見て、彼らがコードの品質に関係しているように感じるのを助ける。次に、意見の相違が生じたときに基準を見つけるために、穏やかに議論を進めます。
誰かがコードをメインのブランチ/トランクにマージし、コードをレビューするときに人々をそれらの標準に留めたいと思うたびにコードレビューを実行します。
そして、私はあなただけがコードレビューを行うべきだという意味ではありません。誰もが他の全員のコードを確認する必要があります。これにより、チーム全体でシステムに関する知識が広まるだけでなく、キャロルがボブのコードを確認して、「整数を使用しているようです。常に列挙型を使用しています」と言う状況も生じます。彼らはあなたが見た不一致を発見し、彼らが気にかけていると仮定すると、彼らは誰もが同じページに乗らなければならないことに気づくでしょう。
受け入れられ、合意された標準が出現します。その時点で、それらを文書化し、人々がそれらを確実に遵守するようにします。これには、「DB for ...の列挙型」などが含まれます。使用するフレームワークのドキュメント化なども含めることができます。
可能な場合は、ツール/スクリプトを記述してプロジェクトを自動的に分析し、プロジェクトが使用している標準、ツール、アプローチを決定できます。これを行うには、CIビルドの一部としてカスタムツールを実行します。
ツールの出力を「スコアカード」ドキュメントに書き込みます。ユニットごとの行（「アプリケーション」、プロジェクト、APIなど）ごとに1つの行があり、さまざまな指標/標準の列が続くGoogleシート。これにより、どのような標準があるのか、どの程度適切に採用されているのかなどがわかり、混乱に秩序が与えられます。
手動で列を更新することもできますが、最新の状態に保つようにしてください：D
提供された回答に加えて、インタビューしている瞬間から始めて、ソフトウェア開発の専門家としてチームに期待することをチームに教育するべきだと私は言います入社する。
1-コードベースの規則を作成して従います
これは、コード品質を向上させるために採用できる最も基本的でありながら有益な手段の1つです。以下の規則の結果として、ソースコードはコードベース全体で統一され、コードファイルの検索と読み取りに関する認識の労力が軽減されます。
2-明確なソフトウェアアーキテクチャを実装する
明確なアーキテクチャスタイルに従わないソフトウェアプロジェクトのコードベースは、新しい非構造化コードが追加されるにつれて徐々に劣化し、変更が難しくなります。したがって、適切なソフトウェアアーキテクチャの設計と保存に時間を費やすことの重要性。
3-少ないほど良い：言語、フレームワーク、ツール
システムに導入する言語、フレームワーク、ツールを追加するたびに、追加の開発コストと運用コストが発生します。短期的な問題を解決する前に、技術的な決定の長期的なコストを常に評価する必要があります。冗長なテクノロジーを避け、現在のスタックを最大限に活用してください。
4-システム設計の決定にチームを関与させる
共有ナレッジ環境を構築する最も効果的な方法は、システム設計のすべての決定にチームを関与させることです。利点はたくさんあります：
- 個人はチームの一員であると評価されていると感じています
- 重要な決定は、行われる前にチーム全体によって挑戦されます
- システム設計の長所と短所が誰でもより明確に理解される
- 集団的な説明責任と信頼感を生み出します
5-オールインルール
私は、システム設計のリファクタリングの取り組みは、部分的に完了するのではなく、完了するまで（オールイン）実施する必要があると考えています。開発者が適切と思われるときにいつでも異なるコーディングスタイルとアーキテクチャパターンをローカルに自由に適用すると、システム設計を侵食する大きなリスクがあります。
この時点で、前の提案を正常に実装した場合、チームはおそらくこの悪質な開発者の行動を専門外で無責任だと評価します。
私は最近、この件についてブログ投稿を書いています。これらのトピックに関する詳細情報は、そこにあります： https://thomasvilhena.com/2019/11/system-design-coherence