開発者の速度を低下させるものは何ですか？[閉まっている]

開発者が遅くなる傾向があるのは何ですか？

次の回答を投稿しないようにしてください。

• 現在は低速ですが、この機能では便利です。（TDD、リファクタリング、...）
• 気晴らしをリストしてください。

ああ、これは簡単です：

1. ミーティング
2. その他の会議
3. 前回の会議に関する会議
4. 今後の会議の準備のための会議
5. 会議用のパワーポイントプレゼンテーションの開発
6. 実装されていない、実装されるべきではない機能を議論する会議のためのパワーポイントプレゼンテーションを開発します。インターネットに接続していないか、ハードドライブにアクセスしていない現在の場所に基づいて、アプリに表示するドキュメントを予測することはできません。いいえ、ただそれを求めるのをあきらめます。

遅いコンピューター

コンテキストスイッチングを引き起こすもの。

StackOverflow、programmers.stackexchange.comなど:)

私は燃え尽きるでしょう。

目の前のタスクに適さないプロセスをたどろうとする試み。

これにはあらゆる種類のものがありますが、私が見る一般的なものには以下が含まれます：

• テスト対象のコードに適合しないテスト方法
• 成果物が保証するよりも劇的に機敏または伝統的なプロセス
• 選択したツールセットとは異なるツールセット向けのガイドライン
• プロジェクトのニーズに応じてスケール外の設計原則
• タスクに適していないツールセットを使用する

これらのすべては、一部のプロジェクトまたは状況では非常に価値がありますが、一部の組織はすべてを一方向に実行しようとするため、他のプロジェクトでは生産性が低下することが多くなります。

政治

例：複数の人が要件（または、さらに悪いことに、2つの異なる既得権益）を所有しており、開発中に要件に対して競合する競合する変更を行う場合。

他の人の会話

一般的なノイズ

多くの回答がコンテキスト切り替えとゾーンからの脱出について語っていますが、ノイズ、特に会話は、私にとってそれらにつながるものの1つです。

キューブワールドでは、すべての面でノイズと会話に囲まれています。メインフレームチームは1行を超えて、キューブ行で定期的な計画会議を開催します。時々、彼らは壁に沿ってオフィスでコンサルタントと会うでしょう、そして、それは騒々しいフーチンとホレリンと笑いにつながる傾向があります、そして、私は彼らにドアを閉めるように頼まなければなりません。

反対側では、Webチームの会議テーブルは私のウェストキューブウォールの反対側にあるので、私はそれが好きかどうかにかかわらず、すべての会議の一部です。サウスキューブの壁の反対側にもプリンターがあります。これは、プリントアウトを待っている人とのチャットに適しています。

「ノイズキャンセリングヘッドフォンを手に入れることはできません」という即座の明白な答えは、あなたが望むものが沈黙である場合には役に立ちません。

コードレビューのために、私は書類の山を昼食室に持って行きます（もちろん昼食以外の時間に）が、そこにはテレビがあります。誰も見ていない場合はオフにします。それ以外の場合は、建物の別の部分の他の部門で空のキューブを見つけに行きます。

プログラマーに必要な作業（主に思考と熟考と検討）を行わせたい場合、それを実行できる環境が必要です。

適切なテストなしでコードの行を書きすぎます。

高品質のコーヒーの欠如。

開発が始まってから絶対に変えてはならない完全な見積もりをしなければならない、それは私の意見では鶏卵シナリオです

他の誰かの壊れたビルドを修正する

議題のない会議。

遅いマシン。

2番目のモニターの欠如。

素敵な新しいマウスの代わりにボールを持っている古いマウス。

マシン上でインターネットにアクセスできないため、MSDN / stackoverflow /などのクエリが少し苦痛になります。

プログラミングに時間がかかりすぎた

プログラミングが本当に好きな場合でも、時間を使いすぎると最終的には燃え尽きてしまいます...

「ゾーン」から抜け出すすべてのものを避けてください。これは、メールの受信トレイ、Twitterポップアップアプリケーション、企業チャットなどを意味します。

静かな労働条件を持つことは、そのデスクトップノイズも避けることを意味します。

事前に知っていれば、実装が簡単だった変更要求。

悪いコード。

そもそも仕事をすることができた誰かの部分を書き直さなければならないことは、私が想像できる最大のタイムシンクです。

あなたを遅くする多くのことは、ブログの投稿としてお。

...

多くのプロジェクトは、コアインフラストラクチャレベルの機能を何度も繰り返し、ビジネスを競合他社と差別化する機能を提供することでビジネスを減速させます。

...

製品とイノベーションが開発者が差別化されていないタスクに費やす時間を削減するのに役立つことは避けられません。問題は、これらのサービスとツールがどのような形になるかです。

...

最近の最大の減速は、特定の順序で行われるべきいくつかのことを同時に開発しているためです。だから、私は（無実を保護するために名前が変更された）ジョンが私のSSISパッケージに必要なコンポーネントを終了し、ハリーはエクスポートをテストするためにいくつかのデータが必要なため、レコードをインポートするのを待って減速しますテーブルにデータがないときに複雑なエクスポートレポートを作成するには？）、設計が完了しておらず、タスクを実行するために必要なデータベーステーブルがまだ作成されておらず、終了しない可能性があるため、全員が遅くなります彼らがそうなると言っていたことである、など。

このようなstackexchange.comの質問に答えます。

気晴らしをリストしないように頼んだが、それらは大きい要因である場合もある。彼らの作業環境を見て、頻繁に中断されているか、プロジェクトに関係しない他のことをするように頼まれているかどうかを確認します。

時々、開発者は今までにやったことのないことをしていて、どこに助けを求めればいいのかわからないために立ち往生するかもしれません。小規模なチームまたは個人の場合、さらに困難になる可能性があります。私たちはやや誇り高い傾向があり、物事のやり方がわからないときは認めたくない。また、他の人に助けを求めるのは好きではありません。開発者にこれを認めさせる簡単な方法はありません。ただし、締め切りに間に合うかどうか、または締め切りに間に合わせるために必要なものを尋ねて、正直になることを望みます。他の助けを求めたり、助けてくれる人を見つけたりする必要があるかもしれません。

要件が明確に定義されていないため、物事を把握したり決定したりする必要が生じます。

• PCが使用可能な状態で起動するまで約15分待たなければならない
• PCがアプリケーションを切り替えるのを待っています
• 自分のお茶/コーヒーを作らなければならないオフィスで唯一の人であること。
• 壊れたキーボード（修正済み！）
• マネージングディレクター（米国CEO）のオフィスの外で作業し（オフィスでもない）、間にパーティションのみ（特に会議がある場合）
• 上司は電子メールでのみ到達可能ですが、他の全員は建物内にいます
• VCSの使用が許可されていない-どうやら脳内にあるはずです
• 小さな画面
• 昼食以外の休憩時間をとらない
• 建物にシステム管理者がいるにもかかわらず、リモートサーバーのバックアップを行う必要がある
• 上記のバックアップを手動で行うように言われます。
• 不必要に複雑な愚かな時間管理システムを使用せざるを得ない
• 仕事を始めて2か月で要件について漠然としたアイデアを得るだけ

続けられますが、金曜日ですので、仕事を忘れたいです。

• ドキュメントの不足（システム、会社など）
• コメント付きコードの欠如
• システムの不完全な理解
• 政治（つまり、不必要な会議、事務処理、経営者による障害...）
• 不完全な要件ドキュメント
• フェイスブック！
• 寝すぎ？

プロジェクトの人が多すぎます。

プロジェクトにさらに人を追加するために必要な実際のデータがないことに基づいて管理者が決定する場面を何度か見ました。それは、何が起こっているのかをほとんど知らない人々の手を握るために、すべてを停止する必要があることを知っている人々に終わります。私は複数のプロジェクトのキノコのサイズを見て、そこからすぐにトイレに入るのに対して、それがうまくいく前には少し遅いかもしれませんが。

そのため、速度が足りないために1か月遅れていることから、余分な人すべての予算を完全に使い果たしていないため、まったく配信しないことになります。

他の人が言及したこととは別に、コードのコンパイルと実行を決定してから肯定/否定の結果を得るまでの長い道のり。理想的には、このRTTはわずか1秒ですが、時間の例を見てきました。ところで、単体テストはこの問題に対処しようとします。

別の関連するこれは、作業環境の一般的な遅延です。気味悪い接続を介して、世界の反対側のコンピューターへのリモートデスクトップ接続を介して作業する必要があると想像してください。私はそこに行ったことがある。私はこれが嫌いです。

• 過度の書類

• 決して周りにいない人に依存している（上司など-質問する必要があるが、彼は常に会議に参加している場合）

• 不十分なツールと機器。

• 誰も理由なくオールを押し込んだり（UIで目に見える変化はこれに影響されます）、ささいなことについてだけ議論します。

• 壊れたコーヒーマシン

• 間違ったタスクが割り当てられている

エアコンが機能しない。

そのため、オフィス内の温度は、夏の最大40度、冬の-5度になります。

-5は手袋を着用して入力できないため、入力には適していません。40は、私の思考を遅らせるだけです。

これは非常に個人的な意見であり、おそらく物議をかもしますが、常に前もって設計するか、「品質」コードを常に書くことについて考えすぎています。「数週間のコーディングで何時間も計画を立てることができる」ということわざがありますが、これは場合によっては真実かもしれません。

しかし、コーディングを始める前に、プログラマーが良いデザインをスケッチしようとするのをよく見ます。プログラムを進めていくと、問題と解決策についてより多くのことを学び、解決策を迅速にリファクタリングして優れた設計にすることができるので、「始め」ることが簡単だと思います。発生する問題のほとんどは、コーディングの開始時にはほとんどわかりません（少なくとも私の弱者の頭の中では）ので、前もって設計するのに多くの時間を無駄にするのは時間の無駄です。

これがTDDが嫌いな理由でもあります。テストの作成に時間を浪費しすぎて、リファクタリングの可能性が低くなるか、テストの書き換えに時間がかかります。単体テストは、プロジェクトのいくつかのケースといくつかの段階に最適ですが、1つの始まりは私見ではありません:)

何かをすばやく取得して改善します。

プログラマーのブロック：他のスローダウンとは異なり、これは解決が困難です。