ソフトウェア工学

これはアンチパターンですか？それは受け入れられる慣習ですか？ try { //do something } catch (Exception e) { try { //do something in the same line, but being less ambitious } catch (Exception ex) { try { //Do the minimum acceptable } catch (Exception e1) { //More try catches? } } }

95 anti-patterns  exception-handling 

私が依存性注入（DI）と自動テストの大ファンであることを知っておいてください。私はそれについて一日中話すことができました。 バックグラウンド 最近、私たちのチームは、ゼロから構築するこの大きなプロジェクトを手に入れました。複雑なビジネス要件を持つ戦略的アプリケーションです。もちろん、私はそれが素晴らしくてきれいであることを望んでいました。だから私はDIを使いたかった。 抵抗 問題は私たちのチームにありました、DIはタブーです。それは数回育てられましたが、神は承認しません。しかし、それは私を落胆させませんでした。 私の動き これは奇妙に聞こえるかもしれませんが、サードパーティのライブラリは通常、アーキテクトチームによって承認されていません（「あなたは指を切らないように、「Unity、Ninject、NHibernate、MoqまたはNUnitについて話さないでください」）。そのため、確立されたDIコンテナーを使用する代わりに、非常に単純なコンテナーを作成しました。基本的には、起動時にすべての依存関係を結び付け、依存関係（コンストラクター/プロパティ）を挿入し、Web要求の最後に使い捨てオブジェクトを破棄します。それは非常に軽量で、必要なことだけを行いました。そして、私は彼らにそれをレビューするように頼みました。 応答 まあ、短くするために。私は重い抵抗に会いました。主な議論は、「すでに複雑なプロジェクトにこの複雑さの層を追加する必要はありません」でした。また、「コンポーネントの異なる実装をプラグインするようなものではありません」。そして、「できる限りすべてを1つのアセンブリに詰め込んで、できるだけシンプルにしたいと考えています。DIは、メリットのない不必要な複雑さです」。 最後に、私の質問 私の状況をどのように処理しますか？私は自分のアイデアを提示するのが苦手で、人々が議論をどのように提示するかを知りたいと思います。 もちろん、私と同じように、DIの使用を好むと思います。同意しない場合は、その理由を言ってください。そうすれば、コインの反対側を見ることができます。同意しない人の視点を見るのは本当に面白いでしょう。 更新 みんなの回答ありがとうございます。それは本当に物事を見通しに入れます。フィードバックを提供するために別の目があれば十分ですが、15は本当に素晴らしいです！これは本当に素晴らしい答えであり、さまざまな側面から問題を見るのに役立ちましたが、私は1つの答えしか選択できないので、トップの投票されたものを選ぶだけです。答えてくれてありがとう。 私はおそらくDIを実装するのに最適な時期ではないと判断し、私たちはその準備ができていません。代わりに、設計をテスト可能にし、自動化された単体テストを提示することに努力を集中します。テストを書くことは追加のオーバーヘッドであり、追加のオーバーヘッドがそれだけの価値がないと判断されたとしても、デザインはまだテスト可能であるため、個人的にはそれを勝利の状況と見なします。また、将来的にテストまたはDIを選択する場合、設計で簡単に処理できます。

95 dependency-injection 

伝えられるところによれば、アラン・ケイは「オブジェクト指向」という用語の発明者です。そして彼はしばしば、今日私たちがOOと呼ぶものは彼が意味するものではないと言ったと引用されています。 たとえば、Googleでこれを見つけました。 「オブジェクト指向」という用語を作成しましたが、C ++を念頭に置いていなかったことがわかります。 -アラン・ケイ、OOPSLA '97 私は彼が何をしたかについてかなり洞察に満ちた何かを聞いたことを漠然と覚えています。「メッセージの受け渡し」に沿った何か。 彼の意味を知っていますか？彼が何を意味し、今日の一般的なオブジェクト指向とどのように異なるのか、詳細を記入できますか？参照がある場合は共有してください。 ありがとう。

95 object-oriented  history 

はいの場合、どのような予防策を講じる必要がありますか

95 licensing 

私はプロジェクトのコンセプトに合わせてデータベースを設計しようとしており、熱く議論されている問題のように思われました。私はいくつかの記事を読んで、フィールドにIDなどのリストを保存することは決して（またはほとんど決して）大丈夫ではないことを示すいくつかのStack Overflowの回答を読んでいます-すべてのデータはリレーショナルでなければなりません しかし、私が直面している問題は、タスクアサイナーを作成しようとしていることです。ユーザーはタスクを作成し、複数のユーザーに割り当てて、データベースに保存します。 もちろん、これらのタスクを「Person」に個別に保存する場合、1人に0〜100個のタスクを割り当てることができるため、ダミーの「TaskID」列を数十個用意し、それらをマイクロ管理する必要があります。 繰り返しますが、タスクを「タスク」テーブルに保存する場合、ダミーの「PersonID」列を数十個用意し、それらをマイクロ管理する必要があります。これは以前と同じ問題です。 このような問題の場合、何らかの形でIDのリストを保存しても大丈夫ですか、それとも原則を破らずに達成できる別の方法を考えていないだけですか？

94 database  database-design  sql  relational-database 

シングルスレッドの非同期プログラミングを行うとき、私がよく知っている2つの主なテクニックがあります。最も一般的なのは、コールバックを使用することです。つまり、コールバック関数をパラメーターとして非同期に動作する関数に渡すことを意味します。非同期操作が終了すると、コールバックが呼び出されます。 jQueryこのように設計されたいくつかの典型的なコード： $.get('userDetails', {'name': 'joe'}, function(data) { $('#userAge').text(data.age); }); ただし、このタイプのコードは、前のコードが終了したときに追加の非同期呼び出しを次々に行いたい場合、面倒で高度にネストされる可能性があります。 2番目のアプローチはPromiseを使用することです。Promiseは、まだ存在しない可能性のある値を表すオブジェクトです。値にコールバックを設定できます。コールバックは、値を読み取る準備ができたときに呼び出されます。 Promiseと従来のコールバックアプローチの違いは、非同期メソッドがクライアントがコールバックを設定するPromiseオブジェクトを同期的に返すようになったことです。たとえば、AngularJSでPromiseを使用した同様のコード： $http.get('userDetails', {'name': 'joe'}) .then(function(response) { $('#userAge').text(response.age); }); だから私の質問は次のとおりです。実際に本当の違いはありますか？違いは純粋に構文上のようです。 ある技術を他の技術よりも使用する深い理由はありますか？

94 language-agnostic  asynchronous-programming  callbacks  promises 

私は有料のコンテンツを参照するのは嫌いですが、このビデオはまさに私が話していることを示しています。ロバート・マーティンでの正確な12分間はこれを見ています。 そして、彼がこれを次のように変えると、「私がやるべきことの1つは、役に立たないブレースを取り除くことです」と言います。 昔、遠く離れた教育で、そうではないことによって制御されていると考える別のインデントされた行を追加することでバグを簡単に導入できるため、これを行わないように教えられましたif。 ボブおじさんに公平を期すために、彼は長いJavaメソッドを、はるかに読みやすい小さな機能にリファクタリングしています。彼がそれを変更し終えると、（22.18）このようになります： それが中括弧の削除を検証することになっているのかどうか疑問に思っています。私はすでにベストプラクティスに精通しています。この点でボブおじさんに挑戦することはできますか？ボブおじさんはその考えを擁護しましたか？

94 java  coding-style 

最新バージョンからのサードパーティSDKのロールバックに関する会議で、開発者がコミット履歴で最新バージョンを使用すべきではないというフラグをすでに立てていることが確認されました。 一部の開発者は、これは悪い習慣であり、代わりにソースファイル（つまり// Don't upgrade SDK Version x.y.z, see ticket 1234）またはプロジェクトレベルのREADMEファイルのいずれかに記載する必要があると主張しました。他の人は、コミット履歴はプロジェクトのドキュメントの一部であるため、私たち全員がとにかくそれを読んでいるはずなので、そのような情報の許容できる場所であると主張しました。 重要な情報を他の開発者に伝えるためにコミット履歴を使用する必要がありますか、またはそのような情報をプロジェクトREADMEや関連するソースファイルのコメントなどの別の場所に複製する必要がありますか？

94 version-control  documentation 

OOPの背後にある基本的な考え方は、データと動作（そのデータに基づく）は不可分であり、クラスのオブジェクトの考え方によって結合されるということです。オブジェクトには、それ（およびその他のデータ）で機能するデータとメソッドがあります。明らかに、OOPの原則により、単なるデータであるオブジェクト（C構造体など）はアンチパターンと見なされます。 ここまでは順調ですね。 問題は、私のコードが最近このアンチパターンの方向にますます進んでいるように見えることに気づいたことです。クラスと疎結合設計の間の情報隠蔽を達成しようとすればするほど、私のクラスは、動作クラスのない純粋なデータとデータクラスのないすべての動作の混合になります。 私は通常、他のクラスの存在に対する認識を最小限に抑え、他のクラスのインターフェイスに関する知識を最小限に抑える方法でクラスを設計します。特にトップダウン方式でこれを実施します。低レベルのクラスは高レベルのクラスについては知りません。例えば： 一般的なカードゲームAPIがあるとします。あなたにはクラスがありCardます。ここで、このCardクラスはプレーヤーの可視性を決定する必要があります。 1つの方法はboolean isVisible(Player p)、Cardクラスに参加することです。 もう1つはboolean isVisible(Card c)、Playerクラスに参加することです。 特に、最初のアプローチは嫌いです。なぜなら、より高いレベルのPlayerクラスに関する知識をより低いレベルのCardクラスに与えるからです。 代わりに、3番目のオプションを選択しました。このViewportクラスでは、指定Playerされたカードとカードのリストによって、どのカードが表示されるかが決まります。 ただし、このアプローチは、可能なメンバー関数の両方CardとPlayerクラスを奪います。カードの可視性以外のものに対してこれを行うとCard、Playerすべての機能が他のクラスで実装されているため、純粋にデータを含むクラスが残りますViewport。 これは、OOPの基本的な考え方に明らかに反しています。 正しい方法はどれですか？クラスの相互依存関係を最小化し、想定される知識と結合を最小化するが、すべての低レベルクラスにデータのみが含まれ、高レベルクラスにすべてのメソッドが含まれるという奇妙なデザインに巻き込まれないようにするにはどうすればよいですか？全体の問題を回避するクラス設計に関する3番目の解決策や視点はありますか？ PS別の例を示します。 DocumentId不変で、単一のBigDecimal idメンバーとこのメンバーのゲッターのみを持つクラスがあるとします。ここで、データベースからこのidをDocumentId返すメソッドをどこかに持つ必要がありDocumentます。 あなたは： クラスにDocument getDocument(SqlSession)メソッドを追加しDocumentId、永続性に関する知識（"we're using a database and this query is used to retrieve document by id"）、DBへのアクセスに使用されるAPI などを突然導入します。また、このクラスでは、コンパイルするために永続性JARファイルが必要になりました。 この方法でいくつかの他のクラスを追加しDocument getDocument(DocumentId id)たまま、DocumentId死んだ、いや行動、構造体のようなクラスとしてクラスを。

94 object-oriented 

関数型言語で見落としている機能の1つは、演算子が単なる関数であるという考えです。したがって、カスタム演算子を追加することは、関数を追加するのと同じくらい簡単です。多くの手続き言語では演算子のオーバーロードが許可されているため、ある意味では演算子は関数のままです（これは、テンプレートパラメーターの文字列として演算子が渡されるDで非常に当てはまります）。 演算子のオーバーロードが許可されている場合、カスタム演算子を追加するのは簡単なことが多いようです。私はこのブログ投稿を見つけました。これは、カスタム演算子が優先順位規則のために中置記法でうまく機能しないと主張していますが、著者はこの問題にいくつかの解決策を提供します。 私は周りを見回しましたが、その言語のカスタム演算子をサポートする手続き言語を見つけることができませんでした。ハック（C ++のマクロなど）がありますが、それは言語サポートとほとんど同じではありません。 この機能の実装は非常に簡単なので、なぜもっと一般的ではないのですか？ itいコードにつながる可能性があることは理解していますが、それによって、過去に言語設計者が簡単に悪用される可能性のある便利な機能（マクロ、三項演算子、安全でないポインター）を追加することを妨げませんでした。 実際の使用例： 欠落している演算子を実装します（たとえば、Luaにはビット演算子がありません） Dの模倣~（配列連結） DSL |Unixパイプスタイルの構文シュガーとして使用（コルーチン/ジェネレーターを使用） 私はまた、言語に興味があるんカスタム演算子を許可するが、私は、より興味なぜそれが除外されています。スクリプト言語をフォークしてユーザー定義の演算子を追加することを考えましたが、どこにも表示されていないことに気付いたときに自分自身を止めました。したがって、言語デザイナーが私よりも賢いのは私がそれを許可していないことにはおそらく十分な理由があります。

94 programming-languages  operators  procedural 

少し背景 私は現在28歳で、ソフトウェア開発の正式なトレーニングを受けたことはありませんが、広報の学士号とプロジェクト管理に焦点を当てたエグゼクティブMBAに相当する2つの高等教育学位を持っています。私はそれらの分野で合計約6年間働いていましたが、2.5年前に仕事を辞めたり、失い、方向を変えることにしました。 1か月後、私はWordPressで小さなWebサイトの開発をフリーランスで始めることにしました。私は自分のやり方を自分で学びました。今日、私はクライアントのためにテーマとプラグインをゼロから開発する謙虚だが成功したキャリアを走っていると言えるでしょう。 しかし、十分な数学を学んでいない、または物事を正式に理解していないと、より経験豊富な開発者と競争したり仕事をしたりするときに、本当に遅れをとると感じることがあります。もっと学ぶ方法を常に探していますが、基本が欠けているようです。 残念ながら、コンピューターサイエンスに4年間を費やすことは今のところ選択肢ではないため、書籍やオンラインリソースからできる限りのことを学ぼうとしています。この方法でNASAが私を雇うことは決してありませんが、私は今のところ本当に気にしません。私の目標は、まず基準をクリアし、自分を本当のプログラマーと呼ぶことができるようにすることです。 私は現在、プログラマー向けJava（誰もが難しい/要求の厳しい言語を把握するため）を勉強し、コードの抜粋（ベストプラクティスを把握するため）とコード：The Hidden Language of Computerを勉強していますハードウェアおよびソフトウェア（コンピューターの内部動作を把握するため）。 TL; DR だから、私の現在の状況はこれです：基本的にPHPで完全なシステムを書くことができ（Googleといくつかの本の助けを借りて）、Ajax、SQLなどを統合し、経験豊富な開発者が期待するよりも少し遅いかもしれません関係するすべての研究のため。 しかし、昨日、if($n1 % $n2 == 0) メソッド モジュラス演算子が記憶されていなかったため、FizzBu​​zzテストの解決策を（Googleではなく）見つけようとしていました。 このジレンマを解決する良い方法として何を提案しますか？問題をより早く、おそらく「プログラマーの方法で」解決するために、どの科目/本を勉強すればよいでしょうか？ 編集 -FizzBu​​zzを解決するために私が知らなかったことについて、いくらかの混乱があったようです。 自分自身を正しく表現しなかったのかもしれません。問題を解決するために必要な手順を知っていました。記憶しなかったのは、モジュラス演算子です。問題は、基本的な数学を知ることではなく、基本的な数学をプログラムに転置することでした。 Coding Horrorで読んだ後、テストを楽しみました。私と、正式に訓練された開発者との間の優れたベース比較ラインだと判断しました。 これは、単純な問題を解決するためにモジュラス演算子などの基本的なものを探す時間を失う前に、コンピューター環境で数学を処理しなかった方法の例として使用しました。

94 skills 

TDD体験のマイナス面は何ですか？赤ちゃんのステップ（テストをグリーンにするための最も簡単な修正）が迷惑で役に立たないと感じますか？価値のないテストを見つけますか（テストは最初は意味がありますが、最終的な実装では他のテストと同じロジックをチェックします）メンテナンスが重要ですか？等 上記の質問は、TDDの経験中に私が不快に思うことに関するものです。だから私は他の開発者が同じような感情を持っているかどうか、彼らは彼らについてどう思うか興味があります。 TDDのネガティブな側面を説明する記事へのリンクに感謝します（Googleはポジティブで熱狂的な記事でいっぱいです）。

94 tdd 

MicrosoftのアプリマーケットプレイスのアプリでLGPLライセンスライブラリを使用したい。それは大丈夫ですか？

94 lgpl 

プログラミングの方法を学ぶための最良の方法は何かと尋ねられると、人々は通常、さまざまな著者によって書かれた大量のテキストへの参照を提供します。 しかし、私は多くの人が本からプログラムを学ぶことをまったく信じていません。彼らは通常、課題に直面しており、それを克服するためのツールとしてプログラミングを使用していることがわかります。 たとえば、私がプレイしていたゲームのサーバーを起動したかったため、プログラミングに「入りました」。そのため、特定のサーバーのサポートをグーグルで調べて読み、現在は開発したスキルのみを使用して雇用されたソフトウェアエンジニアです（そして、さらに開発されました）、あまり人気のないサーバーパッケージ用のC＃スクリプトをコーディングします。 だから私の質問は、人々は一般的にこれらの本から学ぶ方が簡単だと思いますか？私はそれらのいくつかを見て、それらを終了するように私を励ますにはあまりにも「ドライ」であることがわかりました。

94 books  methodology 

私は現在、大企業の上級研究ソフトウェアエンジニアであり、「シニアスタッフエンジニア」の役職に就いています。新しい役職のタイトルが横向きの動きなのか進歩なのかわかりません。 したがって、他のすべてのものはほぼ同じです（給与、専門分野など）、これらのソフトウェアエンジニアのタイトルの外部の違いは何ですか（一般に、可能であれば特定の会社に関係なく）： シニアエンジニア 上級研究員 シニアスタッフエンジニア 技術スタッフ 主任技師 編集：「技術スタッフのメンバー」について詳しく説明しましょう。これは珍しいことです。私はそれが高い研究タイトルだと思います。Oracle、VMWare、および古いBell Labsにこれらのタイトルがあることは知っています。参照：技術スタッフのメンバー。私はそれが何を意味するか知っているが、それが他のタイトルとどのように重なるかわからないので、私は尋ねた。

94 skills  experience  organization