タグ付けされた質問 「development-methodologies」

この質問では、例としてSpring Bootサービスを取り上げていますが、これはどのようなテクノロジーでもかまいません。 次のように仮定します。 環境（dev / QA / prod）は異なるチームによって所有されています。これは、開発者が製品構成にアクセスできないようにする必要があることを意味します。 構成（application.propertiesとしましょう）は外部化されています。つまり、バイナリの一部ではありません。 同じバイナリ/パッケージ（service.jarとしましょう）が各環境にデプロイされ、自動デプロイメントによって制御されます バイナリアーティファクト（service.jar）への変更は自動的に各環境に伝達されますが、構成への変更には依然として手動による介入が必要であり、必然的に各環境で非同期化されます。 たとえば、開発チームが環境内のapplication.propertiesにいくつかのキーと値のペアを追加するとします。これらの新しいキーを記録する最良の方法は何ですか？それで、運用チームで展開が行われるときに、追加するキーが正確にわかっているため、新しいサービスを開始し、キーが見つからないために失敗することを確認するリスクが最小限に抑えられますか？ 手動の手順が含まれることはわかっていますが、人々がこれをどのように処理し、最も効果的な方法を見つけるか知りたいです。

9 spring  development-environment  configuration  development-methodologies 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 この質問のタイトルが示すように、Javaをまったく使用せずにAndroidプラットフォームでアプリを開発できることを楽しみにしています。私がこの美しい言語に対して何らかの復讐をしたり、Javaでアプリを開発する方法がわからなかったりするわけではありません。しかし、私のアプリケーションはXML、JavaScript、およびAjaxを使用することによってのみ開発できると考えています。 それでも、Javaに依存する必要がありますか？ Javaを使用しないことのデメリットはありますか？ 今後もアプリを拡張できますか？ ここで本当に愚かな質問をしていますか？ 親切に私を助けてください。 編集： 私が取り組んでいるアプリ（まだホワイトボードにあり、このアプローチについて専門家の意見が必要です）は、さまざまなニュースソースからニュースをフェッチし、そのユーザーに表示します。

9 java  development-methodologies  android-development 

3組のテストスイートがあります。 実行に数時間しかかからない「小さな」スイート 複数時間かかる「中」のスイートで、通常は毎晩（毎晩）実行されます 実行に1週間以上かかる「大きな」スイート 短いテストスイートもたくさんありますが、ここではそれらに焦点を当てません。 現在の方法論は、トランクへの各コミットの前に小さなスイートを実行することです。次に、ミディアムスイートが毎晩実行され、午前中に失敗したことが判明した場合は、昨日のコミットのどれが原因であるかを特定し、そのコミットをロールバックして、テストを再試行します。大規模なスイートでは、同様のプロセスが、毎晩ではなく毎週のみ行われます。 残念ながら、ミディアムスイートはかなり頻繁に失敗します。つまり、トランクが不安定になることがよくあります。これは、変更を加えてテストするときに非常に煩わしいことです。トランクからチェックアウトするとき、それが安定していることを確実に知ることができず、テストが失敗した場合、それが私のせいかどうかを確実に知ることができないので、それは迷惑です。 私の質問は、トランクを常に最高の状態に保つような方法でこれらの種類の状況を処理するためのいくつかの既知の方法論がありますか？例：「特別な事前コミットブランチにコミットし、夜間が経過するたびにトランクを定期的に更新する」。 そして、それがSVNのような集中化されたソース管理システムであるか、gitのような分散型システムであるかは重要ですか？ ちなみに、私は物事を変更する能力が限られているジュニア開発者ですが、私が経験しているこの痛みに対処する方法があるかどうかを理解しようとしています。

9 testing  version-control  development-methodologies  branching 

私は新しい仕事に取り組んでいます。プロジェクトは厳しい品質基準を満たす必要があり、詳細に文書化され、非常に詳細に管理され、UMLダイアグラムなど、これまでのほとんどの仕事の経験である「カウボーイコーディング」とは反対のすべてのものです。 。大規模な航空宇宙または医療機器ソフトウェアの開発方法を考えてみてください。 カウボーイコーディングの混乱を残してよかったと思います。ヘビー級のエンジニアリング手法がどれほどうまくいくか知りたいです。しかし、どのようにして重いメソッドの経験を迅速に得ることができますか？ 単に数か月/数年の間仕事にいるだけでなく、それはです。 単なる言語、または新しいAPIで、おもちゃのテストプログラムをハックしたり、読んだり、意図的に間違いを起こして何が起こるかを確認したりできます。自転車に乗ったり楽器を演奏したりするのと同じように、練習は不可欠です。フルートを手に取り、毎日30分を費やすのは簡単です。オーケストラに参加したり、フルタイムのフルートコンサルタントになる必要はありません。しかし、大規模で複雑で、チームが関与するソフトウェアエンジニアリング活動をどのように実践するのでしょうか。そのほとんどは、コミュニケーションと計画、コミュニケーションの誤りの回避、およびスケジュールと予算の制限の超過に関するものです。 これは一人で行うことは不可能のようです。少数の人が大きなプロジェクト全体を短時間で（1日）小規模にエンジニアリングできる方法はありますか？

9 self-improvement  programming-practices  development-methodologies  engineering 

駆動設計/開発に関してドメインという言葉は何を意味しますか？ 意味論や学術的定義の観点からではなく、プロセスや哲学をどのように修正するかという観点からですか？ 私は投稿を読んでいました：https : //softwareengineering.stackexchange.com/questions/57828/your-software-problem-solution-approach 私はこの流行語DDDに出くわし、それが何を意味するのか本当に知りませんでした。

9 development-methodologies  domain-driven-design 

具体的には、大衆のアイデアが間違っている場所の例は何ですか。なぜ人々はなぜそもそもアイデアにとらわれたのですか？そして、なぜアイデアは却下されたのですか？あるいは、アイデアはまだ健在で、もしそうならなぜですか？ たとえば、CORBA（および他の同様のテクノロジ）を、ソフトウェアのコンポーネント間の通信の問題を解決しようとしたものと説明する場合があります。多くの人が、さまざまなコンポーネント間の契約を定義する必要があると感じました。最終的に、HTTP + JSONは大衆の問題を解決し、ThriftやProto-bufなどのさまざまなRPCメカニズムがポップアップしました。

9 development-methodologies 

私はBDDから始めて、これが私の話です。 Feature: Months and days to days In order to see months and days as days As a date conversion fan I need a webpage where users can enter days and months and convert them to days. 疑問があります... 何かをコーディングする前にシナリオを書くべきでしょうか、それとも最初にシナリオを書いてからコードを書いたり、シナリオをもう一度書いてからコードを書いたりするべきでしょうか... 以前にシナリオを作成する必要がある場合、私のステップを承認しても製品コードはまだ完了しませんか？ いつコードをリファクタリングする必要がありますか？機能が完了した後、または各シナリオの実装後？

9 programming-practices  tdd  refactoring  development-methodologies  bdd 

私は小さな製品ベースの会社で働いています。既存の製品をゼロから書き直そうとしています。開発にはアジャイル手法を採用する予定です。私の質問は、プロジェクトの開始前でも既存の製品を書き直しているので、すべての要件があるので、アジャイルの世界に飛び込む価値はありますか？すべての要件を事前に用意しておらず、段階的に要件を取得する場合、アジャイルの方が便利ではありませんか？ 次に、アジャイルに移行した場合、データベースを設計するためのベストプラクティスは何でしょうか。最初のイテレーションで、ログインシステムを作成したとしましょう（ユーザーはログイン、ログアウトなどができます）。他のテーブルを気にすることなく、Usersテーブルを作成する必要があるだけですか？そして、他のテーブルは私たちの製品が進歩するにつれて進化するでしょうか？

8 project-management  agile  development-methodologies 

Googleが使用しているソフトウェア開発ライフサイクルの方法について知っている人や情報を持っている人はいますか？

8 google  development-methodologies  sdlc 

「アスペクト指向プログラミング」または「アスペクト指向ソフトウェア開発」について私が学んだすべてから、それをプログラミングのパラダイムまたは方法論として分類することは不正確であるように見えます。私が言えることから、それはプログラミングの基本的なテクニックではありません。 「パラダイム」と「方法論」の意味を明確にするために、アメリカ遺産辞典の次の定義を参照してください。「オブジェクト指向プログラミング」がどれだけ適切に適用されるか、AOPがどれほど適切に適用されるかを比較します。 パラダイム：特に知的分野において、それらを共有するコミュニティの現実を見る方法を構成する一連の仮定、概念、値、および実践。 方法論：専門分野で作業する、または調査に従事する人々が使用する一連の実践、手順、および規則。作業方法のセット。 「エビデンスに基づく医療」はパラダイムの定義を満たしますが、「子宮摘出術に基づく医療」は問題の空間が狭すぎるため、誤った名称になります。 「指向プログラミング」という接尾辞に基づいて、AOPが「オブジェクト指向プログラミング」と同じようにパラダイムと方法論の両方であると主張しているため、AOPの名前が間違っているかもしれないという印象を受けています。 これらの用語（パラダイムと方法論）はどちらも基本的な手法を示しており、アスペクトについて理解しているのは、狭い問題のスコープを解決するためのテクノロジーであり、Javaの静的変数機能に匹敵するかもしれません。 アスペクトが限られた一連の問題を解決し、AOPが誤称ではない場合は、「継承指向プログラミング」、「依存関係」など、すべてのプログラミング手法に「指向プログラミング」接尾辞を付けるべきではないのは事実です。指向プログラミング」または「スコープ指向プログラミング」

8 development-methodologies  aspect-oriented 

私は過去4年間、3つの異なるプロジェクトでSCRUMを使用しています。SCRUMの利点の1つは、柔軟性と適応性にあります。たとえば、変化する顧客の要件に対応できます。別の利点は、管理者がプロジェクトの進捗状況を簡単に追跡できることです。 SCRUMの柔軟性は、要件が非常に速く変化し、プロトタイプを見た後、顧客が何を望んでいるかを本当に理解しているWebアプリケーションを実装する場合などに有利です。 一方、要件がかなり固定されている他の種類のソフトウェアプロジェクト（たとえば、航空宇宙産業）があります。要件仕様のドキュメントを取得し、6か月後には有効なソフトウェアと完全なドキュメントを用意する必要があります。この種のプロジェクトでは、SCRUMが提供する柔軟性が必要であるとは思いません（プロトタイプを作成して顧客に見せて要件についてフィードバックを得る必要がないという意味で）：非常に構造化された体系的なアプローチが必要ですこれはおそらく、プロジェクトごとに何度も何度も繰り返され、驚きの余地はほとんどありません。 それでは、SCRUMはその支持者によって汎用のソフトウェア開発方法論と見なされますか、それともプロジェクトまたはアプリケーション領域の特定のカテゴリに特に適していると見なされますか？ たとえば、私は最近、航空宇宙産業向けのソフトウェアを製造している会社のWebサイトを見て、Vモデルを使用していることに気付きました。SCRUMの支持者は、SCRUMはこの種のプロジェクトにはあまり適していないと言いますか、それともこの会社がSCRUMへの切り替えを試みる必要があると提案しますか？ 注私はこのフォーラムの読者の意見を求めていないのですが、私はSCRUMの提案者の間で定評が何であるかを知りたいこと：SCRUMは、汎用またはプロジェクトのみの特定のクラスのためにかなり適していると考えられますか？後者の場合、どのようなプロジェクトですか？

8 scrum  development-methodologies 

現在のところ、この質問は、Q＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張ディスカッションを誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 なぜアジャイルになるのですか？これは、私がアジャイルになることを考えるときに頭に浮かぶ最初の質問です。アジャイルに移行することで実現できる財務上のメリットは何ですか？ 私たちのほとんどは、顧客やクライアントを自分が何を望んでいるのかを知らない人だと考えるのは確かです。では、なぜ彼らを助けるのか？寄生的な会社である彼らのお金を吸い込んで、彼らを毎日愚かにさせないのはなぜですか。従来のソフトウェア開発は悪くはなく、おそらく（ほとんどの場合私が見た限りでは）アジャイルプロジェクトよりも作業しやすい環境です。 では、なぜアジャイルに移行するのでしょうか。アジャイルは、従来のソフトウェア開発ではできない（経済的に）余分なものを何に与えることができますか？

8 agile  development-methodologies