チームの成長に伴い、アプリケーションアーキテクチャ全体で一貫性を保つ方法

スタートアップの唯一の開発者として、私はアプリケーションのアーキテクチャとフレームワークで多くの決定を下すことができた贅沢がありました。

4年前に早急に買収し、5人でチームを組みました。多くの場合、ワイルドウエストのように感じます。設計上の決定をする人は、彼らを喜ばせます：1つの場所でDB型の整数と列挙、別の場所で文字列、問題のこのフレームワーク、次に同じ問題の別のフレームワークなど。

一貫性を強化するにはどうすればよいですか？それは私にとって重要だと感じていますが、私のチームのメンバーは「うまくいけばうまくいく」方法論に加入しているようです。

私の質問の大部分は、このような標準を期待することは私にとって非現実的ですか？独創性を抑える独裁者として出会うというアイデアに苦労していますが、彼らがやりたいことはスケーラブルではないようです。

何があなたをそんなに特別なのですか？

私のCPUはそれが機能していると言い、私は家に帰りたい。なぜ私を悩ませていますか？

全員にプルリクエストを発行させることで、この態度に対処できます。しかし今、締め切りが迫っています。悪いコードが手つかずの城の門を押し、あなたはついに圧力に屈します。または、あなたは誰もが去り、誰もあなたの手つかずの城を使わないようにするためだけに勝ちます。

この問題を解決するツールはたくさんあります。ソース管理、コードレビュー、コーディング標準などがありますが、問題の核心は、関連性があると見なされるべき最善のものについての主観的な意見です。そのためには、尊敬を獲得し、維持する必要があります。それを行うと、これははるかに簡単です。それを怠ると、ツールや練習があなたを救うことはありません。

そのための最善の方法は、早期にコミュニケーションを取ることです。アイデアに決まった6か月後、「このショップではDBタイプに文字列を使用していません」と言わないでください。それが2年間ドキュメントに埋もれていると言っても、それをさせた理由はありません。

なんらかの理由で、あなたが気にかけているものがあります。あなたがそれらを気にし、すべてのモジュールのコーディングの前、最中、直後にそれらの事柄を明確に伝えるようにします。

コードストーカーは素晴らしい習慣です。必要なツールやプラクティスに投資して、コードを作成してから数分以内にコードをレビューできます。ペアプログラムとツールは、単なるゲストチェアです。

どうして？コードを記述してから1秒が経過すると、コードを変更するコストが指数関数的に増加します。私のコードの記憶には半減期があるためです。私は膀胱が休憩を要求した瞬間にそれを忘れ始めます。

あなたが気にすることをその根底にある原則に減らしてください。従うべき101のルールのリストを私に当てるのではなく、それらが違反している10の原則を教えてください。そうすれば、自分でルール102がどうあるべきかを理解できます。

私はあなたのものを見るのを手伝うことによって私自身のビジョンを課す力を与えてくれます。

このような標準を期待するのは非現実的ですか？独創性を抑える独裁者として出会うというアイデアに苦労していますが、彼らがやりたいことはスケーラブルではないようです。

口述しないでください！これを前向きな体験にしてください。これは、新しい時代のヒッピーなナンセンスではありません。それは基本的な心理学です。あなたは人間の行動を修正しようとしています。ランダムでポジティブなものが最も強化されます（ラスベガスに聞いてください）。ネガティブになれば、あなたはあなたの援軍と一致しなければなりません。それは手に負えない痛みです。知恵を広め、それについて気楽に過ごせるように前向きになってください。

私はそこにいたので、どこから来ているのか知っています。あなたはコントロールを持っていて、今ではなくなっています。あなたはそれを取り戻したい。まあそれを乗り越えます。これでチームができました。それらを制御する必要はありません。彼らに必要なのはリーダーシップです。必要なのはコントロールではありません。それは影響です。それはより良く働き、はるかに少ない仕事です。それをマスターしてリラックスしてください。これは楽しいはずです。

それを正しくすれば休暇に行くことができ、これはまだ機能します。どうやって？リーダーになるだけでなく、他の人もリーダーになるようにします。チームに自分のビジョンを植え付けたら、あなたが行っていることを真似するだけで、あなたがいなくても彼らは働くことができます。初心者にメンタリングを行い、他の人にもステップアップして影響を与えるように勧めます。

難しいことを知っています。私たちは人々に対処するのが得意なので、この職業には行きませんでした。私たちは、コードと最もうまくやり取りします。それはいいです。ただそれを頻繁に行うだけです。あなたの方が優れている理由を教えてください。そうでないと言ったら聞いてください。私はまだそれについて考えている間にこれを行います。私はコーディングが大好きです。地球上で私が話すことができる人はほとんどいません。それらの1つになります。

まず、人々が書いていないものを維持するようにします。開発者は、慣れているフレームワークとテクニックを使用する習慣を身に付けるのは非常に簡単です。フレームワークと方法論を切り替える必要があるのは不快です。誰かがコードの自分のコーナーの外に移動することを余儀なくされ、それを頻繁に経験すると、不満を抱き、できれば何かを標準化したい人につながる生産的な議論を促すでしょう。

次に、プルリクエストとコードレビューを行います。最初にコードをレビューせずに、コードをメインブランチにマージしないでください。誰でもできます。繰り返しになりますが、誰かが自分がしたこととは異なることを見たとき、より良い解決策を求めて議論とチームワークを促すことができます。また、誰もがコードベースの管理者になります。これにより、（願わくば）人々がそれとコードに入る状態を気にするようになります。

最後に、設計について話し合います。正式なものでも非公式なものでもかまいませんが、持っています。参加したい人はそうさせてください。使用するフレームワーク、列挙型と整数型の長所と短所などについて話し合います。その後、決定に至り、それをどこかに文書化します（標準文書など）。次に、問題が発生したときにポイントするものがあります。また、標準の決定を再検討することを恐れないでください。テクノロジーは（急速に）変化するため、チームおよび企業としてのニーズも変化します。

あなたが見たものを見て、彼らがコードの品質に関係しているように感じるように人々を助けます。その後、意見の相違が生じた場合に標準を見つけるための議論を優しく行います。

誰かがコードをメインブランチ/トランクにマージするたびにコードレビューを実行し、コードをレビューするときに人々をそれらの標準に合わせます。

そして、私はあなただけがコードレビューを実行すべきだという意味ではありません。全員が他の全員のコードを確認する必要があります。これにより、システムに関する知識がチーム全体に広まりますが、キャロルがボブのコードを確認して、「そこに整数を使用しているようです。常に列挙型を使用します」という状況も生じます。彼らはあなたが見た矛盾を発見し、彼らが気にかけていると仮定すると、誰もが同じページにアクセスしなければならないことに気付くでしょう。

承認され、合意された標準が出現します。その時点で、それらを文書化し、人々がそれらに従うことを確認します。これには、「…のDBの列挙」などが含まれます。また、使用するフレームワークなどの文書化を含めることもできます。

可能な場合は、ツール/スクリプトを記述して、プロジェクトを自動的に分析し、プロジェクトが使用している標準、ツール、アプローチを決定できます。これを行うには、CIビルドの一部としてカスタムツールを実行します。

ツールからの出力を「スコアカード」ドキュメントに書き込みます。たとえば、単位ごとの行（「アプリケーション」、プロジェクト、APIなど）ごとのgoogleシート、さまざまなメトリック/標準の列が続きます。これにより、人々はどのような標準があるか、どのように採用されているかなどを可視化し、カオスに何らかの秩序を与えます。

列を手動で更新することもできますが、幸運にもそれらを最新の状態に保つことができます：D

提供された回答に加えて、ソフトウェア開発の専門家として彼らに期待することを、彼らが会社に参加するためにインタビューしている瞬間からあなたのチームを教育すべきだと言います。

1-コードベースの規則を作成して従う

これは、コード品質を改善するために採用できる最も基本的かつ有益な手段の1つです。次の規則の結果、ソースコードはコードベース全体で統一され、コードファイルの検索と読み取りの認知的作業が軽減されます。

2-明確なソフトウェアアーキテクチャを実装する

明確なアーキテクチャスタイルに従わないソフトウェアプロジェクトのコードベースは、それが何であれ、新しい非構造化コードが追加されると徐々に劣化し、修正が難しくなります。したがって、適切なソフトウェアアーキテクチャの設計と保存に時間を費やすことの重要性。

3-少ないほうが良い：言語、フレームワーク、ツール

システムに導入する言語、フレームワーク、およびツールが追加されるたびに、追加の開発および運用コストが発生します。短期的な問題を解決する前に、技術決定の長期コストを常に評価する必要があります。冗長なテクノロジーを避け、現在のスタックを最大限に活用してください。

4-システム設計の決定にチームを関与させる

共有ナレッジ環境を構築する最も効果的な方法は、すべてのシステム設計の決定にチームを関与させることです。利点はたくさんあります：

• 個人は尊敬され、チームの一員であると感じる
• 重要な決定は、行われる前にチーム全体によって挑戦されます
• システム設計の長所と短所は誰でもより明確に理解されます
• 集合的な説明責任と信頼感を生み出します

5-オールインルール

私は、システム設計をリファクタリングする努力は、部分的に結論づけられるのではなく、完全に（オールインで）行われるべきであるという見解を持っています。開発者が適切と判断したときにいつでも異なるコーディングスタイルやアーキテクチャパターンをローカルに自由に適用できる場合、システム設計を損なう大きなリスクがあります。

この時点までに、以前の提案を正常に実装できた場合、チームはこの不正な開発者の行動を非専門的で無責任であると評価するでしょう。

このテーマに関するブログ記事を最近書いたので、これらのトピックに関する詳細な情報を見つけることができます：https : //thomasvilhena.com/2019/11/system-design-coherence