ソフトウェア設計者は開発のどの部分を行うべきですか？
私のマネージャーは最近私を「ソフトウェアデザイナー」に昇進させました。このタイトルが存在することは知りません。私の知る限り、SAは高レベルのコード設計を作成し、図を作成します。
高レベルのコード設計を理解するのに苦労しています。私のマネージャーによると、すべてのクラスとそれらのクラス内のすべてのメソッドを設計する必要があります。つまり、コード構造全体を設計し、チームに各関数またはクラスの機能を実装させます。たとえば、CRUDシステムでは、どの関数を使用するか、どのクラスを作成するかを計画できるはずです。
私のソフトウェア設計の経験を考えると、これを実行することは非常に不可能であることがわかりました。開発者として、私は常に自分のクラスを作成し、自分の関数を定義して実装しています。他の人のために機能を設計した経験はありません。
私の質問は：
- これは一般的ですか？非常に大規模なシステムの場合、コードベースは常に変更されませんか？
- これはできますか？
ここでは明らかで愚かな質問をしているのかもしれませんが、私はこれまでずっと正規の開発者であり、システム全体の設計経験はありません。
タイトルに関する予備的なメモ：
時々、あなたが本当にやっていることはあなたの公式タイトルと全く一致しません。一例として、私は数年前、「研究開発部門のアナリストプログラマー」として雇われました。ただし、誰も、分析もプログラミングも研究も開発も採用しませんでした。私（および他の人）が実際に行ったのはコーディングです。サルは私がしたことの半分をすることができました。学部生は、残りの半分を行うことができます。
多くの場合、タイトルは重要ではありません。会社によっては、多くの異なった多様なタスクを実行することになり、そのすべてを説明するタイトルがないだけです。ある会社では、アーキテクト、チームリーダー、マネージャー、UX担当者、コーダー、生産性スペシャリストのタスクを実行し、2つのチームが互いに正しく通信するようにしていました。そのための単一のタイトルはありません。
最後に、タイトルは会社ごとに異なる意味を持つ可能性があります。または、タイトルを最初に付けた人々は、タイトルの実際の意味があるとしても、その意味について少しも理解していません。場合によっては、流行のタイトルと流行語があるだけです。昔ながらのシステム管理者は必要ありません。 DevOpsスペシャリストが必要です。誰かを雇うときにビジネスインテリジェンスやデータマイニングについて話すのではなく、ビッグデータについて話すのです。
タイトルを忘れて、正確に何をするように求められたかに集中してください。幸いなことに、あなたの質問はまさにそれを行います。
これは一般的ですか？非常に大規模なシステムの場合、コードベースは常に変更されませんか？
私はそれを見たことがなく、それが持続可能であるとは思えません。
これはできますか？
はい、ただし普通の犠牲を払ってチームを去ります。
上司が心に留めているのは、設計を行い、それをUML図の形式で提示することです。それは昔ながらですが、誰が気にしますか？この慣行は一部の企業では非常に人気があり、それでも他の企業ではまあまあうまく機能しています。あなたが非常に熟練している場合、それは適切なアプローチかもしれませんが、チームの他のすべてのメンバーは初心者プログラマーです：彼らは単に適切な設計を行うのに十分な経験がなく、あなたは助けるために非常に良い立場にいますそれら。
もし私があなただったら、私があなたのマネージャーと話をすることから始めて、それが彼が心に描いているのが本当にこれであるかどうかを判断します。はいの場合、ゲームをプレイし、このアプローチを1〜2週間試します。何が起こる可能性がありますか？
アプローチがチームに適していることがわかります。この場合、マネージャーの洞察に感謝するか、アプローチが機能しません。
この場合、最初にチームと話し合って、なぜうまくいかなかったのか、プロセスを改善するために何をすべきかをまとめるために（言い換えれば、回顧を行う）。次に、プロセスに変更を加えることができる場合は、プロセスに変更を実装するか、マネージャーにアクセスしてマネージャーと話し合います。
その後、繰り返します。 2週間ごと（またはコンテキストで適切と思われるもの）。
理想的には、Software ArchitectはSenior Software Engineerの別の用語であり、おそらくいくつかの追加の責任があるか、または彼らが公式のポイントであることをその人に一般的に認識させる方法として使用するシステムの技術的な問題、またはあまり知らない開発チームのメンバーが、システムの一部が特定の方法で設計された理由がわからない場合は、それらに頼ることができます。または、問題に対する良い/許容できる解決策が見つからないときに問題に苦しんでいます。
私の見解では、ソフトウェアアーキテクトは、他の開発者のためにデザインを作成したり、一方的な決定を下したことのある「象牙の塔」で働く人物であってはなりません。設計の決定必須コードの記述と保守に積極的に関与している人々によって依然として推進され、開発チームは集合的な責任を負う必要があり、個々の開発者は自分のコードの品質に責任を持って理解する必要がありますシステムの設計、およびアーキテクチャを「壊す」か、許容できないレベルの技術的負債をもたらす変更を導入しないため。
ソフトウェアチームがアイデアを伝達し、知識を共有するのを支援する手段としてシステムの高レベルの設計をキャプチャすることは価値がある場合があります（特に、初心者や経験の浅い開発者に）、設計の主な活動はコード自体を書くことです（自動テストを含む）;ソフトウェアアーキテクトが設計ドキュメントの「所有権」を取得することは理にかなっていますが、それは彼らがそれを書いているということと同じことではありません。さらに、チームが必要かつ十分なドキュメントを作成し、その正確性を確認するために利用できることを保証します。
すべての実用的な目的のために、ソフトウェア設計の役割を開発から分離しようとすることには本質的に同じものがあるため、ほとんどまたはまったく価値がありません-実際、現実は通常、開発者がそれによって開発者にメンタリティをもたらす傾向があるため、かなり有害です自分自身で考えることを禁じられた生産ラインの「コードモンキー」として扱われます。
あなたの説明では、あなたのマネージャーはあなたにリーダーシップのポジションを引き受けて、これを明確にする方法がわからないことを望んでいるようです
彼はあなたを昇進させ、あなたにソフトウェアを設計してタスクを分割してほしいと思った。明確に表現する方法についての彼の混乱は自然なことです。彼はあなたをマネージャーとしての彼の役割と容易に混同される可能性があるリーダーシップの立場に置いています。
従来の開発チームには、外部活動（資金調達、政治、ヘッドハンティングの才能、アイデアや製品の販売など）と内部活動（開発の調整）に分かれた1人のマネージャーがいます。しかし、この活動は対立しており、異なるスキルセットが必要です。通常、「マネージャー」は外部の活動には優れ、内部の活動には悪いです。
この役割は分離できます。実際、スクラム方法論の重要な特徴の1つです。私が知っている成功した生産的なチームは、これらの役割を分離しました。そして、ほとんどの人は彼らがそうしていることさえ知りません。プログラマーの1人がチームを編成し始め、マネージャーがそれを任せました。
これは、「マネージャー」と「リード開発者」の間に信頼の絆がある場合にのみ機能します。多くのチームが失敗します。開発者の1人が主導権を握ると、マネージャーは脅威や嫉妬を感じることがあります。チームはマネージャーがいつも外出していて、外部の活動の重要性を理解していないため、マネージャーへの敬意を失う可能性があります。それを認識し、それらの問題を回避することが重要です。
タスクを分割する方法
タスクを分割するために、彼の例に従う必要はありません。
チームの進捗状況をよりわかりやすくするために、概念実証、機能的な探索的プロトタイプを乱用することが重要です。重要なのは、開発が進んでいると感じていることです。
これを実現する1つの方法は、SQLのみのプロトタイプを作成することです。テーブルを作成し、データを入力して、メイン画面とルーチンが実行するクエリを実行するSQLのみのテストケースを作成します。シミュレーションが適切であると確信したら、ジュニア開発者の間で作業を分割して、画面とルーチンを作成します。ジュニア開発者が作業している間、次の開発サイクルのプロトタイプを作成しています。
誰もが忙しく、生産性が高く、マネージャーは幸せです。
いくつかのスプリントで試してみてください。ただし、管理している開発者に深刻な迷惑をかけると、聞いている人にうめき声を上げます。
チームの一般的なアーキテクチャの決定（プッシュとプル、メッセージパターン、サービスxはDDDまたはCRUDで問題ない）をチームで設定していると仮定します。次に、コードレビュープロセスとペアリングを使用して、全員を順調に進め、行き詰まっている場合に彼らを助けます。
それは本当にトップダウンである必要はありません、UMLによる死。あなたが探しているのは、間違った場所にあるクラスです。ビジネスロジックが期待どおりに機能しないなど。
チームが何か知っていることを学んでいる場合は、チームに負担をかけすぎないでください。最初に新しい原則に取り組み、次に長引く悪い慣行をクリーンアップします。