原因
最近、大学でJAVAでのクライアントとサーバーの対話用のソフトウェアパッケージを開発しました。 いわば、特別コースの最終課題。
10人が開発に参加しました。 それ自体が、あらゆるアクティビティの組織を調整します。 チームリーダーの職務を引き受けて、彼はこれに直接参加しました。
もちろん、それはすべてアイデアから始まりました ：なぜ最後にそのようなことを書くのか、先生を喜ばせるため、そして1つは自動的に試験を獲得するためです。 最初のブレーンストーミングの結果、彼らはプロジェクトのコンセプトを次のように述べました。
クライアントサーバーアーキテクチャを使用してネットワークアプリケーションを作成しましょう。サーバーには、学生、写真、情報、引用文を含むデータベースが含まれています。 クライアントはサーバーに情報を要求し、ユーザーに表示します。
後にさらに大胆な考えが生まれました：
- サーバーの管理を行う場合：リモート停止、起動、構成の変更。 したがって、ここでは、管理者がすべてを操作するためのクライアントを追加します。
- アプリケーションの国際化：プログラムが必要な言語を話すとき、それは常に便利で便利です:)
仕事
その後、何が続きましたか？ 設計、オブジェクト指向モデリング。 ここでは、オブジェクトの相互作用のメカニズムを構築し、そのプロパティとインターフェイスを説明する問題を提示しました。
最も簡単ですが、最も重要な部分 ：基本クラス、データを正しい形式で決定します：学生のクラス、学生のリスト。 後に、サーバー学生が通常の継承者として選択されましたが、サーバー上の写真へのパスの追加フィールドを使用して、拡張性（データベースから、または他の方法でリストをファイルからロードするかどうか）のために、リスト（JAVA OOP用語で）用のインターフェイスが開発されました。 画像、データを操作するためのクラス。
当初、彼らは同じクライアントがコンソールとGUIバージョンに存在することを決定し、GUIはフロントエンドに過ぎませんでした。 サーバーは、セレクターとチャンネル、つまり ブロックせずにすべてのネットワーク操作。 相互に一貫性のあるサーバー、これは私たちのコースが呼んだものです。 答えを生成するために、インターフェイスを再度割り当て、それを別のクラスに実装しました。
ここでは 、実装の責任が分散され、プロトコルの作業が分解され、そのためのすべての要件が形成されました。
実装のさらなる技術的手段 ：JAVA用のEclipse開発環境 、開発同期用の部門のSVNサーバー。
さて、これらの詳細の設計後、開発が始まりました。
まず、各クラスの役割を説明したプロジェクトのおおよそのフレームワークをレイアウトし、すべてをパッケージに散らばらせました。 プロトコルの説明を例とともに投稿し、タスクの分布、SVNを使用するためのメモをレイアウトしました。
SVNでは、TODOまたはFIXMEで欠落しているメソッドをスタブ化することが許可されていない限り、SVNで、コンパイルされていないコードをコミットし、コミットのコメントを空のままにして、他の人のクラスに不必要にクロールすることは不可能であるとすぐに議論されました。 これにより、SVNの競合を最後まで回避できました。
誰かが必要な知識を持たず、むしろ経験を持っているとは言いたくないので、タスクモデルと実装は簡素化され、同じ設計パターンなどを知る必要はなかったので、割り当てられた時間は新しい、異常なものへの再構成に費やされませんでしたいいよ
軟膏で飛ぶ。
どのような間違いがあったか（私の意見では）：
- プログラムに関係するデータを変換するためのフレームワークに事前に同意する必要がありました。 その結果、異なるパッケージのクラスの2人が、バッファを文字列に、またはその逆に変換するための同じユーティリティメソッドを作成しました（簡単ですが、時間を無駄にします）。
- プロジェクトに関する情報や詳細はあまりありません。 このように思える場合でも、他の人が私の意見を共有するということではありません。 初期段階では、SVNの変更は元の計画と必ずしも一致していませんでした。
- 事前に作業を完了するための期限を設定する必要があります。 私たちは皆、懸念と問題を抱えた人々です。 セットの締め切りはわずかに長くなったため、全員が急いで終了しました（6セットのうち4日目に、開発活動が急増しました）。
- 作業の終わりには注意が散漫になるため、リリースに関するいくつかのことが予期せず見逃されているように見えます。 各タスクのタイムプランを常に選択する必要があります。 時間がない場合は、すぐに終わらせないでください。他の人を完了した後、できるだけ早く延期してください。
- 他人のコードを常に尊重する必要があります。 気に入らないものがある場合は、それがどのように必要であるかを伝える方が良いですが、書き直して新しいオプションを指すのではありません。 すべての参加者の意見に興味を持ち、いくつかの事項で無条件に信頼する必要があります。 良い仕事と一般的にあらゆる種類の支援をありがとう 。 結局のところ、プロジェクトの詳細は、だれかが重要な利益を受け取ることを意味するものではないことは明らかです。 （オープンソースを思い出してください）
- あなたはすべてを自分でやろうとするべきではありませんが、そのような欲求はしばしば起こります。繰り返しますが、実装に対する異なるアプローチのために、ささいなことを選択します。
労働の成果。
はい、だから私は暗い部分を終えました、そして今ポジティブに：
プロジェクトは予定通りでしたが、最後の夜は2人にとって本質的に眠れませんでした。
先生は私たちと同じように喜んでいた。
もちろん、常に発生するように、最後の機能は削減されましたが、他の誰かの作業がリリースから削除されるほどではありませんでした。
あとがき。
私はソースコードを正しく管理しているとは思わないので、それを適用しませんが、プログラム自体と公的にアクセス可能なサーバーのアドレス：常に歓迎します。
多かれ少なかれ成功を収めているチームプロジェクトは、鼻をかき回す権利を与えず、大成功への希望を大事にしています。
客観性を主張せず、ほとんど経験がないことを意識して、実際的なアドバイスを期待する。