タグ付けされた質問 「cowboy-coding」

私はいたずらだった...あまりにも多くの「カウボーイコーディング」、十分なコミット。さて、ここで私は多大なコミットをしています。はい、ずっとコミットしていたはずですが、今は遅すぎます。 何が良いですか？ 私が変更したすべてのものをリストする1つの非常に大きなコミットを行う ファイルには複数の修正、変更、追加のメソッド名などがあるため、コンパイルできない可能性のある小さなコミットに分割してみてください 適切なコミットのためだけにファイルの部分的な復元を行ってから、新しい変更を元に戻します。 注：現時点では、このプロジェクトに取り組んでいる唯一のプログラマーです。少なくともより多くのプログラマを雇うまで、これらのコミットコメントのいずれかを見るのは私だけです。 ところで：私はSVNとSubclipseを使用しています。これらの変更を行う前に、新しいブランチを作成しました。 詳細：そもそもどうやってこの状況に陥ったのかということに関して、別の質問をしました。アプリケーションの接着剤を書き換える準備をする方法

100 version-control  development-process  scm  cowboy-coding 

アジャイルアプローチは、要件があいまいで、エンドユーザーのアイデアを形作るのに多くの相互作用が必要なプロジェクトに最適だと思います。 しかし...私の専門的な仕事では、「アジャイル」アプローチが前もってデザインに労力が費やされなかった理由の言い訳として使われている会社に行き着きます。要件が十分に理解されている場合。 アジャイルなアプローチがなかったら、いいハイレベルな仕様でここに座っていて、何か他のものができあがったときでも同じ画面と機能を二度と再訪する必要はないだろうと考えずにはいられませんそんなことは考えていませんでした。 アジャイル手法の利点は、カウボーイの技術的なリードに足りないという言い訳を上回るのに本当に十分なのでしょうか？ 更新：皮肉なことに、私は認定スクラムマスターになりました。スクラムコースで発表された論文の1つは、最適な開発プロセスは、設計上の決定を下す単一の専門家または第一人者がいるが、明らかな弱点があるものであると述べました。スクラムは、品質の高いソフトウェアを作成する責任を「チーム」に移します。つまり、標準以下のチームは、他のアジャイル開発プロセスや非アジャイル開発プロセスと変わらないスパゲッティを排除できます。

73 agile  cowboy-coding 

アジャイル、ウォーターフォール、RUPなど、政治的に正しい方法論を擁護するほとんどのプログラマー。それらの一部は方法論に従いますが、すべてではありません。率直に言って、方法論を選択できれば、確かに主流の「正しい」方法論に行くのでしょうか、それともカウボーイプログラミングのような「より簡単な」方法論を好むでしょうか。どうして？ 私はそれが依存することを知っています。いつ使用するか説明してください。カウボーイコーディングにはどのような利点がありますか。 ウィキペディアでカウボーイコーディングについて参照してください

66 development-process  development-methodologies  cowboy-coding 

更新 私は4人の開発者の小さなチームで働いています。それらはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えられず、代わりに使用しないことを選択します。ソース管理は専門能力開発の必要な部分だと強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になります。 チームはTFSの使用に慣れていません。2回のトレーニングセッションを行いましたが、1時間しか割り当てられていませんでした。 チームメンバーは、サーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。ですから、nonoと言うと10倍時間がかかります...これらの問題を絶えず説明し、自分自身を危険にさらす必要があります。 サーバー上の物理ファイルは、〜100ファイルにわたって未知の点で異なります。マージには、当面のプロジェクトの知識が必要であり、したがって、開発者の協力を得ることはできません。 他のプロジェクトは同期していません。開発者はソース管理に不信感を持ち続けているため、ソース管理を使用しないことで問題を悪化させています。 開発者は、マージはエラーが発生しやすく、難しいため、ソース管理の使用は無駄だと主張します。これは議論するのが難しいポイントです。なぜなら、ソース管理がひどく誤用され、ソース管理が継続的にバイパスされると、間違いが起こりやすいからです。したがって、彼らの見解では証拠は「それ自身のために語る」。 開発者は、サーバーコードを直接変更し、TFSをバイパスすると時間を節約できると主張します。これも議論するのが難しいです。開始するコードを同期するために必要なマージには時間がかかるためです。これに私たちが管理する10以上のプロジェクトを掛けます。 永続ファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。そのため、公開（完全公開）は、ソース管理にないこれらのファイルを消去します。これはまた、ソース管理に対する不信感を引き起こします。「公開するとプロジェクトが壊れる」ためです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを解決する（保存されたファイルをソリューションサブフォルダーから移動する）には多大な時間とデバッグが必要です。 だから、文化はそれ自体が持続します。悪い習慣はより悪い習慣を生みます。悪い解決策は、新しいハックを駆り立てて、より深く、より時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。それでも、ユーザーの期待は高まっています。 この状況で何ができますか？

62 version-control  teamwork  team-foundation-server  cowboy-coding 

私は質問（チームのコードカウボーイ）を見つけましたが、それは私が抱えている問題よりも「Ninja Coder」に関連していました。 「カウボーイコーダー」の純粋に生きた例であるチームメンバーがいます。人を変えることはできないことを理解していますが、彼が「カウボーイコーダー」のように振る舞うのをやめる方法ですか？ 彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有などを停止しました。 はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグ生成プログラムです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80％は彼のコードに起因しています。私は彼のバグを修正したくありません。そして、経営陣は盲目であるか、これを見たくないか、多分彼らは彼の「スピード」を好む。 私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？ このカウボーイコーダーを武装解除するにはどうすればよいですか？ 私はこのプロジェクトを本当に気にかけている最後の人だと感じています。

37 development-environment  teamwork  communication  cowboy-coding 

ネストされた関数（PythonやDなど）をサポートする言語で複雑なアルゴリズムを扱う場合、私はしばしば（アルゴリズムが複雑なため）巨大な関数を記述しますが、ネストされた関数を使用して複雑なコードを構成することでこれを緩和します。ネストされた関数を使用して内部的に適切に構造化されていても、巨大な（100行以上の）関数は依然として悪と見なされますか？ 編集：PythonまたはDに精通していない人のために、これらの言語のネストされた関数は、外部関数スコープへのアクセスも許可します。Dでは、このアクセスにより、外部スコープ内の変数の突然変異が許可されます。Pythonでは、読み取りのみが許可されます。Dでは、宣言することにより、ネストされた関数の外部スコープへのアクセスを明示的に無効にできますstatic。

23 coding-style  coding-standards  readability  cowboy-coding