ソフトウェア工学

同僚が「それは恐ろしい、恐ろしいハックだ」と言っているのをよく耳にします。 私がそれから奪うことができるのは、それが良くないということです。うまくいくかどうか尋ねると、彼らは「はい、でも良くない」と言います。それは良い解決策ではないということですか？それが機能する場合、ソリューションはどのように悪いですか？それは良い習慣によるものですか？または、メンテナンスできませんか？ソリューションの一部としてコードの副作用を使用していますか？ 何かがハックに分類されると、私にとって興味深いです。どうすれば識別できますか？

55 terminology 

私はちょうど（コンピューティングの）修士号を取得し、仕事に応募しています。多くの企業がオブジェクト指向の理解を特に求めていることに気付きました。人気のあるインタビューの質問は、継承、ポリモーフィズム、アクセサーなどに関するものです。 オブジェクト指向は本当に重要ですか？私はCでのプログラミングの仕事の面接さえ受けましたが、面接の半分はオブジェクト指向でした。 現実の世界では、実際のアプリケーションの開発において、ほとんど常にオブジェクト指向が使用されていますか？ポリモーフィズムのような主要な機能はLOTを使用していますか？ 私の質問は私の弱点の一つから来ていると思います。私はオブジェクト指向について知っていますが、私はそれを私のプログラムに大いに組み込むことができないようです。

55 object-oriented  inheritance  polymorphism 

ビルド番号について考えると、新しいナイトリービルドが作成されるたびに、新しいビルド番号が生成され、そのビルドに割り当てられます。したがって、7.0バージョンのアプリケーションでは、ナイトリービルドは7.0.1、7.0.2などになります。そうですか？それでは、ビルド番号の後のREVISIONの使用は何ですか？または、毎晩のビルド後に改訂部分が増分されますか？私はここで少し混乱しています...私たちは、各ナイトリービルドを参照してくださいBUILD？ 形式はここに記載されています：AssemblyVersion-MSDN

55 builds  versioning 

免責事項：プレフィックスとポストフィックスのインクリメントのセマンティクスを完全に知っています。したがって、それらがどのように機能するかを私に説明しないでください。 スタックオーバーフローに関する質問を読んで、プログラマがpostfix increment演算子に何度も何度も混乱することに気づかずにはいられません。これから、次の疑問が生じます：後置インクリメントがコード品質の面で本当の利点を提供するユースケースはありますか？ 例で私の質問を明確にしましょう。以下は、非常に簡潔な実装ですstrcpy。 while (*dst++ = *src++); しかし、それは私の本の中で最も自己文書化されたコードではありません（そして、それは正気のコンパイラで2つの迷惑な警告を生成します）。それでは、次の選択肢の何が問題になっていますか？ while (*dst = *src) { ++src; ++dst; } その後、条件内の混乱する割り当てを取り除き、完全に警告のないコードを取得できます。 while (*src != '\0') { *dst = *src; ++src; ++dst; } *dst = '\0'; （はい、私は知っている、srcそしてdstこれらの代替ソリューションで異なる結末値を持つことになりますが、以来strcpy、すぐにループの後に返す、それはこの場合には重要ではありません。） 後置インクリメントの目的は、コードをできるだけ簡潔にすることだと思われます。私はこれが私たちがどのように努力すべきかを単に見逃しています。これがもともとパフォーマンスに関するものであった場合、それは今日でも関連していますか？

55 c++  c  postfix 

ジョエル・スポルスキーは、彼の有名な投稿の1つで次のように述べています。 ソフトウェア会社が犯す可能性のある最悪の戦略的ミスは、コードをゼロから書き直すことです。 チャド・ファウラーはこう書いた： ビデオ、ウェブログの投稿、誇大広告を見たことがあるので、Rails（またはJava、.NET、Erlangなど）で製品を再実装することにしました。 気をつけて。これは、予想よりも長く、困難で、失敗しやすいパスです。 BIG Rewriteに参加したことがありますか？ この悲劇的なトピックについてのあなたの経験に興味があります。特に、（もしあれば）成功裏に完了した大きな書き直しに興味があります。

55 rewrite 

あなたの経験（逸話的またはその他）で、アジャイルを非アジャイル組織または会社に導入するための効果的な方法は何ですか？ 更新：アジャイルを導入しようとしたが「撃ち落とされた」ケースについてだれでも話せますか？また、なぜあなたが「撃down」されたのかを振り返って理解していますか？

55 agile  scrum  methodology  culture 

コードレビューのガイドラインをまとめています。正式なプロセスはまだありませんので、正式にしようとしています。そして、私たちのチームは地理的に分散しています。 私たちが使用しているTFSをソース管理のために（私たちは、同様のタスク/バグトラッキング/プロジェクト管理のためにそれを使用するが、我々は、移行とJIRA）開発のためのVisual Studio 2008で。 コードレビューを行う際にあなたが探しているものは何ですか？ これらは私が思いついたものです 強制FxCopののルールを（我々は、Microsoftの店です） パフォーマンス（任意のツール？）とセキュリティ（OWASP-コードクローラーの使用について考えています）およびスレッドセーフを確認します。 命名規則に従う コードはエッジケースと境界条件をカバーする必要があります 例外を正しく処理する必要があります（例外を飲み込まないでください） 機能が他の場所で複製されているかどうかを確認します メソッド本体は小さく（20〜30行）、メソッドは1つのことと1つのことのみを行う必要があります（副作用はなく、一時的な結合を回避します-） メソッドでnullを渡さない/返さない デッドコードを避ける パブリックおよび保護されたメソッド/プロパティ/変数を文書化する 他に何か気をつけるべきことはありますか？ レビュープロセスを定量化できるかどうかを確認しようとしています（別の人がレビューすると同じ出力が生成されます）。例：「メソッド本体は、体は小さくなければなりません」。 または、コードレビューは非常に主観的ですか（また、レビュー担当者ごとに異なります）。 目的は、開発者がコードをチェックインする際により慎重になるように、マーキングシステム（各FxCopルール違反ごとに-1ポイント、命名規則に従わない場合-2ポイント、リファクタリング用に2ポイントなど）を持つことです。これにより、常に良い/悪いコードを書いている開発者を特定できます。目標は、レビュー担当者がレビューを行うために最大で約30分を費やすことです（変更セット/リビジョンに複数のファイル/既存のアーキテクチャへの大きな変更などが含まれる可能性があることを考えると、これは主観的なことですが、一般的な考え方として、レビュー担当者は誰かのコードをレビューするのに何日も費やすべきではありません）。 開発者が書いた良い/悪いコードを識別するために、他にどのような客観的/定量化可能なシステムに従っていますか？ ブックリファレンス：Clean Code：Robert Martinによるアジャイルソフトウェアの職人技のハンドブック。

55 code-reviews 

このサイトでは何度もこのようなことをしようとしている人がいます： <script type="text/javascript"> $(document).ready(function(){ $('<?php echo $divID ?>').click(funtion(){ alert('do something'); }); }); </script> これは、人々が自然に陥るようなパターンではないと思います。これを示しているチュートリアルや学習資料がそこになければなりません。そうでなければ、それはあまり見られません。私が求めているのは、これをあまりにも大きくしているのですか、これは本当に悪い習慣ですか？ 編集： これについて私の友人に話していました。彼はしばしばJavaScriptにルビーを入れて、この点を持ち出しました。 JavaScriptにアプリケーション全体の定数を動的に配置して、2つのファイルを編集する必要はありませんか？例えば... MYAPP.constants = <php echo json_encode($constants) ?>; また、ライブラリで使用する予定のデータを直接エンコードしてもかまいません ChartLibrary.datapoints = <php echo json_encode($chartData) ?>; または毎回AJAX呼び出しを行う必要がありますか？

55 php  javascript  web-development 

履歴書に載せる前に、その言語でどれくらいの経験が必要ですか？私は間違いなく履歴書を書きますが、Cでの大規模なプログラミングやC＃を独学で学んだが、意味のあるプロジェクトを書いていない大学の数学期のコースを取ったと言います（Java）に堪能な言語が1つありますその中で、雇用主にそれを笑わせたり、インフレを再開させたりすることなく、これらの言語を履歴書に載せることはできますか？

55 programming-languages 

TDDの赤-緑-リファクタリングサイクルは十分に確立され、受け入れられています。失敗した単体テストを1つ作成し、できるだけ単純に合格させます。クラスに対して失敗する多数の単体テストを記述し、それらすべてを一度に合格させることに対するこのアプローチの利点は何ですか。 テストスイートは、リファクタリング段階で誤ったコードを記述したり、ミスを犯したりすることからあなたを保護します。クラス（またはモジュール）のすべてのテストを「ブレインダンプ」の形式として最初に記述して、予想されるすべての動作を一度に書き留めることが簡単な場合があります。

55 unit-testing  development-process  tdd 

動的言語と静的言語について、非常に上級のアーキテクトと異常な短い会話をしました。彼は、企業データは、静的言語を使用した場合の生産性向上の証拠があることを示していると述べました。注意してください、それは長い歴史を持つ大企業です。驚いたことに、彼が使用した測定基準は追加されたコード行でした。 彼は、SLOCメトリックが生産性を比較するのに役立つように、同じ企業内で、似た文化、業種、十分なデータを持つ違い（個人の固有の状況と能力に関する）が十分に混ざり合っていると言うメトリックに関する異議をすぐに却下しましたツールと言語。 この主張が厳密な統計分析に裏付けられているとは思わないが、この考え方を裏付ける証拠は業界にあるか？

54 productivity  metrics 

私はコンピューターサイエンスの新入生で、Pythonで実際のプロジェクトを始めました。教授がクラスで提案したペンと紙の方法を使用すると、非常に効率的であることがわかりました。しかし、問題を書き留めることができず、アルゴリズムを紙に書き出すことができないと、本当に遅くなります。ラボでは、宿題を宿舎に戻す必要があるようです。そこに着いてそれを書き出すと、クラス全体を5分ほどでかかった問題を解決します。 たぶん、私が目の前で人々が研究室を解いているのを見るのがストレスになるからでしょう。または多分それはペンと紙の方法です。 私はフォーラムを閲覧していましたが、誰かがプログラムを紙に書かなければならないなら、プログラマーになってはいけないと書いています。実際にコードを入力する前に、プログラムが何をしているのかを確認し、それを自分のやり方で追跡できるようになったときのほうがずっと良いので、本当に心配です。私は何か間違っていますか？ 編集：不明瞭で申し訳ありませんが、紙に書いたとき、問題解決のアプローチ（例の作成、値を含むテーブルの作成など）は実際のコードではありませんでした。紙を使ってアイデアを出しているだけです。

54 algorithms  planning 

私が所属するチームは、当社のプラットフォームと統合するために会社のパートナーが使用できるコンポーネントを作成します。 そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。 いくつかの例： フレームワークの最も低いAPIレベル（.NET標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。 JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。 標準ライブラリのHTTP実装に依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。 同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。 私たちはそれをやりすぎだと感じています。これは私たちの速度に大きな影響を与えると思うので、これにどう対処するのか疑問に思っています。

54 architecture  .net  dependencies  third-party-libraries  code-ownership 

かなり基本的に聞こえますが、最近、同僚に、呼び出されたメソッドstartHttpServerがまだ実行されていない場合にサーバーを起動するだけなので、理解するには複雑すぎると言われました。「真剣に？私はこれを何十年も続けてきました。これはプログラミングの一般的なパターンです」と答えたとき、私はトラブルに陥ります。私が認めようと思うよりも頻繁に、彼は、プログラミングコミュニティ全体が彼の視点の背後にあることを示す文書化された証拠とともに戻ってきて、私はひどい気持ちになります。 質問：必要なアクションが既に有効になっている場合、ノーオペレーションであるメソッドの概念の背後にある文書化された設計パターンはありますか？または、パターンでない場合、名前もありますか？そうでない場合、この方法でメソッドを記述することを検討するのが複雑すぎると考える理由はありますか？

54 design-patterns  patterns-and-practices  anti-patterns 

Youtubeを例として使用したいと思います。彼らはの形式のIDを使用しますPEckzwggd78。 単純な整数を使用しないのはなぜですか？ またはimgur.com- 9b6tMZS画像やギャラリーなどのIDも使用します。連続した整数ではありません。 なぜ整数（特に連続した整数）を使用しないのですか？ どのような場合、整数の代わりにそのような文字列IDを使用することが賢明な決定ですか？

54 database  database-design  web-services