ソフトウェア工学

SunのJavaコードの規則では、演算子の前に改行を配置することが提案されていますが、他の多くのガイドラインは改行に同意しません。明らかな長所と短所はないので、これらのスタイルの1つを別のスタイルよりも使用する利点はありますか？ String longVarName = a + b + c + d + e + f; 対 String longVarName = a + b + c + d + e + f;

29 java  coding-standards  coding-style 

開発段階では、同じ実行で修正する必要がある特定の変数がありますが、時間をかけて修正する必要がある場合があります。たとえば、booleanデバッグモードを通知するには、通常は実行しないプログラムで処理を行います。 これらの値を定数、つまりfinal static int CONSTANT = 0Java に含めるのは悪いスタイルですか？実行中は定数が同じままであることを知っていますが、もちろん、計画外の変更を除いて、開発全体で同じであると想定されていますか？ 同様の質問を検索しましたが、私の質問に完全に一致するものは見つかりませんでした。

28 const  constants 

を実装しDelegateCommandていますが、コンストラクターを実装しようとしていたときに、次の2つの設計の選択肢を思いつきました。 1：複数のオーバーロードされたコンストラクターを持つ public DelegateCommand(Action<T> execute) : this(execute, null) { } public DelegateCommand(Action<T> execute, Func<T, bool> canExecute) { this.execute = execute; this.canExecute = canExecute; } 2：オプションのパラメーターを持つコンストラクターを1つだけ持つ public DelegateCommand(Action<T> execute, Func<T, bool> canExecute = null) { this.execute = execute; this.canExecute = canExecute; } どちらを使用するかわからないのは、提案された2つの方法のいずれかにどのような利点/欠点があるかわからないからです。両方とも次のように呼び出すことができます： var command = new DelegateCommand(this.myExecute); var command2 = …

28 c#  class-design  parameters  constructors 

ここには、想像できない悪いコードを含む大規模なレガシーコードベースがあります。 現在、いくつかの品質基準を定義し、それらを完全に新しいコードベースだけでなく、レガシーコードに触れる場合でも満たすことを望んでいます。 そして、すでに数千件の違反があるSonar（コード分析ツール）でそれらを実施しています。 ここで、レガシーのこれらの違反を減らすための議論が行われました。レガシーだからです。 議論は読みやすさの規則についてです。ネストされたifs / for ..の数など。 さて、レガシーコードのコーディング品質の低下に反対するにはどうすればいいですか？

28 code-quality  static-analysis  legacy-code 

開発中に#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つのコピーだけですべてを実行できます。開発のための良いアプローチですか、それともより良いプラクティスがありますか？

28 c++  programming-practices  development-process 

私はプログラマーというよりは学者であり、研究をサポートするために、私自身が使用する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開発に特に関連した回答を歓迎します。

28 python  programming-practices  development-process 

私はソフトウェア開発と単体テストの作成について考えていました。私は次のアイデアを得ました： 開発者のペアがあるとしましょう。各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目は機能の単体テストを記述します。テストはコードの後に​​記述されます。私の考えでは、彼らはお互いを助けますが、かなり別々に働きます。理想的には、2つの同様のサイズの機能で動作し、テスト準備のために交換します。 このアイデアにはいくつかの利点があると思います。 テストは、実装の詳細を確認できる誰かが作成します。 ペアプログラミング（2つの機能を同時に使用）よりも作業を少し速くする必要があります。 テストとコードの両方に責任者がいます。 コードは少なくとも2人でテストされ、 コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。 また、コード開発とテスト開発の間にコードレビューのために別の開発者を追加することも良い考えです。 このアイデアの欠点は何ですか？それはすでに私にとって未知の方法論として説明されており、ソフトウェア開発で使用されていますか？ PS。私はプロのプロジェクトマネージャーではありませんが、プロジェクト開発プロセスについては何かを知っており、いくつかの最も一般的な方法論を知っています。

28 unit-testing  methodology 

最近、分岐とマージとSCMについてのMSDNの記事に出くわしました：分岐とマージプライマー-Chris Birmele。 記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。 Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。 これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。 私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク（subversion）から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。 トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。 10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。 また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します（poor mans rebase）。 私が持っているいくつかの直接的な質問は次のとおりです。 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？ このマージプロセスの結果に見られる問題の一部はありますか？ 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？ 編集：私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。 この状況に関する他の洞察は歓迎されます。

28 svn  anti-patterns  merging  scm 

C ++ 14は、std::mutexがロックされているかどうかをチェックするメカニズムを省略しているようです。このSOの質問を参照してください。 https://stackoverflow.com/questions/21892934/how-to-assert-if-a-stdmutex-is-locked これを回避するには、いくつかの方法があります。 std::mutex::try_lock() std::unique_lock::owns_lock() しかし、これらのどちらも特に満足のいく解決策ではありません。 try_lock()現在のスレッドがミューテックスをロックしている場合、false negativeを返すことが許可され、未定義の動作があります。また、副作用もあります。オリジナルの上のowns_lock()建設を必要とします。unique_lockstd::mutex 明らかに、自分でロールバックすることもできますが、現在のインターフェースの動機を理解したいです。 ミューテックスのステータスをチェックする機能（std::mutex::is_locked()）は、私には難解な要求とは思えないので、標準委員会は見落としではなく意図的にこの機能を省略していると思います。 どうして？ 編集：わかりましたので、多分このユースケースは私が期待していたほど一般的ではないので、特定のシナリオを説明します。複数のスレッドに分散された機械学習アルゴリズムがあります。各スレッドは非同期で動作し、最適化の問題が完了するとマスタープールに戻ります。 次に、マスターミューテックスをロックします。次に、スレッドは子孫を変異させる新しい親を選択する必要がありますが、現在他のスレッドによって最適化されている子孫を持たない親からのみ選択できます。したがって、現在別のスレッドによってロックされていない親を見つけるために検索を実行する必要があります。マスタースレッドミューテックスがロックされているため、検索中にミューテックスのステータスが変更されるリスクはありません。明らかに他の解決策もありますが（私は現在ブール値のフラグを使用しています）、mutexはスレッド間同期の目的で存在するこの問題に対する論理的な解決策を提供すると考えました。

28 c++ 

この質問は、SQLとNoSQLの違いに関するものではありません。私は現時点では本当に理にかなっていない何かの理由を探しています（おそらく私の理解や感謝の欠如のため）。 MVC5、Entity Framework 6コード、SQL Server 2008を使用してゼロから新しいプロジェクトを開始しました。アプリケーションコードのビジネスレイヤー内で適用する必要があります。 私の意見では、外部キーはデータ/参照整合性の一部を形成し、実際にはビジネスロジックを模倣していません。ビジネスロジックは、参照を適用する対象/タイミング/方法/理由を制御するプロセスと検証に過ぎません。一意の制約はほぼ間違いなくビジネスプロセスであることを理解できますが、私にとってこれはロジックを補完するだけで、整合性の一部を形成します。 2番目の引数は、データにNoSQLアプローチを採用することです。SQL-Server 2008の使用、レポートの必要性、テラバイトにスケーリングされないデータ、Mongo、Ravenなどのテクノロジーに対する考慮の欠如を考慮すると、これは非常に珍しくて非正統的であることがわかりました。 以前にそのようなシナリオに出くわした人はいますか？なぜ参照データ用に設計されたSQL ServerでNoSQLアプローチを採用し、外部キーを必要としないのですか？

28 sql  sql-server  nosql 

私は、1人のユーザーが2011年からリンクを投稿し、IISが他のほとんどの（* nix）Webサーバーよりもはるかに速いことを説明するHacker Newsスレッドを読んでいました。別のユーザーは、HTTP.sysというカーネルモジュールを持つことでIISがその利点を得ると説明します。私の知る限り、2015年に他のほとんどの一般的なWebサーバーはこれを行いません。 カーネルモードのWebサーバーを作成したくありません。セキュリティエクスプロイト（低い保護リングでの実行はそれほど深刻ではない）から解放されると自分を信頼することはできません。 ソフトウェアエンジニアの観点から（Webサーバーの顧客とは対照的に）、カーネルモードで実行するのは賢明なパフォーマンス決定ですか？カーネルモードサーバーを消費者の純利益にするという点まで、アプリケーション開発でセキュリティの懸念を緩和できますか？

28 security  operating-systems  iis  web-servers  apache2 

ディスク操作が遅いことは常に知られており、それらが遅い理由はわかっています。ここでの質問は、なぜI / Oを待たなければならないのか、なぜIOWaitなどのようなものがあるのか​​ということです。 バックグラウンドでいくつかのI / Oタスクを実行しているとき、コンピューターが基本的にかなり遅くなることに気づいたことを意味します。Linuxを使用している場合、より長いI / Oタスクを実行している場合は特に、OSは完了するまでほとんど使用できなくなります。 確かに、私は記事でもこのトピックを見つけました、スニペットがあります： I / O待機は12.1％です。このサーバーには8つのコアがあります（cat / proc / cpuinfoを使用）。これは非常に近い（1/8コア= 0.125） つまり、基本的にはコンピューターの速度がかなり低下しているということです。なぜですか？つまり、通常のコンピューターは少なくとも2コアであり、ハイパースレッディングなどの理由で4コア以上である場合もあります。しかし今、問題はCPUが実際にそこに留まらなければならない理由であり、実際にはIOを待つ以外に何もしませんか？私はプロセス管理の基本的なアイデアやアーキテクチャを意味しますが、今ではそれがOSに起因するのか、それともハードウェアの部分に起因するのかわかりませんが、CPUが待機したり、定期的にチェックし、実際には他の多くのタスクを実行し、準備ができたときにのみIOプロセスに戻ります。確かに、それがそのような困難なタスクであり、CPUが待たなければならないのであれば、なぜ ハードウェアによってより効率的に管理されていますか？たとえば、ある種のミニCPUがあり、それを待って、プロセスに戻ったらすぐにデータのごく一部を実際のCPUに配信します。そのため、プロセスが繰り返されます。実際にデータコピープロセスにCPUコア全体を捧げる...または、この種のものを発明し、そのためにノーベル賞を受賞すべきだろうか？：S さてさて、私は今、オブザーバーの観点から実際にそれを入れています、そして私は本当にそのトピックに深く入っていませんが、CPUがHDDの速度で動作しなければならない理由を本当に理解していません別のことをして、準備ができたらHDDに戻ってください。そのアイデアは、そのIO操作またはコピープロセスなどを必要とするアプリケーションを高速化することではありませんが、その操作の実行中にCPU消費に最小限の影響を与え、OSが他のプロセスおよびユーザーに利用できるようにすることですコピー操作を行うときに一般的なコンピューターの遅延を感じる必要はありません...

28 cpu  io  operations 

誰もがソフトウェア開発のレガシーコードについて語っていますが、過去10年間に、コードベースを悪いものとして表現するために使用される用語を聞いたことがあります。 プログラマにも同様に強力な意味合いを持つこの用語はどこから生まれたのでしょうか？ この用語を開拓したソフトウェア開発に関する本が必ずあるはずです。「レガシーコード」という用語の起源を特定したいと思います。

28 terminology  history  software  legacy-code 

私のチームでは、主要なコードレビューが隠蔽されていると考えています。コメントなしでマージされたコードレビューが多すぎます。 単一のコメントなしにコードレビューのようなものはないように思えます。 チームリーダーとして、チームが適切なコードレビュープロセスを行っていることを適切に監視し、プロセスのメリットを最大化するためにチームを支援するにはどうすればよいですか？ 更新 人々はアップデートについて知りたいと思うかもしれません。ここで与えられた多くの提案を試みました。ほとんどはすでに使用されていました。一部は少し助けた。しかし、問題は残りました-私が見ていなかったときに、一部の人々は絶えず悪いコードを得ました。 コードレビューの監視は、チームツールを提供してコードを改善することほど有用ではないことがわかりました。 そこで、コピーペーストを検出するために「jscpd」という名前のライブラリを追加しました。コピーペーストでビルドが失敗しました。これにより、1つの問題がすぐに解消されました。 次に、codeclimateを試します。 また、半日スプリントで1回、古いコードレビューの手動レビューを行っています。私はtodosを問題/チケットに変換しています-人々がそれらを書いていることがわかりましたが、後で処理されることはありません。また、適切なときにコードをレビューするために、チーム全体と会議を行っています。 一般的に、正しい方向に進んでいるように感じます。

28 code-reviews  review 

最近、GitHubでPythonライブラリに出会いました。ライブラリは素晴らしいですが、関数名に1つの明白なタイプミスが含まれています。dummy_fuction()それがあるべきときにそれを呼び出しましょうdummy_function()。この関数は間違いなく「インザワイルド」であり、組み込みシステムで使用される可能性が最も高くなります。 最初に思い浮かぶのは、正しい名前の関数の2番目のバージョンを追加し、次のリリースの最初のバージョンに非推奨の警告を追加することです。 3つの質問： 上記のアプローチは、意図しない結果をもたらす可能性がありますか？ この種の問題に対する標準的なアプローチはありますか？ 非推奨の警告はいつまで残しておくべきですか？

28 python  version-control  coding-standards  deprecation