率直に言って、あなたはカウボーイコーディングを好みますか？
アジャイル、ウォーターフォール、RUPなどの方法論を政治的に正しい方法で擁護するほとんどのプログラマー。方法論に従う人もいますが、すべてではない人もいます。率直に言って、方法論を選択できる場合、主流の「正しい」方法論に確実に行くか、カウボーイプログラミングのような「より簡単な」方法論を好むでしょうか。どうして？
状況次第です。どちらを使用するか説明してください。カウボーイコーディングにはどのような利点がありますか。
ウィキペディアで Cowboyコーディング について参照してください
経験豊富なプログラマーのほとんど全員が3つの段階を経ており、一部は4つの段階を経ています。
Cowboy coders または nuggets は、デザインについてほとんど何も知らず、不必要な形式だと見なしています。非技術的な利害関係者のために小さなプロジェクトに取り組む場合、この態度はしばらくの間彼らに役立つかもしれません。 it Gets Things Done、それは上司に感銘を与え、プログラマーに自分自身について気分を良くさせ、彼がしていることを知っているという考えを確認します（知らない場合でも）。
Architecture Astronauts は、変化する状況に適応するための最初の球技プロジェクトの失敗を目の当たりにしました。すべてを書き直す必要があり、将来anotherを書き直す必要をなくすために、inner platformを作成し、最終的に支出します1日4時間のサポート。適切に使用する方法を誰も理解していないため。
準エンジニアは実際のと誤解することがよくあります。訓練されたエンジニアは、本当の意味で有能であり、エンジニアリングの原則を理解しているためです。彼らは、リスク、ROI、UX、パフォーマンス、保守性など、基礎となるエンジニアリングとビジネスの概念を認識しています。これらの人々は、設計とドキュメントをcontinuumと見なし、通常、アーキテクチャ/設計のレベルをプロジェクトの要件に適合させることができます。
この時点で、アジャイル、ウォーターフォール、RUPなどに関わらず、多くの人が方法論に恋をします。彼らは、絶対的な不可謬性、さらにはnecessityに気づかずにこれらの方法論を信じ始めます実際ソフトウェア工学の分野。それらは単なるツールであり、宗教ではありません。そして残念ながら、それは彼らがこれまでにない最終段階に到達することを妨げます：
ダクトテーププログラマ AKA gurus または高額コンサルタントプロジェクトの要件を聞いた後、5分以内にどのアーキテクチャと設計を使用するかを把握します。すべてのアーキテクチャと設計作業はまだ行われていますが、直感的なレベルで非常に速く行われているため、訓練を受けていないオブザーバーがカウボーイコーディングと間違える可能性があります-and many do。
一般的に、これらの人々はすべて「十分に良い」製品を作成することを目的としているため、彼らの作品は少しアンダーエンジニアリングされているかもしれませんが、カウボーイコーダーによって生成されたスパゲッティコードからmiles離れています。ナゲットは、これらの人々が彼らについて話されたである場合、それらを特定することすらできません。なぜなら、彼らにとって、バックグラウンドで起こっているすべてが存在しないからです。
この時点で、私が質問に答えていないと自分で考えている人もいるでしょう。これは、質問自体に欠陥があるためです。カウボーイコーディングはchoiceではなく、スキルレベルであり、読み書きができないほどにカウボーイコーダーになることはできません。
あなたがカウボーイのコーダーなら、他に方法はありません。
あなたが建築の宇宙飛行士になったなら、あなたは肉体的にも精神的にもできないデザインのないソフトウェアを作り出すことに夢中です。
準エンジニア（またはプロのエンジニア）の場合、事前の設計作業をほとんどまたはまったく行わずにプロジェクトを完了することは、（通常は不合理な期限のために）意識的な選択であり、明らかなリスクと比較検討し、実行する必要があります。関係者が同意した後にのみ（通常は書面で）。
そして、あなたがダクトテーププログラマーである場合、quality製品を同じくらい迅速に作成できるため、「カウボーイコード」を使用する理由はありません。
方法論ではないため、他の方法論よりもカウボーイコーディングを「好む」人はいません。これは、ビデオゲームのボタンをマッシュするのと同等のソフトウェア開発です。初心者レベルでは問題ありませんが、そのステージを過ぎてしまった人は誰もそれをしません。彼らは似ているように見えるをするかもしれませんが、同じことではありません。
はい
また、靴下を脱いだ床に置き、机を印刷物と古いスナックラッパーで覆い、流し台に汚れた皿を詰め、ベッドを整えません。
私は、事前に計画された休暇を適切な休暇と見なしたり、栄養物の適切な食事を心がけて食べたり、既知のトレイルで適切なハイキングをしたりすることは考慮していません。
私は楽しんで、驚いて、新しいことを学び、間違いを犯し、それを元に戻すかどうか確信が持てないようにしています。そして時々、その態度は正確にプロジェクトを地面から始めるために必要なものです...
...しかし、ほとんどの場合、それは無責任です。ダンスが終了すると、パイパーに支払いが行われます...これを危険にさらすことを忘れてください。
あなたは正確です。この「カウボーイプログラミング」アプローチは、コードの最初のリビジョンをより早く入手できるかもしれませんが、その時間の節約は、以下のおかげで失われた以上のものになります。
- その他のバグ
- とにかく持っていたはずのバグを見つけるために必要な追加の時間
- 6か月以内に変更を加える必要があるときに、コードをリバースエンジニアリングして何をしたかを覚える必要がある
- コードで作業する必要がある追加の開発者のトレーニングに費やされた余分な時間
- 何かを壊すような変更を加えたときに、振り返るリビジョンのログがない
- 後のプロジェクトで簡単に再利用できるモジュールがない
- そしてどんどんどんどん
ニールバターワースが彼の答えで述べたように、時々あなたは自分がやらなければならないことをやらなければならない。ただし、一般的な慣例として、いいえ、ソースコード管理、パターン、ドキュメントなどに費やす時間をかけずに、できるだけ早くコードを実行するのは非常に悪い習慣です。
同僚のように盲目的に行うのではなく、同僚を分析し、その習慣が有益か有害かを検討するのに適しています。
これは本当に、きちんとした構造がなく、計画に多くの時間を費やさなくても、正しく実装できるかどうかという問題に帰着します。
私はここで本当に不人気かもしれない何かをここに捨てます：顧客は一般的にカウボーイのやり方で物事を扱いたいと思っています。
つまり、彼らは何かが成し遂げられることを要求し、誰かにそれにジャンプしてもらい、それを実行して、そこに送り出したいと考えています。プロジェクト管理、会議、電話会議、フォームはありません。早くやれよ。私は、「ちょっと、これは私たちの好みにはあまりにも早く行われました。次回、そこに小さな滝や何かを入れていただければ幸いです」とお客様に言われたことは一度もありません。
チームの方法論と構造は、プロジェクトの競争条件を平準化し、同じページでさまざまなレベルの開発者が同じ目的で同じ方法で作業できるように設計されています。
私が協力して成功した「カウボーイ」は次のことができます。
- 何かをすばやく実装する最も簡単な方法を特定する
- いつ壊れるかを知る
- わかりやすく、読みやすく、わかりやすいコードを書く
- ユーザーがそれをどのように使用し、悪用し、破壊するかを予測する
- 適切な場所にそれをスケーリング/抽象化し、建築宇宙飛行士はそれに乗らない
- Edgeのケースと例外を処理する場所と方法を知る
このような人々は、管理と構造のオーバーヘッドがほとんどなく、本当に素晴らしい結果を生み出しますが、まれです。
編集：今後の参考のために、私の答えはこの質問にマージされた another 質問に対するものです。それはここではかなり場違いですが、それは私の呼び出しではありませんでした。
彼女はただ怠惰で、傲慢で、無知で、非常に利己的です。この動作は無謀です。
つまり、彼女が型破りな、あるいはおそらく時代遅れの方法論を使用しているということではありません。彼女は意識的にnoneを使用しています。基準はありません。品質保証はありません。まったくありません。彼女はソフトウェアの品質がどこから来ると期待していますか？木？
おかしいことに、彼女が明らかに欠けているときに、あなたが引用する人々の体験を実際に否定しているのはおかしいです。彼らの主張を疑問視するための検証可能で関連性のある議論を提供することは有効です。しかし、彼らの経験を否定することによって彼らの信用を落とそうとすることはそうではありません。
しかし、要点は次のとおりです：バージョン管理にはどのくらい時間がかかりますか？
彼女が時々5秒を投資することに確信が持てない場合は、上司に伝える必要があります。バージョン管理はオプションではありません。フルストップ。
また、バージョンコントロールを使用している彼女に、彼女が導入したバグを簡単に追跡できます。そして、herに修正させます。それは彼女の混乱です、なぜあなたはそれを片付けるべきですか？彼女が自分のアプローチの方が良いと思う場合は、それをやらせてください-ずっと。
彼女が実際に（妥当な時間内に）それを行うことができると仮定すると、まだ問題があります。彼女とのチームワークはほとんど不可能です。そして、これはあなたが彼女を説得する（それはありそうに聞こえない）、彼女を休暇にする（あなたの会社のために）、または辞任するために（あなたの正気のために）解決しなければならないことです。
しかし、そもそも彼女の失敗ははるかに可能性が高く、間違いなくあなたの主張を証明するはずです。そして、彼女は、多くの経験を持つ多くの人々がするように、ベストプラクティスを順守し始めます。
私がソロで作業しているか、チームで作業しているかに完全に依存します。
私がチームで働く場合、some規則と合意が必要です-チームの全員がsome共通の目標に向けて取り組むことで共通に合意された基準。
でも一人でやればもちろんカウボーイになりたいです。世界のすべての素晴らしい作品は、1人、または多くても2人の働くカウボーイスタイルによって発明されました。いくつか例を挙げると：
- 古典力学？カウボーイアイザックニュートン、後にライプニッツ、ラグランジュ、ハミルトンから追加。
- 飛行機？カウボーイライト。
- 相対性理論？カウボーイアルバートアインシュタイン。
- コンピュータの基礎科学？カウボーイアランチューリング。
- トランジスタ？カウボーイズウォルターブラタンとジョンバーディーン。
チームは段階的な改善を行い、実績のあるレシピに基づいて新しいシステムをかなり迅速に作成するのが得意です（ただし、うまく指導されている場合）。チームワークとそれに必要な方法には長所がありますが、カウボーイコーディングもそうです。
問題によって異なります。優れた上級開発者は、非常に安定しており、ドキュメントのページやさまざまなパターンやパラダイムのトンを介さずにすべてのベストプラクティスを使用する、非常にコンパクトでシンプルで堅牢なコードを作成します。しかし、彼はいつ彼がそのようなことをする余裕があるかを知るでしょう。
もし彼が新たな問題を取り、何ヶ月もかかるアプリケーションをゼロから設計し始めるとしたら、私はショックを受けるでしょう。しかし、それがプラグインであり、2時間で作成できる単純なツールである場合、一部の変換を実行し、再利用を目的としたものではないため、設計とパターンは、実際には時間を浪費するのにのみ適しています。
また、デザインの大部分はすでに上級開発者の頭の中のどこかでバックグラウンドスレッドで処理されていると思います。
上級開発者が複雑なシステムのクラスや新しいアプリケーションをゼロから始め、計画を立てずに心配する必要があります。
状況によります。たとえば、いくつかの悲惨な取引スキャンダルの後、いくつかの電子証券取引所は、自動取引フラグがすべての取引に追加されると主張しました。そして、これは1週間以内にすべての取引ソフトウェアに当てはまるはずでした。私はそれが行われなければならなかったことを意味します-旗がそこになかったなら、あなたは取引することができませんでした。そのような状況では、すべての優れた慣行は取締役会によって決定されます-（私たちがかつて言っていたように）「ハッキー、ハッキー、ハッキー」に行かなければなりません。そして、そのような状況では、コードを高速かつ正確に書くことが重要です。特に利用できるテストシステムがなかったので。
私の経験から、ソースコントロール付きのカウボーイコーディングは、大規模なソフトウェアシステムを開発するための最善かつ最もバグのない方法です。
この種の人はハッカーと呼ばれ、私たちの間でより専門的な専門家からの補完的な言葉ではありません。
お気づきのように、設計、編成、および制御で節約された時間はデバッグで失われます。そして、多くの場合、実際に出荷されたコードのリリースを見つけることでした。もしそれを見つけることができれば！
私はこの種の人は自分自身に包み込まれすぎているのがわかります。彼らは他の人が苦しむ「制限」に対処するには上手すぎると思うので、気にしないでください。チームは彼らの後を片付ける必要があります。また、バグ修正プロセスにも関与していません（これは、 'l33tコーダーのスキルと才能の下にある、メンテナンス開発者のタスクです）。
それで、それは他の場所では一般的なアプローチかもしれませんが、私の場所では（そして私はこのアプローチに傾向がある上級コーダーです）、私たちはそれに苦しみません。私たちは大量のプロセスと手順を要求するわけではありませんが、最小限の組織化、ソースコード管理を主張します（正直に言うと、血の気の利いたイーストであり、とても便利です！）
ケントベック 他、古いプロセスを積んだ方法は自分たち自身が悪いと思っていたすべての専門家なので、よりクラフト指向を維持しながらコーディングを整理するための新しい方法論を作成し、他のすべての人に伝えましたそれについて-本を出版することによって（インターネットの前にそれ以外にどのようにそれをしましたか？）
あなたはあなたがそれを正しく持っているように聞こえます-他の人がそれをハッキングできないからといって、悪い練習を受け入れないでください。チームリーダーまたはマネージャーは、この「ロックスター」に懸命に取り組むべきですが、そうでない場合でも、正しいことを行うことを妨げるものではありません。彼女が下手な練習を受け入れないでください、もし彼女が台無しになったなら（そして彼女はそれをします！）、彼女にそれを片付けさせます。コーディングの生産性を損なうことなく引き継がせることなく、優れた慣行に忠実であり（そしてそれが何であるかを知っている）、将来のために良いことになります。
これが、本当に洞察力に富んだ作家からの エッセイ です。それはあなたの問題を解決しませんが、なぜそれがそうであるのかについてのいくつかの洞察を与え、そして専門的にそれを扱うためのいくつかのヒントを与えます。
私はコメンテーターの一人がそれを正しかったと思います-結果についてのすべてです。
人が良い製品を生み出すことができる場合-それがするはずのことを行うものであり、そしてmaintainableおよびreliableである場合-正式な方法論またはプロセスに従っている場合、何が問題となるか？プロセスはフロアの品質を確保するのに最適ですが、誰かがそのフロアより上で作業している場合、プロセスは方程式に何も追加しません。最近、あまりにも多くの開発者、imoは、プログラミングのpointはproducingとは対照的にプロセスに固執することであると考えているようです。
率直に言って、カウボーイコーディングを好みますか？ 問題は、「カウボーイコーディング」は人によって異なることを意味し、訓練されていない目にはすぐには分からないことです。あなたが見ているバージョン。
誰かが問題を見てすぐにそして正確にコードのベルトを張り始めることができるとき、それはmay以前にそれを何千回も見て、すでに最善の方法を知っているマスターエンジニアの兆候です問題を解く。
または、ランク素人のサインかもしれません。
一つだけ言っておきます。「アカデミック」すぎるため、バージョン管理やテストの作成を拒否することは、間違いなくnot「上級」またはリモートで専門的なアプローチです。この種のことがMicrosoftやGoogleなどの主要なソフトウェアショップで行われることは決してありませんし、ほとんどの新興企業やかなり成熟したエンタープライズチームでも見られないでしょう。
リスクは大きすぎます。 PCが一晩で死亡した場合はどうなりますか？バイバイ3年間の生産性。さて、あなたはバックアップを作成します。次に、大きな変更を加え、それが完全に間違っていたことに気づき、元に戻す必要がある場合はどうなりますか？ 要件が間違っているため、これは最も経験豊富で才能のある開発者でも起こります。バージョンコントロールを実行していない場合は、泥の中でホイールを回転させるだけです。私は一度行ったことがあるのですが、never戻ります。
言い訳はありません-リポジトリをセットアップするのに10分、コミットを行うのに10秒かかります。これは、開発時間全体の1％に相当します。テストは、急いでいる場合、1日20〜30分まで簡単に調整でき、それでもかなり便利です。
私はアジャイル（大文字のAに注意）の方法論のファンではありませんが、たまに袖をまくって気の利いたコードを書き始める必要がある場合もあります。私は「分析麻痺」を抱える人々やチームを見てきましたが、生産性は実際に目に見える打撃を受けています。しかし、リビジョン管理やテストなどの基本的なツールを解雇することは、私にとって非常に重要です。この人は上級職にいない。
唯一の重要な事実は、チームの長期的な製品結果です。
1人（またはそれ以上）の優れたプログラマーを含むチームは、平均レートでコーディングする平均的なプログラマーの数がさらに多いチームよりも優れた結果を生み出すという主張があります。
カウボーイが通常のプログラマーが提供しないものを（指定された期限または仕様に対して）作成し、カウボーイを持つチームがカウボーイの混乱を片付けるために数週間/月も費やす必要がある場合でも、彼らはまだより早くより良い結果。
カウボーイを抱えるチームが何ヶ月も何年も経っても混乱をクリーンアップ（文書化、デバッグ、統合、維持）できない場合、カウボーイがどのような進歩を遂げても、チームに長期的なメリットはありませんでした。
どちらを決定し、チームの名簿を最適化します。
最終的な結果が良好である限り、すべてのプログラマーが同じ方法で作業する（または作業する必要がある）わけではありません。
「伝統的な」方法論を考えるとき、「管理には開発者を理解する方法がわからないので、開発者の世界に入って何が起こっているのかを十分に理解するのではなく、彼らは開発者を彼らの世界に連れて行く」と思います。
基本的には、「アジャイル」について考えるとき、「複数の人が共同で作業することによってもたらされる非効率性を最小限に抑えるために必要なことを行う」と思います。だから私は「[〜＃〜] the [〜＃〜]アジャイル方法論、単なる値と原則のセット」。
つまり、非常に大規模なプロジェクトで実行する必要があることと、小規模なプロジェクトで実行する必要があること、そして両方で実行する必要があることです。
たとえば、私が自分で取り組んでいるプロジェクトの最も単純なバックログ以上のものはありません...それは単なるto-doリストです。私たちが2人いる場合、おそらくそのリストは共有されますが、非常にシンプルな形式（おそらく、コードリポジトリに保存されているメモ）です。 3または4を取得したら、なんらかの作業項目システムを探しています。
はい、しかしそれをしてはいけないときを認識する必要があります。
どんな小さなものでもおそらく問題はありませんが、複雑で危険なもの、制約されているものなどがある場合は、適切な設計が追加の時間に見合う価値があることを認識する必要があります。
また、アーロノートの答えを通して間違いなく考えるべきだと思います。カウボーイは人によって意味が異なります。
彼女のスタイルに対するあなたの嫌悪感が、あなたにそれを少し誤解させているような気がします。あなたは言うカウボーイアプローチはデバッグで支払われます-これはすでに起こっていることですか、それともそれがどのように展開するかについてのあなたの仮定ですか？
公正な開示-私自身も上級開発者であり、設計と継続的な経験のための正式なプロセスをしばしば忘れます。問題領域で非常に経験のある人に正式なプロセスがないことは非常に一般的です。問題を何十回も解決した場合、同様のソリューションを再度公式化するための正式なプロセスは必要ありません。
正式なプロセスはコードの設計を扱います-正式なプロセスが欠落しているために、なぜバグを追加する必要があるのかわかりません。私があなたのアカウントで読んだ唯一の大きな問題は、リビジョンコントロールが使用されていないことです。これは利己的であるだけでなく、開発者のためにまったく無謀です。彼女は実際にはまったくコミットしていませんか、それともあなたの好みに合ったパターンでコミットしていませんか？
私の本では、設計への正式なアプローチがないことは「カウボーイコーディング」ではありません（ただし、リビジョンコントロールを使用しないことはできます）。そのために経験を使用する必要があります。「十分な」ソリューションを考案するのに必要な時間を短縮するためです。忘れてはならないのは、現在ある問題を解決し、コードを簡単に変更できるようにすることであり、決して起こり得ない将来のシナリオに合わせて設計するのではありません。経験を積むと、非常に速くそれを行う方法について良い感触を得ることができます。
結果を支持するキャンプと原則を支持するキャンプの2つがあるようです。私は後者に陥ります。
私は平凡ですが間違いなく良心的なプログラマです-コーディング時の私の主な懸念はbeyond仕事を終わらせることですが、自分のコードを使って仕事を終わらせる人を手伝っています。常に達成したとは言えませんが、それを目指しています。
確かに、あなたはmayチームにホットロッドを持っています-しかし、彼らが2週間ほど離れて、あなたが彼らの仕事をデバッグするか、それに何かを追加するように求められたらどうなりますか？結局のところ、カウボーイプログラマーはチームプレーヤーではありません。彼らは素晴らしいコードを作るかもしれませんが、チームがそれらに依存しているなら、それは危険です。
非常に単純な機能のプロトタイプを作成する場合のみ。
その後、正しい方法で検討し終えたら、コードを破棄して真剣になります。
私はそれを実際のプロジェクトで1回行いました（当時はSamurai Programmingと呼ばれていましたが、Saturaly Night LiveのSamurai Tailorシリーズのスケッチの後で）。もちろん、私が始めたのはゴミだったので、悪化させるリスクはほとんどありませんでした。
しかし、私は心の中では「すっきり」していて、ヒップからシュートするスタイルの開発は嫌いです。
一方で、プロセスを多用する手口も私の好みではありません。行動する前に計画を立てたいだけです。
全体として、適切な正式なプロセスの量は、プロジェクトの規模（コードのサイズ、プロジェクトの期間、開発者の数、要件の種類など）に大きく依存すると思います。アビオニクスや生物医学機器用のソフトウェアを開発する人々に、厳格で厳格な基準を課してほしい。ゲームの場合、たとえば、失敗のマイナス面がはるかに少ないため、厳密で系統的な開発プラクティスのコストと負担は実際には正当化されません。
これは、プロジェクトのサイズに（大きく）依存します。一方で、まともな結果を得るには、設計をhaveにする必要があります。一方、プロジェクトが小さくて、それを書き留めたり、図を描いたりすることなく、デザイン全体（とにかくほとんどが）を概念化できる場合、追加の作業なしで、おそらくうまくいくでしょう。あなたがするすべてを文書化します。
ほとんどすべての人が恐怖の話を聞いたことがあるので、何をしているか、何が起こっているのかを明確に考えずに飛び込もうとすることは災害のレシピだと気づきました。はるかにまれに指摘されていることは、その逆も同様に悲惨である可能性があるということです。ほんの一例として、私たちのほとんどは、プログラミングの過程で日常的に小さなツールを作成しています。完全な仕様、テスト、ドキュメントを作成することは、多くの場合、価値がありません。製品化の価値がないしきい値はあります。人々は、車輪の再発明を嫌うことがよくありますが、場合によっては、回避するよりも再発明する方が簡単な場合があります。
このような場合、しばしばis価値があるのは、このようなタスクを容易にするためにライブラリを製品化することです。これにより、フロントエンドコードが非常に簡単になるため、必要なことを実行するための完全なプログラムを取得する方法を整理するよりも、必要なことを実行するコードを作成（または変更）する方が簡単になります。例として、50以上の異なるフラグを持つgnuインデントを検討してください。その多くはさまざまな微妙な方法で相互作用します。そのため、唯一の合理的な選択肢は、1）まったく使用しないか、2）提供するものを気に入ってもらうことですあなたがもともと欲しかったものを得ようとする代わりに。
カウボーイコーディングは上級アプローチではないと思います。
他の人が言ったように、バージョン管理を破棄することには本当の危険があります。ドキュメンテーションと分析をスキップすると、ユーザーが望まないものを配信するリスクが高まる可能性もあります。私の意見ではありますが、カウボーイコードしかなければ、「コーダー」から「開発者」に移行するとは思いません。
ただし、はい、ニールバターワースが言及しているような例外があります。そして、これらの状況では、経験豊富な上級開発者にカウボーイコーディングを行わせる必要があります。
あなたの投稿は面白いと思います。私はよくあなたの主題と意見を共有しました、そして彼女の感情は形式化された方法が窒息していると感じています。他の誰かが指摘したように、彼女が天才であり、忘れたり混乱したりせずに同時に多数のメンタルノートを追跡できる場合、複雑なコードのモノリシックなチャンクを維持し、完全にあいまいな変更で驚くべきことを実行することはかなり可能です。それをすることができる人々の脳に来るある特定の精神的な幸福があります-それはあなたの心の中で小さな宇宙の神であるようなものです。
しかし、賢い雇用者は、元の作者以外の誰もそのコードに対して価値のあることを何もできないという難しい方法を学びました。プログラマーが先に進むと、彼らは結局多くのお金を無駄にして、唯一の選択肢は書き直すことであると考えました（以前はそれが完全な損失を意味すると思っていましたが、最近では、外部機能レベルでの反復的な開発）。
個人的には、チームにそのような誰かがいても大丈夫です。なぜなら、緊張すると、彼らは他の誰も考えていないことをするかもしれないからです。
一方、あなた自身の人間になって、あなたの質問に対する答えが何であるかを自分で決めてください。確かなのは、ソフトウェアの構築に関してはnobodyがそれを理解しているということだけだからです。これは興味深い分野の1つです...
カウボーイプログラミングは 泥の大きなボール を作成するかなり確かな方法です。それは、不愉快に思えるかもしれませんが、 配信する傾向があります ...
新しいプログラマーは、プロジェクトやスコープの経験があまりない場合や上司からのプレッシャーが原因で「ただやり遂げよう」としている場合などに、カウボーイコーディングを行う傾向があると思います。使用する適切なパターンに関する知識が不足していて、「ハッキング」しただけなので、間違いなくこの道をたどったことは間違いありません。
私とあなたが不平を言っている人との違いは、私は通常、私はそれをもっと上手くできて、より保守可能にできると気づいた直後に、通常、私はより多くを学び、私のスキルを向上させるように駆り立てます（本や記事に関する記事を読むことによって）件名）。これらのハッキングされたソリューションのいくつかをデバッグするために戻ったとき、私は通常それが苦痛であることを発見し、それが「正しい方法」でそれを行う方法を学びたいという私の欲求にさらに貢献します。あなたが説明しているこの人は、基本的に幼児レベルの自己反映で立ち往生しており、ソフトウェア開発者としてのスキルを実際に向上させるために自分のエゴを邪魔させているのは、私が一緒に働きたい人のようではないようです。
いいえ、ありません。
私は常に要件分析を行い、アーキテクチャについて考え、詳細を設計してからコードを作成します。個人的なプロジェクトのために家で一人で働いていても。
そして、彼/彼女がカウボーイスタイルで働いていた場合、私は私のチームの開発者を即座に解雇します。私たちはエンジニアであり、お客様とユーザーに対して責任があります。