ソフトウェア工学

近い将来、すべてのコンテンツの国際的なローカライズを必要とする.NET MVCアプリケーション用のUIを開発しています。私は一般的に.NETに非常に精通していますが、国際的なアクセシビリティにそのような重要な焦点を当てる必要のあるプロジェクトは一度もありませんでした。 投影は最初は英語で行われています。将来ローカライズを実装しやすくするために、この時点でどのような対策を講じる必要がありますか？

121 .net  localization  internationalization  multilingual 

一部の人々は、統合テストはすべての種類の悪い点と間違っていると主張しています -すべてを単体テストする必要があります。さまざまな理由で、私は常に好きではないオプション。 場合によっては、単体テストでは何も証明されないことがわかります。 例として、次の（PHPでの）単純な（単純な）リポジトリー実装を取り上げましょう。 class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …

120 unit-testing  testing  integration-tests  repository-pattern 

現在、米軍のプロジェクト（低セキュリティレベル、非戦闘人事タイプのデータ）に取り組んでいる人々を知っています。 プロジェクトコードの初期状態がレビューのために軍に提出され、彼らは何らかのセキュリティアナライザーツールを介してプログラムを実行しました。コード内の既知のセキュリティ問題のレポートと、最終製品の配信前に実装する必要がある変更が必要なレポートを返しました。 解決する必要がある項目の1つは、Rubyが動的言語であるために作成されたプロジェクトの一部を削除することでした。 動的言語を安全な設定で使用できないようにする背景/理由は何ですか？これは、政府が新しい技術を採用するのが遅いのですか？または、動的言語は静的言語（ala C ++またはJava）と比較して追加のセキュリティリスクをもたらしますか？

120 code-security  dynamic-languages  government 

1行のコードを実行し、プログラムで1回だけ呼び出されるパラメーターレス（編集：必ずしもではない）関数を考えてください（将来再び必要になることは不可能ではありませんが）。 クエリを実行し、いくつかの値をチェックし、正規表現に関係する何かを実行できます。 この背後にある理論的根拠は、読みにくい評価を避けることです。 if (getCondition()) { // do stuff } where getCondition()は1行関数です。 私の質問は単純です：これは良い習慣ですか？私には大丈夫のようですが、長期については知りません...

120 functions 

リリース日が技術的なものに基づいて設定されているのではなく、営業担当者がそれまでに顧客にコミットしているため、繰り返し立ち往生しているようです。他の会社で開発中の友人との議論に基づいて、同じことが起こるようです。 「ここがコミットされた機能セットであり、ここがコミットされたリリース日です」と主張するのは困難です。なぜなら、この時点でそれに乗っているお金があり、それがすべてに勝るからです。 一般的に、これを後押しする方法はありますか？ このリリースではない場合、将来的にはどうですか？私が抱えている問題は、私がそうする一つの方法を見る唯一の方法であり、それはできる限り最善を尽くすことですが、いわば「現状のまま」ソフトウェアをリリースすることです。 私の名前が付けられているので、バグの多いソフトウェアをリリースしたくありませんが、一度に数か月間80時間週を実行するだけで、任意に設定されたリリース日を証明するだけです。 編集：記録のために、私は今80時間の週をやっていない、ちょうどそれはリリース日までに予想される機能セットをカバーするために必要なものとして思い浮かぶ。

120 communication  estimation  release-management 

ここで最近報告されたように： Xamarinは、2D / 3Dゲーム開発フレームワークであるCocos2D-XNAを分岐させ、PCLプロジェクトに含めることができるクロスプラットフォームライブラリを作成しました。 ただし、分岐したプロジェクトの創設者は次のように述べています。 MITライセンスの目的は、公正使用を妨げないことです。あなたが言うように、ソフトウェアを自分のものとしてブランド変更し、それから「新しい方向に持って行く」ことを奨励しないでください。 違法ではありませんが、非倫理的です。 新しいプロジェクトのGitHub ページでは、それが典型的なGitHubのようにフォークであることさえ示していないようで、代わりに簡単に取り外し可能な履歴セクションを選択しています（下を参照）。 だから私の質問は： Xamarinのアクションとアクションの実行方法は倫理的でしたか？ あなたが独身の開発者または小さな資金のない開発者グループである場合、そのような状況を避けることは可能ですか？ これがwikiの質問になるか、現代のOSS倫理/哲学に基づいた客観的な答えがあることを望んでいます。

119 open-source  ethics  mit-license  philosophy  forking 

私のオフィスは、ブランチの分割とマージをどのように処理するかを理解しようとしており、大きな問題に直面しています。 私たちの問題は、長期的なサイドブランチにあります-マスターから分かれるサイドブランチで数人の人々が働いている種類で、数ヶ月間開発し、マイルストーンに到達すると2つを同期します。 今、私見、これを処理するための自然な方法は、単一のコミットにサイドブランチをつぶすことです。master前進し続けます。当然のことです- master過去数か月の並列開発を過去にさかのぼってダンプしているわけではありません。そして、もし誰かがサイドブランチの歴史のためにより良い解像度を必要とするなら、もちろん、それはすべてまだそこにあります-それはただではなくmaster、サイドブランチにあります。 問題は次のとおりです。私はコマンドラインのみを使用していますが、残りのチームはGUISを使用しています。そして、GUISには他のブランチからの履歴を表示するための合理的なオプションがないことを発見しました。したがって、「この開発はブランチから押しつぶされた」と言って、スカッシュコミットに到達した場合XYZ、何が入っているかを確認するのは非常に苦痛XYZです。 SourceTreeでは、私が見つけることができる限り、それは大きな頭痛の種です：でmaster、からの履歴を見たいmaster+devFeature場合は、チェックmaster+devFeatureアウトする必要があります（異なるすべてのファイルに触れる）、または適切な場所が見つかるまで、リポジトリのすべてのブランチを並行して表示するログをスクロールします。そして、あなたがどこにいるのかを理解してください。 私のチームメイトは、開発の歴史にあまりアクセスできないことを望んでいません。したがって、彼らは、これらの大きくて長い開発側ブランチを、常にマージコミットでマージしたいと考えています。マスターブランチからすぐにアクセスできない履歴は必要ありません。 私はその考えが嫌いです。それは、並行した開発の歴史が無限に行き来できないことを意味します。しかし、私たちがどのような選択肢を持っているのか見ていません。そして、私はかなり困惑しています。これは、優れたブランチ管理について私が知っているほとんどすべてをブロックしているようであり、解決策が見つからない場合は、常にフラストレーションが溜まります。 ここには、サイドブランチを絶えずマージコミットでマスターにマージする以外のオプションがありますか？または、マージコミットを常に使用するのが私が恐れているほど悪くないという理由はありますか？

119 version-control  git  development-process 

多くの質問で気づいたSEの繰り返しのテーマは、C ++がJavaのような高レベル言語よりも高速で効率的であるという継続的な議論です。反論は、最近のJVMまたはCLRは、増加するタスクのJITなどのおかげで同じように効率的であり、C ++ は、あなたが何をしていて、なぜ特定の方法で物事をしているのかを知っている場合にのみ効率的であるということですパフォーマンスの向上に値します。それは明らかであり、完全に理にかなっています。 JVMやCLRよりもC ++で特定のタスクが高速である理由と方法についての基本的な説明（そのようなことがある場合）を知りたいのですが？JVMまたはCLRが実行時にJITコンパイルの処理オーバーヘッドをまだ持っているのに対して、C ++がマシンコードにコンパイルされているからでしょうか？ トピックを調査しようとすると、C ++が高性能コンピューティングにどのように利用できるかを正確に理解することに関する詳細な情報なしで、上で概説したのと同じ議論だけを見つけます。

119 java  c++  performance  jit 

大学を5年間しか卒業していないのに、燃え尽きたように感じます。 私のキャリアの最初の3年間、物事は素晴らしいものでした。学校で特別なことは一度もありませんでしたが、会社で特別な気持ちになりました。振り返ってみると、私はすべての正しい動きをしたと言えるでしょう。 私は積極的に毎日自分自身を改善しようとしました。 私はできる人を助けることを強調しました。 私は良いチームメンバーであることを主張しました（そして本に関する本を読みました）。 私は楽しい時間を過ごした。 トップ従業員として3年連続で評価された後、私はその政治的資本を、私と非常に尊敬されている上級技術リーダーという2人の開発者だけで、興味深く魅力的なプロジェクトに取り組むことへと変えました。 私はそのプロジェクトでハードに取り組み、大成功を収めました。高品質、低バグ、遅延なしなど シニアテクノロジーリードは、メジャープロモーションとGIGANTICボーナスを獲得しました。何もありません。 私はとてもがっかりして、思いやりをやめました。去年、私はただ浮かんできました。最初の4年間は、1日10時間後に活力を感じました。今では、1日6時間働けるようになりました。 何かアドバイス？私が何を求めているのかさえ分かりません。賢い人がこれを見て、私にいくつかの知恵を落とすことを望んでいます。

119 productivity 

依存性注入（DI）は、よく知られた流行のパターンです。ほとんどのエンジニアは、次のような利点を知っています。 単体テストの分離を可能/簡単にする クラスの依存関係を明示的に定義する 優れた設計の促進（たとえば、単一責任原則（SRP）） すばやく切り替え実装を可能にする（DbLogger代わりにConsoleLogger例えば） DIは良い、有用なパターンであるという業界全体のコンセンサスがあると思います。現時点ではあまり批判はありません。コミュニティで言及されている欠点は、通常は軽微です。それらのいくつか： クラスの数が増えました 不要なインターフェイスの作成 現在、同僚とアーキテクチャ設計について話し合っています。彼はかなり保守的ですが、心を開いています。ITの多くの人々は最新のトレンドをコピーし、利点を繰り返し、一般的にはあまり考えすぎないため、あまり深く分析しないでください。 お願いしたいことは： 実装が1つしかない場合、依存性注入を使用する必要がありますか？ 言語/フレームワーク以外の新しいオブジェクトの作成を禁止すべきですか？ 特定のクラスの単体テストを計画しない場合、単一の実装をインジェクトするのは悪い考えです（実装が1つしかないため、「空の」インターフェースを作成したくないとしましょう）。

118 design-patterns  architecture  dependency-injection 

エンジニアリングの理由はありますか？RDBMSの場合、「YEAR」は「MONTH」よりも具体的であるため、パフォーマンスと関係があるのではないかと思っていました。たとえば、2000年は1年しかありませんが、毎年「1月」これにより、年ごとに何かを簡単にフィルタリング/ソートできるようになります。そのため、年が最初になります。 しかし、それが本当に意味をなすかどうかはわかりません...何か理由はありますか？

118 sql  engineering  rdbms  date-format 

プロジェクトがソース管理に最初にコミットするのに十分であるかどうかはわかりません。プロジェクトが「フレームワーク完了」になるまでコミットを延期する傾向があり、それ以降は主に機能をコミットします。（これには大きすぎるコアフレームワークを持つほどの個人的なプロジェクトは行っていません。）これがベストプラクティスではないと感じていますが、何が間違っているのかわかりません。 たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。約10行のボイラープレートコードと、プロジェクトを非常に基本的な機能（1つまたは2つの機能）で動作させるために100行かかります。最初にチェックインする必要があります： 空のファイル？ 定型コード？ 最初の機能は？ 他のポイントで？ また、特定の時点でチェックインする理由は何ですか？

118 project-management  version-control  development-process 

私は中規模（10万行）のコードベースに取り組んでいます。それはすべて比較的新しいコード（1年未満）であり、ユニットテストのカバレッジが良好です。 どこでも使用されなくなったメソッドや、特定のメソッドのみをテストする単体テストでのみ参照されているメソッドに出くわします。 不要になったことが確実な場合、このコードを削除する必要がありますか？ 削除する理由： 少ないコード、少ないバグ 他の人にとってはコードが少ないほど消化しやすい まだソース管理下にあります 維持する理由： 参照として使用できます いつか役に立つかもしれません クラスの機能を「概算」するために作成された可能性があります

118 refactoring  clean-code 

ほとんどのプログラミング言語の関数が、任意の数の入力パラメーターをサポートするように設計されていますが、戻り値は1つだけである理由はありますか？ ほとんどの言語では、その制限を「回避する」ことができます。たとえば、出力パラメータを使用したり、ポインタを返したり、構造体/クラスを定義/返したりすることができます。しかし、プログラミング言語が複数の戻り値をより「自然な」方法でサポートするように設計されていないことは奇妙に思えます。 これについての説明はありますか？

118 programming-languages  language-design 

私はしばらくこの問題を熟考してきましたが、絶えず警告や矛盾を見つけているので、誰かが次の結論を出すことを望んでいます。 エラーコードよりも例外を優先する 私が知っている限りでは、業界で4年間働いて、本やブログなどを読んでから、エラーを処理するための現在のベストプラクティスは、エラーコード（必ずしもエラーコードではなく、エラーを表すタイプ）。 しかし-私にはこれは矛盾しているようです... 実装ではなく、インターフェースへのコーディング 結合を減らすために、インターフェイスまたは抽象化にコーディングします。インターフェースの特定のタイプと実装を知りませんし、知りたくありません。では、どの例外をキャッチする必要があるのか​​をどのようにして知ることができますか？実装は10種類の例外をスローすることも、何もスローしないこともあります。例外を確実にキャッチするとき、実装について仮定しているのでしょうか？ 場合を除き-インターフェイスが持っています... 例外仕様 一部の言語では、開発者は特定のメソッドが特定の例外をスローすることを宣言できます（たとえば、Javaはthrowsキーワードを使用します）。 しかし-これは...を示唆しているようです 漏れやすい抽象化 インターフェイスでスローできる例外を指定する必要があるのはなぜですか？実装が例外をスローする必要がない場合、または他の例外をスローする必要がある場合はどうなりますか？インターフェイスレベルでは、実装がスローする例外を知る方法はありません。 そう... 結論する ソフトウェアのベストプラクティスに矛盾するように見える（私の目には）のに、なぜ例外が優先されるのですか？また、エラーコードが非常に悪い場合（およびエラーコードの悪徳で販売する必要がない場合）、別の選択肢がありますか？上記のベストプラクティスの要件を満たしているが、エラーコードの戻り値をチェックする呼び出しコードに依存しない、エラー処理の現在の（またはまもなく）技術の現状は何ですか？

118 design  language-agnostic  error-handling