設計経験のあるチームの唯一のメンバーであるときにソフトウェア設計プロジェクトを処理する方法
いくつかの背景
私は3人の開発者の小さなチームの最新メンバーです。過去2年間、私は2人で約5〜6年前に作成したアプリケーションの開発に取り組んできました。このアプリケーションにはドキュメントがなく、設計または分析方法論が開発プロセスに適用されたことはありません。最新の中規模のシステムへの変更は、現在のコードベースである複雑な混乱の結果、1年以上続いています。
この変更に関する死後の分析の結果、市場はシステムを拡張するよりも速く動いているため、アプリケーション全体の完全な書き直しに向かっています。ただし今回は、ラッシュフォワードではなく、方法論的に行うことを強くお勧めします。私の同僚はソフトウェアデザインの経験がないことが明らかになりましたが、これは熱意に満ちていました。
質問へ
私はチーム内でソフトウェア設計の経験を持つ唯一の人であり、その経験は純粋に学問的なものです。つまり、少なくとも最初は重い仕事をすることは私にかかってしまいますが、これにより、チームメンバーがソフトウェアを推論する方法についての理解を高めながら、プロセスで自分自身を壊さないようにする方法を説明します。つまり、GRASPやSOLIDなどのトピック、またはオブジェクト指向のデザイン全般について、またワークショップを生産的な方法で構築する方法について、ワークショップのアイデアや学習リソースを探しています。
編集：説明と背景
質問を短くするために、私は現在の状況でいくつかの重要なポイントを無視したと思います。私が述べた書き直しは、「新しいプラットフォームへのリファクタリング」に似ており、主に構築されており、セキュリティとパフォーマンスの観点からマスタードをこれ以上削減しない非推奨のテクノロジーを採用しています。アプリケーションはブラウザベースのWebアプリケーションであるため、現在のソリューションのルートを切り替えて、「最小限の労力」で新しいソリューションを指すようにし、少しずつ少しずつ古いものの一部を新しいものに少しずつ置き換えることができます。 。上で述べた変更が唯一の要因ではありませんでしたが、それがより大きな問題の原因となっています。もともとは社内で使用されていましたが、ニッチ市場を埋め尽くすため、現在はソリューションをお客様に販売しています。元の製品所有者のワークフローは、他のお客様のワークフローと一致しません。以前の実践的な管理アプローチにより、不要になったショートカットや機能しないショートカットのために、すべてが他のすべてに接続されるシステムにつながります。私がここで働き始める前は、誤解により、受け入れテストと開発の間で何週間も問題が発生していました。テストとは、サポートスタッフがプッシュボタンを押して、期待どおりの結果が得られるかどうかを確認することを意味します。数年前に安定して完全であると考えられていた機能は、予想される入力からの逸脱に失敗するため、これは懸念事項でした。
これがreal問題を見るところです。私たちの開発プロセスは高品質のコードを生み出すものではなく、私たちの仕事のやり方を変えるために何かをする必要があります。新しいバージョンが間近に迫っているので、まさにそれを行う機会があると思います。すべての問題の解決策としてではなく、方法論的なソフトウェア設計を紹介したいのですが、アプリケーションの実際の要件だけでなく、アプリケーション自体のさまざまな部分がどのように機能するかをよりよく理解できるように、少しペースを落とします全体を形成するために一緒にフィットします。これは複雑なビジネスロジックでいっぱいのアプリケーションではなく、共通のコアエンティティとの対話を除いてほとんど重複しないさまざまな問題ドメインの大規模なコレクションです。そこには、開発、販売、サポートを容易にするモジュール式のアーキテクチャがありますが、それだけでは表示されません。何かをしなければ、あまりにも多いため、いつもと同じ問題に直面します。私たちが持っているものを見て、同じことを別の言語で行うのは簡単です。
そして、これが私がチームの残りのメンバーをソフトウェア設計に導入する方法に関するアドバイスやリソースを探している理由です。少なくとも、私が持っている知識を適用できるほど十分です。 特にプロジェクトを2つのフェーズに分割しているため、1つのフェーズは完全に新しい機能の小さなサブセットであり、新しいUIと一般的なユーザビリティの目標があります。現在の機能を新しいシステムに移行するタスクを引き受ける前。最初のフェーズは3人ですべて社内で行い、2番目のフェーズは主にレビューの下でリモートで作業する外部コンサルタントによって実装されます。ボールを転がすことができれば、フェーズ1は新しい開発プロセスで歯を切る絶好の機会になると思います。
ゼロから始めて、最初からデザインしますか？
申し訳ありませんが、私はあなたの仮定に挑戦しなければなりません...あなたは混乱を一年掃除するのを失いました。この状況では、チームがゼロからの再起動を検討するのは人間です。しかし、それは本当に「熱意」を持っているのか、それとも必死になってしまっているのでしょうか。
大きなデザインの素敵なドキュメントから始めるとしましょう。しかし、結局のところ、今回の方が成功すると思う理由は何ですか。実証済みの実用的なOO=設計経験がない場合、特にクロックが刻々と過ぎて圧力が高まっているときに、チームは（いくつかの初期設計作業の後で）古いプログラミング戦略にフォールバックできなくなりますか？
あなたの不信感と苛立ちを感じます。しかし、私の控えめな挑発を無視する前に、この記事をご覧いただけますか "すべきではないこと" 、私たちのコミュニティで尊敬されている第一人者、ジョエルから？それはまさにあなたがやろうとしていることについてです...
どうやって進むの？最初のステップ：理解を共有する
まず第一に、すべての経験豊富なプログラマーにサウンドデザインアプローチを導入する最も早い方法は、 ncle Bob 's "の集合的理解を組織することです。クリーンコード " 。
1つの方法は、章をあなたの間で共有することです（そのため、全員が完全な本を読む必要はありません。並列化）。そして、全員が残りのチームのために章の要約を作成します。各プレゼンテーションの後、チームは既存のソフトウェアで原則をどのように使用できるかをまとめて反映します。または、原則が適用されなかったために発生した典型的な問題。
別の方法は、本を読んだり、ビデオを見たりすることです。問題は、ファストトラック学習が1つのことですが、新しい知識を既存のニーズに接続すると、知識がアクティブになり、使用できるようになります。
これで十分でない場合は、いくつかの設計パターンの知識も役立ちます。これは悪いデザインの解決策ではありませんが、確かに実用的な問題に優れたデザイン原則を適用するのに役立つ優れた学習ツールボックスです（幸いにも 基本的なデザインパターン には多くの資料があり、Martin Fowlerの素晴らしい本があります） about エンタープライズアプリケーションアーキテクチャのパターン これがあなたが作成している種類のソフトウェアの場合）.
次のステップ：リファクタリング
私はもっと信じています 包括的なドキュメントよりも実用的なソフトウェアで 。特に小さなチームでは。
したがって、しばらくの間全体を再設計してから新しい設計で再実装を開始する代わりに、体系的な refactoring アプローチを使用して既存のシステムを改善することを選択します。次のリファクタリングターゲットを何にするべきか、そして最善の方法を常にチームで話し合ってください。
アイデアは、各リファクタリングサイクルの後でも、機能する製品があるということです。また、実際のソフトウェアにはない体験をチームに提供します。したがって、リファクタリング中に設計パフォーマンスが向上します。数回のリファクタリングセッションの後に、チームが新しい機能や機能強化に優れた設計を採用し始めることに驚かれることでしょう。
最後の言葉
変更によってこのような混乱が生じる場合は、自動ユニットテストの包括的なセットなど、機能していないものをすばやく特定するのに役立つ他のものが不足している可能性があります。したがって、デザインだけでなく、他のいくつかの実績のある開発手法も改善することは、考える価値があります。