率直に言って、カウボーイコーディングが好きですか？[閉まっている]

アジャイル、ウォーターフォール、RUPなど、政治的に正しい方法論を擁護するほとんどのプログラマー。それらの一部は方法論に従いますが、すべてではありません。率直に言って、方法論を選択できれば、確かに主流の「正しい」方法論に行くのでしょうか、それともカウボーイプログラミングのような「より簡単な」方法論を好むでしょうか。どうして？

私はそれが依存することを知っています。いつ使用するか説明してください。カウボーイコーディングにはどのような利点がありますか。

ウィキペディアでカウボーイコーディングについて参照してください

経験豊富なプログラマーのほぼ全員が3つの段階を経ており、一部は4つの段階を経ていると思います。

1. カウボーイのコーダーまたはナゲットは、デザインについてほとんど何も知らず、それを不必要な形式とみなします。非技術的な利害関係者のための小規模なプロジェクトに取り組んでいる場合、この態度はしばらく彼らに役立つかもしれません。Gets Things Done、上司に感銘を与え、プログラマーに自分自身について気分を良くし、自分が何をしているのかを知っているという考えを確認します（たとえ彼がそうしなくても）。

2. 建築宇宙飛行士は、変化する状況に適応するための最初の糸玉プロジェクトの失敗を目撃しました。すべてを書き直す必要があり、将来の別の書き直しの必要性を防ぐために、内部プラットフォームを作成し、それらを適切に使用する方法を誰も理解していないため、サポートに1日4時間費やしています。

3. 準エンジニアは、真の能力を持ち、いくつかのエンジニアリング原則を理解しているため、実際の訓練を受けたエンジニアと間違えることがよくあります。彼らは、リスク、ROI、UX、パフォーマンス、保守性など、基礎となるエンジニアリングおよびビジネスの概念を認識しています。これらの人々は、設計とドキュメントを連続体と見なし、通常、アーキテクチャ/設計のレベルをプロジェクト要件に適合させることができます。

   この時点で、多くはアジャイル、ウォーターフォール、RUPなどの方法論に恋をします。彼らは、実際のソフトウェア工学分野では単なるツールであることに気付かずに、これらの方法論の絶対的な不可ibility性と必要性さえ信じ始めます、宗教ではありません。そして残念なことに、それは彼らが最終段階に到達するのを防ぎます：

4. ダクトテーププログラマ AKA達人または高度に支払ったコンサルタントが、彼らがプロジェクトの要件を聞いた後、5分以内に使用するつもり何建築とデザインを知っています。アーキテクチャと設計のすべての作業はまだ行われていますが、直感的なレベルで行われているため、訓練されていない観察者がカウボーイコーディングと間違えます。

   一般的にこれらの人々は、彼らの作品は少し下エンジニアリングかもしれないが、彼らは「十分に良い」の製品を作成する方法についてなど、すべてのあるマイル離れたカウボーイコーダによって生成スパゲッティコードから。ナゲットは、彼らについて話されたときに、これらの人々を識別することすらできません。なぜなら、彼らにとって、バックグラウンドで起こっていることはすべて存在しないからです。

おそらく、この時点で私が質問に答えていないと思う人もいるでしょう。質問自体に欠陥があるためです。カウボーイコーディングは選択ではなく、スキルレベルです。また、読み書きができないことを選択できる以上に、カウボーイコーダーになることはできません。

あなたがカウボーイコーダーであるなら、あなたは他の方法を知りません。

建築の宇宙飛行士になった場合、物理的および心理的にデザインのないソフトウェアを作成することはできません。

準エンジニア（またはプロのエンジニア）である場合、事前の設計作業をほとんどまたはまったく行わずにプロジェクトを完了することは、明白なリスクと比較検討する必要がある（通常は不合理な期限による）意識的な選択です。利害関係者が同意した後（通常は書面で）。

そして、もしあなたがダクトテーププログラマーなら、「カウボーイコード」を使う理由はありません。それは、高品質の製品を同じくらい迅速に構築できるからです。

方法論ではないため、他の方法論よりもカウボーイコーディングを「好む」人はいません。これは、ビデオゲームのボタンをマッシングするソフトウェア開発に相当します。初心者レベルでも大丈夫ですが、その段階を過ぎて移動した人は誰もそれをしません。彼らは似たようなことをするかもしれませんが、同じことではありません。

はい。

また、靴下を脱いだ床に置いておき、机を印刷物や古いスナックラッパーで覆い、流し台を汚れた皿でいっぱいにし、ベッドを整えずにおくことを好みます。

私は、事前に計画された休暇を適切な休暇、栄養に適切な食べ物を求めて食事をすること、または既知のトレイルに適切なハイキングに滞在することを考えていません。

私は楽しみ、驚き、新しいことを学び、間違いを犯すのが好きで、それを取り戻すかどうかはよくわかりません。そして、時には、その態度は、まさに地面からプロジェクトを取得するために必要な何...

...しかし、ほとんどの場合、それは無責任です。ダンスが終了すると、パイパーに支払われます...これはあなたの危険で忘れてください。

正解です。この「カウボーイプログラミング」アプローチは、コードの最初のリビジョンをより高速に公開する可能性がありますが、その時間の節約は次のおかげで失われます。

• 追加のバグ
• とにかく持っていたであろうバグを見つけるために必要な追加の時間
• コードをリバースエンジニアリングして、6か月で変更を加える必要があるときに何をしたかを記憶する必要がある
• コードに取り組む必要がある追加の開発者のトレーニングに費やした余分な時間
• 何かを壊すような変更を行ったときに振り返るリビジョンのログがない
• 後のプロジェクトで簡単に再利用できるモジュールがない
• そしてどんどん

ニール・バターワースが彼の答えで言及したように、時々あなたはあなたがやらなければならないことをしなければなりません。ただし、一般的な慣行として、いや、ソースコード管理、パターン、ドキュメントなどに時間をかけずにコードをできるだけ速くバングアウトすることは非常に悪い習慣です。

あなたの同僚を分析し、彼らの習慣が盲目的に行うのではなく、彼らの習慣が有益であるか有害であるかを考慮するのに適しています。

これは本当に、きちんとした構造がなく、計画に多くの時間を費やすことなく、物事を正しく実装できるかどうかという問題に帰着します。

ここでは本当に人気のないものをここに放り投げます。顧客は一般的にカウボーイのようなやり方で処理されることを望んでいます。

つまり、彼らは何かを成し遂げることを要求し、誰かにそれを飛び越えさせ、それを実行させ、そこに出させたいのです。プロジェクト管理、会議、電話会議、フォームはありません。早くやれよ。「ちょっと、これは私たちの好みには少し早すぎました。次回、そこに小さな滝や何かを入れていただければ幸いです」とお客様に言われたことはありません。

チームの方法論と構造は、プロジェクトの場を平準化し、同じページで同じレベルでさまざまなレベルの開発者が同じ目的で同じ方法で作業できるように設計されています。

私が協力して成功した「カウボーイ」は次のことができます。

• 何かをすばやく実装する最も簡単な方法を特定する
• どの時点で破損するかを知る
• 簡潔で読みやすい、わかりやすいコードを書く
• ユーザーがそれをどのように使用し、悪用し、破壊するかを予測する
• 適切な場所でそれをスケーリング/抽象化し、建築宇宙飛行士に行くことはありません
• エッジケースと例外を処理する場所と方法を知る

このような人々は、管理と構造のオーバーヘッドをほとんど伴わずに本当に素晴らしい結果を生み出しますが、まれです。

編集：将来の参考のために、私の答えは別の質問に対するもので、これはこの質問に統合されています。ここではかなり不適当ですが、それは私の電話ではありませんでした。

彼女はただ怠け者で、ar慢で、無知で、非常に利己的です。この動作は無謀です。

つまり、彼女は型にはまらない、あるいは時代遅れの方法論を使用しているわけではありません。彼女は意識的にどれも使っていません。標準なし。品質保証なし。まったくありません。彼女はソフトウェアの品質がどこから来ると期待していますか？木？
彼女が明らかにそれを欠いているとき、彼女はあなたが引用する人々の経験を実際に否定しています。彼らの主張に疑問を呈する検証可能な関連する議論を提供することは有効です。しかし、彼らの経験を否定することによって彼らを信用しようとするだけではありません。

しかし、要点は次のとおりです。バージョン管理にはどれくらい時間がかかりますか？
彼女が時々5秒を投資することを納得できない場合、あなたは彼女の上司にそれを取る必要があります。バージョン管理はオプションではありません。完全停止。

そして、彼女にバージョン管理を使用させると、彼女が導入したバグを簡単に追跡できます。そして彼女に修正させてください。それは彼女の混乱です、なぜあなたはそれをきれいにする必要がありますか？彼女のアプローチがより良いと思うなら、彼女にそれをさせてください- ずっと。
彼女が実際に（妥当な時間内に）できると仮定すると、あなたにはまだ問題があります：彼女とのチームワークはほとんど不可能です。そして、これは彼女を説得する（そうは思えない）、彼女を去る（あなたの会社のために）、または去る（あなたの正気のために）ことによって解決しなければならないものです。
しかし、そもそも彼女の失敗ははるかに可能性が高く、間違いなくあなたの主張を証明するはずです。そして、多くの経験を持つ多くの人々がそうであるように、彼女はベストプラクティスに固執し始めるでしょう。

それは完全に私がソロで作業しているか、チームで作業しているかによって異なります。

私はチームで作業する場合、いくつかの条約や協定が必要とされている-チームの全員が従わなければならないいくつかの彼らの努力に互換性があるように、共通の目標に向かって努力することが一般的に合意された標準を。

しかし、私が一人で仕事をするなら、もちろんカウボーイになりたいです。世界中のすべての素晴らしい作品は、カウボーイスタイルの単一の心、またはせいぜい2つの心で発明されています。ほんの数例を挙げると：

• 古典力学？カウボーイアイザックニュートン、後にハミルトン、ラグランジュ、ライプニッツから追加。
• 飛行機？カウボーイズライト。
• 相対性理論？カウボーイアルバートアインシュタイン。
• コンピューターの基礎科学？カウボーイアランチューリング。
• トランジスタ？カウボーイズのウォルター・ブラッテンとジョン・バーディーン。

チームは段階的に改善を行い、実績のあるレシピに基づいて新しいシステムをかなり迅速に組み立てることができます（チームがうまく導かれている場合）。しかし、チームによって行われた実際の発明について聞くことはまれです。チーム作業とそれに必要な方法には長所がありますが、カウボーイコーディングにも長所があります。

問題に依存します。優れたシニア開発者は、非常に安定した非常にコンパクトでシンプルで堅牢なコードを記述し、ドキュメントのページやさまざまなパターンやパラダイムを乱すことなくすべてのベストプラクティスを使用します。しかし、彼はまた、いつそのようなことをする余裕があるかも知っています。

彼が新しい問題に取り組み、ゼロから人月を必要とするアプリケーションの設計を始めたらショックを受けるでしょう。しかし、それがプラグインで、2時間で書くことができるシンプルなツールである場合、何らかの変換を行い、再利用を目的としない関数は、デザインとパターンは実際には時間を無駄にするだけです。

また、デザインの大部分は、シニア開発者の頭の中のどこかのバックグラウンドスレッドですでに処理されていると思います。

上級開発者が複雑なシステムのクラスや新しいアプリケーションを一から作成し始めたとき、計画ステップなしで心配する必要があります。

それは状況に依存します。たとえば、いくつかの悲惨な取引スキャンダルの後、いくつかの電子証券取引所は、自動取引フラグがすべての取引に追加されると主張しました。そして、これは1週間以内にすべての取引ソフトウェアに適用する必要がありました。私はそれが行われなければならなかったことを意味します-旗がそこになかったら、あなたは取引できませんでした。そのような状況では、すべての良い慣行は取締役会に委ねられます-あなたは（私たちが言っていたように）「ハッキング、ハッキング、ハッキング」に行けばよいだけです。そして、そのような状況では、コードを迅速かつ正確に書くことが重要です。特に利用可能なテストシステムがなかったため。

私の経験から、ソース管理によるカウボーイコーディングは、大規模なソフトウェアシステムを開発するための最良かつ最もバグのない方法です。

コメンテーターの1人が正しかったと思う-結果についてのすべて。

その人が良い製品を生産することができれば-本来の目的を果たし、保守可能で信頼できるものであれば-正式な方法論やプロセスが守られれば何が問題になりますか？プロセスは品質のフロアを確保するのに最適ですが、誰かがすでにそのフロアより上で作業している場合、プロセスは方程式に何も追加しません。最近の開発者が多すぎると、imoは、プログラミングのポイントは、優れた製品を生産するのではなく、プロセスを遵守することだと考えているようです。

この種の人はハッカーと呼ばれ、通常、私たちの間でより専門家からの無料の用語ではありません。

お気づきのように、設計、組織、および制御で節約された時間は、デバッグでは失われます。そして、多くの場合、実際に出荷されたコードのリリースを見つける際に。あなたがそれをまったく見つけることができるなら！

この種の人は自分自身に包まれすぎており、他の人が苦しめなければならない「制限」を扱うにはあまりにも良いと思うので、気にすることはありません。チームはそれらをクリーンアップする必要があります。また、バグ修正プロセスにあまり関与していません（これはメンテナンス開発者のタスクであり、「l33tコーダーのスキルと才能のかなり下にあります」）。

だから、それは他の場所では一般的なアプローチかもしれませんが、私の場所（そして私はこのアプローチに傾向がある上級コーダーです、エム）私たちはそれに苦しみません。大量のプロセスと手順を要求するということではありませんが、最小限の組織、ソースコード管理を主張します（正直なところ、血まみれの東部であり、非常に便利です！）

ケント・ベックらはすべて、古いプロセスを搭載した方法自体が悪いと見たプロフェッショナルであるため、コーディングをよりクラフト指向のままに整理する新しい方法論を作成し、それを他の人に本を出版することで（インターネットの前に他にどのようにそれをやりましたか？）

あなたはそれが正しいように聞こえます-他の誰かがそれをハックできないという理由だけで悪い練習を受け入れないでください。あなたのチームリーダーまたはマネージャーは、この「ロックスター」に懸命に取り組むべきですが、そうでなければ、それでもあなたが正しいことをすることを妨げません。彼女がねじ込み（そしてそうする！）なら、彼女から粗雑な練習を受け入れないでください。コーディングの生産性を損なうことなく、優れた実践に固執し（そして、それが何であるかを知っています）、将来のために良いことになります。

これは本当に洞察力に富んだ作家のエッセイです。それはあなたの問題を解決するものではありませんが、それがなぜそうなのかについていくつかの洞察を与え、そしておそらくそれを専門的に扱うためのいくつかのヒントを与えます。

唯一の重要な事実は、チームの長期的な製品結果です。

1人（またはそれ以上）の優れたプログラマーを含むチームは、平均的なレートでコーディングする平均的なプログラマーの数がさらに多いチームよりも良い結果を生むという主張があります。

カウボーイが通常のプログラマーが（特定の期限や仕様のために）提供しないものを作成し、カウボーイとチームがカウボーイの混乱を片付けるのに数週間/月を費やさなければならない場合でも、彼らはまだ終わるかもしれませんすぐに良い結果。

カウボーイのチームが何年も何年も経っても混乱をクリーンアップ（文書化、デバッグ、統合、保守）できない場合、カウボーイが作成した進歩がチームに長期的な優位性を与えませんでした。

どちらを決定し、チームの名簿を最適化します。

最終結果が良好である限り、すべてのプログラマーが同じ方法で働く（または働くべきではない）とは限りません。

Franklyへの私の答えに洞察が見つかるかもしれませんが、カウボーイコーディングは好きですか？ 問題は、「カウボーイコーディング」は人によって異なることを意味することであり、訓練を受けていない目では、どのバージョンを見ているのかはすぐにはわかりません。

誰かが問題を見てすぐにコードを素早く正確に開始できるようになると、それは以前に何千回もそれを見て、問題を解決する最善の方法をすでに知っているマスターエンジニアのサインかもしれません。

または、それはランクアマチュアの兆候かもしれません。

私はあなたに一つのことをお伝えします：彼らがあまりにも「アカデミック」であるので、バージョン管理の使用またはテストの記述を拒否することは、間違いなく「上級」または遠隔のプロのアプローチでもありません。MicrosoftやGoogleなどの主要なソフトウェアショップでこの種のことが行われることは決してありませんし、ほとんどのスタートアップや適度に成熟したエンタープライズチームでも見られないでしょう。

リスクは大きすぎます。PCが一晩で死んだ場合 さようなら3年間の生産性。さて、バックアップを作成します。次に、大きな変更を加え、それが完全に間違っていたことに気付き、元に戻さなければならない場合はどうなりますか？要件が間違っているため、これは最も経験豊富で才能のある開発者でも起こります。何らかの種類のバージョン管理を実行していない場合は、泥の中でホイールを回転させるだけです。私はかつてそこに行ったことがあり、二度と戻りません。

言い訳はありません-リポジトリのセットアップには10分かかり、コミットには10​​秒かかります。総開発時間の1％を占めます。テストは、急いでいる場合、1日20〜30分に簡単に削ることができ、それでもかなり有用です。

私はアジャイル（大文字のAに注意してください）方法論のファンではありませんが、時には袖をまくり上げて、いまいましいコードを書き始める必要があります。「分析麻痺」の人やチームを見てきましたが、生産性は本当に目に見える打撃を受けます。しかし、リビジョン管理やテストなど、私たちの取引の基本的なツールを却下することは、私にとって本当に決め手です。この人は上級職に属していません。

はい、しかし、あなたはそれをしないときを認識しなければなりません。

どんな小さなものでも大丈夫かもしれませんが、複雑で危険なもの、制約のあるものなどがある場合は、適切な設計が余分な時間の価値があるかどうかを認識する必要があります。

また、アーロンノートの答えをよく考えてください。カウボーイは人によって意味が異なります。

「伝統的な」方法論を考えるとき、「管理者は開発者を理解する方法を知らないので、開発者の世界に行き、何が起こっているのかを十分に理解するのではなく、開発者を自分の世界に入れます」と思います。

基本的に、「アジャイル」について考えるとき、「複数の人が一緒に作業することによって生じる非効率性を最小限に抑えるために必要なことをする」と思います。だから私は「のようなものがないことをキャンプにしっかりとよアジャイル方法論、価値観と原則のセットだけ」。

つまり、非常に大規模なプロジェクトで実行する必要があるものがあり、小規模なプロジェクトで実行する必要があるものがあり、両方で実行することがあります。

たとえば、自分が取り組んでいるプロジェクトのバックログは、最も単純なものしかありません...これはただのやることリストです。私たちが2人いる場合は、おそらくそのリストを共有しますが、非常に単純な形式（おそらく、コードリポジトリに保存されているメモ）になります。3または4ができたら、何らかの作業項目システムを探しています。

非常に単純な機能のプロトタイプを作成する場合のみ。

その後、適切な方法を検討し、コードを捨てて真剣になります。

実際のプロジェクト（Saturday Night LiveのSamurai TailorシリーズのスケッチにちなんでSamurai Programmingと呼ばれたとき）で一度やってみましたが、驚いたことに、うまくいきました。もちろん、私が始めたのはごみでしたので、それを悪化させるリスクはほとんどありませんでした。

しかし、私は心の「ニート」であり、ヒップからの撮影スタイルの開発が嫌いです。

一方で、プロセスを大量に使用する方法も私の好みではありません。行動する前に計画したいだけです。

全体として、適切な正式なプロセスの量は、プロジェクトの規模（コードのサイズ、プロジェクトの期間、開発者の数、要件の種類など）に大きく依存すると感じています。航空電子工学や生物医学機器用のソフトウェアを開発する人々に厳格で厳しい基準を課したい。たとえばゲームの場合、失敗のマイナス面がはるかに少ないので、厳密で系統的な開発プラクティスのコストと負担はそれほど大きくない正当化された。

プロジェクトのサイズに（大きく）依存します。一方で、適切な結果を得るには、デザインが必要です。一方、プロジェクトが十分に小さく、書き留めたり、図を描いたりすることなく、デザイン全体を概念化できる（とにかくほとんどの場合）場合は、おそらく追加の作業なしでうまくいくでしょう。あなたがするすべてを文書化する。

ほとんど誰もが、自分が何をしていて何が起こっているのかを明確に理解せずに飛び込もうとすることは災害のレシピであることに気付くのに十分な恐怖物語を聞いています。はるかにめったに指摘されていないのは、反対も同様に悲惨なことがあるということです。ほんの一例として、私たちのほとんどは、プログラミングの過程で小さなツールを日常的に書いています。多くの場合、完全な仕様、テスト、ドキュメントを作成するだけでは価値がありません。製品化には価値がないしきい値があります。人々はしばしば車輪の再発明を嫌いますが、場合によっては回避するよりも再発明する方が簡単です。

このようなケースでは、何が多いのは、ある価値があるが、この簡単なようなタスクを行うために、ライブラリを製品化しています。それにより、フロントエンドのコードはたいてい些細なものになり、目的のことを実行するためのコードを書く（または変更する）ことは、完全なプログラムを実行する方法を整理するよりも簡単になります。たとえば、gnuインデントには50以上の異なるフラグがあり、それらの多くはさまざまな微妙な方法で相互作用するため、合理的な唯一の選択肢は1）まったく使用しない、または2）与えるものを好きにすることです元々欲しかったものを手に入れる代わりに。

2つのキャンプがあるように見えます-結果を好む人と、原則を好む人。後者に該当します。

私は平凡ですが、間違いなく良心的なプログラマーです。コーディングを行う際の主な関心事は、仕事を成し遂げる以上に、自分の仕事を成し遂げるために自分のコードを使う人を助けることです。私は常にそれを達成したとは言えませんが、それが私が目指していることです。

もちろん、あなたはチームにホットロッドを持っているかもしれません-しかし、彼らが数週間の休暇を取って、あなたが彼らの仕事をデバッグするか、それに何かを追加するように頼まれたとき、どうなりますか？最終的に、カウボーイプログラマーはチームプレーヤーではありません。彼らは素晴らしいコードを作成するかもしれませんが、チームがそれらに依存している場合、それは危険です。

彼女のスタイルに対するあなたの嫌悪感があなたにそれをわずかに誤って伝えていると感じています。カウボーイアプローチはデバッグで支払われると言いますが、これはすでに起こっていることですか、それとも、それがどのように機能するかというあなたの仮定ですか？

公正な開示-私は自分自身がシニア開発者であり、設計と経験を継続するための正式なプロセスをしばしば忘れています。問題の領域で非常に経験のある人のために正式なプロセスを持たないことは非常に一般的です。何十回も問題を解決した場合、同様のソリューションを再度策定するための正式なプロセスは必要ありません。

正式なプロセスはコードの設計を扱います-正式なプロセスが欠落しているため、なぜさらにバグを導入する必要があるのか​​わかりません。あなたのアカウントで読んだ唯一の大きな問題は、リビジョン管理が使用されていないことです。彼女は実際にはまったくコミットしていないのですか、それとも単にあなたの好みに合ったパターンでコミットしていないのですか？

設計に正式なアプローチを持たないことは、私の本では「カウボーイコーディング」ではありません（ただし、リビジョン管理は使用していません）。まさにそのために経験を使用する必要があります-「十分な」ソリューションを考え出すのに必要な時間を短縮するため。忘れてはならないのは、あなたが現在抱えている問題を解決し、コードを簡単に変更できるようにすることであり、決して起こり得ない将来のシナリオのために設計することではありません。経験を積むと、それを非常に高速に行う方法がよくわかります。

いいえ、決して。

私は常に要件分析を行い、アーキテクチャについて考え、詳細を設計してからコードを作成します。個人的なプロジェクトのために自宅で一人で仕事をしていても。

そして、彼/彼女がカウボーイスタイルで働いていたならば、私はすぐに私のチームで開発者を解雇します。私たちはエンジニアであり、顧客とユーザーに責任があります。

カウボーイコーディングは上級のアプローチではないと思います。

他の人が言ったように、バージョン管理を破棄することには本当の危険があります。ドキュメントと分析をスキップすることは、ユーザーが望まないものを配信するリスクがあることも意味します。ただ私の意見ですが、あなたがするのがカウボーイコードだけなら、「コーダーから開発者」に行くとは思いません。

しかし、はい、ニール・バターワースが言及したような例外があります。そして、このような状況では、カウボーイコーディングを行わなければならないのは、経験豊富な上級開発者になりたいです。

カウボーイプログラミングは泥の大きなボールを作るかなり確実な方法です。それは、それが聞こえるほど不快ですが、配信する傾向があります...

新しいプログラマーは、プロジェクト/スコープの多くの経験のない側面や、ボスからのプレッシャーのために「物事を成し遂げようとしている」などの側面に取り組むとき、いくつかのカウボーイコーディングを行う傾向があると思います。使用する適切なパターンに関する知識が不足していて、「それを自分のやり方でハッキングした」ために、私はこのパスを確実に数回行ったことを知っています。

私とあなたが苦情を言っている人との違いは、私は通常、すぐにそれを改善し、維持しやすくしたことに気づき、通常、より多くを学び、スキルを向上させることを促します（本の記事/記事を読むことによって件名）。これらのハッキングされたソリューションのデバッグに戻ったとき、私は通常それが苦痛であると感じ、それを「正しい方法」で行う方法を学びたいと思っています。あなたが説明しているこの人は、基本的に自己反省の幼児レベルで立ち往生しており、それは彼ら自身のエゴがソフトウェア開発者としてのスキルを実際に向上させることを妨げていると思います。

あなたの投稿が面白いと思います。私はしばしばあなたの主題と意見を共有しました、そして彼女の感じは、形式化された方法が息苦しいということです。他の誰かが指摘したように、彼女が天才であり、忘れたり混乱したりせずに同時に多数のメンタルノートを追跡できる場合、複雑なコードのモノリシックなチャンクを維持し、完全に不明瞭な変更で驚くべきことをすることができます。それを行うことができる人々の脳に来る特定の精神的な幸福があります-それはあなたの心の小さな宇宙の神であるようなものです。

しかし、賢明な雇用主は、元の作者以外は誰もそのコードに対して価値のあることをすることができないという難しい方法を学んでいます。プログラマーが先に進むと、書き直すことが唯一の選択肢であると考えて、多くのお金を浪費することになります（私はそれが完全な損失を意味すると思っていましたが、外部機能のレベルでの反復開発）。

個人的には、チームにそのような人がいることを気にしません。クランチでは、他の誰も考えていないことをするかもしれないからです。

一方、あなた自身の人間になって、あなたの質問に対する答えが何であるかを自分で決めてください。確かなことは、ソフトウェアの構築に関しては誰もそれを理解していないということだけだからです。それは興味深い分野になるものの一つです...