ソフトウェア工学

今日、私は「JUnitの基本」ビデオを見ていました。著者は、プログラムで特定のメソッドをテストするとき、プロセスで他のメソッドを使用しないでくださいと言いました。 具体的には、引数に名前と姓を使用するレコード作成メソッドをテストし、それらを使用して特定のテーブルにレコードを作成することについて話していました。しかし、彼は、このメソッドをテストする過程で、他のDAOメソッドを使用してデータベースにクエリを行って最終結果を確認するべきではないと主張しました（レコードが実際に正しいデータで作成されたことを確認するため）。彼は、そのために、データベースを照会して結果を確認するための追加のJDBCコードを作成する必要があると主張しました。 私は彼の主張の精神を理解していると思います：あるメソッドのテストケースが他のメソッド（この場合はDAOメソッド）の正確さに依存することは望ましくなく、これはあなた自身の検証を（再び）書くことによって達成されます/ supportingコード（より具体的で焦点が合っている必要があるため、よりシンプルなコード）。 それにもかかわらず、私の頭の中の声は、コードの重複、不必要な追加作業などの議論で抗議し始めました。他の方法をテストしながら、それらの方法の一部を使用しても大丈夫ですか？それらの1つが想定されていることを実行していない場合、独自のテストケースは失敗します。それを修正し、テストバッテリを再度実行できます。コードの複製（複製コードがいくぶん単純であったとしても）や無駄な努力は必要ありません。 私が書いたいくつかの最近のExcel - VBAアプリケーション（VBA用Rubberduckのおかげで適切にユニットテストされた）のため、私はこれについて強い気持ちがあります。 これについての洞察を共有していただけますか？

83 programming-practices  unit-testing  code-reuse 

コメントに関して、新しい同僚と議論をしています。私たちはどちらもClean Codeが好きで、インラインコードのコメントを避け、クラスとメソッドの名前を使用してそれらの動作を表現する必要があるという事実にまったく問題ありません。 ただし、主に単一の責任原則パターンを維持しやすいように、クラスの目的と実際に何が表されているのかを説明しようとする小さなクラスの要約を追加するのが大好きです。また、メソッドが何をすべきかを説明する1行の要約をメソッドに追加することにも慣れています。典型的な例は簡単な方法です public Product GetById(int productId) {...} 私は次のメソッドの概要を追加しています /// <summary> /// Retrieves a product by its id, returns null if no product was found. /// </summary メソッドがnullを返すという事実は文書化されるべきだと思います。メソッドを呼び出したい開発者は、メソッドがnullを返すか例外をスローするかどうかを確認するためにコードを開く必要はありません。インターフェースの一部であることがあるため、開発者はどのコードが実行されているのかさえ知りませんか？ しかし、私の同僚は、これらの種類のコメントは「コード臭」であり、「コメントは常に失敗」であると考えています（Robert C. Martin）。 コメントを追加せずに、これらの種類の知識を表現および伝達する方法はありますか？私はロバートC.マーティンの大ファンなので、少し混乱しています。要約はコメントと同じであるため、常に失敗しますか？ これはインラインコメントについての質問ではありません。

83 comments  clean-code 

ソフトウェア開発の最も基本的で広く受け入れられている原則の1つはDRYです（繰り返してはいけません）。また、ほとんどのソフトウェアプロジェクトには何らかの管理が必要であることも明らかです。 では、管理が簡単なタスク（見積もり、スケジュール、制御）は何ですか？正しい反復タスク、DRYに従って回避すべきタスク。 そのため、プロジェクト管理の観点からは、既存のコードを100回コピーしてタスクを解決し、必要に応じて各コピーに若干の修正を加えることは素晴らしいことです。常に、あなたが行った仕事の量と残っている量を正確に知っています。すべてのマネージャーはあなたを愛します。 代わりに、DRYの原則を適用して、重複するコードを多かれ少なかれ除去する抽象化を見つけようとすると、状況は異なります。通常、多くの可能性があります、あなたは決定を下し、研究を行い、創造的でなければなりません。短い時間でより良いソリューションを思いつくかもしれませんが、失敗することもあります。ほとんどの場合、どれだけの作業が残っているかを実際に言うことはできません。あなたはプロジェクトマネージャーにとって最悪の悪夢です。 もちろん大げさですが、明らかにジレンマがあります。私の質問は次のとおりです。開発者がDRYをやりすぎているかどうかを判断する基準は何ですか？どうすれば良い妥協点を見つけることができますか？または、妥協を見つけるだけでなく、このジレンマを完全に克服する方法はありますか？ 注：この質問は、前の質問「ソフトウェア開発における日常作業の量と推定への影響」と同じ考えに基づいていますが、それが私のポイントをより明確にするので、繰り返して申し訳ありません:)。

83 design  project-management  estimation  technical-debt 

私はフリーランスのWeb開発者でしたが、2004年頃に管理ルートを下り始めましたが、再び開発（特にJavaScriptとHTML5 Web /モバイルWebアプリ）に戻ることを決定し、本当に得意な印象を受けましたこれらおよび類似の高速移動テクノロジーは、新しいスキルの学習に加えて、既存のスキルの向上に投資するために一定の時間を確保する必要があります。 私は今、かなり急な学習曲線があることに戻ってきているので理解していますが、どれだけ多くの人がそこにいるのかを見る-私がそこに立ち上がる唯一の方法は、深刻な時間を費やすことです。 フルタイムの開発者として働いている人にとって、私が理解しようとしているのはこれです。ほとんどの日、学習/研究に比べて実際にオフィスでコードを削るのに費やされる時間です。毎日2〜4時間を費やして、物事を進めるための最善の方法を身に付けることができました。 フルタイムで雇用されている優秀な開発者のほとんどは、仕事以外でかなりの時間を投資してスキルを磨いていますか？ それとも、この完全に間違っているのを見ているのでしょうか？

83 javascript  html5  development-environment  time-management 

私は多くの技術面接中に演技または座るように頼まれます。インタビュー対象者が紙で解決できることが期待される論理的な質問と簡単なプログラミングの問題を尋ねます。（キーボードにアクセスしたいのですが、それはまた別の問題です。）時々、人々は問題に対処する方法を知っていると感じますが、緊張や質問のいくつかの推測によってハングアップします（トリックの質問を意図したものではありません）。 上司が助けやヒントを与えるのを聞いたことはありません。彼はインタビューの回答に（それがどんなに良くても悪くても）感謝し、次の質問や問題に移ります。しかし、私はウサギの穴について、敗北と神経があなたを導く可能性があること、そしてそれがどのようにあなたの心を無効にするかについて知っています。失敗したインタビューの数。 困惑した面接対象者にヒントと支援を提供する必要がありますか？

83 interview 

物をパブリックドメインに入れることに関する問題のために、Unlicenseを使用すべきでないとよく耳にします。ただし、これがUnlicenseの問題になる理由はわかりません。Unlicenseは、ライセンスされていないものをすべてパブリックドメインに入れようとします。ただし、Unlicenseの作成者は、パブリックドメインに何かを置くことはそれほど簡単ではなく、不可能な場合もあることを理解しているため、Unlicenseにはバックアップ句（2番目の段落）が含まれています。ライセンスなしのソフトウェアが必要です。Unlicenseには、通常の「このソフトウェアはそのままの状態で提供されている」法的情報を含む免責事項も含まれています。 Unlicenseが悪いのは、それが短く、「unlicensor」、「unlicensee」、サンタクロースが誰であるかを定義していないからです。はいの場合、MIT / BSDスタイルのライセンスはどうですか？それらは一般に有効であると考えられているのに、なぜUnlicenseではないのですか？Unlicense、Creative Commons CC0、FUDなどの寛容なライセンスバックアップ条項でパブリックドメインの権利放棄に反対するのか、それとも本当に大きな法的問題があるのか​​？ Unlicenseの全文は次のとおりです。 これは、パブリックドメインにリリースされる無料で邪魔にならないソフトウェアです。 ソースコード形式またはコンパイル済みバイナリとして、商用、非商用を問わず、あらゆる手段で、誰でもこのソフトウェアを自由にコピー、修正、公開、使用、コンパイル、販売、または配布できます。 著作権法を認める司法管轄区では、このソフトウェアの作者は、ソフトウェアに対するすべての著作権をパブリックドメインに捧げます。この献身は、一般の人々の利益のために、そして相続人と後継者の不利益のために行われます。私たちは、この献身が著作権法の下でこのソフトウェアに対する現在および将来のすべての権利を永久に放棄する明白な行為であることを意図しています。 本ソフトウェアは、商品性、特定の目的への適合性、および非侵害の保証を含むが、これに限らず、明示または黙示を問わず、いかなる保証もなしに「現状のまま」提供されます。いかなる場合においても、作者は、ソフトウェア、使用、またはその他の取引から生じる、契約、不法行為、またはその他の行為に関係なく、いかなる請求、損害またはその他の責任についても責任を負わないものとします。 詳細については、http：//unlicense.org/を参照してください。

83 licensing  legal 

コードを少しずつ書くのは得意だと思いますが、私のデザインは本当にひどいものです。問題は、デザインをどのように改善し、さらに優れたデザイナーになるかです。 学校や大学は人々に数学的な問題解決の達人になる方法を教えるのに良い仕事をしていると思いますが、学校で作成されたほとんどのアプリケーションは一般的に約1000-2000行の長さであるという事実を認めましょうこれは、実際のソフトウェアの複雑さを反映していません-数十万から数百万行のコードです。 ここで、topcoder / project eulerのようなプロジェクトもあまり役に立たないと思います。それらは数学的な問題解決能力を研ぎ澄ますかもしれませんが、あなたはアカデミックプログラマーになるかもしれません。素敵できれいなものにもっと興味を持ち、ほとんどのアプリケーションプログラマが扱う日常的で毛むくじゃらのものにまったく興味がない人。 私の質問は、どのように設計スキルを向上させるのですか？つまり、数千行のコードに入る小規模/中規模のアプリケーションを設計する能力ですか？より良いhtmlエディターキット、またはgimpのようなグラフィックプログラムを構築するのに役立つデザインスキルをどのように学ぶことができますか？

83 design  skills 

クラスライブラリのメソッドまたはプロパティを記述する必要が生じることがありますが、実際の答えがなくても失敗することは例外ではありません。何かを判断できない、利用できない、見つからない、現在不可能、または利用可能なデータがもうない。 このような比較的例外的ではない状況で、C＃4の失敗を示す3つの解決策があると思います。 そうでなければ意味のないマジック値を返します（nullandなど-1）。 例外をスローします（例KeyNotFoundException）。 パラメータでfalse実際の戻り値を返し、提供しoutます（などDictionary<,>.TryGetValue）。 質問は次のとおりです。どの例外ではない状況で例外をスローする必要がありますか？そして、私が投げてはいけない場合：パラメータ付きのメソッドを実装する上で与えられた魔法の値を返すのはいつTry*outですか？（私にはoutパラメーターが汚れているようで、適切に使用するのはより手間がかかります。） 設計ガイドライン（Try*メソッドについては何も知りません）、使いやすさ（クラスライブラリを求めて）、BCLとの整合性、読みやすさなどの事実に関する答えを探しています。 .NET Framework基本クラスライブラリでは、3つのメソッドすべてが使用されます。 そうでなければ意味のないマジック値を返します。 Collection<T>.IndexOf -1を返します StreamReader.Read -1を返します Math.Sqrt NaNを返します。 Hashtable.Item nullを返します。 例外を投げる： Dictionary<,>.Item KeyNotFoundExceptionをスローします。 Double.ParseFormatExceptionをスローします。または パラメータfalseで実際の戻り値を返し、提供しoutます。 Dictionary<,>.TryGetValue、 Double.TryParse。 HashtableC＃にジェネリックがなかったときに作成されたように、それが使用され、objectしたがってnullマジック値として返されることに注意してください。しかし、ジェネリックでは、で例外が使用されてDictionary<,>おり、当初はありませんでしたTryGetValue。どうやら洞察が変わります。 明らかに、Item- TryGetValueとParse-のTryParse二重性は理由があるので、非例外的な障害に対して例外をスローすることはC＃4で行われていないと思います。ただし、Try*メソッドが存在した場合でも、常に存在するとは限りませんでしDictionary<,>.Itemた。

83 c#  .net  exceptions  error-handling 

さまざまな公開Webサイトをクロールし、それらのデータを処理/集約する機能を開発します。電子メールアドレスを探すことほど厄介なことはありません。実際、サイトへのトラフィックを実際に増やす可能性があるものです。しかし、私は脱線します。 敬意以外robots.txtに、（a）悪意のあるように見えて禁止されている可能性を回避し、（b）サイト所有者/ウェブマスターに問題を引き起こさないために、従うべきルールまたはガイドラインはありますか？ 私が考えることができるいくつかの例は重要かもしれないしそうでないかもしれません： 並列リクエストの数 リクエスト間の時間 クロール全体の時間 潜在的に破壊的なリンクの回避（スパイダーオブドゥームになりたくない-しかし、これが実用的かどうかを知っている人） しかし、それは実際には単なる吐き出しです。クモを書いたり利用したりしようとする人に広く適用できる実証済みの知恵はありますか？

83 web-scraping  web-crawler 

ここを見てください：タブとスペースの典型的な聖戦。 弾性タブストップをご覧ください。すべての問題が解決し、非常に便利な新しい動作が多数追加されました。 弾性タブストップは、タブ対スペースの議論でも言及されていますか？何故なの？弾力性のあるタブストップのアイデアには非常に深刻な欠点があり、誰もそれを人気のあるエディターに実装したことはありませんか？ 編集：「なぜ彼らは言及されていない」にあまりにも重点を置いて謝罪します。それは本当に私が意図したものではありませんでした。その質問はおそらく話題外です。私が本当に言っているのは、明らかに有益なアイデアのより広範な採用を妨げるこの最大の欠点は何ですか？（すべてがすでにそれをサポートしている理想的な世界で） （そこには、Microsoft Connectのリクエストすでにだ判明弾性タブストップのVisual Studioの実装は、およびEclipseの要求はあまりにも。プラスについて尋ねる質問があります弾性タブストップを実装する他のエディタは）

83 coding-style  indentation 

次のコードを書きました。 if (boutique == null) { boutique = new Boutique(); boutique.setSite(site); boutique.setUrlLogo(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getLogo()); boutique.setUrlBoutique(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getUrl()); boutique.setNom(fluxBoutique.getNom()); boutique.setSelected(false); boutique.setIdWebSC(fluxBoutique.getId()); boutique.setDateModification(new Date()); boutiqueDao.persist(boutique); } else { boutique.setSite(site); boutique.setUrlLogo(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getLogo()); boutique.setUrlBoutique(CmsProperties.URL_FLUX_BOUTIQUE+fluxBoutique.getUrl()); boutique.setNom(fluxBoutique.getNom()); //boutique.setSelected(false); boutique.setIdWebSC(fluxBoutique.getId()); boutique.setDateModification(new Date()); boutiqueDao.merge(boutique); } ここにはコメントアウトされた行があります。しかし、私はそれが差が間にあるものを明らかにすることにより、コードが明確になり考えるifとelse。違いは、色の強調表示でさらに顕著です。 このようなコードをコメントアウトするのは良い考えでしょうか？

83 documentation  comments 

GitHubで人気のあるプロジェクトを最近見ていると、developブランチがないことがわかりました。実際、GitHub Flowガイドでも言及されていません。私の理解から、master常に完全に安定し、生産を反映する必要があります。開発者が機能ブランチに取り組んでいてmaster、それらが完了したらそれらをマージする場合、機能/修正がマージされmaster、masterブランチが実際に本番よりも新しい期間があることを意味します。 チームが機能/修正ブランチを作成developし、そこにマージして、次のバージョンが完全にリリースの準備ができたら、developマージされmasterてタグが作成されるのはより理にかなっていますか？人々がに直接マージされmaster、masterブランチのコードベースが大幅に変更されたために修正が困難になるバグが本番環境で報告されていると想像してください。その後、開発者はユーザーに次のリリースまで問題を解決するまで待つように指示するだけです。 編集：この質問は「分岐するかしないか」とは異なります。特に、developブランチの使用から遠ざかる人々と、それを取り巻く理由を扱っています。これは、長い間ベストプラクティスとして宣伝されていたためです。

82 git  github 

私は現在、プロのプログラマーです。スキルセットを拡大したいのですが、チームの一員としてキャリアをデブリードにしたいと思っています。学ぶべきことはたくさんあることは知っていますが（これはすぐにはわかりません）、私はそれを行うのに十分賢く、挑戦していると思います。 ここのメンバーの多くはおそらく自分でこれを経験しており、現在は開発リードとして成功しています。残念ながら、私が改善したい個人的な分野（知識の深さ、知識の幅、スキルセットなど）を知っていても、私はこのようなことをどのように始めるか本当にわかりません。 プログラマーとして、この目標を達成するにはどのようなステップを踏む必要がありますか 何を優先すべきですか？

82 skills  experience  team-leader 

MariaDBとMySQLの違いは何ですか？私は両方にあまり詳しくありません。私は主にフロントエンド開発者です。 それらは構文的に似ていますか？これら2つのクエリ言語はどこが違うのですか？ ウィキペディアでは、ライセンスの違いについてのみ言及しています。 MariaDBは、MySQLデータベースのコミュニティ開発ブランチであり、その推進力は、Oracleが現在所有しているMySQLライセンスステータスの不確実性とは対照的に、GPLの下での無料ステータスのコミュニティ維持です。

82 database  mysql  mariadb 

本物のプログラマは1週間以内にどんな言語でも簡単に学べるとよく耳にします。言語は物事を成し遂げるための単なるツールである、と私は言います。プログラミングは、習得して習得しなければならない究極のスキルです。 単に言語の詳細を学ぶのではなく、実際にプログラミングの方法を学んでいることを確認するにはどうすればよいですか？また、1つだけではなくすべての言語に適用できるプログラミングスキルをどのように開発できますか？

82 programming-languages  learning  computer-science  skills  theory