職に就く前に、潜在的な雇用主のコードの品質をどのように確認しますか？[閉まっている]

会社で働き始める前の私の経験では、コードベースを見る機会がありません（私は尋ねましたが、機密性の理由から、誰もが常にノーと言っていました、それは公平だと思います）。コードがどのような状態にあるかを知るために尋ねる最も重要な質問だと思いますか（結局、犬なら、毎日歩かなければならない貧しい不幸な人たちになるでしょう）？

更新：

チェックリスト：尋ねる。

• 彼らがコードベースについてどう思うか。そして、あなたがそうするとき、表情とそれらが反応するのにかかる時間に細心の注意を払ってください。[アノン]
• 会社のCMMレベル[DPD]とは何ですか（レベル5が逆に聞こえるとしたら[Doug T]）
• 彼らが使用するライフサイクル[DPD]（「アジャイル」と聞いた場合、鋭い質問をして「アジャイル」とは「アジャイル」または「カウボーイコーディング」を意味するかどうかを判断しようとします[Carson63000]）
• コード品質を評価するためにどのツールを使用していますか？[DPD]
• 開発に使用するツールは何ですか？[DPD]（リファクタリングツールと継続的なビルドサーバーを探します）
• どのソースコード（バージョン管理）システムを使用しているのか、そしてフォローアップとして、なぜ使用するのかを尋ねることです。[ザカリーK]。
• テスト手順はどのようなものですか？[Karl Bielefeldt]（特にモックフレームワークを使用し、NUnit / JUnitのような確立されたフレームワークを通じて徹底的な自動化されたユニットテストに重点を置くチームを探します。テストが堅実なソフトウェア開発に不可欠であると考えていない場合は注意してください。専用のテスターを持つチームを探してください。
• 新しい開発者にはどのような割り当てが与えられますか？経験豊富な開発者ですか？[カールビーレフェルト]
• プロジェクトで何人が働いていますか？[カールビーレフェルト]
• リファクタリングは許可されていますか？励まされますか？[カールビーレフェルト]
• どのような品質関連のプロセスまたはアーキテクチャの変更が検討中ですか、または最近行われましたか？[カールビーレフェルト]
• 個人はモジュールに対してどの程度の自律性を持っていますか？[カールビーレフェルト]
• 新しいプロジェクト（グリーンフィールド開発）またはレガシープロジェクト（ブラウンフィールド開発）を開発しますか？（グリーンフィールドの開発は一般的にもっと楽しく、他の誰かのミスで片付けないので問題が少ないです）。
• 組織またはチームの従業員の離職率は高いですか？（多くの場合、これはコードの品質が低いことを示しています）[M.Sameer]
• 独自のプログラミングの問題。しかし、ジャークのように見えることは避けてください。[キラキラ]
• 開発者はどのように協力し、チーム間で知識をどのように共有しますか？（これはあなたの性格と一致するはずです;ソロとペアの作品の混合はおそらくあなたの社会的ニーズに一致する比率で最高でしょう）
• それらのデータベースは、第3正規形（3NF）にどれだけ近いか、そしてそれがどこで、なぜそれから逸脱するか？（彼らが「3NF ???」と言ったら、去る。そうでないなら、そうでない理由が十分あるかもしれないのなら、彼らが何であるかを見つけなさい）。

注： 約1週間後、コミュニティはそれが最良のものであると考えるため、Anonの回答を受け入れました。しかし、私は誰もが言いたいことがあると思います。

コードを確認するのではなく、コードベースについてどう思うかを尋ねます。そして、あなたがそうするとき、表情と彼らが反応するのにかかる時間に細心の注意を払ってください。

次に、文化の非言語的ジェスチャーに関する知識を適用して、実際に言っていることを解釈します。北米の企業の場合、以下は正確でなければなりません。

• 小さな肩をすくめ、そして「それはもっと良いかもしれない」という素早い応答：それはおそらくかなり良いです。
• 長い一時停止、息の吸い込み、おそらく小さな笑い：それは気分が悪く、面接している人はそれを話すのが気分がよくありません。
• 目を転がし、「それはひどい」という素早い反応：良いかもしれないし、悪いかもしれないが、政治的なゲームが起こっている。そのゲームをプレイする準備ができているか、静かな誰にもならない限り、近づかないでください。
• 眉を上げたり縮めたり：彼らは質問を理解せず、コードベースはほぼ間違いなく腐敗しています。

もちろん、対人コミュニケーションに問題がある場合、これはうまくいかないかもしれません。

私もあなたが尋ねたことに驚いています。参加する前に、どの会社もあなたにコードを見せることはありません。機密保持契約に署名していない限り、プロセスのために呼び出されたコンサルタントでさえもです。

確認するためにあなたが頼むことができるものはここにある。

• 会社のCMMレベルは何ですか（理想的には5）
• あなたの将来のプロジェクトで従われるプロセスは何ですか（ところで、これはあなたが「どんな」仕事だけでなく「この」仕事に興味があることを示しているので、これは良いことだと尋ねます）
• ライフサイクルはどのように使用されますか（「アジャイル」が聞こえない場合は判断しないでください。古い学校のモデルを使用する正当な理由があるかもしれません）
• コードの品質を確認するためにツールやメトリックを使用しているかどうかを尋ねます。そして、もしそうならどちらか（彼らがメトリックのために少なくとも1つのツールを使用し、品質のために別のツールを使用する場合、それは良い兆候です。）
• また、使用するツールにも注意してください。フリーウェアツールの代わりにResharperなどの高価なツールである場合、品質に関しては非常に深刻です。

1. ソース管理を使用しているかどうかを尋ねます。
   • ソース管理なし？->最も可能性の高いコード
2. コードレビューを行う頻度を尋ねます。
   • コードレビューなし？->コードは疑わしいかもしれません（ただし、必ずしもそうではありません。特に、まともな開発者で構成された小さなチームの場合）。
3. 実稼働に入る前に、どのようにテストおよびデプロイするかを尋ねます
   • テスト環境はありませんか？本番環境に直接展開しますか？->おそらくくだらないコード。
4. 継続的な統合を行っているかどうかを尋ねます（つまり、Hudsonでビルドを実行します）
   • 継続的な統合はありませんか？->コードは疑わしいかもしれませんが、必ずしもそうではありません。
5. （＃3に関連）、テスト環境が開発環境から分離されているかどうかを尋ねますか？
   • テストは開発者ですか？->良い兆候ではなく、本当に現金で縛られていない限りではありませんが、余分な箱はどれくらい高価ですか？
6. 実稼働環境に展開する前に、アクションリストを確認するかどうかを尋ねます。
   • 運用展開前にアクションのレビューはありませんか？->悪いジュジュ。
7. ビルドを実行するために必要なステップ数を尋ねます。
   • 3つ以上？->通常、悪いジュジュ。
8. 循環的複雑度やLCOM（クラス結合の尺度）などのコードメトリックを使用しますか（推測するか）。
   • はい？->おそらく（しかし確かではないが）コード品質に関する良い兆候。
   • いいえ、しかし、彼らは概念（少なくとも循環的複雑性）を理解していますか？->言いにくい
   • 彼らは、サイクロマティックな複雑さは、ティンブクトゥのエキゾチックな料理または媚薬であると考えています（言い換えれば、それが何であるかを知りません）？->悪いジュジュの可能性。
   • 彼らはそれが無関係のたわごと（または他の種類の態度）だと思いますか？->逃げます。
9. バグを追跡する方法を彼らに尋ねます。
   • 彼らはいくつかのメトリックに対するバグの数を追跡します（つまり、プロジェクトごと、変更されたモジュールの数、要件/変更要求の数など）？->コード（およびソフトウェアプロセス）についての良い兆候。
   • 彼らは、上記のいずれかの操作を実行し、予想されるメトリック（変更要求の＃、プロジェクトの規模、など）に基づいて、彼らが将来的に遭遇する可能性のあるバグ（または進行中の）プロジェクトの数を予測しようか？-> 非常に良い兆候。
   • バグを解決するためだけにバグを追跡しますか？->わかりにくい
   • 一貫した追跡がありませんか？->逃げます。

それは私の頭の上からだろう。私の質問のいくつかは、厳密にコーディングだけでなく、ソフトウェア開発プロセスに関係していることに気付くでしょう。後者の品質は、前者の品質の直接的な機能です。

そうは言っても、これらの質問をするときは注意して進めてください。それらを研究し、面接時にいくつかを選択します。

留意すべき点がいくつかあります。優れた開発チームは、インタビューを受けた人がこれらの質問を聞くのを喜んでいます...彼らがタクトで尋ねられるならば。それを間違えると、面接官に慢と完璧主義の印象を与えます。開発チームがどれほど優れていても、完璧なグループは存在せず、全員が解決すべき問題や品質の低下などを抱えています。彼らは、破壊的な完璧主義者ではなく、品質を好むチームプレイヤーを求めています。ので注意してください。

また、外部環境によって同等以下の品質のコードで作業しなければならない優秀な人々のチームがある場合があります（彼らはジュニア開発者であるか、限られた範囲で作業しなければならないがらくたの山を単純に継承します）品質を向上させるためのリソース。）あなたの周りの人も（個人的にも職業的にも）善良な人であれば、くだらないコードを使って仕事をすることができます。質問するときに間違った印象を与えると、彼らはあなたを完全に雇うことを避けるかもしれません（非常に困難で困難な状況で良い人と働く機会を奪います）。

• ところで、私はソフトウェア開発者が何らかのタイプの希望を超えた（または希望を超えた）コードで少なくとも一度は働いたことは絶対に必要だと思います。あなたはそれを生き残り、良い仕事をします。それは貴重な教訓です。

また、くだらない人々とのくだらない開発グループに出会うかもしれません。明らかに、彼らのコードはくだらないものになり、これらの質問のいずれかでだまされます。彼らはあなたにハードボールの質問をすることを軽deするかもしれません（したがってあなたに好意を持っているかもしれません）、または彼らはあなたを必要とするのであなたを雇います（たとえ彼らがあなたと一緒に働くことができない/できなくても）。

それが起こるとき、あなたはあなたがこの仕事がそんなに悪いのを必要とするかどうか自問する必要があります。時々あなたはそうします、そして、あなたはスパゲッティたわごとの山に突っ込む必要があります。しない場合もあります（つまり、そうしない余裕があるということです）。

これらは、インタビュアーにコードとソフトウェアプロセスの品質について質問することを選択した場合/選択した場合に考慮する必要があるものです。

実際のコード品質の代わりに、コード品質の重要性が十分に理解されている会社を探したいと思います。

たとえば、会社Aが「計画は無駄な時間」であり、「設計の問題を後で修正できる（たとえば、地獄が凍結した場合。時間がある）」と考えているマネージャーがいるとします。その会社がたまたま良いコードベースを持っていたとしても、彼らはそれを長い間持たないでしょう。そして、あなたはそれを悪化させる（強制する）人になります。

一方、B社のコードベースは悪いが、経営陣はコード品質がすべてのバグと遅延を引き起こしていることを理解しており、変更の必要性を認識しており、それに対して何らかの措置を講じる意思があるとしていますリファクタリングまたは書き換えさえも）。その会社はコードベースを改善し、あなたは彼らがそれを実現するのを助けることができます。

どこで働きたいかを知っています。

開始する前にコードが表示されない可能性は99.9％です。（もちろん、彼らがフリーソフトウェア製品を出さない限り）

だからあなたは何ができますか、私はプロセスについて尋ねます、一般的に良いプロセスは良いコードを生成します。Joelテストから始めて、開発方法について尋ねます。また、基本を超えてください。たとえば、私は常にどのソースコードシステムを使用しているかを尋ねるので、フォローアップとしては、なぜそれを使用するのかを尋ねることです。

私が非常に高品質のコードで作業した場所では、基本的に開発者の3分の2がコードに触れることができませんでした。他の人は、代わりに自動化されたブラックボックステストスクリプトを作成しました。実際のコードを変更する価値があると証明した場合、要件は非常に過剰に指定されているため、基本的にソースコードへの転写にすぎません。テストスクリプトは実際には書くのがもっと面白かったです。

私が最低品質のコードを見た場所はまったく逆でした。通常、それは会社の製品に直接関連していないか、実験的であると見なされたツールであったため、比較的訓練されていないかメンターのないプログラマーだけがコードに触れました。

最も快適な職場はバランスが取れています。新しい開発者には実際の課題が与えられますが、指導されます。間違いを発見するための優れたQA部門とピアレビュープロセスがあります。あなたは間違いを犯したことで罰せられることはありませんが、間違いを修正してそこから学ぶことが期待されています。時折、ひどく書かれたモジュールがひび割れに陥りますが、それらに遭遇したときにコード品質を改善するのに時間を費やすことについては批判されません。会社は全体として、コードを改善するための新しい方法を見つけるために絶えず努力しています。

したがって、コードの品質を評価するために私が尋ねる質問は次のとおりです。

• テスト手順はどのようなものですか？
• 新しい開発者にはどのような割り当てが与えられますか？経験豊富な開発者ですか？
• プロジェクトで何人が働いていますか？
• リファクタリングは許可されていますか？励まされますか？
• どのような品質関連のプロセスまたはアーキテクチャの変更が検討中ですか、または最近行われましたか？
• 個人はモジュールに対してどの程度の自律性を持っていますか？

@DPDと@Zacharyが言ったように、プロセスとSDLCは非常に重要な要素ですが、私の経験によればコード品質に大きな影響を与える他の要素をいくつか追加したいと思います。

• 比較的新しいプロジェクトで開発に取り組むのか、それともレガシーアプリケーションを維持するのかを尋ねます。レガシーアプリケーションは、新しいプロジェクトよりもクリーン度が低い傾向があります。
• 組織またはチームで従業員の離職率が高いかどうかを確認してください。これにより、コードの品質も低下する可能性が最も高くなります。

プロセスは大いに役立ちますが、上記の要因に対する完全な免除は得られないことに注意してください。多くの開発者がプロ​​ジェクトを引き継ぐとき、それぞれが異なる考え方を持っています。アーキテクトと開発者は、前任者が行った正確な方法に従わないため、矛盾が生じます。

私の態度はこれです、コードはコードです、それが悪いなら、それを改善するのは難しいことです。それが良い場合、それを改善することはさらに難しい課題です！

私にとって最も重要なのは、会社とやり取りする機会のある人のために働きたいかどうかです。コードは変更できますが、人々は変更できません...

少し冗談を言って、私にインタビューします。

私は通常、インタビューテストとしてコードベースの実際のバグ（既に修正済み）を使用しているため、実際のコードが表示されます。一般的に少し複雑なコードで、バグがあります。

バグが本物であり、問​​題が本物であり、発見して修正するのにかかった時間を知っているので、このテクニックを使用することをお勧めします。

素晴らしいことは、かなり難しい問題を抱えることができるということです。

私は、非常に難しい問題を最後のインタビューの質問として使用して、専門家とかなり良い人を区別しました。

OPの質問との関連性は、物理的なインタビューに参加したすべての人がコードを見ることができるということです。（会社の機密コンテンツを含むものではありません）

たとえば、コードベースの冒fanのためにこの手法を使用できなかった場合、テストは機能します。見込みの従業員が「コードを表示できますか」と尋ねると、返信は「ああ、できません」冒とくに満ちた」。

もちろん、標準的な「それはすべて会社の秘密です」という答えは、完全な馬肉バターです。
私の証明：私の以前の雇用主では、軍事製品の非機密部分がインタビューの質問のコードサンプルでした。[幸運にも未分類]

分類されたデザインの品質を決定する問題は、そこで働く前に私よりも賢い人に任せます。私は、機密扱いが監視の自由と同義であることは一般的かもしれません。

彼らがあなたに彼らのコードを見せるのは疑わしいが、あなたに彼らにプログラミングの宿題を与えた場合、それがどんなものであるかを知ることができるかもしれない。多くの場所で、インタビュー対象者に、あなたを評価するために使用できる持ち帰りのプログラミングの課題を与えています。好意を返します。自分が何を獲得できるかをより正確に判断できるように、そのうちの1つを期待してください。

コードを本番ビルドに組み込むために必要なものを尋ねます。「開発者がコミットします...」というメッセージが表示された場合は、ほぼ間違いなくゴミです。

コードの品質を向上させる傾向があるものが多数あります（明らかに、保証はありません）。

• 静的分析（.NETでは、fxcop / stylecopなどです）
• テストスイートのサブセット（またはフルセット）-ユニット/統合/回帰/マニュアルなど
• バディビルド（チームの別の開発者が変更をビルドして、マシン/ユーザーに依存する問題があるかどうかを確認します-場合によっては迅速な健全性も実行します）
• コードレビュー

これらは、コードの強度だけでなく、コードの品質の向上にも役立ちます。

ユニットテストについて質問します。彼らがそれを真剣に受けとめれば、インタビュアーはおそらくその主題についていくつかの明確な意見を持ち、それらを共有して喜んでいるでしょう。答えがあいまいな場合、それは大きな警告サインです。

Javaショップの場合は、使用しているORMライブラリを尋ねます。彼らが自分で転がしたなら、それはどちらの方向にも行くことができます-それは吸う可能性があります、またはそれは大丈夫です。使用していない場合は、すぐにドアに向かって走ります。

非常に多くのさまざまな悪いコーディング慣行があり、それらをすべて予測することはできないため、これは難しい作業です。

残念ながらできません。どの会社もあなたのコードを見ることはありません（しかし、彼らはあなたのコードを見ることを求めます...）、そしてあなたがあなたに彼らにあなたがあからさまに嘘をつく環境について質問するならチャンスです（「バージョン管理？確かに..使用します..ええと.. Sub .. Sub-something」を考えたり、品質について誤解したりします（「私たちは.NET 4を使用している間、彼らが。 .NET 1.1のように書き直してください）。

私は過去に何度もそのことに夢中になりましたが、品質を測る良い方法をまだ見つけていません。通常、最善の方法は、あなた自身の判断を使用することです。そして、それが最終的にそれであるならば、あなたが思ったより悪いならば、すぐに去ってください。あなたは仕事のホッパーになってしまうかもしれませんが、あなたは正気を保ちます。