ソフトウェア工学

私はこれに本当に混乱しています。経験を積むほど、間違いを見つけて素早く修正する専門家になれると信じています。 今、私の上司は非常に悪いコーディングをしているプログラマーからウェブサイトを得ました。今、彼は修正する問題のリストを送信します。 それがスタイルシートの問題であり、老人がそれを修正する方法を知らないと仮定しますが、私の経験により、私は問題が何であるかをすぐに知っており、私は2分でそれを修正できます。 しかし、すべてを修正した後、他の人が解決できなかったすべての問題を15分で修正したことに気付きました。 私は1時間あたり25ドルを受け取るので、学習に長年の経験を要したもののリストに対して6ドルを請求するのは非常に悪いと感じています。 6 $を充電しても大丈夫ですか？それとも何かを充電する方法がありますか？

127 freelancing 

これは少し面倒ですがId、次のように使用する人もいます。 private int userId; public int getUserId(); および他の使用： private int userID; public int getUserID(); これらの1つは他よりも良い名前ですか？どうして？大規模なプロジェクトでは、これが非常に一貫性のない形で行われるのを見てきました。私がほとんどの人が慣れ親しんでいる標準を設定する場合はどうなりますか？従来の標準はどれですか？

126 coding-style  naming  variables 

再帰を使用するほうがループを使用するよりも優れている場合と、ループを使用する方が再帰を使用するよりも優れている場合があります。「正しい」ものを選択すると、リソースを節約したり、コードの行数を減らすことができます。 ループではなく再帰を使用してのみタスクを実行できる場合はありますか？

126 recursion  loops 

ソフトウェアの面接で（または面接前のスクリーニングの質問として）Stack Exchangeのユーザー名を求められた場合、それは適切だと思いますか？ 私にとって、それは非常に合理的な要求のようであり、非常に有益なもののようです-候補者については、彼らがStack Exchangeに投稿した質問と回答を見ることで5分でもっと学ぶことができると確信しています30分のインタビュー。しかし、そのような質問は悪い形でしょうか？「あまりにも個人的」ですか？ （GitHubや他の公開/オンラインコード共有フォーラムの場合も同様です。）

126 interview 

ソフトウェア業界で流行している最悪の偽りの経済（それは最終的に貯蓄以上の費用がかかるお金を節約する方法）とは何ですか？

126 programming-practices  project-management 

なぜ私たちの多くが同じ変数名を使用してこの同じパターンを繰り返すのかを考えたことはありますか？ for (int i = 0; i < foo; i++) { // ... } 私が今まで見てきたほとんどのコードはi、繰り返し変数としてj、kなどを使用しているようです。 私はどこかからそれを拾ったと思うが、なぜこれがソフトウェア開発でそれほど普及しているのだろうかと思う。それは私たち全員がCから拾ったものなのでしょうか、それともそのようなものですか？ 頭の後ろでしばらくかゆみがありました。

126 programming-practices  coding-style  coding-standards 

今日のUnityに関する講義の1つで、ユーザーがボタンを押した場合にすべてのフレームをチェックしてプレーヤーの位置を更新することについて説明しました。誰かがこれは非効率的だと言ったので、代わりにイベントリスナーを使うべきです。 私の質問は、プログラミング言語、またはそれが適用される状況に関係なく、イベントリスナーはどのように機能するのですか？ 私の直感では、イベントリスナーはイベントが発生したかどうかを常にチェックすると想定します。つまり、私のシナリオでは、イベントが発生した場合はすべてのフレームをチェックすることと同じです。 クラスでの議論に基づいて、イベントリスナーは異なる方法で動作するようです。 イベントリスナーはどのように機能しますか？

125 event-programming 

これは私が何度か遭遇した問題です。データベーステーブルに保存するレコードがあるとします。このテーブルには、「date_created」というDateTime列があります。この特定のレコードはかなり前に作成されたものであり、正確な日付は確かではありませんが、年と月はわかっています。あなたが年だけ知っている他の記録。日、月、年を知っているその他の記録。 「1978年5月」は有効な日付ではないため、DateTimeフィールドは使用できません。複数の列に分割すると、クエリを実行できなくなります。他の誰かがこれに遭遇しましたか？もしそうなら、どのようにそれを処理しましたか？ 私が構築しているシステムを明確にするために、それはアーカイブを追跡するシステムです。かなり前に作成されたコンテンツもありますが、知っているのは「1978年5月」だけです。1978年5月1日として保存することもできますが、この日付が月に対してのみ正確であることを示す何らかの方法があります。その方法で、数年後、そのアーカイブを取得するときに、日付が一致しない場合でも混乱しません。 私の目的では、「1978年5月の不明な日」と「1978年5月1日」を区別することが重要です。また、ほとんどのデータベースシステムでは無効な日付値として拒否されるため、「1978年5月0日」のように不明な値を0として保存したくないでしょう。

125 database  date-format 

余分に見えるコードを見つけましたが、コンパイラーはそれに気付きません。このコードを削除してもリグレッションが発生しないことを確認する（またはできる限り確実に近くする）ために何をしますか。 2つのアイデアが思い浮かびます。 「単純に」、コードが実行されるように見えるかどうかに基づいて演deを使用します。ただし、これは複雑で時間のかかる作業であり、実質的なビジネスリターンが得られないため、わずかにリスクが高い（評価がエラーになりやすい）場合があります。 そのコードセクションにロギングを配置し、実際に入力される頻度を確認します。十分な実行後、コードを削除しても安全であると合理的に確信できます。 より良いアイデアや標準的なアプローチのようなものはありますか？

125 clean-code 

同じロジックを複数回記述していることに気付くたびに、通常、それを関数に固定するため、アプリケーション内でそのロジックを維持する必要がある場所は1つだけです。副作用は、次のような1行または2行の関数になることです。 function conditionMet(){ return x == condition; } または function runCallback(callback){ if($.isFunction(callback)) callback(); } これは怠け者ですか、それとも悪い習慣ですか？これは、非常に小さなロジックの関数呼び出しの数が多くなるためです。

125 programming-practices  coding-standards 

ストックオプションは会社のプライベートなのであまり意味がありません。[あなたが一種のFacebookであり、規制システムがsecondmarketのようなサイトを許可している場合でも、それは可能です。 私はいくつかを考えることができました： 両親および義理の両親に対する健康上の利点 職場まで車で行くための省燃費自転車のスポンサー 1年、3年、5年のサービスの完了のような機会のためのギフトカード ここでさらに提案をすることができます。 編集： 応答してくれてありがとう。要約すると、私のHRができることは次のとおりです。 従業員が拠出する場合、従業員退職基金へのマッチング拠出 継続教育、専門コースなどへの資金提供 ACM、IEEE、Safari Booksなどへの会社のサブスクリプション 食事券 ジムの会員 オフィスでのレクリエーションルームのホスト スポットボーナス 個々の貢献の認識におけるコードスパイクのオフ 安息日

125 management 

自動テストを学習する（そして愛する）ので、ほとんどすべてのプロジェクトで依存性注入パターンを使用していることに気付きました。自動テストを使用する場合、このパターンを使用することは常に適切ですか？依存性注入の使用を避けるべき状況はありますか？

124 design-patterns  dependency-injection 

「タイプ」属性を持つエンティティがあるとします。可能なタイプは20以上あります。 ここで、タイプをA-> Bから変更できるものを実装するように求められます。これは唯一のユースケースです。 したがって、有効なタイプである限り、タイプの任意の変更を許可するものを実装する必要がありますか？または、要件ごとにA-> Bからの変更のみを許可し、B-> AまたはA-> Cなどの他のタイプの変更を拒否する必要がありますか？ 両方の長所と短所を見ることができます。一般的な解決策は、将来同様の要件が発生した場合の作業が少なくなることを意味しますが、間違っている可能性が高くなります（ただし、これで発信者を100％制御しますがポイント）。 特定のソリューションではエラーが発生しにくくなりますが、同様の要件が発生した場合、今後さらに作業が必要になります。 優れた開発者は、将来の拡張が容易になるように、変更を予測してシステムを設計する必要があると聞き続けていますが、これは一般的な解決策のように思えますか？ 編集： それほど具体的ではない例に詳細を追加する：この場合の「汎用」ソリューションは、「特定」ソリューションよりも作業が少なくて済みます。特定のソリューションでは、古いタイプと新しいタイプの検証が必要です。新しいタイプのみを検証する必要があります。

124 programming-practices  api-design  requirements 

関数の正確な結果を事前に予測するのが難しい、非常に数値的/数学的なプログラムを頻繁に使用しています。 この種のコードでTDDを適用しようとすると、そのコードの単体テストを書くよりもテスト対象のコードを書く方がはるかに簡単だと思うことがよくあります。期待される結果を見つける唯一の方法は、アルゴリズム自体を適用することです頭の上、紙の上、またはコンピューターで）。これは間違っていると感じます。なぜなら、テスト中のコードを効果的に使用して、単体テストを検証するためであり、その逆ではありません。 テスト対象のコードの結果を予測することが困難な場合に、単体テストを作成し、TDDを適用するための既知の技術はありますか？ 結果を予測するのが難しいコードの（実際の）例： 機能weightedTasksOnTime日あたりの仕事量が与えられると、workPerDay範囲（0、24]、現在時刻initialTime> 0、およびタスクのリストtaskArrayプロパティ完了するまでの時間と各; time> 0、期日due、及び重要度をimportance、リターン彼らの前に完了することができるタスクの重要性を示す範囲[0、1]に正規化された値dueの各タスクは、場合によって与えられた順序で完了した場合、日付taskArrayから開始し、initialTime。 この関数を実装するアルゴリズムは比較的簡単です：でタスクを繰り返しtaskArrayます。各タスクについて、に追加timeしinitialTimeます。新しい時間<の場合、アキュムレーターdueに追加importanceします。時間は逆workPerDayによって調整されます。アキュムレータを返す前に、タスクの重要度の合計で除算して正規化します。 function weightedTasksOnTime(workPerDay, initialTime, taskArray) { let simulatedTime = initialTime let accumulator = 0; for (task in taskArray) { simulatedTime += task.time * (24 / workPerDay) if (simulatedTime < task.due) { accumulator += task.importance } } return accumulator / totalImportance(taskArray) } 上記の問題は、コアを維持しつつworkPerDay、正規化要件を削除することで単純化できると考えています。 …

124 unit-testing  tdd 

私たちは1つの製品を持つ小さなソフトウェア会社です。 私たちはscrumを使用し、開発者は各スプリントに含める機能を選択します。残念ながら、過去18か月の間に、チームはスプリントのためにコミットした機能を一度も提供していません。 「ソフトウェアは、完了したらすぐに、すぐに、もうすぐに...完了します。チームにプレッシャーをかけたり、より多くの人を投入したりするのには役立ちません。 ...」スプリントの成功率をどのように改善できるかという質問に対して、開発者の1人から同様のフィードバックを受け取りました。ああ、そうです、私たちは回顧展を使用しています。 私の質問は基本的に： 開発者の質の問題を探すのはいつですか？ 独自の作業/機能を選択しても、各スプリントに失敗する場合は、次のように考え始めています。-独自のコードの複雑さを監督することはできません。-または、コードが非常に複雑であるため、誰もその複雑さを監視できません。 何か不足していますか？

124 scrum  planning