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

ソフトウェア開発のプロセスに関する質問。

8
リファクタリング時にユニットテストをどのように機能させ続けるのですか?
別の質問で、TDDの問題の1つは、リファクタリング中およびリファクタリング後にテストスイートをコードベースと同期させることであることが明らかになりました。 今、私はリファクタリングの大ファンです。TDDをやめるつもりはありません。しかし、マイナーなリファクタリングが多くのテストの失敗につながるような方法で書かれたテストの問題も経験しました。 リファクタリング時にテストが中断しないようにするにはどうすればよいですか? テストを「より良い」と書いていますか?もしそうなら、あなたは何を探すべきですか? 特定の種類のリファクタリングを避けていますか? テストリファクタリングツールはありますか? 編集:質問の意味を尋ねる新しい質問を書きました(ただし、これは興味深いバリエーションとして残しました)。

4
#ifdefを使用して、開発中に異なるタイプの動作を切り替える
開発中に#ifdefを使用して、さまざまな種類の動作を切り替えることをお勧めしますか?たとえば、既存のコードの動作を変更したい場合、動作を変更する方法がいくつかあります。異なるアプローチをテストおよび比較するには、異なる実装を切り替える必要があります。通常、コードの変更は複雑で、異なるファイルの異なるメソッドに影響を及ぼします。 私は通常いくつかの識別子を導入し、そのようなことをします void foo() { doSomething1(); #ifdef APPROACH1 foo_approach1(); #endif doSomething2(); #ifdef APPROACH2 foo_approach2(); #endif } void bar() { doSomething3(); #ifndef APPROACH3 doSomething4(); #endif doSomething5(); #ifdef APPROACH2 bar_approach2(); #endif } int main() { foo(); bar(); return 0; } これにより、さまざまなアプローチをすばやく切り替えて、ソースコードの1つのコピーだけですべてを実行できます。開発のための良いアプローチですか、それともより良いプラクティスがありますか?

6
個人のPythonプロジェクトをリリース可能なライブラリに変える
私はプログラマーというよりは学者であり、研究をサポートするために、私自身が使用するPythonプログラムを長年書いています。私の最新のプロジェクトは、私だけでなく他の多くの人にとっても有用である可能性が高く、オープンソースのPythonライブラリとしてリリースすることを考えています。 ただし、機能している個人プロジェクトから、他の人が簡単にインストールして使用できるライブラリに移行するには、かなりのハードルがあるようです。この質問は、パブリックリリースに向けて作業を開始するために最初に実行する必要がある手順に関するものです。 現在、ライブラリとライブラリ自体を使用するコードを含む単一のgitリポジトリがあり、何かが壊れた場合に備えてgitを緊急の元に戻すボタンとして使用しています。これはすべて単一のユーザーには問題なく機能しますが、リリースしたい場合は明らかに適切ではありません。最後にしたいのは、ライブラリが別のリポジトリにあり、他の人がを使用してインストールできpip、安定したAPIがあることです。 setuptoolsなどを使用することを学習するのは、一度公開したいと思ったらそれほど難しいことではないでしょう。私の問題は、そのポイントに到達するためにどのように作業すべきかを知ることです。 だから私の質問は、公共の消費のためにPythonライブラリプロジェクトの準備を始めるためにとるべき最初のステップは何ですか?ライブラリの公開に向けて作業を開始するには、ディレクトリ構造、gitリポジトリなどをどのように再編成すればよいですか? より一般的には、これを初めて試すときに役立つと知られているリソースがある場合、非常に役立ちます。ベストプラクティスや回避すべき間違いなどへのポインタも非常に役立ちます。 いくつかの明確化:現在の回答は、「Pythonライブラリを他の人が使用できるようにするにはどうすればよいですか?」という行に沿った質問に対処しています。これは便利ですが、私が尋ねるつもりの質問とは異なります。 私は現在、プロジェクトのリリースに向けて長い旅の始まりにいます。私の実装の中核は機能します(そして非常にうまく機能します)が、先の作業量に圧倒されており、プロセスをナビゲートする方法についてのガイダンスを探しています。例えば: 現在、私のライブラリコードは、それを使用する独自のドメイン固有のコードに結合されています。サブフォルダーに存在し、同じgitリポジトリーを共有します。最終的には、スタンドアロンのライブラリにして独自のリポジトリに配置する必要がありますが、その方法がわからないため、これを先延ばしにしています。(ライブラリを「開発モード」でインストールして編集できるようにする方法も、2つのgitリポジトリを同期させる方法もありません。) 私のドキュメント文字列は簡潔です。最終的にはSphinxまたは他のツールを使用する必要があることを知っているからです。しかし、これらのツールは学ぶのが簡単ではないようですので、これは主要なサブプロジェクトになります。 ある時点で、setuptoolsまたは他のツールを使用してパッケージ化し、依存関係を追跡する方法を学ぶ必要がありますが、これは非常に複雑です。今すぐこれを行う必要があるかどうかはわかりませんが、ドキュメントは新しいユーザーにとって絶対的な迷路なので、後で行うことを決め続けています。 体系的なテストを行う必要はありませんでしたが、このプロジェクトには間違いなく取り組むので、(i)自分のプロジェクトに適した方法論を知るためにテストについて十分に学ぶ必要があります。(ii)選択した方法論で利用可能なツールを学習します。(iii)選択したツールの使用方法を学ぶ。(iv)プロジェクトにテストスイートなどを実装します。これはそれ自体がプロジェクトです。 他にもやらなければならないことがあるかもしれません。たとえば、jonrsharpeは、git-flow、tox、TravisCI、virtualenv、CookieCutterについての役立つリンクを投稿しました。(投稿は2013年からのものであるため、現在どれだけ残っているかを調べるためにいくつかの作業を行う必要があります。) これをすべてまとめると、膨大な量の作業が必要になりますが、プラグインを続けて行けば、すべてを完了することができると確信しており、急いでいません。私の問題は、それを1つずつ実行できる管理可能な手順に分解する方法を知ることです。 言い換えれば、最終的にリリース可能な製品に到達するために、私が今取ることができる最も重要な具体的なステップはどれかを尋ねています。週末が空いている場合、これらのうちどれに焦点を当てるべきですか?他の作業とは別に(もしあれば)どの作業を行うことができますか?これらのことを学習する最も効率的な方法は何ですか?それで、プロジェクト自体に集中する時間を確保できますか?(これは基本的に趣味のプロジェクトであり、私の仕事ではないことを心に留めておいてください。)実際に行う必要のないことはありますか?したがって、膨大な時間と労力を節約できますか? すべての回答は大歓迎ですが、これらのプロジェクト管理の側面に焦点を当てた回答、特に現代のPython開発に特に関連した回答を歓迎します。

7
チームメイトに基本的なルールに従うよう説得する方法
チームメイトに問題があります。簡単に言えば、私たちはコンテストのプロジェクトで働く3人の学生です。このプロジェクトは、2つの個別のアプリケーションで構成されています。1つはWindows用(もう1つは開発中)、もう1つはAndroid用(私の同僚が開発に責任を負います)です。コードベースが交差することはなく、アプリはサードパーティのツールを介して通信します。 問題は次のとおりです。昨年大企業でインターンシップを行ったときにチームで働いた経験があり、コードのコーディング標準を強制しようとしています。また、コードをプッシュしたり、アイデアを書いたり、プロトコルを文書化したりするために使用できるgitリポジトリ/ wiki /コラボレーションソフトウェアも設定しましたが、これらのツールを使用しているのは私だけであるようです。 質の高いコードを書いて、すべてのステップを文書化することは長期的には私たちに利益をもたらすと彼らに伝えようとしましたが、彼らはそれの利点を理解していないようです。また、いくつかの統合テストを追加することを考えていましたが、私が見ることができることから、彼らが生活を楽にするために現在のツールを使用しない限り、統合テストの有用性を説得することはできないと思います。 ピアのコードのほとんどは自分のコンピューター上にあり、共通のコードベースを共有していません。私が知ったように、彼らはusbスティックを介してコードを会議および共有することで、それらの部分を統合しました。 私の質問は次のとおりです。いくつかの不条理なルールを施行しますか?これは小さなプロジェクトであり、要件は非常に明確であることに注意してください(アプリケーションの動作を指定するドキュメントを作成しました)。3人の熟練した開発者が3〜4日でこれを行うことができます。現在のメソッドが機能する限り、コードを作成します。 gitなどを使用してコードをドキュメント化することの利点を示す方法はありますか?

7
ずさんな企業文化を変えるにはどうすればよいですか?[閉まっている]
解決する必要がある問題があるとき、それを解決する最も簡単な方法は、小さなプログラムを個人的なツールとして書くことです。使用するのは私だけなので、使いやすくしたり堅牢にしたりすることはありません。 その後、同僚はプログラムを見て、同じ問題にぶつかり、ツールが役立つ可能性があるため、それを要求します。私は彼に「それはきれいではないが、仕事をやり遂げるだろう」という免責事項を与え、彼にそれを手に入れました。 私が知っている次のことは、上司が私に電話して、クライアントのコンピューターでソフトウェアを動作させようとしているが、Xエラーメッセージが表示されていると言っていることです。WTF ?? そのソフトウェアはリリースの準備ができていません。また、リリースの準備が必要だとは言われませんでした。しかし、何らかの理由で、上司はそれが十分であると考え、元の開発者に伝えることなくそれをリリースしました。 現在、この特定の問題はを使用して簡単に修正できますMessageBox.Show("DO NOT GIVE TO CLIENTS!");。しかし、この問題はより深い問題を示しています。当社の企業文化はずさんです。ずさんなソフトウェアは問題ありませんし、ずさんなプロセスは問題ありません。将来について心配する必要はありません-現在はほとんど動作しないように十分な努力を払い、バイナリを.zipファイルに入れて、出荷してください。政府の仕事には十分です。 これは、10人の正社員を抱える小さな会社で、成長を続けており、しばらく前から存在しています。誤解しないでください。ここで働くのが大好きで、会社が大好きです。走るように言わないでください。私は会社をより良くするための一部になりたいです。この種の文化にどのように良い変化をもたらし始めますか?

9
高度にカスタマイズされたソフトウェアをどのように整理しますか?
私は、世界中のさまざまな顧客向けに高度にカスタマイズされた大規模なソフトウェアプロジェクトに取り組んでいます。つまり、80%のコードがさまざまな顧客に共通しているだけでなく、ある顧客から別の顧客に変更する必要がある多くのコードがあることを意味します。過去に別のリポジトリ(SVN)で開発を行い、新しいプロジェクトが開始されたとき(大規模な顧客はほとんどありませんが)、過去のプロジェクトがニーズに最適なコードベースに基づいて別のリポジトリを作成しました。これは過去に機能していましたが、いくつかの問題に遭遇しました。 あるリポジトリで修正されたバグは、他のリポジトリでは修正されません。これは組織の問題かもしれませんが、5つの異なるリポジトリのバグを修正してパッチを当てるのは難しいと思います。このリポジトリを保守しているチームは世界の別の場所にいて、テスト環境がないことに注意してください、スケジュールや要件を把握していません(ある国の「バグ」は別の国の「機能」かもしれません)。 別のプロジェクトにも役立つかもしれない1つのプロジェクトに加えられた機能と改善は失われ、別のプロジェクトで使用された場合、多くの場合、1つのコードベースから別のコードベースにそれらをマージする大きな頭痛の種を引き起こします)。 1つの開発ブランチで行われたリファクタリングとコードの改善は、ブランチ間でこれらのすべての変更をマージする必要がある場合、失われるか、害よりも害をもたらします。 現在、これらの問題を解決する方法について議論しており、これまでのところ、これを解決する方法について次のアイデアを思いつきました。 開発を別々のブランチで維持しますが、一般的なバグ修正がマージされる中央リポジトリを持ち、すべてのプロジェクトがこのセントラルリポジトリからの変更を定期的に(たとえば毎日)独自のものにマージすることで、より整理されます。これには、大きな規律と、ブランチ間のマージに多大な労力が必要です。ですから、特に時間のプレッシャーがかかったときに、それがうまくいくと確信していません。 個別の開発ブランチを放棄し、すべてのコードが存在する中央のコードリポジトリを持ち、プラグ可能なモジュールと構成オプションを使用してカスタマイズを行います。既にコードの依存関係を解決するためにDependency Injectionコンテナーを使用しており、ほとんどのコードでMVVMパターンに従ってビジネスロジックをUIから明確に分離しています。 2番目のアプローチはよりエレガントに見えますが、このアプローチには多くの未解決の問題があります。例:モデル/データベースでの変更/追加の処理方法。エンティティフレームワークで.NETを使用して、エンティティを厳密に型指定しています。ある顧客には必要だが、データモデルを乱雑にすることなく別の顧客には役に立たないプロパティをどのように処理できるかわかりません。サテライトテーブル(特定のエンティティ用の追加の列が元のエンティティへの1:1マッピングで存在する個別のテーブルを持つ)を使用してデータベースでこれを解決することを考えていますが、これはデータベースのみです。これをコードでどのように処理しますか?データモデルは中央ライブラリにあり、このアプローチを使用して顧客ごとに拡張することはできません。 この問題に苦しんでいるのは私たちだけではないと確信しており、このトピックに関する資料がほとんどないことにショックを受けています。 私の質問は次のとおりです。 高度にカスタマイズされたソフトウェアに関してどのような経験があり、どのアプローチを選択し、どのように機能しましたか? どのアプローチをお勧めしますか、またその理由は何ですか?より良いアプローチはありますか? お勧めできるトピックに関する良い本や記事はありますか? 技術環境(.NET、Entity Framework、WPF、DI)について具体的な推奨事項はありますか? 編集: すべての提案をありがとう。アイデアのほとんどは、すでにチーム内で持っていたものと一致しますが、あなたがそれらで得た経験と、それらをより良く実装するためのヒントを確認することは本当に役立ちます。 どの方向に進むかはまだわかりませんし、(単独で)決定を下すわけではありませんが、チームでこれを伝えて、役に立つと確信しています。 現時点では、テナーはさまざまな顧客固有のモジュールを使用する単一のリポジトリのようです。私たちのアーキテクチャがこれに合っているか、それを適合させるためにどれだけ投資する必要があるのか​​はわかりません。 それで、すべての応答に再び感謝します!

5
コードの所有権はコードの匂いですか?
これは、物議を醸すプログラミングの意見のスレッドでこの答えを読んで以来ずっと考えてきたことです。 あなたの仕事は、自分を失業させることです。 雇用主向けのソフトウェアを作成する場合、作成するソフトウェアは、開発者が理解し、最小限の労力で理解できるように作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。 あなたがバスにぶつかったり、解雇されたり、解雇されたり、仕事を辞めたりした場合、あなたの雇用主はすぐにあなたに取って代わることができ、次の人があなたの役割に入り、あなたのコードを拾い上げて1週間以内に走ります。彼または彼女がそれを行うことができない場合、あなたは惨めに失敗しました。 興味深いことに、その目標を持っていることが雇用主にとってより価値のあるものであることがわかりました。使い捨てになるように努力すればするほど、彼らにとってより価値のあるものになります。 そして、これは他の質問、例えばこれで少し議論されましたが、私は再びそれを持ち出し、より多くの空白から「それはコードの匂いです!!」という観点から議論したかったのです。まだ深さ。 私は10年間プロの開発者です。私は、適切な新しい開発者が比較的迅速に理解できるようにコードが十分に書かれた仕事を1つ持っていますが、業界のほとんどの場合、非常に高いレベルの所有権(個人とチームの所有権の両方)が普通。ほとんどのコードベースには、新しい開発者がそれらを選択してすばやく作業できるようにするためのドキュメント、プロセス、および「オープン性」が欠けているようです。コードベースを非常によく知っている(「所有している」)誰かが知っている、書かれていない小さなトリックやハックが常にたくさんあるようです。 もちろん、これに関する明らかな問題は次のとおりです:人がやめるか、「バスにぶつかった」場合 または、チームレベルで、チームランチに出かけたときにチーム全体が食中毒になり、全員が死亡した場合はどうなりますか?チームを比較的簡単に新しいランダムな開発者の新しいセットに置き換えることができますか?-私の過去の仕事のいくつかでは、そのことがまったく想像できません。システムには非常に多くのトリックとハックがあり、「知っておく必要がある」だけなので、採用する新しいチームは収益性の高いビジネスサイクル(たとえば、新しい安定したリリース)よりもはるかに長くかかります。要するに、製品を放棄しなければならないとしても、私は驚かないでしょう。 明らかに、チーム全体を一度に失うことは非常にまれです。しかし、これにはもっと微妙で不吉なことがあると思います-これは、このスレッドでこれまで議論したのを見たことがないので、このスレッドを開始することを考えさせたポイントです。基本的に、コードの所有権に対する高いニーズは、技術的な負債の指標であることが非常に多いと思います。システムにプロセス、コミュニケーション、優れたデザイン、多くの小さなトリックやハッキングが欠けていて「知っておく必要がある」などの場合は、通常、システムが次第に深く技術的な負債に陥っていることを意味します。 ただし、コードの所有権は、プロジェクトや会社に対する一種の「忠誠心」として、またあなたの仕事に対する「責任を負う」肯定的な形として提示されることが多いため、完全に非難することは一般的ではありません。しかし同時に、方程式の技術的負債の側面は、コードベースが次第にオープンになり、作業が難しくなることを意味することがよくあります。そして、特に人々が前進し、新しい開発者がその地位に就く必要があるため、技術的な負債(つまり、メンテナンス)コストが高騰し始めます。 ですから、ある意味では、コードの所有権に対する高いレベルのニーズが、一般的なプログラマーの想像力の中で、仕事の匂いとして公然と見られていれば、私たちの職業にとって良いことだと思います。「仕事に責任と誇りを持っている」と見なされるのではなく、「技術的な負債を介して自分自身を定着させ、人工的な職の安全を確保する」と見なすべきです。 そして、テスト(思考実験)は基本的にすべきだと思います:もしその人(あるいはチーム全体)が明日地球の表面から消えたとしたら?これはプロジェクトの巨大な-おそらく致命的な-怪我になりますか、それとも新しい人々を連れて来て、彼らにdoccosとヘルプファイルを読んでもらい、数日間コードを遊んでもらうことができますか?数週間でビジネスを開始します(1か月ほどで完全な生産性に戻ります)。

18
終わりのない技術的な議論をやめて決定を下す
私はいつも、最も小さな「技術的なもの」を長年にわたって叩きたい人に出会います。 誤解しないでください。私はオタクのプログラマーで、自分の仕事を愛していますが、会話のタイプは知っています。 MacはWindowsよりもはるかに優れています For Eachループを使用せず、Whileループを使用します IntelベースのPCを購入するのではなく、AMDベースのPCを入手してください。 1つのIoCコンテナーを別のコンテナーよりも使用する必要があります。 これらすべての「モノ」には、双方にとって有効な長所と短所があり、「正しい」答えは決して得られず、その人はその点を認めません。(もちろん、答えがあるところもあるでしょう:)。 私の質問(私はそこに着いています!!):ソフトウェアチームにおいて、イノベーションを阻害することなく、これらの長い議論をどのように切り抜けて、決定を下し、実際のビジネス上の問題を解決できるようにするかです。


5
データ入力検証-どこ?いくら?[閉まっている]
データ入力の検証は、常に私にとって非常に内部的な闘争でした。 レガシーアプリケーションリライトプロジェクトに実際のセキュリティフレームワークとコードを追加する寸前(これまでのところ、カードキャッスルに強力なレガシーセキュリティコードとデータ検証を保持している)、私はどのくらい検証すべきか、どこなど プロのJava開発者としての5年間で、データ入力の検証とセキュリティ対策のための個人ルールを作成し、改良しました。私は自分の方法を改善したいので、皆さんからいくつかのアイデアを聞きたいと思います。一般的なルールと手順は問題ありませんが、Java固有のものも同様です。 要約すると、これらは私のガイドライン(3層のWebアプリケーションスタイルで公開)であり、簡単な説明があります。 第1層のクライアント側(ブラウザ):最小限の検証、不変のルールのみ(必須の電子メールフィールド、1つのアイテムを選択する必要があるなど)。「6〜20文字」などの追加検証の使用頻度が少なくなります。これにより、変更のメンテナンス作業が増加します(ビジネスコードが安定したら追加できます)。 第1層サーバー側(Web通信処理、「コントローラー」):このルールはありませんが、ここではデータ操作とアセンブリ/解析エラーのみを処理する必要があると考えています(誕生日フィールドは有効な日付ではありません)。ここにさらに検証を追加すると、簡単に本当に退屈なプロセスになります。 第2層(ビジネス層):堅実な検証、それ以下。入力データ形式、範囲、値、メソッドをいつでも呼び出せない場合の内部状態チェック、ユーザーの役割/権限など。できるだけ少ないユーザー入力データを使用し、必要に応じてデータベースから再度取得します。取得したデータベースデータも入力と見なす場合、特定のデータが信頼できないか、DBで十分に破損していることがわかっている場合にのみ検証します。 第3層(データ層/ DAL / DAO):データにアクセスするのはビジネス層のみであるため、ここでは多くの検証が必要とは考えられません(「param1がtrueの場合、param2はnullであってはならない」などの場合に検証します)。ただし、「ここ」を意味する場合、「データベースにアクセスするコード」または「SQL実行メソッド」を意味することに注意してください。データベース自体はまったく逆です。 データベース(データモデル):適切なプライマリキー、外部キー、制約、データ型/長さ/サイズを使用して、DB上の不正なデータや破損データを可能な限り回避するために、十分に考慮し、強力かつ自己強化する必要があります/ precisionなど-独自のプライベートディスカッションがあるため、このトリガーは除外します。 初期のデータ検証は優れており、パフォーマンス面でも優れていることは知っていますが、繰り返しデータ検証を行うのは退屈なプロセスであり、データ検証自体は非常に面倒です。これが、非常に多くのコーダーがそれをスキップするか、途中でやる理由です。また、常に同期されていない場合、重複する検証はすべてバグの可能性があります。これらは、時間、帯域幅、CPU、ケースバイケースで処理される例外を犠牲にして、ほとんどの検証をビジネス層まで許可することを好む主な理由です。 それで、あなたはこれについてどう思いますか?反対意見ですか?他の手順はありますか?そのようなトピックへの参照?寄付はすべて有効です。 注:物事のJavaの方法を考えている場合、私たちのアプリはSpring MVCとMyBatisを使用したSpringベースです(パフォーマンスと不良データベースモデルはORMソリューションを除外します)。Spring SecurityをセキュリティプロバイダーとJSR 303(Hibernate Validator?)として追加する予定です。 ありがとう! 編集:第3層に関する追加の明確化。

2
コードの文書化の方法とソフトウェアの文書化が不十分な場合が多いのはなぜですか?
java apiなど、よく文書化されたコードの良い例があります。しかし、gitや企業の内部プロジェクトなどの公開プロジェクトのコードの多くは、文書化が不十分であり、初心者にはあまり適していません。 私のすべてのソフトウェア開発スティントでは、文書化が不十分なコードを処理する必要がありました。次のことに気づきました- コード内のコメントはほとんどまたはまったくありません。 メソッド名と変数名は自己記述的ではありません。 コードがシステムまたはビジネスプロセスにどのように適合するかについてのドキュメントはほとんどまたはまったくありません。 悪い開発者を雇うか、良い開発者を指導しない。シンプルでクリーンなコードを書くことはできません。したがって、開発者を含む誰にとってもコードを文書化することは困難または不可能です。 その結果、多くのコードを調べて、多くの人と話して物事を学ぶ必要がありました。これはみんなの時間を無駄にすると感じています。また、プロジェクトへの新規参入者向けのKT /ナレッジ転送セッションの必要性も生じます。 次の理由により、ドキュメントには値する注意が払われていないことを学びました。 怠惰。 開発者はコード以外は何もしません。 雇用保障。(コードを簡単に理解できる人がいない場合、簡単に交換できない可能性があります。) 期限が厳しいため、文書化する時間がほとんどありません。 ですから、会社やプロジェクトで優れた文書化の実践を奨励し、実施する方法があるのだろうかと思っています。プロジェクトの複雑さに関係なく、システムの適切なドキュメントとプロジェクトのコードを作成するために使用する戦略は何ですか?最小限のドキュメントが必要な場合やドキュメントが不要な場合の良い例はありますか? 私見、私は私達がプロジェクトが渡された後文書の検討があるべきであると感じます。単純で簡潔、説明的で使いやすいものでない場合、開発者または技術文書エンジニアがその責任を負い、修正する必要があります。私は、人々が最初の本のようにユーザーフレンドリーになることを望んではなく、ドキュメントの連を作ることを期待していませんが、何時間もの分析と無駄なKTセッションの必要性を排除すると期待しています。 この狂気を終わらせる、または軽減する方法はありますか?「ドキュメント駆動型開発」でしょうか?

4
同じ問題/チケットに複数の欠陥を投稿することが推奨されないのはなぜですか?
これが次の概念的な質問をする場所であるかどうかはわかりません(Stackoverflowは間違いなくそうではありません)。 この質問は、ISTQB試験に似た多肢選択試験(単一回答)で見ました。 同じ問題/チケットでいくつかの欠陥を報告することが推奨されないのはなぜですか? a。レポートを簡潔かつ明確にするため。 b。開発者が修正できるバグは1つだけだからです。 c。テストグループのテスターは、発見したバグの量によって評価されるためです。 d。バグ管理システムは、複数のバグのこの機能をサポートしていません。 私の唯一の意見は、それaが正しい答えだということです。 b-fix-feedback-resolved-closedがそのケースを回避するはずなので、それはできません。 c-明らかに間違っています。 d -Redmine / Tracプラグインは複数のフィールドをサポートします。 解答用紙によると、答えはbです。 誰かが理由を説明できますか?回答に関する意見を含むコメントを歓迎します。

8
コードレビューのアイデアが嫌いな人にどう対処するか?
明らかに、経営者がコードレビューに時間を費やすことに投資する場合、誰もがそれをしなければなりません。 しかし、常に彼らの存在のあらゆるオンスに抵抗するそれらの人(またはギャル)がいます。 査読者としてこのシナリオを扱うとき、どのようにこのシナリオを効果的に管理しますか?

11
時間の見積もりがうまくいかない場合はどうすればよいですか?
ケースの推定時間が3日間だとしましょう。2日目には、ケースが増えており、時間の推定が行われたときにカウントされなかった新しいシナリオがポップアップしていることに気付きます。新しい調査結果は、2日間余分にかかります(合計5日間)。これは、開発者として遅かれ早かれ直面する典型的な問題です。 プロジェクトリーダーに新しい納期を通知する場合、どの戦略を使用できますか? 多くの場合、なぜ質問がありますか?新しい配達時間をどのように動機付けますか? 実際、多くのプロジェクトでは、SDLCの分析と設計にあまり時間をかけていません。 編集: 非常に複雑なプロジェクトでは、分析と設計にどれだけ合理的な時間を費やしても、ビジネスルールが複雑すぎるため、常に驚きがあります。しかし、そのような場合、プロジェクトリーダーは複雑さを認識し、予期しない驚きが生じたときに正しい態度をとる必要があると思います。問題は、複雑さを理解していないプロジェクトリーダーにどのように取り組むかです。

7
ソフトウェアの再利用はプロセスの再現性を妨げますか
問題としてのコードの再利用 私が考えていたこの質問ソフトウェア・デリバリーに、私は問題に戻って来るまま再現性および/または再現。プロジェクトを繰り返さないと、プロジェクトのビルドに使用したプロセスを改善することが難しくなるためです。エンジニアリングでは、高品質のプロジェクトを作成するために、設計と建設に関連するプロセスを絶えず改善する必要があります。 ソフトウェアは、そのデジタル形式のために再利用に大きく依存できます。モジュールを書き換える代わりに、もう一度呼び出すか、他のシステムにコピーします。いくつかの例は、認証/ログインまたはおそらくロギング機能です。これらのカテゴリには多くのよく知られた例があります。そして、従来の知恵は、あなた自身のものを転がす代わりに存在するものを再利用することです。 他の分野とのいくつかの比較 建設 対照的に、物理システム(建物、橋)の建設は、再利用できるほど近くはありません。家の設計図を何度も再利用して同じ家のコピーを作成できることは事実ですが、そのたびに建設を実行する必要があります。アナログの世界では、カットアンドペーストはそのようには機能しません。橋の設計図は、サイトの条件が異なるため、住宅よりも再利用性が低くなります。 マスタービルダーは、その地域で数十、数百、または数千のものを設計および/または構築したことで知られる専門家です。たとえば、世界的に有名な建築家およびデザイナーであるフランク・ロイド・ライトdesigned more than 1,000 structures and completed 532 works。「ちょうど」5つの言語(Turbo Pascal、Delphi、J ++、C#、Typescript)を設計したAnders Hejlsbergとは対照的です。ドメインが異なるため、多くの点で不公平な比較です。しかし、大まかに言って、2人の非常に知的な人からの定量化可能な作品は大きく異なります。 武道 武道家は、動きの習得は数千の繰り返しからのみ来ると言うでしょう。これらの繰り返しのかなりの部分が投入された後、多くの武道家は、以前は複雑な型または形であると認識されていたことが単純になったことに驚いています。それらの学生のインストラクターは、動きがより流動的で意図的であり、動きが経済的であることにも気付くでしょう。同様に、経験豊富な武道家は、経験の少ない学生よりも複雑なカタをより速く拾うことができます。繰り返しの経験から、より迅速に学習できるフレームワークまたはプロセスが得られました。 木工 木工労働者も同様の変化を経験します。趣味の木材職人は、多くの引き出しを必要とする最初のプロジェクトを常に参照しています。彼らがプロジェクトを完了すると、彼らは組立ラインが生み出す効率性に新たな評価を得ることができます。木材を最大限に活用するために、シートストックに引き出し部品をレイアウトする方法をよりよく理解するなど、他の利点もあります。愛好家と比較して、プロの木材労働者は、以前に何度も作ったアイテムをより迅速に設計、開始、および構築することができます。彼らはまた、他の誰かの設計に内在する問題を自分の仕事でその間違いを犯したことを見る能力を得ます。 それで、ソフトウェアの再利用はソフトウェア開発者がより熟練するのを妨げますか? 多くの点で、ソフトウェアの設計と構築は常に新しいものです。モジュール、ライブラリ、またはシステムを再利用できる場合は、再利用できるため、過去の作業を繰り返すことはありません。ゼロから全体を書き換える前に、既存のシステムを優先的に拡張します。しかし、繰り返しにより、設計と構造の効率を見つけることができます。スポーツや身体活動を実践したことがある人なら誰でも、繰り返しが良い開業医になるための鍵であることを教えてくれます。 私の質問:ソフトウェアの再利用能力は、プロジェクトを繰り返すことから生じる必要なプロセスの改善と効率を妨げますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.