速くて汚いプログラマーは、どうやってそれが正しいことを知るのでしょうか？

プログラマーにきれいなコードを書くべき理由を尋ねると、一番の答えは保守性です。それは私のリストに載っていますが、私の主な理由はより直接的で利他的ではありません：新しいコードが汚れていると正しいかどうかわかりません。個々の関数とコードの行に重点を置いているので、最初のドラフトを終えて戻って全体像を見ると、ときどききれいに合わないことがあります。クリーンさのために1〜2時間のリファクタリングを行うと、ラフドラフトでは検出が非常に困難であったコピー/貼り付けエラーまたは境界条件が明らかになることがよくあります。

ただし、一部の人々は、「後でそれをクリーンアップする」計画で、ソフトウェアを出荷するために意図的にダーティコードをチェックインしてもよいと時折感じています。可読性が理想よりも低い場合に、コードの正確性に自信を与える実用的な手法はありますか？開発しようとする価値はありますか？または、コードに対する自信の欠如は、一部の人々が受け入れやすいと感じるものですか？

コードはおそらく正しくありません。

ただし、それは重要ではありません。

次のような状況では、迅速で汚れが適切な方法です。

• コードの寿命は短いです。たとえば、アドホックプログラムを使用して、大量のデータを標準形式に変換しています。
• 失敗の悪影響はわずかです：
  • 変換するデータは重要ではなく、データのエラーは簡単に修正できます
  • エンドユーザーは共感的なプログラマであり、エラーメッセージについて推論し、入力をマッサージするなどして回避します。

コードが堅牢であり、考えられるすべての入力を処理することは重要でない場合があります。手持ちの既知のデータを処理するだけでよい場合もあります。

その状況で、ユニットテストがコードの記述を高速化するのに役立つ場合（これは私にとってはそうです）、それを使用します。それ以外の場合は、コードをすばやく汚して、仕事を終わらせてください。トリガーされないバグは問題ではありません。修正するバグや、その場で回避するバグは問題ではありません。

絶対に重要なのは、これらの状況を誤診しないことです。コードが1度しか使用されないために手早く汚いコードを作成する場合、誰かがより良いコードに値するプロジェクトでコードを再利用することに決め、そのコードはより注意を払うに値します。

彼らはしません。現在、「後でクリーンアップする」「素早い汚い」プログラマーによって作成されたコードベースに取り組んでいます。それらはもうなくなっており、コードは存続し、忘却の方向に向かってきしむ。 カウボーイコーダーは、一般に、ソフトウェアが持つ可能性のある潜在的な障害モードのすべてを理解していないだけでなく、会社（およびクライアント）にさらされているリスクを理解していません。

さて、完全な投票権を失うリスクがあるので、反対意見を「悪魔が擁護する」つもりです。

私たちの開発者は、適切な実践やコードの清潔さなどについて過度に心配する傾向があると提案します。これらのことは重要ですが、出荷しない場合は重要ではないことをお勧めします。

しばらくこのビジネスに携わった人なら、多かれ少なかれ無期限にソフトウェアをいじることができるだろうということにおそらく同意するでしょう。デュークヌケムフォーエバー、私の友達。その便利な機能や、非常に緊急のリファクタリング作業を脇に置き、DONEと呼ばれるべき時が来ます。

私はこれについて何度も同僚と戦ってきました。常にもう1つの微調整があり、それが「正しく」行われるために「すべき」なことです。あなたは常にそれを見つけることができます。ある時点で、現実の世界では、十分に良いだけで十分でなければなりません。現実の、実際の、出荷ソフトウェアは完璧ではありません。無し。せいぜい、それで十分です。

そのようなプログラマーは、自分が正しいことを知ることはほとんどなく、そう信じているだけです。そして、違いは容易に理解できないかもしれません。

ユニットテストについて学ぶ前に、どのようにプログラミングをしていたかを覚えています。ユニットテストの最初のまともなスイートを実行した後、まったく異なるレベルの自信と信頼感を覚えています。私のコードにこのようなレベルの信頼性が存在することは知らなかった。

この経験がない人にとって、違いを説明することは不可能です。そのため、彼らは生涯を通じてコードアンドプレイモードで開発を続け、状況を考慮して最善を尽くしていると慈悲深く（そして無知に）信じているかもしれません。

そうは言っても、本当に問題のある空間全体を完全なフロー状態で保持することができた場合、優れたプログラマーと例外的なケースが存在する可能性があります。私はこのようなまれな瞬間を経験しました。何を書くべきかを完全に知っていたとき、コードは簡単に飛び出して、すべての特別なケースと境界条件を予測でき、結果のコードはうまくいきました。私はプログラミングの天才がいることを疑う余地はありません。彼らは長期間またはほとんどの時間さえそのようなフローの状態に留まることができ、彼らが作り出すものは努力のないように見える美しいコードです。そのような人は、すでに知っていることを確認するために、小さなユニットテストを書く必要はないと感じるかもしれません。そして、あなたが本当にそのような天才であれば、それは大丈夫かもしれません（それでも、あなたはそのプロジェクトを永遠に回避することはないでしょう、そしてあなたは後継者について考えるべきです...）。しかし、そうでなければ...

それに直面してみましょう、あなたはそうではない可能性があります。私は、自分自身ではないことを知っています。流れのまれな瞬間がいくつかありました。そして、無数の悲しみと悲しみがありました。これは通常、私自身の間違いが原因でした。正直で現実的であるべきです。実際、最高のプログラマーは自分の誤りや過去の間違いを完全に認識していると思うので、安全な側に自分自身を保つために、前提を二重にチェックし、小さな単体テストを書く習慣を意識的に開発しました。（「私は優れたプログラマーではありません。優れた習慣を持つ優れたプログラマーです。」 -ケント・ベック。）

単体テスト。あらゆるコードに信頼を寄せる唯一の方法です（汚れているかどうか）。

サイドノートで。

ショートカットは長い遅延をもたらします（Pippin）

単体テストとコード調整がどれだけ行われても、合理的な複雑さのソフトウェアシステムは完璧ではないことを受け入れることを学ぶのは良いことです。ある程度の混乱と予想外の脆弱性は、常にコード内に潜んでいます。これは、優れたコードの生成や単体テストの実施を試みてはならないという意味ではありません。これらはもちろん重要です。求めなければならないバランスがあり、これはプロジェクトごとに異なります。

開発するスキルは、特定のプロジェクトで使用する必要がある「完成度」のレベルを理解することです。たとえば、12か月のプロジェクトタイムラインを使用して電子カルテアプリケーションを作成している場合、1回限りの会議登録Webアプリの場合よりも、コードのテストと保守に十分な時間を費やす必要があります。金曜日までに展開する必要があります。プログラマーがコードの調整に忙しすぎて、EMRアプリを実行している人がだらしないか、登録アプリが時間内に展開されない場合に問題が発生します。

サブシステム内では、高速でダーティな処理は問題ありません。がらくたとシステムの他の部分との間に明確に定義されたインターフェイスがあり、andくて汚いコードが正しいことを実行することを確認する単体テストのセットがあれば、それは完全に問題ないかもしれません。

たとえば、サードパーティからのファイルを解析するために、正規表現とバイトオフセットの恐ろしいハックがあるかもしれません。また、サンプルファイルの解析から得られる結果が期待どおりであることを示すテストがあるとします。これをクリーンアップして、次のことができます...サードパーティがファイル形式を変更したときに、より迅速に対応できますか？それだけでは十分ではありません。より完全に新しいAPIに変更される可能性が高く、古いパーサーを破棄して、同じAPIに準拠する新しいパーサーをプラグインすると、できあがりです。

迅速で汚れが問題になるのは、アーキテクチャが迅速で汚れている場合です。コアドメインオブジェクトとインターフェイスを十分に検討する必要がありますが、通常、パイパーにお金を払わなくても、システムのエッジは乱雑になります。

これは、私が知っている手早くて汚いプログラマーの話です。

ユニットテストを時間の無駄だと考える人を知っています。多くの議論の後、彼は最終的に1つを書いた。&&と||を振りかけた1つの長いメソッドで構成されていました。そしてassertTrueにブール値を返しました。ステートメントは20行にまたがっています。その後、再び、彼はすべてのメソッドが1行で、メインメソッドが1000行を空白なしで含むクラスを書きました。それはテキストの壁でした。私が彼のコードをレビューし、いくつかの新しい行を挿入したとき、彼は「なぜ」と尋ねました。「読みやすさのため」と言いました。彼はため息をつき、それらを削除しました。彼は一番上にコメントを付けた。「触らないで、うまくいく！」

前回彼と話したとき、彼は会社のウェブサイトをコーディングしました。彼はバグを見つけようとしていました。彼は最後の3日間を1日8時間過ごしました。少し後に私は再び彼と話をしましたが、彼のチームメイトはリテラルの価値を変え、他の場所では更新しませんでした。それは定数ではありませんでした。そこで、彼は他のリテラルも変更して、バグを修正しました。彼はチームメイトのスパゲッティコードについて不平を言いました。彼は「ハハ、デバッガで一晩中起きて、1つの厄介なバグで眠れないということを私たち全員が知っているのではないか」と言いました。

また、彼はプログラミングの本やブログを読むことは無意味だと考えています。彼は、「プログラミングを始めてください」と言います。彼はそれを12年間やっており、彼は優れたプログラマーだと思っています。/ facepalm

ここにもう少しあります。

WebアプリのDatabaseManagerクラスを作成していたとき。彼はすべてのデータベース呼び出しをそれに入れました。それは、考えられるすべてのものに対して50を超えるメソッドを持つ神のクラスでした。すべてのコントローラーがすべてのデータベースメソッドを知る必要があるわけではないため、サブクラスに分割することをお勧めします。彼は同意しませんでした。データベース全体に1つのクラスを用意するのは「簡単」で、必要なときに新しいメソッドを追加するのは「高速」だったからです。最終的に、DatabaseManagerには、ユーザーの認証から考古学的なサイトの場所のソートまで、100を超えるパブリックメソッドがありました。

迅速で汚いことを避けるための私の教訓は、1年分の作業と見積もられた（過小評価された）ものを提供するのに6か月を費やしたときでした。仕事を始める前に方法論を研究することにしました。結局、3か月の研究に投資し、残りの3か月で成果を上げることができました。

共通の機能を特定し、それらの要件を処理するために必要なライブラリを構築することにより、大きな利益を得ました。使用可能なライブラリルーチンがある場合でも、コーダーが独自のコードを記述しているのを見ます。これらのコーダーは、後で同じ問題を解決する必要があるときに、同じコードを書き換えたり、せいぜいカットアンドペーストしたりすることがよくあります。バグ修正では、常にコードコピーの一部のみをキャッチします。

ある開発者は、ライブラリコードを使用するように頼んだときに、「ごまかしていないのですか。学校で自分のコードをすべて書かなければなりませんでした」と言った。

場合によっては、「すべての」バグを見つけて動作を検証する回帰テストの大規模なスイートがあり、それにより迅速で汚れたコーディング手法が可能になると思います。しかし、ほとんどの場合、それは悪いプロジェクト計画の問題であり、それを正しく実行するよりも、それを実行することがより重要だと考えるマネージャーです。

そして、「後でそれをきれいにする」ことを忘れてください、それは決して起こりません。まれに、プログラマーがほとんどのコードを忘れてしまい、最初に正しく行った場合よりも多くのコストがかかることになります。

製品が出荷されます。

コードはバキュームには存在しません。私は、迅速で汚れたカウボーイコーディングの結果を語り尽くせない悲しみに苦しんでいます。しかし、製品を完成させることが優先される場合があり、最適なコードの書き方を考え出すことはできません。最終的に、製品が出荷されて十分に機能する場合、ユーザーと顧客は内部のコードがどれほど「悪い」かを知りませんし、気にしません。私はそれをドアから出した限り。

はい、これは組織的な問題であり、「決して起こらないはずです」。しかし、管理が不十分で期限が非常に長い組織でコードを記述している場合、個々のプログラマーレベルでの選択肢は限られています。

保守が容易でない場合、彼らは正直に言って正しいとは言えないと思います。彼らが「後でそれを片付けなければならない」と認めるなら、おそらく十分に考えていない何かがあるでしょう。徹底的にテストしても、汚れたコードの問題が本当に明らかになるだけです。

私は個人的に「ダーティコードを書く」スキルとその正確さについて自信をつけることを目指していません。初めて適切なコードを書きたいと思います。

彼らはそれが正しいことをどのように知っていますか？テストは簡単な答えです。

彼らのコードが優れたQAチームによって徹底的にテストされ、合格した場合、私は彼らが正しいと言ったでしょう。

迅速でダーティなコードを書くことは習慣として行うべきものではありませんが、同時に、ダーティと分類される可能性のあるコードの作成に20分を費やしたり、正しく実行するために多くのコードを4時間リファクタリングすることができます。ビジネスの世界では、仕事をするのに20分で十分な場合があります。締め切りに直面したときは、迅速かつ汚いことが唯一の選択肢かもしれません。

私はこれの両端にいましたが、汚いコードを修正し、開発中のシステムの制限を回避するために独自のコードを書かなければなりませんでした。私はコードに自信を持っていたと思いますなぜなら、それは汚れていて、時にはハッキングのようなものでしたが、徹底的にテストされ、多くのエラー処理が組み込まれていることを確認したので、何かがうまくいかなくてもシステムの残りを破壊することはありませんでした。

これらの迅速で汚いプログラマーを見下ろすとき、私たちは一つのことを覚えておく必要があります、顧客は一般に製品を出荷するまで支払いません。ほぼ機能する製品を目の前に置いたときに引き出される可能性は非常に低くなりますが、もし彼らが何も持っておらず、「xを修正するだけですぐに手に入れる」または「 「完璧に機能している」彼らはあきらめ、競合他社と行く可能性が高くなります。

もちろん、この画像が示すように、誰も迅速で汚いコードの危険性を過小評価すべきではありません！

私はあなたがその道を進んで行くべきではないと思います。速くて汚れていると、より速く仕上げるという一時的な利点が得られますが、最終的にこれを行うには常に10倍の費用がかかります。

私の意見では、Q＆Dコードが正しいかどうかを判断することを学ぶことは、単に悪い習慣であるため、開発する価値のあるスキルではありません。その理由は次のとおりです。

「迅速で汚い」と「ベストプラクティス」が一緒になるとは思いません。多くのコーダー（私自身も含まれています）は、トリプル制約のゆがみの結果として、素早く汚いコードを作成しました。私がそれをしなければならなかったとき、それは通常、絶え間なく迫る締め切りと組み合わされたスコープクリープの結果でした。私がチェックインしているコードが吸い込まれていたことは知っていましたが、入力のセットが与えられると適切な出力を吐き出しました。利害関係者にとって非常に重要なことは、時間通りに出荷したことです。

元のCHAOSレポートを見ると、Q＆Dが良いアイデアではなく、後で（メンテナンス中または拡張中に）予算が枯渇することが明らかになります。Q＆Dコードが正しいかどうかを判断する方法を学ぶことは時間の無駄です。ピーター・ドラッカーが言ったように、「効​​率的に行うほど役に立たないものは何もありません。」

新しいコードが汚れていると正しいかどうかはわかりません。

「汚れた」とは、人によって異なることを意味します。私にとって、それは主にあなたがたぶんあなたがたぶん頼るべきではないことを知っているが、あなたは近い将来働くことを期待できることも知っているものに頼ることを意味します。例：高さを計算する代わりに、ボタンの高さが20ピクセルであると仮定します。名前を解決する代わりにIPアドレスをハードコーディングする。配列を提供するメソッドはそれを保証していませんが、配列を知っているので、配列を頼りにしてソートされます。

汚れたコードは脆弱です-テストして、現在動作していることを知ることができますが、将来のある時点で壊れることはかなり良い賭けです（または、それを壊すことを恐れて全員を卵殻の上に歩かせる）。

少し物議聞こえるのリスクで、私は誰もが本当にあると主張したい知っている彼らのコードが100％正しいとエラーなしの100％であること。テストカバレッジが非常に良好で、優れたBDD / TDDプラクティスを厳密に適用している場合でも、エラーを含むコードを開発できます。

コードを書いてそれが機能すると仮定することは、その開発者自身の能力に関する開発者の感覚に対する自信過剰を意味し、問題が発生した場合（必然的に）、コードをデバッグして維持するための努力は、特に他の開発者が必要とする場合、費用がかかります後でコードを維持します。本当の違いは、適切なソフトウェアエンジニアリングの実践を適用することで実現されます。これにより、コードがほとんどの時間で動作する可能性が高いことを確信できます。後でそのコードを操作する人に関係なく、変更と保守にかかる費用が大幅に削減されます。

顕著な点は、十分にファクタリングされ、十分にテストされたコードにより、OTHERSがコードに自信を持つことができることです。これはほとんどの場合、自分の自信よりも重要です。

ダーティコードが十分にテストされていれば、信頼できます。問題は、ダーティコードの単体テストは通常​​非常に難しく、扱いにくいことです。これが、TDDが非常に優れている理由です。汚れや臭いを明らかにして取り除きます。また、ユニットテストは多くの場合、時間の予測に苦しむ最初のものです。したがって、最もクリーンな人が今までで最もクリーンなコードを作成したとしても、時間の保証のためにユニットテストを省略したとしても、私はそれを少しも信用しません。

優れたプログラマー（Quick＆Dirtyなど）には、自分が正しいと思っているhub慢がありません。彼らはすべての大規模システムにバグと欠陥があると仮定していますが、ある時点で十分にテストおよびレビューされて、コードが出荷できる十分に低いリスクまたは十分な低コストを実現できると考えています。

では、なぜこれらの、いわゆるQuick＆Dirty、プログラマーが存在するのでしょうか？私の仮説はダーウィン選択です。実行可能なコードを高速で出荷するプログラマーは、競合他社が出荷する前に出荷する場合があります。予算が尽きるか、会社が破産します。そのため、彼らの会社は、クリーンアップする必要がある混乱について不平を言うために、新しいプログラマーを雇用している。いわゆるクリーンコードも出荷されますが、Quick＆Dirtyのコーダーを絶滅させるのに十分な差はありません。

おそらく、ライフタイムが短い、ビジネスへの影響が小さい、またはコードを実行する時間が少ないため、コードの最適でない部分が違いを生むことはないと考えるかもしれません。正解は、あなたは本当に知らないということです。「これは小さな機能です」または「できるだけ早く簡単にしましょう」と誰かに聞いて、適切なデザインについて考えるのに十分な時間を費やさない。次のとおりです。

1-）プロジェクトは大きくなり、チームのモチベーションは低くなり、「ステッチ」でいっぱいのコードに取り組んでいます。その場合、プロジェクトはカオスに向かう高速レーンになる可能性があります。

2-）プロジェクトは非最適なソリューションであることが知られるようになり、新しいソリューションまたは新しいソリューションと同じくらい高価なリファクタリングを支持して、その使用は推奨されなくなります。

可能な限り最高のコードを常に実行するようにしてください。時間が足りない場合は、もっと必要な理由を説明してください。粗末な仕事で自分を危険にさらさないでください。常により良い専門家になりましょう。あなたが合理的であれば、誰もあなたにこれを罰することはできません。もしそうなら、それはあなたが働くことを気にするべき場所ではありません。

上級者と話し合い、失敗した場合の影響を評価します。たとえば、ダーティを修正できる状況には1日かかり、堅牢なコードには設計とアーキテクチャの変更が必要であり、4〜6か月かかる場合があります。

リスト内の時間+容量+優先度にも基づいて決定する必要があります。チームで先輩や経験のある人たちと話し合うことは、チームとその成果物に最適な決定を下すのに役立ちます。

クリーンコードは、エスカレーションを保存するダーティコードとして、クライアントのゴー/ノーゴーの決定、ストッパー、危機にorganizationしている組織の評判など、ダーティコードがクリーンコードに到達する多くの場所で最も重要なアプローチです。