タグ付けされた質問 「methodology」

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 開発ツールがより強固で堅牢になったとしても、優れたコードを書くことは困難になっているようです。そのツールでさえも強力であり、コードの品質は向上していません。私は2つの重要な要素を思いつきます。時間は短く、プロジェクトはより複雑です。現在使用しているツールはより強力であるため、より複雑なコードを書く方が簡単ですが、計画する時間がないため、振り返らずにコードの品質が低下し、バグとメンテナンスが増加します。以前に複雑なコードを書いたわけではありません。もっと複雑なコードを書くということです。 私の質問は次のとおりです。より強力な言語とツールがあることを考慮してください。 良いコードを書くのが難しいのはなぜですか？ 要因、時間、複雑さがこれに寄与していますか？ 方法論は正しく実践されていませんか？ 私が考えるプロジェクトのタイプは、非常に複雑でビジネスロジックのあるエンタープライズアプリケーションです。「良いコード」の定義は個々のものです。「良いコード」の解釈にとらわれないでください。

19 programming-languages  methodology 

フィルター処理された検索フォームを実装する際のご意見をお聞かせください。次の場合を想像してみましょう。 多数の列を持つ1つの大きなテーブル このSQL Serverを言うことは重要かもしれません このテーブルのデータを検索するフォームを実装する必要があります。このフォームには、この検索を最適化するためのいくつかのチェックボックスがあります。 ここで私の質問は、次のどれが検索を実装するための最良の方法であるべきかということです。 内部にクエリを含むストアドプロシージャを作成します。このストアドプロシージャは、パラメータがアプリケーションによって指定されているかどうかを確認し、指定されていない場合は、ワイルドカードがクエリに挿入されます。 動的クエリを作成します。動的クエリは、アプリケーションによって指定された内容に従って構築されます。 これは、SQL Serverがパフォーマンスを最適化するためにストアドプロシージャの作成時に実行プランを作成することを知っているためですが、ストアドプロシージャ内で動的クエリを作成すると、実行プランによって得られる最適化が犠牲になりますか？ あなたの意見で最善のアプローチは何でしょうか教えてください。

17 database  sql  sql-server  methodology  development-approach 

私は過去3年間ソフトウェアを開発してきましたが、最近、自分が良い慣習にどれほど無知であるかに目覚めました。これにより、Clean Codeという本を読み始めることになりました。これは私の人生をより良い方向に変えていますが、プログラムを書くための最良のアプローチのいくつかについて洞察を得るのに苦労しています。 Pythonプログラムがあります。 argparse required=Trueを使用して、両方ともファイル名である2つの引数を適用します。最初は入力ファイル名、2番目は出力ファイル名 readFromInputFile入力ファイル名が入力されたことを最初に確認する機能があります writeToOutputFile出力ファイル名が入力されたことを最初に確認する機能があります 私のプログラムは十分に小さいので、＃2と＃3のチェックは冗長であり、削除する必要があると信じるようになるため、両方の機能を不要なif状態から解放します。しかし、「二重チェックは大丈夫」であると信じるようになり、引数の解析が行われない別の場所から関数を呼び出すことができるプログラムでは正しいソリューションになるかもしれません。 （また、読み取りまたは書き込みが失敗した場合、try except適切なエラーメッセージを生成する各関数があります。） 私の質問は、すべての冗長な状態チェックを避けるのが最善ですか？プログラムのロジックは非常に堅固であるため、チェックは一度だけで済みますか？これまたはその逆を説明する良い例はありますか？ 編集：答えてくれてありがとう！それぞれから何かを学びました。非常に多くの視点を見ると、この問題にどのようにアプローチし、自分の要件に基づいて解決策を決定する方法についての理解が深まります。ありがとうございました！

16 clean-code  methodology 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私の会社では、行うべきタスクが非常に少ない日がいくつかあることがわかりました。最近、私の技術について新しいことを学ぶために研究をすることを強調しています。 平均して、やりたいことはほとんどない（または1週間の時間の組み合わせ）ことは週に1日程度あります。 これがソフトウェア開発環境で一般的な状況であるかどうかを知りたいのですが、この質問に対する答えはフルタイムと契約作業で異なります。

16 self-improvement  methodology 

最初にプログラミングを始めたとき、私はフローチャート（およびプリンター間隔チャート）に大きく依存していました。COBOLクラスにいる間、フローチャートがインストラクターによってサインオフされるまで、コードを書き始めることができませんでした。当時、私はすべてのフローチャートを作成する必要がありました。 25年後の今日、私は2種類のことだけをフローチャート化しています。ロジックがトリッキーまたは非常に一般的な概念であるすべての大きなステップを適切な順序で定義できるようにするための非常に具体的なアルゴリズム。 私が単に見落としているフローチャートの他のユースケースはありますか？

14 design  methodology  flowchart 

チームが頻繁にソフトウェアをリリースするのが困難になっています（毎週1回）。以下は、典型的なリリースのタイムラインです。 反復中： 開発者は、マスターブランチに基づいて、短期間（これは熱狂的に実施されます）機能ブランチのバックログのストーリーに取り組みます。 開発者は、頻繁に機能ブランチを統合ブランチにプルします。統合ブランチは、自動的に継続的に構築およびテストされます（テストカバレッジの範囲内）。 テスターは、統合をステージング環境に自動展開する機能を備えており、これは週に複数回行われ、テストスイートの継続的な実行が可能になります。 毎週月曜日： （テスターの作業に基づいて）どのストーリーが「既知の善」であり、したがってリリースに含まれるかを決定するリリース計画ミーティングがあります。ストーリーに既知の問題がある場合、ソースブランチは統合から除外されます。 テスターがリリースをカットするための安定したコードベースを確保するために、今週の月曜日に新しいコード（テスターに​​よって要求されたバグ修正のみ）を統合に取り込むことはできません。 毎週火曜日： テスターは、可能な限り時間をかけて可能な限り統合ブランチをテストし、既知のバグがないため、リリースがカットされ、運用ノードにゆっくりとプッシュされました。 これは実際には問題ないように思えますが、達成するのは非常に難しいことがわかりました。チームには次の症状が見られます 本番環境では、ステージング環境で特定されなかった「微妙な」バグが見つかります。 土壇場でのホットフィックスは火曜日まで続きます。 実稼働環境の問題にはロールバックが必要であり、ライブデプロイメントが成功し、マスターブランチが更新される（したがって分岐する）まで、継続的な開発をブロックします。 ここでは、テストの範囲、コードの品質、回帰テストの迅速な機能、土壇場での変更、環境の違いが関係していると思います。誰もが「継続的な」配信を達成するための最善の方法に関するアドバイスを提供できますか？

14 methodology 

いくつかの背景情報 私は社内のソフトウェア開発チームの一員です。で構成されます 5人の開発者（2〜5年の経験があり、私もその1人です） 3人の実装スタッフ（ソフトウェアの展開とトレーニングを行います） および1人のプロジェクトマネージャー。 多くの小規模から中規模のプロジェクトを開発しており、それらのスケジュールは通常重複しています。開発は次のようになります。 「クライアント」は一連の初期要件を提供します 上記の仕様に合わせてシステムを開発します システムを「クライアント」に提示する 「クライアント」は、上記のプレゼンテーションに基づいて追加の要件を提供します 「クライアント」の新しい要件がなくなるか、展開の対象日が近づくまで2〜4を繰り返します システムをセットアップして展開する これは、ほとんどの場合、期限を処理する「クライアント」であるという事実（これはプログラマーとPM.SEで私が見ているものからの赤旗です）であり、明確な開発方法論に従っていませんカウボーイコーディング、メンテナンス不可能なコード、本番環境を通過するバグなどが含まれます。それが、スクラムのようなアジャイルベースの方法論を採用することを選んだ理由です。 なぜスクラムなのか？ それは私たちのマネージャーのイニシアチブであり、現在の状況を考えると誰もがそれに同意するようです。 スクラムの問題 スクラムの一部の要素は、特にアジャイル開発者の「すべての取引」という性質に簡単に対処できない現在のセットアップと競合しています。展開チームはプログラミングの方法を知らず、開発者は平均以下のコミュニケーションとトレーニングのスキルを持っています。そして、このラインナップはすぐに変わることはありません。 質問 方法論としてのスクラムの有効性に影響しますか？補償するために他の変更を行う必要がありますか？それとも、考えを完全に捨てて、別の方法論について考える方が良いでしょうか？

13 agile  scrum  methodology 

私は、製造現場のスケジューリングプログラムの作成をITに任せている製造工場で働いています（これは非常に必要です）。他の経験に基づいて、より少ない時間で利用可能な基本的なフレームワークを構築し、機能を追加することでその上に構築するか、完全に実装されたソリューションをすぐに作成して開始する方が良いでしょうか？私は約1年しかデベロッパーではなく、このサイズのアプリの初期作成の経験はあまりありません。私は、ある種のデジタルスケジュールが非常に必要なため、ベアボーンアプリが最初に行く方法であるという考えに傾いてきましたが、事実の後にランダムな機能を追加すると少し厄介になる可能性があります。あなたが同じ状況にあった場合、あなたはどの道に向かって傾くでしょうか？

11 design  theory  methodology 

一部の組織ではアジャイルの採用が失敗する場合があります。ウォーターフォールが唯一の（真の）方法である会社で働いていましたが、それは彼らがプロジェクトでアジャイルを試みて失敗したためです。 まだ覚えている人たちに聞いたとき（私は後輩でした）、本当に起こった悪い悪夢を思い出させたように、私は激しくシャットダウンされました。 プロジェクトが失敗した理由はわかりません。一部の企業ではアジャイルが失敗する理由がウェブ上に記載されていますが、その理由は主に経済的です。そこで、私はここでいくつかのフィードバックをお願いすると思った。 一部の組織でアジャイルの採用が失敗する理由は何ですか？または、別の言い方をすれば..アジャイルで成功するには何が必要ですか？

11 agile  methodology  waterfall  technique 

今日、私はinfoqでMDSEという頭字語に出会いましたが、その情報は非常に不明確で、説明には流行語がたくさんありました。 MDSEは、要件、アーキテクチャー、および設計情報が（情報「エントロピー」の観点から）最大限に整理され、保持される抽象化のレベルでソフトウェアエンジニアが作業できるようにすることを目的としています。（これを「設計作業成果物」と呼びます）。さらに、MDSEは、主に「設計作業成果物」の用語を設計の検証および検証する手段をエンジニアに提供する必要があります そして、どうやら、誰もがそれをやっています：（再び記事から） MDSE時代の幕開けです。今後5〜10年で、MDSEへの大幅なシフトが見られます。この期間の終わりまでに、ソフトウェアの60〜80％がモデルベースの手法を使用して設計されると私は信じています。 MDSEとは何か、流行語のない具体的な説明をお願いします。90年代のRational Roseのように、UMLボックスを描画してコードを生成していますか？ （その間、誰かがそれらの技法を使用して生成されたソフトウェアの例を持っている場合、私は本当に具体的な例を見たいです）。

10 methodology 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 8年前休業。 小さなイテレーションが好きです。単体テストが好きです。コードレビューが好きです。私が気に入らないのは、ドキュメントがほとんどないかまったくないところから始めることです。私はこれで一人ですか？プロセスについて誤解しているだけですか？ どんな考えでもいただければ幸いです。

10 agile  documentation  methodology 

私はソフトウェア開発方法論を含む小さな研究論文を書いています。私は利用可能なすべての方法論を調べていましたが、すべての方法論から、他の方法の基礎を提供しているものはあるのでしょうか。 例として、 アジャイル、プロトタイピング、クリーンルーム、反復、RAD、RUP、スパイラル、ウォーターフォール、XP、リーン、スクラム、Vモデル、TDDの方法論を見てみましょう。 私たちはそれを言うことができます： プロトタイピング、反復、スパイラル、ウォーターフォールは他のものの「基礎」です？ それとも「基礎」などはなく、それぞれの方法論には独自の歴史がありますか？ もちろん、私は自分の論文ですべての方法論について説明したいと思いますが、それを行う時間がないので、どの方法論を代表として見ることができるかを知りたいのです。

10 project-management  language-agnostic  project  development-methodologies  methodology 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 中規模以上のソフトウェアを完全に自分で開発する必要があるとします。達成したい個人的なプロジェクトのように。 どのような方法論/ツールを使用して、開発、学習する必要があるかを定義し、システムの詳細と全体像を把握する必要がありますか？ 基本的に自分を追跡し、途中で迷子にならないようにします。

10 tools  methodology 

以前は専門のコンサルティング会社で働いていましたが、さまざまな契約条件で働いていました。時間と材料のプロジェクトを取得できたら、SCRUMで実行し、課題追跡システムでバックログを追跡しました。 ただし、ほとんどの場合、固定価格契約の下で納品する必要がありました。これには、契約の付録として仕様書が必要でした。そのため、仕様から作業項目をバッチインポート（さらには手動で入力）することになりました。変更注文は、特にプロジェクトの終わりに向かって、すべてが同期していることを確認するのに長い時間がかかりました。 このプロセス全体をDRYに保つ方法論またはソフトウェアツールはありますか？私はいくつかの検索を行ったが、どうやら正しい用語を使用していない。私の専門ネットワークのほとんどは固定価格の仕事をしていません。 私は次のことを受け入れます： バグトラッカーの切り替えまたはプラグインの購入（現在はFogBugzを使用）。 別の開発方法論に従う 仕様を管理し、バグトラッカーと仕様ドキュメントを更新するソフトウェアを作成する（ただし、これは、疑わしい利益のために多くの作業が必要と思われます） 最後に、これは本当に解決する価値がありますか？一部のプロジェクトではかなりの費用がかかりましたが、他のプロジェクトでは影響はありませんでした。

9 issue-tracking  specifications  methodology 

暇なときにゲームのコーディングをしていますが、プログラミングに関しては、まだ初心者です。この質問がトピックから外れている場合や、他の人に役に立たない場合は、申し訳ありませんが、うまくいけば、役に立ちます。 コードの設計や、コーディングのさまざまな方法論やアプローチについての本を読むのに多くの時間を費やしてきました。この調査の過程で、私はテスト駆動開発の概念に出会います。このアイデアを支持する人々は通常、それについて非常に情熱的です。私はそれがソフトウェアを書くスピードと効率を助けることができると信じています。時間は非常に貴重なリソースであるため、プログラミングクラフトの知識を広げようとせずに、何とかやり過ごすのではなく、最善の方法で学ぶことを学びたいと思います。 とにかく、私は初心者だからといって、テスト駆動開発をゲームにどのように適用するか想像できません。この件についていくつかの記事を見つけましたが、あまり役に立ちませんでした。私が見た単体テストの例のほとんどは、非常に単純な定型の例、またはまったくゲームに似ていないソフトウェアの例です。 私自身のコーディングでは、同様の考え方でテスト駆動開発に取り組みますが、実際にはTDDとしての資格はないと確信しています。ゲームに追加する機能を実装するための最小限のコードを記述し、すぐにゲームをテストして、機能するかどうかを確認します。意図したとおりに起こらない場合は、すぐに変更を加えて、自分が望むものに近づけます。機能していないか壊れている場合、およびコードを読み取ってもバグを見つけることができない場合は、予期しない動作が見つかるまでデバッガーのメソッドを順に実行し、それを削除します。私が言おうとしているのは、ほぼすべての増分変更の後で、常にゲームをテストしているということです。テストは私の開発を推進します。「単体テスト」は私の頭の中にあります、 私の実際の質問に移ります。複雑なゲームの単体テストを作成するにはどうすればよいですか？複雑に言うと、ゲームプレイの多くの創発的な側面を意味します。つまり、ゲームプレイの本質は、プレイヤーの選択と組み合わされたゲーム内のさまざまな要素間の相互作用から生まれます。たとえば、手続き型の世界を持つローグライクなRPG。そのようなゲームのためにどんなユニットテストを書くでしょうか？このようなゲームにテスト駆動開発をどのように適用できますか？

8 unit-testing  tdd  game-development  methodology  games