22

約 2 年前にプロのソフトウェア開発者として最初の仕事を始めて以来、一般的に受け入れられている方法論 (スクラム、XP など)、テクノロジ (EJB、Spring など)、技術 (TDD、コード レビューなど) に関する記事をたくさん読んできました。 )、ツール (バグ追跡、ウィキ) などをソフトウェア会社で使用しています。

これらの多くについて、私たちの会社ではそれらを使用していないことがわかり、その理由を自問自答しました. 私たちのやり方は間違っているのでしょうか、それとも単に私が読んだこれらの記事が、実際の世界がどのようなものかを実際に伝えていないだけなのでしょうか? これらの記事はより学術的ですか？

では、御社での様子を教えてください。ソフトウェア開発に関するすべてを教えてください。ここにいくつかの提案があります（私の頭に浮かんだ順序で）。少なくとも実行するかしないかを伝えるか、短いコメントを付けてください。

  • テスト駆動開発
  • ドメイン駆動設計
  • モデル駆動型設計/アーキテクチャ
  • テストしますか？
  • 単体テスト
  • 統合テスト
  • 受け入れ試験
  • コードレビュー
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST など)
  • アジャイル
  • ペアプログラミング
  • UML
  • ドメイン固有言語
  • 要件仕様 (どのように?)
  • 継続的な統合
  • コード カバレッジ ツール
  • Aenemic ドメイン モデル
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント)
  • 労力の見積もり
  • チームサイズ
  • ミーティング
  • コード メトリクス
  • 静的コード分析
  • バグ追跡
  • ...

そして覚えておいてください：私はあなたが何をしたいのか、何をすべきだと考えているのかではなく、あなたが本当に何をしているのか知りたいのです.

4

23 に答える 23

26
  • テスト駆動開発- まさか。
  • ドメイン駆動設計-設計とは?
  • モデル駆動設計/アーキテクチャ-デザインとは? 私たちは建築チームを持っています。1 人の例外 (最年少のアーキテクト) を除いて、彼らは紙袋からコードを書き出すことができませんでした。でも、線でボックスを描くのは得意ですよね！そして、くだらない、価値のない、過度に一般的で、まったく役に立たない基準を確立します。(古い OPC のものは問題ありませんが、UA 標準は過去 4 年間ほど「来月完成」しています。)
  • テストしますか？- はい、専任のテストチームがいます。10 ～ 12 人の開発者ごとに約 1 人のテスターがいます。彼らは完全に圧倒されています。テストがうまくできているかどうか聞いてください。
  • 単体テスト- 完全に非公式/開発者次第。与えられたスケジュールが許すときはそうします。
  • 統合テスト- はい。これは、私たちが開発およびサポートする一連の製品を考えると必要です。
  • 受け入れテスト- はい、契約作業のみ。
  • コード レビュー-常にリップ サービスを行い、絶対に行わないでください。
  • 革新的なテクノロジ (Spring、Hibernate、Wicket、JSF、WS、REST など) - 新しい依存関係を利用することは、非常に嫌われています。Boost は決して採用されません。たとえば、新しいバージョンの .Net を入手できたのは一般的に幸運でしたが、通常は 2 年ほど遅れています。
  • アジャイル- いいえ。経営陣は「アジャイル」を望んでいると主張していますが、それが何であるかについての最低限の理解は示していません。最近、プロセスを変更して、優先度の高いタスクが仕様化され、実装されるようになりました... (待ってください) 優先度が高くなります! 経営陣は、これが私たちの新しい「アジャイル」プロセスだと言っています。それでも、滝のようににおいがし、歩き、鳴きます。
  • ペアプログラミング- まさか！1人の仕事をするために2人にお金を払いますか？次に、開発者が設計やコード レビューなどのナンセンスに時間を費やすべきだと提案します。犬、猫、共生！
  • UML - いいえ。進化したレガシー コードベースを理解するのに役立つ UML ツールを入手したことがあります。ツールの評価担当者はこのツールを気に入り、30 秒以内に 100 万行以上の C++ コードベース全体をリバース エンジニアリングしました。彼らがそれを購入するよう説得され、実際の開発者がそれを使用しようとした後、コードベースの 95% 以上を解析するのに 30 秒しかかからなかったことがわかりました。エラー報告は非常にひどかったため、評価者は失敗したことさえ理解していませんでした。（私はあなたを見ています、子供！） そのためのライセンスを取り下げるのに1年半しかかかりませんでした。見る？アジャイル！
  • ドメイン固有言語- おそらくどこかで使用されていますが、私自身ではありません。
  • 要件仕様 (どのように?) - プロダクト マネージャーがブードゥー教を実行し、それらを発明します。時には、お客様にそのことを話すことさえあるかもしれません! 本当に運が良ければ、彼らはユースケースと要件の違いさえ理解してくれるでしょう。ただし、当てにしないでください。ユースケースは実際には行いません。
  • 継続的統合- まさか。すべてが一度に壊れると、はるかにエキサイティングです。
  • コード カバレッジ ツール- 寒い、寒いサーバー ルームのソース リポジトリ サーバーにブランキーを置いたことがあります。それは重要ですか？
  • Aenemic Domain Model - 真面目な話、これは聞いたこともありません。
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - メモ。Lotus Notes は「電子メール」を行いません。新しいゴミの束。
  • 労力の見積もり- そうではありません。私の組織では、見積もりは目標のコードです。. プロジェクトの期日は、ウォーターフォール開発のプロジェクトの 5 つの「アジャイル」フェーズの最初の段階で固定されます。これらの期日は「概算見積もり」と呼ばれますが、実際には「発送日」を意味します。
  • チームサイズ- 製品に基づいて全範囲を実行します。マネージャーを含めると、4 人から 15 人までのチームがあります。
  • 会議- 比較的後輩で、1 つまたは 2 つの製品に取り組んでいない場合は悪くありません。週に 2 ～ 3 回の 1 時間の会議に出席するだけで済みます。
  • コード メトリクス- いいえ。
  • 静的コード分析- 理論的には .Net b/c には FxCop が組み込まれており、その使用は標準で義務付けられていますが、実際にはありません。コードレビューがないため、誰もチェックしません。今年の認証が何であれ、失われないようにするための時折の品質監査（別名、紙の証跡/非難監査）。
  • バグの追跡- はい。ただし、顧客から報告された問題のみが対象です。開発者は、「チーム プレーヤー」ではない b/c に取り組んでいる製品に対して発見されたバグを送信することはできません。(私の上司の上司は、私がその間違いを犯したときに、これを非常に詳細に説明してくれました。現在、私は他のサポート関連のコミュニケーションの過程で「偶然」言及する可能性のあるバグを「発見」することをいとわない特定の顧客と友好的です。 .)

大規模な企業の開発者ではない限り、もっと悪いところがあります。私が住んでいる場所と、この地域にはハイテク関連の仕事が不足していることを考えると、ギグを持てて本当に幸運です。とはいえ、物事が好きでなければならないというわけではありません。確立された企業文化に影響を与えようとするだけでも、多くの時間と絶え間ないプレッシャーが必要です。

しかし、彼らが文化を変えようとする私の試みにうんざりして私をクビにしたとしても、私はその夜眠るために泣いたりはしないと思います.

于 2008-10-23T13:18:46.260 に答える
5

有名なBig Ball of Mudパターンは、多くの作業環境を説明しており、この種の問題に対処する方法についていくつかの良いアイデアを与えてくれると思います。

ところで、私はあなたの質問に直接答えていないことは承知していますが、開発状況の憂鬱なほど大きな割合で泥の大きなボールが優勢です。テスト駆動開発や欠陥追跡などについて質問することはできますが、私が見たものから真実が語られるとすれば、ビッグ ボール オブ 泥は、人々が働く事実上の方法であると言えます。 -- すべきかすべきでないか。

于 2008-10-23T12:45:01.817 に答える
2
  • テスト駆動開発 - もうすぐです。
  • ドメイン駆動設計 - いいえ
  • モデル駆動型設計/アーキテクチャ - いいえ
  • テストしますか？- はい
  • 単体テスト - はい
  • 統合テスト - はい
  • 受け入れテスト - いいえ
  • コード レビュー - いいえ
  • 革新的/新技術 (Spring、Hibernate、Wicket、JSF、WS、REST、...) - ASP.NET MVC? NHibernate? はい
  • アジャイル - 始めたばかり
  • ペアプログラミング - いいえ
  • UML - 正式なものはありません
  • ドメイン固有言語 - いいえ
  • 要件仕様 (どのように?) - はい。ストーリーの要件をキャプチャします。
  • 継続的統合 - はい。チームシティ
  • コード カバレッジ ツール - はい。Nカバー
  • Aenemic ドメイン モデル - いいえ
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - IM、電子メール
  • 工数の見積もり - 1,2,4,8
  • チームサイズ - 4
  • ミーティング - デイリースタンドアップ
  • コード メトリクス - いいえ
  • 静的コード分析 - いいえ
  • バグ追跡 - 既存のカスタム ジョブ

私の部署は進行中の作業です。過去数か月間、私は継続的な改善を強制する努力をしてきました。話すのが難しいこともあります。しかし、振り返ってみると、それらは改善されています。

于 2008-10-23T12:35:44.317 に答える
2
  • テスト駆動開発:いいえ。せいぜい、非常に小さな部分で。私たちは皆話しているが、それをしないでください。
  • ドメイン駆動設計:いいえ。技術的なフレームワークを開発している場合、「ドメイン」が何であるかを知るのは困難です。DDD の使用方法を知るには、DDD の経験があまりありません。
  • モデル駆動設計/アーキテクチャ:いいえ。
  • テストしますか?:はい、しかし十分ではありません。リリースごとに (8 週間ごとにマイナー リリースをプッシュしようとしています)、常に 2 つ以上のサービス リリースがあります。商品開発1年目なので、そこそこいけると思います。
  • 単体テスト:はい。約で。30% のカバレッジ。ほとんどの開発者は、自分で単体テストを作成する必要があることを知っています。自分のコードの重大なバグを修正する必要があるたびに、最初にバグを防ぐために簡単なテストを事前に書いていれば、その利点を実感できます。
  • 統合テスト:はい、Selenium と WebDriver を使用します。
  • パフォーマンス テスト:はい、今から始めます。目標は、長期的なパフォーマンス測定値をアーカイブし、リリースと比較することです。そのための JMeter と専用のパフォーマンス テスト サーバーを使用します。
  • 受け入れテスト:そうではありませんが、私たちの製品は社内でも使用されており、リリース前にかなり早くフィードバックを受けています。私はそれを受け入れテストとみなします。
  • コード レビュー:いいえ。時々、他の誰かがそれを 30 分間見ますが、それだけです。
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST、...):私の視点から見ると、これらのテクノロジーはもはや「革新的」ではありません。彼らは今ではかなり古い学校です。数年前に亡くなったJSFを除いて。過去数年間、Spring + Hibernate を実行しました。現在、Wicket + WS を 2 年間行っています。Hibernate を iBatis SqlMaps に置き換えました。
  • アジャイル:いいえ。
  • ペアプログラミング:いいえ。
  • UML:主に配置図用に少し。クラス図は細かすぎて、現実と同期していないことがよくあります。開発者は、UML ダイアグラムが指示することではなく、自分が最善だと思うことを行います。
  • ドメイン固有言語:はい、独自のビジネス ルール テクノロジを使用しています。これは、エンドユーザーに適したビジュアル DSL です。Visio を使用して意思決定をモデル化するようなものです。
  • 要件仕様 (どのように?):いいえ。
  • 継続的インテグレーション:はい。Hudson と Maven に基づいています。単体テストはビルドごとに実行されます。より詳細なレポートが有効になっている追加のナイトリー ビルド。失敗したビルドについてチーム全体に通知されます (そうです、何かがチェーンを壊し、30 個のサブモジュールすべてがビルドに失敗した場合、たとえば、Maven リポジトリに到達できない場合に、時々あまりにも多くのメールを受け取ることについて不満を漏らします)
  • コード カバレッジ ツール:はい。Maven/Cobertura およびソナー。
  • Aenemic ドメイン モデル:これがどうあるべきかわかりません。
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント): Wiki、メール、IM、毎日のスタンドアップ ミーティング、プロ/非開発者によって書かれたエンドユーザーおよび開発者のマニュアル。
  • 見積もりの​​努力:良い見積もりをしようと懸命に努力すること。ただし、要件がなければ、それらは単なる概算です。ただし、リソース計画には十分です。
  • チームサイズ: 12
  • ミーティング:毎日のスタンドアップ、各マイナー リリース後の 8 週間ごとの振り返り。
  • コード メトリクス:ソナー。ほとんどのルールを順守することを目指しています。ただし、ニーズに合わせてルールを再構成する時間がありませんでした。
  • 静的コード分析:ソナー。
  • バグ追跡: JIRA

ノート：

  • Sonar はコード品質サーバーです。PMD、Findbugs、Checkstyle などのツールを組み合わせています。
于 2009-11-01T22:15:48.020 に答える
2
  • テスト駆動開発: はい
  • ドメイン駆動設計: はい
  • モデル駆動型設計/アーキテクチャ: はい
  • テストしますか？はい
  • 単体テスト - はい
  • 統合テスト - はい
  • 受け入れテスト - はい
  • コードレビュー - はい
  • 革新的なテクノロジー - はい
  • アジャイル - アジャイルのみ
  • ペアプログラミング - はい
  • UML - 場合によっては ddd ホワイトボードでの戦い
  • ドメイン固有の言語 - はい
  • 要件仕様 (どのように?) - 例と受け入れテストの形式で
  • 継続的インテグレーション - はい - TeamCity
  • コード カバレッジ ツール - はい - NCover
  • Aenemic ドメイン モデル - 不明
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - wiki、メール、msn
  • チームの規模 - 6 名以上 (プロジェクトによって異なります)
  • ミーティング - 毎朝 9:30 - SCRUM
  • コード メトリクス - わからない
  • 静的コード分析 - わからない
  • バグ追跡 - マンティス

最も重要な...

  • 5時半に全員帰宅：YES

しかし、この会社で働きたいという人が多いため、給与はかなり低くなっています。全部ありえない！

于 2008-12-08T13:52:42.583 に答える
1
  • テスト駆動開発-これがコードの前にテストを書くことを意味する場合、常にではありません
  • ドメイン駆動設計-純粋なDDDではありません
  • モデル駆動型の設計/アーキテクチャ-決して、しかし実際には決して、二度と
  • テストしますか？- はい、いつも
  • ユニットテスト-はい、常に
  • 統合テスト-状況によって異なりますが、通常は遅いため、回避しようとしています。
  • 検収試験-はい、理想的には自動化されています
  • コードレビュー-はい、これは完了の定義に含まれています
  • 革新的なテクノロジー（Spring、Hibernate、Wicket、JSF、WS、RESTなど）-言及されたテクノロジーが革新的であるかどうかはわかりませんが、Spring、Hibernate、WSには当てはまります
  • アジャイル-はい、これは私のDNAにあります
  • ペアプログラミング-常にではありませんが、はい（明示的に求められた場合、新しい主題について、新しいチームメンバーと）
  • UML-少し（つまり、ホワイトボード上のクラスまたはシーケンス図）、役立つ場合のみ
  • ドメイン固有言語-今まで実際の使用法はありません
  • 要件仕様（どのように？）-軽量仕様（例：ユーザーストーリー）
  • 継続的インテグレーション-もちろん（そして、doneの定義によれば、コードは「統合」されている必要があります）
  • コードカバレッジツール-はい（cobertura）、これは完了の定義にあります
  • Aenemic Domain Model-いいえ、それを避けようとしています
  • コミュニケーション（Wiki、メール、IM、メーリングリスト、その他のドキュメント）-対面、Wiki、IM、メール、メーリングリスト（ただし、単語ドキュメントは避けます）
  • 労力の見積もり-はい、バックログレベルのストーリーポイントで、イテレーションレベルの時間で
  • チームサイズ-7+/-2
  • ミーティング-はい。ただし、有用なのは1つだけで、常にタイムボックス化されています（反復計画、毎日のミーティング、デモ、回顧）
  • コードメトリクス-はい（循環的複雑度、コードカバレッジ、ソナーで収集されたコーディング標準）
  • 静的コード分析-はい（findbugs、checkstyle）
  • バグ追跡-はい、もちろんです（ただし、バグを発見したらすぐに修正しようとします）
于 2009-11-01T19:51:41.663 に答える
1
  • テスト駆動開発-いいえ
  • ドメイン駆動設計-いいえ
  • モデル駆動型-設計/アーキテクチャ-いいえ
  • テストしますか？- ほとんどは決してない
  • ユニットテスト-ほとんどありません
  • 統合テスト-いいえ
  • 検収試験-いいえ
  • コードレビュー-いいえ
  • 革新的なテクノロジー（Spring、Hibernate、Wicket、JSF、WS、REST、...）-Spring、Hibernate、Wicket
  • アジャイル-いいえ
  • ペアプログラミング-いいえ
  • UML-スケッチだけ
  • ドメイン固有言語-いいえ
  • 要件仕様（どのように？）-膨大な顧客要件仕様を取得し、マインドマップを使用して実際の機能を抽出し、それを推定します
  • 継続的インテグレーション-いいえ
  • コードカバレッジツール-いいえ
  • Aenemicドメインモデル-はい
  • コミュニケーション（Wiki、メール、IM、メーリングリスト、その他のドキュメント）-マインドマップ、メール
  • 労力の見積もり-FITA（空中の指、ここを参照）
  • チームサイズ-2-6
  • ミーティング-週に2〜3回
  • コードメトリクス-いいえ
  • 静的コード分析-いいえ（FindBugsとCheckstyleを試しました）
  • バグ追跡-はい、Bugzilla
于 2008-10-23T12:00:04.530 に答える
1

申し訳ありませんが:) グッドプラクティスを実際に理解して使用するには、常に実践的なグッドプラクティスを実践する必要があるため、働くには良い環境ではありません。

あなたのリストのすべての「良い」ボックスにチェックを入れることができる会社をいくつか（私のものも含めて）知っています。

ただし、問題は詳細にあり、優れた SDP ポリシーを備えた一部の企業でさえ、すべてのプロジェクトがそれに従っているわけではありません。

于 2008-10-23T12:19:09.407 に答える
1
  • Test-Driven-Development - これは持ち込もうとしていたはずですが、うまくいったとは思わないので、これはまだいいえですが、詳細が追加されました。
  • ドメイン駆動設計 - いいえ
  • モデル駆動型設計/アーキテクチャ - いいえ
  • テストしますか？- はい、しかし包括的ではありません。いくつかの単体テスト、いくつかの統合テスト、いくつかの WatiN テストがあります。
  • 単体テスト - 新しい開発用にいくつかありますが、従来のものにはありません。
  • 統合テスト - 通常、該当する場合。私のチームはウェブチームであり、これはまだあまり頻繁に行われていないようです.
  • 受け入れテスト - これにはいくつかのレベルがあります。1 つ目は、新しい機能が開発されていて、コードに統合される前のコンテンツを入力する別のチームの誰かから最初の承認を得る必要がある場合です。2 つ目は、スプリントの最後に機能のデモンストレーションを行い、何が正しくないか、またはうまく機能していないかについて、より多くのフィードバックを得る場合です。それから本番に入る直前に第 3 レベルがあります。
  • コード レビュー - これらはもう行われていませんが、おそらく良いことです。
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST など) - 私たちのプロジェクトにはいくつかの RESTful なアイデアが適用されており、ラムダ式などの .Net フレームワークのいくつかの機能を使用しています。
  • アジャイル - スクラムを使用し、スタンドアップ、ストーリー ボード、イテレーション計画ミーティングを行います (これは実際にはスプリント用であり、2 つのスプリントのイテレーションではありません。スプリントの各ペアの後、エグゼクティブや他の部門に作業が示され、他のデモが行われるためです)。アーキテクトおよびコンテンツ入力チームの責任者向けです。)
  • ペア プログラミング - ほとんどの新しい開発では、単調な作業とは見なされないペアリングがあります。したがって、サイトのトレーニング部分に取り組みたい人は、1 人の開発者ではなく、2 人で行うことになります。
  • UML - いいえ、UML 用のツールは新しいマシンから削除されました
  • ドメイン固有言語 - いいえ。ただし、社内製品の名前が、他の人がさまざまなことに使用する可能性のある用語と衝突するため、会社独自の解釈である用語がいくつかあります。
  • 要件仕様 (どのように?) - これは、何をする必要があるかを綴った大きな単語のドキュメントから、何をすべきかについての会話まで、さまざまです。
  • 継続的な統合 - コードの変更をコミットするときに使用する CI 用に Cruise Control.Net を実行しています。
  • コード カバレッジ ツール - いいえ。
  • Aenemic ドメイン モデル - 実際には大きなドメイン モデルはありません。
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - 重要度の高い順に、電子メール、IM、電話、訪問キュービクル。アプリケーションのマネージャーとの毎週のチームミーティングと、大きなプロジェクトに関する毎日のスタンドアップがあります。
  • 作業量の見積もり - これは現在、各スプリントで一般的ですが、スクラム マスターが最終的に確認できるようにすべての結果を組み合わせて見積もりを記入するスプレッド シートを全員に送信することによって行われることもあります。
  • チームの規模 - チーム リーダーを含む 5 人の開発者、スクラム マスターであるビジネス アナリスト、私たちが持っているものを監督するテスター、および実際にシステムを使用するコンテンツ作成者を含む、必要に応じてポップアップするチーム外の他の人。
  • ミーティング - ビジネスに即したもので、短く、効果的で、現在の状況を伝えるのに適しています。
  • コード メトリクス - 私が知っているものはありません。
  • 静的コード分析 - いいえ。
  • バグの追跡 - Quality Center は、欠陥の追跡に使用されます。 * ソース管理 - 現在 Subversion を使用しています。機能やバグについては、新しいブランチを作成して、独立して作業できるようにし、何かに取り組んでいるときにコミットがビルドを壊さないようにします。ただし、私たちは皆、開発用に同じ DB を共有しているため、興味深いことがあります。
  • IDE - .Net 3.5 および Sitecore 6.1 を使用する XP 上の Visual Studio 2008
  • ...

チームは、私がここにいるほぼ 2 年間で 3 番目のチームリーダーです。

CMS プロジェクトは、私たち全員が取り組んでいる大きなプロジェクトですが、他の人が処理するさまざまなサポート要求があります。

IS 担当副社長が就任した年には、多くの変化がありました。プロダクションはよりロックダウンされており、リリースを完了するための作業が増えています。これは、チェック リストの手順があり、役立つ可能性のあるフープが増えているためです。

于 2008-10-23T15:38:55.883 に答える
1

私は南アフリカの Chillisoft.co.za で働いています

テスト駆動開発: 最初の Kent Beck Book からテスト駆動開発プラクティスを使用してきました。テスト ランナーとして NUnit と R# を使用します。

テストしますか？: TDD に加えて、手動テスト (ビジュアル) を行い、必要に応じて自動化します。自動化に使用されるテクノロジーは、UI テクノロジーに依存します。

単体テスト: TDD を参照してください。

統合テスト: はい。ただし、まだ広く使用されているわけではありません。

受け入れテスト: 外部の顧客向けにカスタム ソフトウェア開発を行います。受け入れられるまで支払いはありません。

コード レビュー: プロジェクトごとに隔月でスケジュールされます。ペア/ピアプログラムされたものでも。

ペア プログラミング: ほとんどのコーディングはペアで行いますが、プロジェクトのいくつかのタスクや段階では、これが非効率的であることは確かです。私たちがしているのは、プロジェクトの開始時 (各フェーズの最初の数週間) で、プログラムをペアリングします。仕上げ段階ではありません。また、オープンソース プロジェクトに取り組む特定の時間 (開発者 1 人あたり週 8 時間) もあり、これらはすべてペア プログラムです。私たちのすべてのマシンは、開発者間のスムーズなやり取りを容易にするために、複数のキーボードとマウスでセットアップされています。

革新的なテクノロジー: 私たちはHabaneroで多くの作業を行い、このフレームワークを DI コンテナー Unity および RhinoMocks と共に使用しています。

アジャイル: 私たちはアジャイル哲学を 8 年間使用しており、この道を進みながら、ツールと哲学の実験を続けています。

要件仕様 (どのように?) : MSWord での次の反復のために、ユーザー ストーリー (ユース ケース) をキャプチャします。次に、これらの要約を Jeera に取り込んで、グラフの作成などを管理する作業見積もりなどを作成します。

継続的統合: 現在、SVN 上で動作する Hudson を使用しています。

コード カバレッジ ツール: ナイトリー ビルドの一部として、すべてのプロジェクトのコード カバレッジを実行します。結果のレポートを Hudson レポートに統合して、すべてのプロジェクトについて毎日これらを追跡できるようにしました。

コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) : 明らかに、内部 Wiki などを使用してさまざまな方法でコミュニケーションをとっています。

チームの規模: 15 人のソフトウェア開発者がいます。

ミーティング: 毎朝約 10 分間の「スクラム」があります。

バグ追跡: 内部バグ追跡 (開発中および内部テスト中) と外部バグ追跡 (顧客からのバグ) には異なるシステムを使用しています。内部追跡 (つまり、内部テストおよび開発中) には redmine を使用します。外部追跡 (つまり、お客様の場合) は Mantis を使用しています。

于 2010-01-27T13:02:40.170 に答える
1

私はオーストラリアのブリスベンにある Ruby on Rails のコンサルタント会社で働いています。

  • テスト駆動開発: これは、私たちのオフィスで非常に熱心に推進されています。テストしないことは「信じられないほど愚か」と見なされます。コードを書き、CI などの自動化されたプロセスを介して、それが引き続き機能することをどのように保証しますか? テスト。

  • テストしますか？: ポイント 1 を参照してください。

  • 単体テスト: RSpec を使用して常に。私は Test::Unit と Shoulda にも「堪能」です。

  • 統合テスト: 繰り返しになりますが、Cucumber です。

  • 受け入れテスト: 私たちのチケットでは、受け入れ基準を付けて「配信」します。次に、クライアントは跳ねるボールをたどって、それらを「受け入れる」か「拒否する」必要があります。Acceptance Criteria には、Cucumber の機能が記述されているものでもあるというボーナスがあります。

  • コード レビュー && ペア プログラミング: ペアリングします。これは、コード レビューのインスタント バージョンです。座って他の誰かが作業しているのを見て、彼らがテストを書き、そのテストに合格するコードを書くことができるのは素晴らしいことです。あなたが病気の場合、他の人はあなたが何をしていたかを知っており、他の人とペアを組むことができます.

  • Innovative Technologies : Rails を使用しているため、REST が非常に気に入っています。

  • アジャイル: Pivotal Trackerを使用して 2 週間のイテレーションに取り組んでいます。

  • 要件仕様 (どのように?) : Pivotal Tracker の機能を使用して、クライアントはどのような要件を持っているかを指定できます。次に、(通常は顧客と話し合うことによって) それらを受け入れ基準に肉付けし、最終的には実世界の機能にします。

  • 継続的統合:私が開発したconstructというCIサーバーを使用しています。これは Integrity に似ているという考えで構築されましたが、バックグラウンド ジョブとブランチのサポートが向上しています。Integrity にはバックグラウンド ビルドが用意されていますが、まだ分岐サポートがあり、私たちを「先へ」進めています。

  • コード カバレッジ ツール: RCov の場合もあります。私たちはコードを書く前にすべてをテストするので、コードカバレッジにあまりこだわっていません。存在する場合は、それをテストするものがあります。

  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) : クライアントとは主に電子メールを使用してやり取りしますが、Skype を使用してクライアントとの「スタンドアップ」も行います。これにも Basecamp を使用しました。ちょっとした実験として、次のプロジェクトで Google Wave を使用したいと考えています。本当に役立つと思います。

  • チームの規模: 私たちのチームは 4 人で構成されており、誰かが病気でない限り、通常は 2 組です。

  • ミーティング: 午前中に約 15 分間の「スクラム」/「スタンドアップ」があります。これの考え方は、前日にやったこと、遭遇した問題、今日やろうとしていること、そして見つけた「新しくて輝かしい」何かを振り返ることです. これがプロジェクト会議になってはいけません。これらは、必要に応じてスタンドアップ後に使用します。
  • バグ追跡: ここでも Pivotal Tracker を使用しています。クライアントはここでバグを報告し、(理想的には) それを複製する方法を書くことができます。次に、これが二度と起こらないようにするためのテスト (別名: 回帰テスト) を作成し、機能と同じ作業プロセスを経て、提供し、クライアントが受け入れます。
于 2009-12-05T04:37:54.627 に答える
0

私の会社は、ほとんどの「流行語」の方法論に飛びつきました。単体テスト、テスト駆動開発、スクラム、アジャイル、継続的インテグレーション、コードカバレッジ分析など。経済によってチームの規模が変化するにつれて、製品から製品へと飛躍していることがわかりました。たくさんのレイオフの後、Rally Dev/ScrumからJira/Agileに移行しました。自動テストにはSeleniumを使用していますが、現在はTelleniumとGoogleのWebDriverを検討しています。

私たちは何を見つけていますか？そのために作成されたすべてのテスト（負荷テストを含む）に合格したサイトは、真に分析すると非常に非効率になる可能性があります。コードパフォーマンス分析の結果、サイトの1つでサーバーリソースを2/3削減することができましたが、それでもパフォーマンスは向上しました。それでも同じテストに合格しました。

フロントエンドの自動テストでは、人間が数秒で気付くようなポジショニングの問題は検出されません。確かに、ポジショニングをチェックするためのテストを書くのに数時間を費やすことができます。ただし、テストは脆弱であり、ページレイアウトが少しでも変更された場合は、書き直す必要があります。テストは通常​​、コードがどれだけ優れているかではなく、コードが機能していることを示しているだけです。

私は多くの異なるテクノロジーを使用して大小の企業で働いてきました。シンプルな「カウボーイコーディング」を含みます。計画とテストの方法論を採用しなかった場合、さらに多くのバグが発生しましたが、より迅速に移行しました。変更と修正は、数日と数週間ではなく、数時間でプッシュされました。

Facebookは毎週（火曜日）「プッシュ」を行います。多くの場合、最新のコードプッシュにはバグがありますが（テストが不十分ですか？）、問題を修正するために、木曜日または金曜日までに別のプッシュを実行することがよくあります。私の推測では、Facebookは「カウボーイコーディング」方法論に近く、彼らのために働いています。

于 2009-06-18T13:44:41.987 に答える
0
  • テスト駆動開発-いいえ、意図的に。
  • ドメイン駆動設計-いいえ、まだドメインを把握しています。
  • モデル駆動型-設計/アーキテクチャ-いいえ
  • テストしますか？-ビルドをテストし、パワーユーザーにテストしてもらいます。
  • ユニットテスト-正式なものはありません（nUnitなどはありません）
  • 統合テスト-いいえ
  • 検収試験-はい
  • コードレビュー-時折。
  • 革新的なテクノロジー-ランダムなSharePointツール
  • アジャイル-はい
  • ペアプログラミング-いいえ
  • UML-決して
  • ドメイン固有言語-いいえ
  • 要件仕様（どのように？）-私たちはこれを軽視し、繰り返します。いくつかの要件分析を行うBAがありますが、通常は、計画と毎日の会議にお客様を招待するだけです。正式なドキュメントはありません。
  • 継続的インテグレーション-はい（cruisecontrol.net）
  • コードカバレッジツール-いいえ（ただし、Visual Studio Code Analysisを使用しています）
  • コミュニケーション-展望
  • 努力の見積もり-球場、それを2倍にしてから、もう一度2倍にします。
  • チームサイズ-2-4
  • ミーティング-毎日午前9時（スクラム！）に加えて、毎週の計画/レビューミーティング
  • コードメトリクス-いいえ
  • バグ追跡-Bugzilla
  • ソース管理-SVN
于 2009-06-18T19:38:06.603 に答える
0
  • テスト駆動開発 - いいえ
  • ドメイン駆動設計 - いいえ
  • モデル駆動型設計/アーキテクチャ - いいえ
  • テストしますか？- 時々
  • 単体テスト - ほとんどない
  • 統合テスト - はい
  • 受け入れテスト - 時々
  • コードレビュー - たまにしか
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST など) - いいえ
  • アジャイル - いいえ
  • ペアプログラミング - いいえ
  • UML - 私のマーカー ボードでは、はい。
  • ドメイン固有言語 - C++ はドメイン固有ですよね?
  • 要件仕様 (どのように?) - 私たちはそれらを満たしていると思います。
  • 継続的統合 - はい
  • コード カバレッジ ツール - いいえ
  • Aenemic ドメイン モデル - ドメイン モデルとは
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - メールと Skype。ウィキとは？
  • 工数の見積もり - 特定のタスクで 1 ～ 2 日
  • チームの規模 - ソフトウェア エンジニア 2 名、ハードウェア エンジニア 10 名
  • ミーティング - 週2回
  • コード メトリクス - いいえ
  • 静的コード分析 - いいえ
  • バグ追跡 - いいえ
于 2008-10-23T12:24:27.337 に答える
0
  • テスト駆動開発 - はい
  • ドメイン駆動設計 - いいえ
  • モデル駆動型設計/アーキテクチャ - いいえ
  • テストしますか？- はい
  • 単体テスト - はい
  • 統合テスト - はい
  • 受け入れテスト - 開始済み
  • コード レビュー - いいえ
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST など) - いいえ?
  • アジャイル - はい
  • ペアプログラミング - はい、ほとんどの場合
  • UML - ホワイトボードの線とボックスほど正式なものはありません。
  • ドメイン固有言語 - 少し
  • 要件仕様 (どのように?) - いいえ、可能であればユーザー ストーリーを取得しようとします。
  • 継続的統合 - はい
  • コード カバレッジ ツール - いいえ
  • Aenemic ドメイン モデル -
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他の文書) - Wiki、IM、電子メール、Word Docs
  • エフォートの見積もり - T シャツのサイズ (S、M、L、XL など) と、スプリント速度によるスプリントのポイント システムを組み合わせて使用​​します。
  • チームサイズ - 6->8
  • ミーティング - デイリースタンドアップ
  • コード メトリクス - いいえ
  • 静的コード分析 - いいえ
  • バグ追跡 - Bugzilla / バージョン 1
于 2008-10-23T12:25:54.167 に答える
0
  • テスト駆動開発: 非常にまれに、誰かがコンポーネントのためにそれを行うことがあります。また、コンフォーマンス テストに付属する公開仕様を実装すると、TDD の利点の一部が提供されます。
  • ドメイン駆動設計: いいえ
  • モデル駆動型設計/アーキテクチャ: いいえ
  • テストしますか?: はい
  • 単体テスト: いくつかありますが、完全ではありません。コンポーネントの多くは、顧客が使用するライブラリです。「strlen」実装の単体テストと機能テストの間には微妙な境界線があります。
  • 統合テスト: そうではありません。単体テストとシステム テストの間にはほとんどありません。
  • 受け入れテスト: はい、システム テストとして使用される受け入れテストのサブセット
  • コード レビュー: 正式なプロセスはありませんが、一部のコードはレビューされます
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST など): いいえ
  • アジャイル: いいえ
  • ペアプログラミング: いいえ
  • UML: いいえ
  • ドメイン固有言語: ごくまれに
  • 要件仕様 (どのように?): 一種の
  • 継続的インテグレーション: いいえ、ただし、テスト チームの裁量で、毎日のビルドと障害の原因となる変更の復帰
  • コード カバレッジ ツール: 正式な要件はありません。テスト チームはこれらを使用することが知られています。
  • Aenemic Domain Model: これが何かもわからない
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント): 要件と設計ドキュメントはソース管理下の HTML でなければならず、ヘッダーの Doxygen コメントから内部インターフェイス ドキュメントが生成されることを除いて、アドホックに選択されたすべてのドキュメント。
  • 労力の見積もり: 少し
  • チームの規模: 約 20 人のプログラマーが、1 ～ 4 人のコンポーネント チームにさまざまにグループ化されています。自分が所属するチームのコンポーネントだけに専念する人はほとんどいません。
  • ミーティング: 進捗報告を交換したり、その他の方法で何が起こっているかを共有するための毎週の完全なミーティング。開発者向けの定期的な会議は他にありません。必要に応じて議論が行われます。
  • コード メトリクス: いいえ
  • 静的コード分析: あなたが数えない限り、そうではありません -pedantic ;-)
  • バグ追跡: Bugzilla、ソース管理とある程度統合
于 2008-10-23T12:30:06.030 に答える
0

•テスト駆動開発 - 引き継がれ始めたばかりですが、これまでのところ非常に満足しています

•テストしますか？- もちろん、誰もがそうです。QA に笑われたい人はいますか?

•単体テスト - 約 2 年間、安定性に役立っており、テストはビルドごとに実行されます。

•コードレビュー - あちこち、特に最近の変更

•アジャイル - アジャイルとその応答性が大好き

•ペアプログラミング - いくつかのスポットで試してみるだけで、早期リターンが期待できます

•継続的な統合 - 勝利のための CruiseControl.NET !!! そのような大きな助け

•コード カバレッジ ツール - ユニット テストの実行中は常に、CC.NET はこの情報を世界中に公開します。

•コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - WIKI、IM、Campfire

•チームの規模 - 小規模ですが、製品チームが大きくなると機能チームに分割されます

•会議 - 短くて頻繁ではないため、廊下で集まる可能性が高くなります

•コード メトリクス - 循環的複雑度のみ

•静的コード分析 - 実際にこれを試してみてください もっと FxCop と VSTS の自家製のものを使用してください

•バグ追跡 - Windows 用の TFS と Mac 用の Traq

于 2008-10-23T12:31:57.553 に答える
0

ここに私の観察があります：

  • テスト駆動開発 : いいえ

  • ドメイン駆動設計 : はい

  • モデル駆動型設計/アーキテクチャ : はい

  • テストしますか？： はい

  • 単体テスト: はい

  • 統合テスト: はい

  • 受け入れテスト : はい

  • コード レビュー : いいえ

  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST、...): はい

  • アジャイル ペア プログラミング : いいえ

  • UML : はい

  • ドメイン固有の言語: はい

  • 要件仕様 (どのように?) はい

  • 継続的な統合: はい

  • コード カバレッジ ツール : いいえ

  • Aenemic Domain Model : いいえ (これはどういう意味ですか?)

  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他の文書) : Wiki、メール、IM、メーリングリスト

  • 工数の見積もり : はい

  • チームサイズ : 2～4 人

  • ミーティング : 毎週月曜日は固定ミーティング、隔日はフローティング ミーティング

  • コード メトリクス : はい

  • 静的コード分析: いいえ

  • バグ追跡 : はい

于 2009-11-01T19:17:11.140 に答える
0
  • テスト駆動開発: いいえ。
  • ドメイン駆動設計: いいえ
  • モデル駆動設計/アーキテクチャ: アプリのモデルから始めます
  • テストしますか？はい。時々、自分のものをテストするのは私だけです。私はこれが嫌いです。
  • 単体テスト - いいえ。これは、私のスキルセットに欠けている領域であり、是正することの優先度が高いと考えています。
  • 統合テスト - いいえ
  • 受け入れテスト - 時々。On High からの脅威があっても、ユーザーにそれをやり遂げさせるのは困難です。
  • コード レビュー - いいえ。私たちはそれを行うことについて話し合いましたが、最終的には決して行いません. 私はこれに不満を感じています。
  • 革新的なテクノロジー - いいえ
  • アジャイル - 私たちはやや機敏ですが、事前に熟考した努力によるものではありません
  • ペアプログラミング - いいえ
  • UML - 必要最小限ですが、モデル化します (ここではより意図的にアジャイルにしています)。
  • ドメイン固有言語 - いいえ
  • 要件仕様 (どのように?) - 私たちはそうします。私のグループは、主に要件の収集を担当することがあります。現在は通常、ビジネス アナリストの支援を受けていますが、常にそうだったわけではありません。Veep は、どこから来たのか分からない要件を私たちに渡すことがあります。時には、それらは決して行われなかった古いことですが、何年も前に計画されていました. 通常、収集された要件は、主要なユーザーだけでなく、私のチーム、ビジネス アナリスト、および Veep によってレビューされた Word ドキュメントに配置されます。
  • 継続的統合 - いいえ
  • コード カバレッジ ツール - いいえ
  • Aenemic Domain Model - 私は彼のことはよく知りませんが、違います。
  • コミュニケーション (Wiki、メール、IM、メーリングリスト、その他のドキュメント) - メールと対面のみ。私は最近、もっと何か、できれば wiki を行う必要があるため、この件を打ち明けました。バックバーナーに載せました。
  • 作業量の見積もり - はい。ただし、実際に追跡する試みは行っていません。これは私が欠けている別の領域です。
  • チームの人数 - 3 人、私も含めて (ディレクター <- チーム リーダー <- 私)。
  • ミーティング - 常にではありませんが、週に 1 回ミーティングを行います。上司は通常、少なくとも週に数回、個別にチェックインします。大規模なグループ会議は散発的に行われます。そしてもちろん、必要に応じてプロジェクトの要件を明確にするための会議をスケジュールします。
  • コード メトリクス - いいえ
  • 静的コード分析 - いいえ
  • バグ追跡 - エラーを記録します。それが私たちのバグ追跡です。

それでおしまい。改善できると思う分野があります。

アップデート：

私がこれを投稿してから数週間後 (2008 年 11 月初旬)、ビジネス アナリストを大規模なレイオフで失いました。それ以来、私は既存のアプリケーションに ELMAH を実装し、バグ追跡を支援するために最近開発したアプリケーションに ELMAH を実装しました (データベースにもログを記録します)。使いやすさ、機能、および例外をキャッチする機能が気に入っていますキャッチしません（ほとんど使用されていませんが、それでも十分なカバレッジがあります）。私はまだ自分で単体テストをいじっています-私は本当にそこでペースを上げる必要があります（MVCも学びたいですが、ほとんどそれもいじっています）。

現在、新しいアプリケーションを設計しており、6 つのモジュールのうちの 3 つのモジュール (チーム リーダーが他の 3 つに取り組んでいます) のモック DB スキーマ (いくつかの基本的な図を取得します) を作成しています。これは、IronSpeed Designer (6.1) を使用して 3 人 (それぞれ 2 つのモジュール) によってタンデムで開発されるため、楽しみではありません。IronSpeed には、私が好きなことがいくつかありますが、これらのことを迅速に行う唯一の方法ではありません。

他に何も変わっていません。

于 2008-10-23T15:47:04.057 に答える
0

NDepend を見ましたか？このツールは C# および .NET コードを分析し、分析結果を閲覧するための優れた機能を多数備えています。NDepend を使用すると、コードにルールを記述したり、コード ベースの 2 つのバージョンを比較したり、 80を超えるコード メトリクスを利用したりできます。

また、このツールには、次のようないくつかの優れた視覚化機能が付属しています。

依存関係グラフ: 代替テキスト

依存関係マトリックス: 代替テキスト

ツリーマッピングによるコード メトリックの視覚化: 代替テキスト

于 2010-10-18T18:09:52.573 に答える
0

テスト: 私は多くのシステム テストを行い、ユニット テストははるかに少ない量で行います。理にかなっている場合はテスト駆動開発を使用するようにしていますが、ほとんどの場合、自分がやっていることの核心には意味がないように感じます.

残りの部分については、「ドメイン固有言語」を適切に実行しているかどうかはわかりませんが、自動生成されたコードを大量に使用して、仕事の繰り返しをキャプチャしています。9 つの Perl スクリプトを数えると、ほぼ100,000 行のコード。

それ以外については、チームのサイズは常に 1 です。私は PC-Lint を静的コード分析に年に 1 回程度使用しています。私は gprof と valgrind をかなり頻繁に使用しています (このクラスのツールについて言及していないようです)。私は何年もの間、適切なバグ トラッカー システムを切望してきましたが、現時点ではまだ To Do リスト ソフトウェアと電子メールを使用して処理しています。

于 2008-10-23T12:32:15.993 に答える
-1

MDA、DDD、およびペア プログラミングがどこにも使用されていないと聞いてうれしいです:D Martin Fowler は神ではありません。

  • テスト駆動開発 - 必要に応じて
  • 単体テスト - はい
  • コードレビュー - ちょっと
  • 革新的なテクノロジー (Spring、Hibernate、Wicket、JSF、WS、REST、...) - はい、Seam
  • UML - ちょっと
  • 継続的統合 - はい、いいえ
  • コード カバレッジ ツール - はい、いいえ
于 2008-10-23T12:49:42.900 に答える