ソフトウェア工学

私は個人的に夜遅くまで起きて、コーディングし、個人的なプロジェクトの作業を楽しんでいます。私の他の同僚も同じように感じ、夜のコーディングが好きです。しかし、それは個人的な趣味に情熱を注ぐことではなく、夜に生産性が向上したと本当に感じています。 夜には何かがあり、その暗闇、沈黙、開発者の生産性を高める別の属性があると思います。 これには真実がありますか？なぜ一部の開発者は夜間に生産性が高いと信じているのですか？この命題を正当化する科学的証拠はありますか？「夜、モニターの光の害は少ない」、「夜の自然の空気は酸素が多いので、思考プロセスに適している」などのようなものです。 モデレーター注： 質問は、この主題に関する科学的証拠およびその他の引用情報を求めています。サポート参照を提供しない回答は削除されます。これは、目覚めたときに共有する必要がある投票ではなく、個人的に生産性の高い部分です。

34 productivity  behavior 

私はPythonを学んでおり、PEP 20 The Zen of Pythonの次の点に興味があります。 明白な方法が1つあり、できれば1つだけである必要があります。オランダ人でない限り、その方法は最初は明らかではないかもしれませんが。 誰もこの格言の具体的な例を提供できますか？Rubyなどの他の言語とのコントラストに特に興味があります。Rubyの設計哲学の一部（Perlを起源とするのでしょうか？）は、それを行う複数の方法が良いことであるということです。誰もが各アプローチの長所と短所を示すいくつかの例を提供できますか。注：私はどちらが良いか（おそらく主観的すぎて答えられない）の答えではなく、2つのスタイルの公平な比較を求めています。

34 python  ruby  philosophy 

私は最近いくつかのOpenJDKコードを参照していますが、ビット単位の操作に関係する興味深いコードを見つけました。StackOverflowで質問したこともあります。 ポイントを説明する別の例： 1141 public static int bitCount(int i) { 1142 // HD, Figure 5-2 1143 i = i - ((i >>> 1) & 0x55555555); 1144 i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); 1145 i = (i + (i >>> 4)) & 0x0f0f0f0f; 1146 i = i …

34 low-level  bitwise-operators 

Handbook of Mathematicsに似たスタイルのアルゴリズムの百科事典はありますか？多数のファイルを1か所で利用できると便利です。Art of Computer Programmingは良い情報源と考えられていますが、教訓的なほど百科事典的ではないようです。 モデレーターノート いくつかの説明とコンテキストを提供する長い答えを探しています。本をリストするだけではなく、本やリソースを推奨する理由を説明してください。何も説明していない回答は削除されます。詳細については、良い主観、悪い主観を参照してください。

34 algorithms 

この質問に答えながら、なぜ多くの開発者が優れた設計がパフォーマンスを考慮すべきではないと考えるのか疑問に思い始めました。なぜなら、そうすると読みやすさや保守性に影響するからです。 優れたデザインでは、執筆時にパフォーマンスも考慮され、優れたデザインの優秀な開発者は、可読性や保守性に悪影響を与えることなく効率的なプログラムを作成できると考えています。 極端な場合があることは承知していますが、なぜ多くの開発者が効率的なプログラム/設計が読みやすさや保守性の低下をもたらすと主張するのでしょうか？

34 code-quality  performance  readability  maintainability 

私は上級コーダーからこの話を聞いたことがあり、自分でその一部を見てきました。無意味なコードを書いているプログラマーのインスタンスがいくつかあるようです。次のようなものが表示されます。 価値のないメソッドまたは関数呼び出し。 個別のクラスファイル、オブジェクト、またはメソッドで行われる冗長チェック。 if 常に真と評価されるステートメント。 スピンオフし、注目に値しないスレッド。 ほんの数例を挙げます。これは、プログラマーが意図的にコードを混乱させて組織に自分の価値を高めたい、または契約や外部委託の作業の場合に繰り返しビジネスをしたいからだと言われました。 私の質問は。他の誰かがこのようなコードを見ましたか？そのコードが存在した理由は何でしたか？ 誰かがこのようなコードを書いた場合、その理由を共有できますか？

34 coding-style 

PHP OOPレガシーWebサイトをリファクタリングしています。 クラスの「最終」を「make it explicit that the class is currently not extended by anything」に使い始めたいと思います。クラスに行くと、これにより多くの時間を節約でき、protectedプロパティまたはメソッドの名前を変更/削除/変更できるかどうか疑問に思っています。クラスを本当に拡張したい場合は、最後のキーワードを削除して、拡張のためにロックを解除します。 すなわち、もし子クラスのないクラスに来たら、そのクラスを決勝にマークすることでその知識を記録することができます。次回、コードベースを再検索して、子があるかどうかを確認する必要はありません。したがって、リファクタリング中の時間を節約できます。 それはすべて賢明な時間節約のアイデアのように思えます...しかし、クラスはまれ/特別な場合にのみ「最終」にすべきであると読んでいます。 Mockオブジェクトの作成を台無しにしたり、私が考えていない他の副作用があるかもしれません。 私は何が欠けていますか？

34 php  object-oriented  final 

読んだ後、パッケージ名は単数形か複数形か？私は、自分のペットの探求の1つであるインターフェイスの実装の命名に関する適切な議論を見たことがないことに気付きました。 Orderさまざまな方法で実装することを目的としたインターフェースを持っているが、プロジェクトが最初に作成されたときの最初の実装のみがあると仮定しましょう。あなたはのために行くかDefaultOrderまたはOrderImpl虚偽の二分法を避けるために、または他のいくつかの変種？そして、実装が増えたらどうしますか？ そして最も重要なのはなぜですか？

34 naming  interfaces 

私の会社では、インターネットの使用に厳しい制限があります。スタックオーバーフローにのみ、貧弱なモバイルインターフェイスを使用する必要があります。ただし、このサイトは仕事には非常に便利です。 マネージャーにスタックオーバーフローのブロックを解除するよう説得するにはどうすればよいですか？管理者が確認できる利点の概要はオンラインで利用できますか？

34 productivity 

ときどき、コードを「きれいに」見えるようにすることに苦労してばかげた時間（時間）を費やします。私は物事を対称的に見せることを意味します。実際にクラス全体をすばやくスクロールして、「きれい」または「きれい」に見えないものが飛び出すかどうかを確認します。 時間を無駄にしていますか？この種の動作には何か価値がありますか？コードの機能やデザインが変更されないこともあるので、見た目が良くなるように再構築します。 私は完全にOCDなのでしょうか、またはこれにいくつかの利点が隠されていますか？

34 clean-code 

UIとモデルの間の適切なデカップリングを実装する方法を十分に理解しようとしていますが、行を分割する場所を正確に把握するのに苦労しています。 私はModel-View-Presenterを見てきましたが、それをどのように実装するのか正確にはわかりません。たとえば、私のビューには複数のダイアログがあります。 各ダイアログのインスタンスを持つViewクラスが必要ですか？その場合、ダイアログはプレゼンターとどのように対話する必要がありますか？すなわち。個々のダイアログがプレゼンターを介してモデルからデータを要求する必要がある場合、ダイアログはプレゼンターへの参照をどのように取得する必要がありますか？建設中に与えられたビューへの参照を介して？ 私は多分ビューが静的なクラスであるべきだと思っていましたか？次に、GetViewダイアログとそこからプレゼンターを取得します... ビューとモデルの所有権を持つプレゼンターをセットアップすることを考えていました（ビューを持つプレゼンターとプレゼンターがモデルを持つのとは対照的に）、プレゼンターはビューのイベントのコールバックを登録しますが、それは多くのように見えますより結合された（または少なくとも言語に依存） 私がしようとしている： これを可能な限り分離する 理想的には、プレゼンター/モデルを他の言語のビューと結合することを可能にします（言語間で大量のことをやったことはありませんが、可能な限り、特にvoid(void)私ができる限り、少なくともC＃アプリでC ++ライブラリ... コードを簡潔かつシンプルに保つ だから..相互作用をどのように処理すべきか提案はありますか？

34 design-patterns  ui  interfaces 

現在、実稼働のUbuntu VPSサーバーでApache httpdを実行しています。PHPスクリプトを作成します。 私はJavaの学習に興味があり、現在の設定で動作するようにサーバーサイドJavaをどのように作成するのかを考えていました。 Apache TomcatとApache HTTP Serverは相互にどのように関係していますか？ Tomcatはhttpdのモジュールになれますか？ または、同じ組織（Apache Software Foundation）によって運営されている2つの非常に異なるプロジェクトだけですか？

34 apache  web-servers 

継続的な統合に関連するオーバーヘッドがあります。たとえば、セットアップ、再トレーニング、認識アクティビティ、データの問題であることが判明した「バグ」を修正するための停止、懸念事項のプログラミングスタイルの強制などです。 継続的インテグレーションは、どの時点でそれ自体に費用がかかりますか？ 編集：これらは私の発見でした セットアップは、VSSまたはTFSから読み取り、Nantを備えたCruiseControl.Netでした。 失敗のいくつかの理由を以下に示しますが、これらはセットアップとは関係ありません。 調査コスト：赤信号の原因がコード、データ品質、またはインフラストラクチャの問題（ネットワークの問題、ソース管理からのタイムアウトの読み取り、サードパーティサーバーなど）の真の論理的不整合によるものかどうかの調査にかかった時間ダウンなど） インフラストラクチャに対する政治的コスト：テスト実行の各メソッドに対して「インフラストラクチャ」チェックを実行することを検討しました。ビルドサーバーを交換する以外、タイムアウトの解決策はありませんでした。赤テープが邪魔になり、サーバーの交換はありませんでした。 単体テストの修正コスト：データ品質の問題が原因の赤信号は、誤って記述された単体テストの指標になる可能性があります。そのため、データに依存する単体テストは書き直され、不良データによる赤信号の可能性を減らしました。多くの場合、ユニットテストを正確に実行できるように、必要なデータがテスト環境に挿入されました。データをより堅牢にすると、このデータに依存している場合、テストはより堅牢になります。もちろん、これはうまくいきました！ カバレッジコスト、つまり、既存のコードの単体テストの記述：単体テストカバレッジの問題がありました。単体テストのないメソッドが何千もありました。そのため、それらを作成するにはかなりの工数が必要になります。これはビジネスケースを提供するには難しすぎるため、今後、新しいパブリックメソッドにはユニットテストを使用することにしました。単体テストを行わなかったものは、「潜在的に赤外線」と呼ばれました。ここで重要な点は、静的メソッドは、特定の静的メソッドがどのように失敗したかを一意に判断する方法の重要なポイントであったということです。 オーダーメイドのリリースのコスト：Nantスクリプトはこれまでのところのみです。たとえば、EPiServer、CMS、またはUI指向のデータベース展開用のCMS依存ビルドにはあまり役立ちません。 これらは、1時間ごとのテスト実行と夜間のQAビルドのためにビルドサーバーで発生した問題の種類です。ビルドマスターはリリース時にこれらのタスクを手動で実行できるため、特にワンマンバンドと小さなビルドでこれらが不要であることを楽しませます。したがって、シングルステップビルドは、私の経験ではCIの使用を正当化するものではありません。より複雑なマルチステップビルドについてはどうですか？これらは、特にNantスクリプトなしでは、構築するのが面倒です。したがって、作成したとしても、これらはもはや成功しませんでした。赤信号の問題を修正するコストは、利益を上回りました。最終的に、開発者は興味を失い、赤信号の妥当性を疑問視しました。 公平に試してみましたが、CIは高価であり、単に仕事を終わらせるのではなく、周辺で多くの作業をしていると思います。アラームシステムを導入および保守するよりも、大規模なプロジェクトを大量に作成しない経験豊富な開発者を採用する方が、費用対効果が高くなります。 これらの開発者が去っても、これは事実です。優れた開発者が辞めるかどうかは問題ではありません。彼が従うプロセスにより、要件仕様、設計仕様を記述し、コーディングガイドラインに準拠し、コードが読みやすくなるようにコメントすることが保証されます。これはすべて見直されます。これが発生していない場合、彼のチームリーダーは仕事をしていません。これは、マネージャーなどが引き受ける必要があります。 CIが機能するためには、単体テストを作成し、完全なカバレッジを維持し、大規模なシステムの機能するインフラストラクチャを確保するだけでは不十分です。 結論：リリース前にできるだけ多くのバグを修正することがビジネスの観点からも望ましいかどうか疑問に思うかもしれません。CIには、顧客がUATで特定できる少数のバグをキャプチャするための多くの作業が含まれます。または、保証期間が期限切れになった場合、クライアントサービス契約の一部として会社が修正の支払いを受けることができます。

34 teamwork  continuous-integration 

コンストラクターパラメーターの検証のベストプラクティスは何ですか？ 単純なC＃を想定します。 public class MyClass { public MyClass(string text) { if (String.IsNullOrEmpty(text)) throw new ArgumentException("Text cannot be empty"); // continue with normal construction } } 例外をスローすることは受け入れられますか？ 私が遭遇した代替案は、インスタンス化する前の事前検証でした： public class CallingClass { public MyClass MakeMyClass(string text) { if (String.IsNullOrEmpty(text)) { MessageBox.Show("Text cannot be empty"); return null; } else { return new …

34 c#  validation  constructors 

現在、職場でアプリケーションを継承していますが、残念なことに、データベースに保存されているユーザーパスワードは社内暗号化機能を使用して暗号化されており、暗号化解除機能も含まれています。 したがって、誰かが本当にする必要があるのは、ユーザーテーブルをコピーし、暗号化アセンブリ（データベースの実稼働アクセス権を持つユーザー）をコピーするだけです。そうすれば、100,000の電子メールアドレスと潜在的なパスワードにアクセスできます。 なぜこれが良いアイデアではないのかをビジネスに説明しようとしていますが、セキュリティの概念は技術的にあまり気になっていないので頭に浮かぶようです（政府向けです）。さらに、管理者ユーザーがユーザーのパスワードを取得してログインし、作業を行うために必要な機能を実行するための、アプリケーション内に実際に存在する機能があります。 そのため、彼らはセキュリティへの影響を理解していません。また、強力なセキュリティポリシー（パスワードを簡単に取得できないようにハッシュする）を実装するには、既存の機能を削除する必要があります。 私は何をすべきか？そもそもパスワードシステムを構築していなかったので、何か問題が発生しても非難できるわけではありません。一方、私はそれについて気分が悪く、また、100,000の潜在的な電子メールログオンにアクセスしたくありません。

34 security  client-relations  passwords