第1回開発ソフト個人まとめ
5093 ワード
プロジェクトの背景
このプロジェクトは、政府からラボに導入されたプロジェクトに由来し、ネットワーク管理ソフトウェアのタイプに属しています.
本プロジェクトの特徴は主に以下の通りである.
1.プロジェクトの時間が短く、4ヶ月以内に需要から納品までのすべての仕事を完成する必要があります.
2.実際のテストプラットフォームが不足し、ハードウェア設備など多くの原因で、ソフトウェアの核心である監視部分は良いプラットフォームでテストできず、いくつかの模擬テストしかできない.
3.お客様のニーズの定義が不明確で、時間の経過とともに変更されることが多い(これは、後からお客様が変更を繰り返す前に確定したニーズから分かることで、事前に完全に当てられるわけではありません.もちろん、ニーズの変更は避けられないことです)
プロジェクト開発プロセス
このプロジェクトの初期段階では,需要仕様説明(SRS)の作成を担当し,SRSに基づいてデータ辞書の握り書きを議論した.ここにはエピソードがあります:もともと私たちのグループは私のこの新人がC++しかできないため、C++を採用してこのシステムを実現しようとしましたが、C++の複雑なフレームワークの構築と煩雑な文法のため、もちろん、VS 2008のIntelliSenseはC++に基づくのも本当に弱すぎて、最終的に兄弟子が彼のよく知っているC#言語を採用してアーキテクチャを作りました.
この时、先生はプロジェクトの开発过程全体のスケジュールをリストアップして、私は以下にみんながそれぞれ考えて分析するためにリストアップします:需要:20日;設計と実現:2ヶ月;統合テスト:1ヶ月.このスケジュールの面では、先生はわざときつく手配するに違いない.
それから先生の要求の下で、私は概要の設計のドキュメントを編纂して、先生の兄はかつてこのドキュメントが全く必要ないと言って、変わらない需要がないため、設計はきっと需要によって変化することができて、このような設計はまったく確定することができなくて、これも今多くのソフトウェア開発がもっと敏捷な原因を提唱するのかもしれません.その後の事実も、この措置がプロジェクトにとって何の意味もないことを証明し、このプロジェクトはメンテナンス期間に入るまでドキュメントを使用したことがない.プロジェクトのまとめでは、ソフトウェア開発ドキュメントの個人的な理解について言及します.
需要が「確定」された後、(この時点では2週間近く延期されています)、私たちは需要に応じて開発するソフトウェアを多くのモジュールに分けています.ここではモジュールの粒度に注意し、太すぎると複雑になり、細すぎると煩雑になります.その後、ガント図を描いて初歩的な開発順序とタスク計画を作成し、開発者にモジュールを開発した後、ユニットテストをしなければならないと要求した.(この点は必要)我々のアーキテクチャはプロジェクトの特徴1を考慮して4つの階層に分けられ、より複雑で柔軟なアーキテクチャをしていない.Common層は基礎サービスを提供し、Repository層はMySQLデータベースへのアクセスを提供し、Service層は各種の業務論理面のサービスを提供し、UI層はインタフェースを提供する.△ここで先輩に感謝します.彼は本当に私にたくさん教えてくれました...
次に、私の具体的な開発作業について説明します.設備部分の構成、すべての設備の監視、設備状態の表示です.このブロックが緊密につながっている部分であることを考慮して、私一人に任せました.最初は仕事の量が大きいのではないかと心配していましたが、間違ったプロジェクト管理と無秩序な開発がソフトウェアの開発に与えた損害は、より多くの仕事量による損害をはるかに上回っていることに気づきました.
SnmpSharpNetという開発パッケージを利用してSNMPプロトコルの下でのモニタリングを行いました.ネット上でこの开発バッグの具体的な経験を言う人はいません.明日、私はわざわざブログを书いて自分の経験を说明します.必ずしも正しいとは限りませんが、绝対にN回の试みを経ました.の最初のマルチスレッドモニタリングでは、モニタリング部分の修正を誤って設計して直接データベースを読み取り、避けられないスレッド間の衝突現象(大牛が処理すれば解決できるかもしれないが、不要なデータベースを読み取る操作による消費時間はネットワーク管理ソフトウェアにとって受け入れにくい)をもたらし、後でキャッシュで解決することを提案されるまでこの問題を解決しなかった.マルチスレッド私のデータの衝突に対する処理経験はロックを加えることで、もちろん基本的なタイプならvolatileを加えることです.volatileの詳細は、本人のもう一つのブログ、ここを見ることができます.监视の场所で私は何度もやったが、基本的には毎回全面的に拒否する前のやり方だった...ネット管理ソフトウェアの開発には確かにいくつかの特徴があります.これから開発する前に、必ず他の人の実践経験を聞いてみることをお勧めします.私の間違った経験も次のブログで詳しく説明します.o(╯□╰)o
私の個人部分のモジュールの開発はここであまり言わないで、技術の含有量がなくて、私は得た情報が画像のインタフェースの処理部分に提供することを監視して、だから私は観察者のモードを利用して別の同級生が行くインタフェースを実現しました.以下はそれぞれインタフェースと観察者であり、もう一人の学生はそのクラスの構造関数にObserversを加える必要がある.Observer= this;またインタフェースINotifiableを継承することでインタフェース関数Notify(A a)を定義することができる.namespace Services
{
public interface INotifiable
{
void Notify(A a); //
}
}
namespace Services
{
public class Observers
{
public static INotifiable Observer { get; set; }
}
}
このように最初のバージョンを開発した後、当初の計画より1週間しか延期されなかったが、その後の統合テストと需要の変化によって、このすべてが表面的に美しく見えた.その後の時間の中で、私は絶えず新しい現場テストの情況(プロジェクトの特徴2)によって監視部分をデバッグして、そして絶えず底層のコードを修正して需要の変化に対応して、プロジェクト管理の誤りはこの時次第に現れて、多くの事は道理がなくて、無意味に表面の現象を強調して、誤って管理の下のばらばらで無秩序な開発もコードの品質の低下をもたらしました.最終的にはこのように引きずってバージョンを一つ一つ対応しました.お客様の不満度もますます高くなって、もたらした圧力も管理者がコードの再構築を実施する勇気がなくて、多くの冗長なコードがずっと生きていて、みんなは砂浜の上で部屋を建て始めました.の(コード大全2ソフトウェア開発に関する比喩を参照)ソフトウェア開発はこのように悪循環に入った.の
プロジェクトのまとめ
このあまり満足できないプロジェクトの中で、私はいくつかの点を深く体得して、今みんなと私の血の教訓O(∩∩)Oを分かち合います.
1.経験のあるプロジェクトマネージャは本当に重要です.さもないと、誰もが自信を感じずにまじめさを失う.兵将熊の故事はもう言わない.
2.開発コードは全身全霊を使う必要があります.SVNに提出されたコードは必ず真剣に確認し、注釈をつけなければなりませんが、私はいくつかのことでごまかしと消極的な開発をしています.結果は今ますます挽回しにくくなっています.
3.自動化ユニットテストは重要で、前に時間を浪費する可能性があるが、ソフトウェア開発の成熟にとって非常に必要であり、研削刀は薪を誤って切らない.そうしてください.
4.グループの相互審査コードは必要であり、コアコードを相互に抽出することは、特に自動化ユニットテストがない場合、私たちのような在校中の小さな開発チームにとって必要です.
5.再構築を疑わないでください.短期的には問題が発生する可能性があります(この確率は低いです)が、長期的にはコードの簡素化と設計の明確さを考慮しています.
6.開発チームの相互協力とコミュニケーションは必須であり、インタフェースの確定のために互いにコミュニケーションを取らないわけにはいかない.プログラミングの重要性はこれに似ており、傍観者ははっきりしている.
備考:前に総括の中でプロジェクトに関するドキュメントの理解を書くと言いましたが、昨夜は急いでいたので、落ちてしまいました.今補充します.
個人的なアドバイス:ソフトウェア開発では、ソフトウェア需要仕様の説明、データ辞書、アーキテクチャの説明、モジュールの設計の説明(概要設計は具体的な状況を見なければならない)、テスト例、問題報告が必要です.ユーザーは、ヘルプマニュアルとソースコードの説明も必要になる場合があります.注:ドキュメントはコードよりも重要な場合があります.
--------------------------------------------------------------------------------
著作権声明このブログのすべてのオリジナル文章は、作者が著作権を保持しています.転載は本声明を含み、本明細書の完全性を維持し、著者s5279551と本明細書の元の住所:http://www.cnblogs.com/s5279551/archive/2010/09/19/1831260.htmlをハイパーリンク形式で明記しなければならない.
このプロジェクトの初期段階では,需要仕様説明(SRS)の作成を担当し,SRSに基づいてデータ辞書の握り書きを議論した.ここにはエピソードがあります:もともと私たちのグループは私のこの新人がC++しかできないため、C++を採用してこのシステムを実現しようとしましたが、C++の複雑なフレームワークの構築と煩雑な文法のため、もちろん、VS 2008のIntelliSenseはC++に基づくのも本当に弱すぎて、最終的に兄弟子が彼のよく知っているC#言語を採用してアーキテクチャを作りました.
この时、先生はプロジェクトの开発过程全体のスケジュールをリストアップして、私は以下にみんながそれぞれ考えて分析するためにリストアップします:需要:20日;設計と実現:2ヶ月;統合テスト:1ヶ月.このスケジュールの面では、先生はわざときつく手配するに違いない.
それから先生の要求の下で、私は概要の設計のドキュメントを編纂して、先生の兄はかつてこのドキュメントが全く必要ないと言って、変わらない需要がないため、設計はきっと需要によって変化することができて、このような設計はまったく確定することができなくて、これも今多くのソフトウェア開発がもっと敏捷な原因を提唱するのかもしれません.その後の事実も、この措置がプロジェクトにとって何の意味もないことを証明し、このプロジェクトはメンテナンス期間に入るまでドキュメントを使用したことがない.プロジェクトのまとめでは、ソフトウェア開発ドキュメントの個人的な理解について言及します.
需要が「確定」された後、(この時点では2週間近く延期されています)、私たちは需要に応じて開発するソフトウェアを多くのモジュールに分けています.ここではモジュールの粒度に注意し、太すぎると複雑になり、細すぎると煩雑になります.その後、ガント図を描いて初歩的な開発順序とタスク計画を作成し、開発者にモジュールを開発した後、ユニットテストをしなければならないと要求した.(この点は必要)我々のアーキテクチャはプロジェクトの特徴1を考慮して4つの階層に分けられ、より複雑で柔軟なアーキテクチャをしていない.Common層は基礎サービスを提供し、Repository層はMySQLデータベースへのアクセスを提供し、Service層は各種の業務論理面のサービスを提供し、UI層はインタフェースを提供する.△ここで先輩に感謝します.彼は本当に私にたくさん教えてくれました...
次に、私の具体的な開発作業について説明します.設備部分の構成、すべての設備の監視、設備状態の表示です.このブロックが緊密につながっている部分であることを考慮して、私一人に任せました.最初は仕事の量が大きいのではないかと心配していましたが、間違ったプロジェクト管理と無秩序な開発がソフトウェアの開発に与えた損害は、より多くの仕事量による損害をはるかに上回っていることに気づきました.
SnmpSharpNetという開発パッケージを利用してSNMPプロトコルの下でのモニタリングを行いました.ネット上でこの开発バッグの具体的な経験を言う人はいません.明日、私はわざわざブログを书いて自分の経験を说明します.必ずしも正しいとは限りませんが、绝対にN回の试みを経ました.の最初のマルチスレッドモニタリングでは、モニタリング部分の修正を誤って設計して直接データベースを読み取り、避けられないスレッド間の衝突現象(大牛が処理すれば解決できるかもしれないが、不要なデータベースを読み取る操作による消費時間はネットワーク管理ソフトウェアにとって受け入れにくい)をもたらし、後でキャッシュで解決することを提案されるまでこの問題を解決しなかった.マルチスレッド私のデータの衝突に対する処理経験はロックを加えることで、もちろん基本的なタイプならvolatileを加えることです.volatileの詳細は、本人のもう一つのブログ、ここを見ることができます.监视の场所で私は何度もやったが、基本的には毎回全面的に拒否する前のやり方だった...ネット管理ソフトウェアの開発には確かにいくつかの特徴があります.これから開発する前に、必ず他の人の実践経験を聞いてみることをお勧めします.私の間違った経験も次のブログで詳しく説明します.o(╯□╰)o
私の個人部分のモジュールの開発はここであまり言わないで、技術の含有量がなくて、私は得た情報が画像のインタフェースの処理部分に提供することを監視して、だから私は観察者のモードを利用して別の同級生が行くインタフェースを実現しました.以下はそれぞれインタフェースと観察者であり、もう一人の学生はそのクラスの構造関数にObserversを加える必要がある.Observer= this;またインタフェースINotifiableを継承することでインタフェース関数Notify(A a)を定義することができる.
namespace Services
{
public interface INotifiable
{
void Notify(A a); //
}
}
namespace Services
{
public class Observers
{
public static INotifiable Observer { get; set; }
}
}このように最初のバージョンを開発した後、当初の計画より1週間しか延期されなかったが、その後の統合テストと需要の変化によって、このすべてが表面的に美しく見えた.その後の時間の中で、私は絶えず新しい現場テストの情況(プロジェクトの特徴2)によって監視部分をデバッグして、そして絶えず底層のコードを修正して需要の変化に対応して、プロジェクト管理の誤りはこの時次第に現れて、多くの事は道理がなくて、無意味に表面の現象を強調して、誤って管理の下のばらばらで無秩序な開発もコードの品質の低下をもたらしました.最終的にはこのように引きずってバージョンを一つ一つ対応しました.お客様の不満度もますます高くなって、もたらした圧力も管理者がコードの再構築を実施する勇気がなくて、多くの冗長なコードがずっと生きていて、みんなは砂浜の上で部屋を建て始めました.の(コード大全2ソフトウェア開発に関する比喩を参照)ソフトウェア開発はこのように悪循環に入った.の