私のマネージャーは最近私を「ソフトウェアデザイナー」に昇進させました。このタイトルが存在することを知りません。私の知る限り、SAは高レベルのコード設計を作成し、図を作成します。

高レベルのコード設計を理解するのに苦労しています。私のマネージャーによると、すべてのクラスとそれらのクラス内のすべてのメソッドを設計する必要があります。つまり、コード構造全体を設計し、チームに各関数またはクラスの機能を実装させます。たとえば、CRUDシステムでは、どの関数を使用するか、どのクラスを作成するかを計画できるはずです。

私のソフトウェア設計の経験を考えると、これを実行することは非常に不可能であることがわかりました。開発者として、私は常に自分のクラスを作成し、自分の関数を定義して実装しています。他の人のために機能を設計した経験はありません。

私の質問は：

• これは一般的ですか？非常に大規模なシステムの場合、コードベースは常に変更されませんか？
• これはできますか？

ここでは明白で愚かな質問をしているのかもしれませんが、私はこれまで常に正規の開発者であり、システム全体の設計経験はありません。

タイトルに関する予備的な注記：

• 時々、あなたが本当にやっていることは、あなたの公式タイトルと全く一致しません。一例として、私は数年前、「研究開発部門のアナリストプログラマー」として雇われました。ただし、誰も、分析もプログラミングも研究も開発も採用しませんでした。私（および他の人）が実際に行ったのはコーディングです。サルは私がしたことの半分をすることができました。学部生は、残りの半分を行うことができます。

• 多くの場合、タイトルは重要ではありません。一部の企業では、結局、多くの異なる多様なタスクを実行することになり、そのすべてを説明するタイトルがないだけです。ある会社では、アーキテクト、チームリーダー、マネージャー、UX担当者、コーダー、生産性スペシャリストのタスクを実行し、2つのチームが互いに正しく通信していることを確認していました。そのための単一のタイトルはありません。

• 最後に、タイトルは会社ごとに異なる意味を持つ可能性があります。または、タイトルを最初に付けた人々は、タイトルの実際の意味があったとしても、それについて少しも理解していません。場合によっては、流行のタイトルと流行語があるだけです。昔ながらのシステム管理者は必要ありません。DevOpsスペシャリストが必要です。誰かを雇うときにビジネスインテリジェンスやデータマイニングについて話すのではなく、ビッグデータについて話すのです。

タイトルを忘れて、正確に何を求められたかに集中してください。幸いなことに、あなたの質問はまさにそれを行います。

これは一般的ですか？非常に大規模なシステムの場合、コードベースは常に変更されませんか？

私はそれを見たことがなく、それが持続可能であるとは信じていません。

これはできますか？

はい、しかし、チームを去る通常の人々を犠牲にして。

上司が頭に思い浮かぶのは、設計を行い、それをUML図の形式で提示することです。それは昔ながらですが、誰が気にしますか？この慣行は一部の企業では非常に人気があり、それでも他の企業ではまあまあうまく機能しています。あなたが非常に熟練している場合、それは適切なアプローチかもしれませんが、チームの他のすべてのメンバーは初心者プログラマーです：彼らは単に適切な設計を行うのに十分な経験がなく、あなたは助けるために非常に良い立場にいますそれら。

もし私があなただったら、それが本当にこれが彼の心に描いていることかどうかを判断するために、私はあなたの上司と話をすることから始めます。はいの場合は、ゲームをプレイして、このアプローチを1〜2週間試します。何が起こる可能性がありますか？

アプローチがチームに適していることがわかります。その場合、マネージャーの洞察に感謝するか、アプローチが機能しません。

この場合、最初にチームと話し合って、うまくいかなかった理由をすべて一緒に特定し、プロセスを改善するために何をすべきか（つまり、遡及的に行う）を確認してください。次に、プロセスに変更を加えることができる場合は、プロセスを変更するか、マネージャーにアクセスしてマネージャーと話し合います。

その後、繰り返します。2週間ごと（またはコンテキストで適切と思われるもの）。

理想的には、ソフトウェアアーキテクトは上級ソフトウェアエンジニアの別の用語であり、おそらくいくつかの追加の責任があるか、または彼らが作業しているシステムの技術的な問題に関する公式の連絡窓口であることをその人に一般的に認識させる方法として、または、あまり知らない開発チームのメンバーが、システムの一部が特定の方法で設計された理由がわからない場合に、開発チームに頼ることができます。または、問題に対する良い/許容できる解決策が見つからないときに問題に苦しんでいます。

私の意見では、ソフトウェアアーキテクトは、他の開発者のためにデザインを作成したり、一方的な決定を行ったりすることわざの「象牙の塔」で働く人であってはなりません。設計の決定は、コードの記述と保守に積極的に関与している人々が主導する必要があり、開発チームは、システムの設計を理解するために、個々の開発者が自分のコードの品質に責任を持つ集団的責任を負う必要があります。アーキテクチャを「壊す」か、許容できないレベルの技術的負債をもたらす変更を導入しないため。

ソフトウェアチームがアイデアを伝達し、知識を共有するのを支援する手段としてシステムの高レベルの設計をキャプチャすることは価値がある場合があります（特に、初心者や経験の浅い開発者に）、設計の主な活動はコード自体を書くことです（自動テストを含む）; ソフトウェアアーキテクトが設計ドキュメントの「所有権」を取得することは理にかなっていますが、それは彼らがそれを書いているということと同じことではありません。さらに、チームが必要かつ十分なドキュメントを作成し、その正確性を確認するために利用できることを保証します。

すべての実用的な目的のために、ソフトウェア設計の役割を開発から分離しようとすることにはほとんどまたはまったく価値がありません。なぜなら、それらは本質的に同じものだからです。実際、現実は通常、開発者を混乱させる傾向につながるため、かなり有害です。自分自身で考えることを禁じられた生産ラインの「コードモンキー」として扱われます。

あなたの説明では、あなたのマネージャーはあなたにリーダーシップのポジションを引き受けて、これを明確にする方法を知らないように望んでいるようです

彼はあなたを昇進させ、あなたにソフトウェアを設計してタスクを分割してほしいと思った。明確に表現する方法についての彼の混乱は当然です。彼はあなたをリーダーシップの立場に置き、マネージャーとしての彼の役割と容易に混同される可能性があります。

従来の開発チームには、外部活動（資金調達、政治、ヘッドハンティングの才能、アイデアや製品の販売など）と内部活動（開発の調整）に分かれた1人のマネージャーがいます。しかし、この活動は対立しており、異なるスキルセットが必要です。通常、「マネージャー」は外部の活動には優れており、内部の活動には悪いです。

この役割は分離できます。実際、スクラム方法論の重要な特徴の1つです。私が知っている成功した生産的なチームは、これらの役割を分離しました。そして、ほとんどの人は彼らがそうしていることさえ知りません。プログラマーの1人がチームを編成し始め、マネージャーがそれを許可しました。

これは、「マネージャー」と「リード開発者」の間に信頼の絆がある場合にのみ機能します。多くのチームが失敗します。開発者の1人が主導権を握ると、マネージャーは脅威や嫉妬を感じることがあります。チームはマネージャーがいつも外出していて、外部活動の重要性を理解していないため、マネージャーへの敬意を失う可能性があります。それを認識し、それらの問題を回避することが重要です。

タスクを分割する方法

タスクを分割するために、彼の例に従う必要はありません。

チームの進捗状況をよりわかりやすくするために、概念実証、機能的な探索的プロトタイプを乱用することが重要です。重要なのは、開発が進んでいると感じていることです。

これを実現する1つの方法は、SQLのみのプロトタイプを作成することです。テーブルを作成し、データを入力して、メイン画面とルーチンが実行するクエリを実行するSQLのみのテストケースを作成します。シミュレーションが適切であると確信したら、ジュニア開発者間で作業を分割して、画面とルーチンを作成します。ジュニア開発者が作業している間に、次の開発サイクルのプロトタイプを作成しています。

誰もが忙しく、生産性が高く、マネージャーは満足しています。

2、3のスプリントで試してみてください。ただし、管理している開発者に深刻な迷惑をかけると、聞いている人にうめき声をあげます。

チームの一般的なアーキテクチャーの決定（プッシュvsプル、メッセージパターン、サービスxはDDDまたはCRUDで問題ない）をチームで設定していると仮定します。次に、コードレビュープロセスとペアリングを使用して、全員を順調に進め、行き詰まっている場合は手助けします。

それは本当にトップダウンである必要はありません、UMLによる死。あなたが探しているのは間違った場所にあるクラスです。ビジネスロジックが期待どおりに機能しないなど。

チームが何か知っていることを学んでいる場合は、チームに負担をかけすぎないようにしてください。最初に新しい原則に取り組み、次に長引く悪い慣行を片付けます。