ソフトウェア工学

技術面接を実施して、いくつかの.NETの職に就いた。私はインタビューの人々の多くは、実際にはないかなりよく.NETを知っているが、私は少なくとも90％が「非常に劇的」に「少し」の間でどこでも自分のスキルを飾る見つけます。時には彼らは、彼らが応募しているポジションに関連するスキルを作り上げますが、そうではない場合もあります。 私がインタビューする人々のほとんどは、最も悪質な嘘つきでさえ、詐欺師ではありません。彼らはただ群衆の中で目立つことを望んでいるので、「JBoss」、「LINQ」、「web services」、「Django」などの履歴書にいくつかの流行語を落とします。 （これらのスキルについてうそをついている人が、技術面接でただブラフしているのではないかと思うかもしれません。私の面接では、多くのハンズオンコーディングと問題解決を行います。最初の3分間） これらは2つの自由回答形式の質問ですが、採用マネージャーに推奨事項を提示する際に非常に役立ちます。 エチケットの面接について、自分が主張するスキルをすべて持っているかどうかを判断する必要がありますか？候補者に不快感を与えずにこれを行うことはできますか？ 最終決定に関して、スキルセットの一部を作成したとしても、応募する職種に真に適格な候補者を推薦する必要がありますか？

72 professionalism 

あなたがXXXコメントで見るとき、人々は一般に何を意味します。時折、次のようなコメントが表示されます。 # XXX - This widget really should frobulate the whatsit もちろん、コメントの意味はわかりますが、XXXは一般的にどういう意味ですか？「これはハックです」と言っているのでしょうか、それとも「おそらくこれを後で再検討する必要がある」でしょうか。それとも、まったく別のことを言っていますか？

72 comments  coding-standards 

ヘッダーファイルに絶対に含まれてはならないものは何ですか？ たとえば、多くの定数を持つ文書化された業界標準形式で作業している場合、ヘッダーファイルで定義することをお勧めします（その形式のパーサーを作成している場合）。 ヘッダーファイルにはどの関数を挿入する必要がありますか？ してはいけない機能は何ですか？

71 c  headers 

BBC に関する記事を読みました。彼らが言った例の1つは、姓が「Null」の人が一部のウェブサイトに詳細を入力するのに問題があるということでした。 彼らが直面しているエラーについての説明はありません。 しかし、私が知る限り、文字列 'Null'と実際のNull値は完全に異なります（データベースの観点から）。 これがデータベースで問題を引き起こすのはなぜですか？

71 database  null 

例：Webアプリケーションでフォームの機能テストを実行しているときに、異なる種類のランダムな入力値を入力してフィールドをテストします。 一般に、Webアプリケーションのユーザーとして、フィールドにランダムな値を実際に入力することはありません。 このような問題が本番環境で発生する可能性がはるかに低い場合、バグにつながる可能性のある/そうでない可能性のあるすべてのテストケースを組み込むことの使用は何ですか？ 注：上記の例はサンプルケースにすぎません。このような問題は、あらゆる種類の機能/モジュールで発生する可能性があります。 この質問は、標準的な慣行が続くかどうか、または製品、ドメイン、その他すべての要因に完全に依存するかどうかを知るためだけに行っています。

71 testing  web-applications  bug 

次の状況を考慮してください。 Gitリポジトリのクローンがあります ローカルコミット（まだどこにもプッシュされていないコミット）がある リモートリポジトリには、まだ調整されていない新しいコミットがあります このようなもの： git pullデフォルト設定で実行すると、次のようなものが得られます。 これは、gitがマージを実行したためです。 ただし、代替手段があります。代わりにリベースを行うようにpullに指示できます： git pull --rebase これが得られます： 私の意見では、リベース版には多くの利点があり、それらは主にコードと履歴の両方をきれいに保つことに集中しているため、gitがデフォルトでマージを行うという事実に少し驚いています。はい、ローカルコミットのハッシュは変更されますが、これは、より単純な履歴の見返りとして支払う小さな代償のようです。 しかし、これが何らかの形で悪いまたは間違ったデフォルトであることを決して示唆しているわけではありません。デフォルトではマージが優先される理由を考えるのに苦労しています。なぜ選ばれたのかについての洞察はありますか？デフォルトとしてより適切にする利点はありますか？ この質問の主な動機は、私の会社がリポジトリを整理および管理する方法についてのいくつかのベースライン標準（できればガイドラインに似ている）を確立しようとしていることです。私は通常、このタイプの状況でリベースする必要があるというケースを作成することに興味があります（そしておそらく開発者がデフォルトでリベースするようにグローバル構成を設定することを推奨するため）とても素晴らしい場合はデフォルトです。だから私は私が不足している何かがあるのだろうかと思っています。 この質問は、なぜ多くのウェブサイトが「git merge」よりも「git rebase」を好むのかを複製したものであることが示唆されています。; ただし、この質問はこの質問の逆です。この質問では、リベースよりもマージの利点について質問されていますが、マージよりもリベースのメリットについて説明します。そこでの答えはこれを反映しており、マージの問題とリベースの利点に焦点を当てています。

71 git 

大規模なC＃プロジェクトの既存のコーディング標準には、すべての型名を完全修飾するというルールが含まれており、「using」ディレクティブの使用を禁止しています。だから、おなじみではなく： using System.Collections.Generic; .... other stuff .... List<string> myList = new List<string>(); （var禁止されていることはおそらく驚くことではありません。） 私は最終的に： System.Collections.Generic.List<string> myList = new System.Collections.Generic.List<string>(); それはタイピングの134％の増加であり、その増加のどれも有用な情報を提供しません。私の見解では、増加の100％は実際に理解を妨げるノイズ（混乱）です。 30年以上のプログラミングの中で、私はそのような標準が一度か二度提案されたのを見たことがありますが、実装されたことはありません。その背後にある理論的根拠は私を逃れます。標準を課している人は愚かではなく、私は彼が悪意があるとは思わない。私が何かを逃していない限り、それは他の唯一の選択肢として見当違いのままになります。 そのような標準が課されていることを聞いたことがありますか？もしそうなら、その背後にある理由は何でしたか？usingこの禁止を取り除くようにこの人に説得するかもしれない「それは愚かだ」または「他の誰もが採用している」以外の議論を考えることができますか？ 推論 この禁止の理由は次のとおりです。 完全に修飾された型を取得するには、名前の上にマウスを移動するのは面倒です。常に完全修飾型を常に表示することをお勧めします。 電子メールで送信されたコードスニペットには完全修飾名がないため、理解が難しい場合があります。 Visual Studioの外部（Notepad ++など）でコードを表示または編集する場合、完全修飾型名を取得することはできません。 私の主張は、3つすべてのケースがまれであり、少数のまれなケースに対応するためだけに、誰もが混乱して理解しにくいコードの代価を支払うようにすることは見当違いだということです。 潜在的な名前空間の競合の問題は、私が主な関心事であると予想していましたが、言及さえされていませんでした。名前空間があるためMyCompany.MyProject.Core、これは特に驚くべきことです。これは特に悪い考えです。何かを命名しSystemたりCore、C＃で命名することは、狂気への素早い道であることをずっと前に知りました。 他の人が指摘したように、名前空間の競合は、リファクタリング、名前空間のエイリアス、または部分的な修飾によって簡単に処理されます。

71 c#  coding-standards 

私のチームメイトの1人はITショップのすべての取引のジャックであり、私は彼の洞察を尊重しています。 ただし、彼は時々頭を使わずに私のコードをレビューします（彼はチームリーダーの2番目の指揮官なので、それは予想されています）。そのため、時々、彼は最終目標を完了する前に私の変更をレビューし、すぐに変更を加えます。 また、3か月以上前のコードの一部に不要な改善を加えた場合もあります。 これにはいくつかの理由があります。 間違いを修正する機会が常に与えられるとは限らない 彼は、彼が混乱しているときに私が何を達成しようとしていたかを尋ねる時間をとっていないので、テストや変更に影響を与える可能性があります 彼のコードが読めるとは限らない 期限は問題ではなく、彼の現在のワークロードは、コードの変更を確認する以外に私のプロジェクトでの作業を必要としません。 とにかく、私は過去に彼が私のコードの所有権を取得できるように変更したい何かを私の仕事で見た場合、私に投稿してくださいと言いました（多分私は「欠点」と言うべきでした）、彼は応答しませんでした。 彼に私に彼の変化を説明するように頼むとき、私は攻撃的になるかもしれないと恐れています。 彼は自分を守る静かな人ですが、彼の行動は続きます。私たちはチームであるため、私は彼にコードの変更を禁止したくありません（できませんでしたが）。 説明を追加： 1つの開発ブランチを共有しています。重要な作業を失うリスクがあるため、すべての変更が1つのタスクを完了するまで待機しません。したがって、変更を確実にビルドし、何も壊さないようにします。 私の懸念は、チームメイトが彼の変更の背後にある理由や目的を説明していないことです。私は彼が私の祝福を必要とするべきではないと思うが、私たちがアプローチに同意しない場合、私たちが長所と短所を議論し、両方が何が起こっているかを理解したら決定を下すことが最善だと思った。 これはチームリーダーとはまだ話し合っていません。必要でない限り、経営陣が関与することなく個人的な意見の不一致を解決したいからです。私の懸念は私たちの仕事に対する脅威というよりも個人的な問題のように思われたので、チームリーダーを煩わせないことにしました。私は、コードレビュープロセスのアイデアに取り組んでいます。これは、私のペットの気持ちをすべて気にすることなく、より組織的なコードレビューのメリットを促進するためです。

71 refactoring  teamwork  communication  code-ownership 

たとえば、Autodesk Mayaの規模と複雑さのコード、2千万から3千万行以上のコードについて話しています。 必要に応じて開発をフリーズした場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか？バグのないシステムの存在に対する賛否両論は何ですか？ 修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。 バグとは、UIの最も単純なタイプミスから、回避策のないより深刻な予防バグまでを意味します。たとえば、特定のスクリプト関数は法線を正しく計算しません。また、回避策がある場合でも、問題を解決する必要があります。したがって、提供された関数を使用する代わりに、この特定のことを手動で行うことができますが、その関数はまだ修正する必要があります。

71 programming-practices  bug  software  complexity 

従来、コミット前にコードレビューを実行していましたが、今日、同僚とコミット後のコードレビューを希望する議論がありました。 まず、ここに背景があります。 経験豊富な開発者がおり、プログラミングの経験がほとんどない新規採用者もいます。 製品をリリースするために、高速かつ短時間の反復を実行したいと考えています。 すべてのチームメンバーは同じサイトにいます。 私が学んだコミット前のコードレビューの利点： メンターの新入社員 開発サイクルの早い段階でエラー、障害、不良な設計を防止するようにしてください 他の人から学ぶ 誰かが辞めた場合の知識のバックアップ しかし、私はいくつかの悪い経験もしました： 効率が低いため、一部の変更は数日にわたってレビューされる 特に初心者の場合、速度と品質のバランスを取るのが難しい チームメンバーの1人が不信感を抱いた コミット後のレビューについては、これについてはほとんど知りませんが、私が最も心配しているのは、レビューがないためにコントロールを失うリスクです。意見はありますか？ 更新： VCSにPerforceを使用しています コーディングとコミットは同じブランチ（トランクまたはバグ修正ブランチ）で行います 効率を改善するために、コードを小さな変更に分割しようとしました。また、ライブダイアログレビューをいくつか試しましたが、全員がルールに従ったわけではありません。ただし、これは別の問題です。

71 code-reviews 

私のキャリアを通して、私はさまざまな目的のためにさまざまな環境のコレクションを持つ企業で働いていました。デスクトップ環境、テスト環境、QA環境、ステージング環境、実稼働環境は常に多かれ少なかれありました。これは、サーバー/アプリケーションと私たちが使用していたデータソースの両方に当てはまりました。 現在の会社で仕事を始めたとき、アプリケーションの90％が実稼働データソースに対するデスクトップ環境で開発されたか、プラットフォームに応じて実稼働サーバーで直接開発されたことがわかりました。これは特に驚くことではありませんでした。開発チームの機能を改善するために一部変更を加えるために雇われたため、インタビュープロセスから明らかでした。私たちはゆっくりと哲学を変え始め、ほとんどすぐに、ほとんどのアプリをデスクトップ、テスト、または実稼働環境で実行できました。ステージングもまたそう長くはかからなかった。 現在、ほとんどの開発者はこの方法論の利点を理解し、慎重に防御しています。ただし、移行されていない多くのレガシーアプリがあります。また、これを時間の無駄だと考える多くのレガシープログラマもいます。残念ながら、リップサービスは受けましたが、経営陣からの完全な賛同を得ることはありませんでした。約1年前にこれに実質的に投資するというコミットメントだと思いましたが、かなりの計画を立てましたが、何も実現しませんでした。今、私たちはますます多くの環境を必要としていることに気付いています。セットアップにはサーバー/ネットワーク管理チームの支援が必要であり、リリースサイクルをサポートするにはビジネス関係者の参加が必要です。合理的な開発者が「通常」と考える機能をプロジェクトが機能できる場所になりました 私は完全な議論をしたいと思いますが、経営陣は重大な問題があるまで私を聞くことに時間と関心を本当に持っていません。単にそれが私にとって常に第二の性質であるように思えたので、私は単に利点を実際に明確にすることはできません。開発経験のないマネージャーがこのアイデアをサポートできるようにする環境を分離するための良い、シンプルで反論できない理由があるのだろうかと思っていましたか？。トピックに関する優れたリソース/文学はありますか？

71 culture  development-environment 

ある時点で、楽しみのためにコーディングをやめました。以前は仕事に行って仕事を終え、家に着いたら、楽しみのために横に物を書きました。しかし、今は家に帰って、コンピューターを避けようとしています。紙を読んだり、テレビを見たり、バーに行ったりしたいです。 これは悪い兆候ですか？私はまだ最新のトレンドを追いかけ、開発者フォーラム/ブログ/などにアクセスしようとしていますが、「言語Xを学びたい-それにアプリYを書くことができるかどうか」と言っていません これは他の誰かに起こりましたか？

71 coding 

C / C ++ページの多くの質問と回答、具体的または間接的にマイクロパフォーマンスの問題（間接関数と直接関数とインライン関数のオーバーヘッドなど）、またはO（N 2）vs O（N log N）アルゴリズムの使用100アイテムのリスト。 私は、問題がない限り、または問題があることがわかるまで、常にマイクロパフォーマンスを気にせず、マクロパフォーマンスにほとんど気を配らずに、コーディングしやすく、信頼性の高いコードを維持します。 私の質問は、なぜ多くのプログラマーがそんなに気にするのかということです。それはほとんどの開発者にとって本当に問題なのでしょうか、それについてあまり心配する必要がないほど幸運だったのでしょうか、それとも私は悪いプログラマーですか？

71 c++  c  optimization  code-organization 

コードレビューを実行する理想的な方法を見つけたことがありませんが、多くの場合、顧客はそれらを必要とします。各顧客は異なる方法でそれらを行うようであり、私はそれらのいずれにも満足感を感じたことはありません。 コードレビューを行うための最も効果的な方法は何ですか？ 例えば： 1人が品質の門番と見なされ、コードをレビューしていますか、それともチームが標準を所有していますか？ プロジェクターを使用してチームの練習としてコードをレビューしますか？ 直接、メール、またはツールを使用して行われますか？ コードの品質を確保するために、ペアプログラミングや集合的なコード所有権などのレビューを避けて使用していますか？

71 code-quality  code-reviews 

私はソリッドが好きで、開発中にそれを使用して適用するように最善を尽くします。しかし、SOLIDアプローチがコードを「フレームワーク」コードに変えるように感じざるを得ません。つまり、他の開発者が使用するフレームワークまたはライブラリを作成する場合に設計するコードです。 私は通常、2つのプログラミングモードを練習しました-要件とKISS（通常のプログラミング）で要求される内容を多かれ少なかれ作成するか、他の開発者が必要とする柔軟性を提供する非常に一般的で再利用可能なロジック、サービスなどを作成します（フレームワークプログラミング） 。 もしユーザーが本当にアプリケーションにxとyのことをしたいだけなら、SOLIDに従って抽象化のエントリーポイントの全体を追加するのは理にかなっています。と？これらの抽象化のエントリポイントを追加する場合、ユーザーの要件を本当に満たしていますか、それとも既存のフレームワークと技術スタックの上にフレームワークを作成して将来の追加を容易にしますか？どちらの場合、顧客または開発者の利益に貢献していますか？ これはJava Enterpriseの世界では一般的なことのように思われますが、ユーザーのUXに焦点を当てるのではなく、開発者にとってより良いUXになるようにJ2EEまたはSpringの上に独自のフレームワークを設計しているように感じますか？

70 frameworks  solid