プログラミングにおける有害な誘惑

ちょうど好奇心が強い、プログラミングでどんな誘惑があなたのプロジェクトで本当に有害であることが判明しましたか？

何かをしたいという衝動を実際に感じて、それがプロジェクトに利益をもたらすと信じているとき、または信じられないように自分をだまして、1週間後に実際の問題を解決していないが、代わりに新しい問題を作成した、または、最良の場合、目に見える影響なしにあなたの内なる獣を喜ばせました。

個人的には、悪いコードをリファクタリングしないのは非常に難しいと思います。私は多くの悪いレガシーコードを扱っていますが、リファクタリングが何も壊さないことを証明するためのテストがないとき、それに触れないようにするには深呼吸が必要です。

ユーザーインターフェイスのもう1つの悪魔は、UIレイアウトの変更を楽しんでいるという理由だけで、文字通り何時間もUIレイアウトの変更に費やすことができることです。時々私はユーザビリティに取り組んでいると自分自身に言いますが、真実はボタンを動かすのが大好きです。

あなたのプログラミングの悪魔とは何ですか？また、どのように回避しますか？

時期尚早の一般化は私の大きなバガブーです。まず手元の問題を解決し、一般的なケースの実際の解決が必要になるまで待つのではなく、私は常に一般的なケースを前もって追跡し、必要以上に複雑な大量のコードを書くことにします。

更新：

詳細な説明については、「Sin＃1-Premature Generalization」を参照してください。

「これに戻り、後で修正します。今すぐ動作する必要があります！」

締め切りはとても遠いです、私はそれをするのに十分以上の時間があるので、ウェブサーフィンに少し時間を費やしてみませんか？

「これは単なる概念実証コードです。彼らが気に入ったら、私は本当にそれを良くします。」

1. リリースの数日前にコードの一部をリファクタリングします。
2. インターネット：すべての最大の注意散漫。
3. 新技術：新技術から手を離せない。
4. 最適化：最適化、最適化。..など最適化
5. 完璧さ：コードに満足していない。
6. TODO：決して実行されない時間のTodoがありません。
7. 時間の推定：多くのPMは、これを「推定」と見なしません。彼らは事実として取る。
8. 約束：あまりにも多くの約束を与えます。

既存のフレームワークとライブラリがある場合、すべてを社内で構築しようとすることの犠牲になります。

私の再発する悪魔：時期尚早の最適化とオーバーエンジニアリング。

そして、私はまだそれらを100％避けることはできません...

過度に楽観的な見積もり

上司があなたをじっと見つめているとき、あなたはあなたの腸があなたに言っているよりも低い推定値を与えるために燃えるような気持ちを感じます... それをしないでください！

結局のところ、あなたの腸はおそらくすでに低すぎます！

プロジェクトでテクノロジー/ツール/言語を使用したのは、それを学んだばかりだからです。

開発者の素晴らしさを証明しようとする。

あなたが書いたコードをあなたのものとみなすために。

ちょっと休憩して、stackoverflow.comを見てみましょう;）

最悪の誘惑：

ああ、まあ.. 1つの汚い小さなトリック/ハック/修正は傷つかないでしょう。

推測すると、痛い。:)

コードを書くことは、問題を解決するための最後の手段であることを忘れてください。

機能クリープ

計画を立て、それに固執し、展開します。そして、その後、戻って、人々が求めているものを追加します。

私はこれを何度も見ました。座って、デザインを練り、コーディングを開始します。ユーザーは、お気に入りの機能が「欠落」しているという混乱したナンセンスを聞き、それを求めてロビー活動を開始します。上司は、11時間目に追加することを要求し、展開をファウルし、あらゆる場所にバグを導入し、3か月後、全員が落ち着くと、それを削除するように求められます。そのくだらないレトロな機能はそもそもです！デザインの残りの部分が無意味になったとは言えませんか？

1. 機能を追加する

2. 競争にはこの機能があります。したがって、これは必須の機能であるため、戦略、ポジショニングなどを分析するよりも多くのプログラミングが必要です。

3. 競合他社にはこの機能はありません。したがって、これは差別化機能であるため、戦略、ポジショニングなどを分析するよりも多くのプログラミングを行います。

4. より多くのプログラミングでビジネス上の問題を解決します。例えば、あなたのウェブサイトがホストされているLinuxサーバーの管理に関するより良い専門知識は、より多くの機能をプログラミングすることで得られません。場合によっては、すべてをC＃.Netに再コーディングするのではなく、問題を修正する方法を学ぶ必要があるだけです。

5. より多くのプログラミングでマーケティングの問題を解決します。たとえば、製品に多くの機能をプログラミングして「紫の牛」にすることで、マーケティングの問題を間接的に解決しているというセスゴディンの紫の牛の概念を悪用します。時々、ただの突然変異体モンスター。

6. 本当に重要なものを実際にプログラミングする代わりに、このスクリプトを書くのに費やした時間は数時間で節約できると主張するプログラミングを増やして生産性の問題を解決する

7. コーディングを計画しているが、「正しく」したいのでまだコーディングしていない

8. ダーティバージョンをコーディングし、「後で改善する」ことを約束しますが、「改善する」には戻らないことを約束します。

9. モックアップやサイトマップは「面倒」だからやっていない。モックアップとフリーハンド描画サイトマップ「後で」の競合他社のページのスクリーンショットを撮ることができます。そして、頭の中に視覚化した最初のページのプログラミングにまっすぐ進みます。

告白：私は個人的に1、3、7、8の間違いを犯しましたが、2、4、5、6も犯しましたが、私はそうしなかったことがしばしば自分に惑わされました。

現在、9を修正しています。

編集 質問が解決策を提示する必要があることに気づかなかった。

1）機能を追加する しないでください。ビジネス、マーケティング、ファウンダー、アドバイザーなどと連携して、アプリケーションを1つだけ削除します。

twitterやGrouponなどについて読んで、成功につながったものを1つにまとめた方法について読んでください。

大企業を設立したい場合にのみ機能すると思われる場合は、もう一度考えてください。この行のCtrl + F「このソフトウェアに追加する機能が多いほど、販売は悪くなります。（これは言うまでもなく、ほとんどのソフトウェア開発者にとって非常に直感的ではありません。）」このリンク

2）コンテストにはこの機能があります。だから、これは必須の機能です

ソリューション1を参照

3）競合他社にはこの機能がありません。これは差別化機能です

ソリューション1を参照

4）より多くのプログラミングでビジネス上の問題を解決する。

あなたがあなたに教えるために誰かを雇う必要がある場合、相談をするか、あなたのためにそれをしてから、彼がそれをどのようにしたかを文書化してください。早くやれよ！！コードを書き換えたり、GOを渡したり、$ 200を集めたりしないでください。

5）より多くのプログラミングでマーケティングの問題を解決します。

あなたが販売しているものを人々が理解していない場合、それはマーケティングの問題です。ソリューション1に戻ってピボットします。

6）より多くのプログラミングで生産性の問題を解決する

待つ。

特定の生産性の問題で生産性が2週間より長く苦しんでいると感じるまで待ちます。それがさらに2週間続くと合理的に起こります。

次に、この問題を解決するためのスクリプトのプログラミングに費やされた時間を評価します。最悪の推定値を取り、2を掛けることを忘れないでください。

見積もりに時間料金を掛けます。

次に、代替ソリューションを確認します。アウトソーシング、既製のソリューションの購入、それについて何もしないなど。

最も費用対効果の高いソリューションを選択してください。

それに固執。

7）コーディングを計画しているが、「正しく」したいのでまだコーディングしていない

運動に行きます。あなたはお尻をやる気にさせ、行動する計画を立てるエンドルフィンのラッシュを感じるでしょう。5x5のベンチプレスと5x5のスクワットをしたので、これを知っています。

8）ダーティバージョンをコーディングし、「後で改善する」ことを約束しますが、「改善する」には戻らないことを約束します

GTDでticklerファイルシステムをセットアップします。そして積極的にフォローアップします。自分や他の人への約束をすべてフォローアップしてください。

9）モックアップやサイトマップは「とても面倒」だからやっていない。

balsamiqモックアップデスクトップエディションに75米ドルを費やしてください。私は3週間前に買ったのでこれを知っています。実世界でのドローイングはダメなのに、アーティスト、建築家、先見の明がある人のように感じるので、モックアップをやり直しました。balsamiqで使用されるフォントは、これが単なるモックアップであり、RADで役立つ石に設定されていないことを無意識に思い出させます。

編集を終了

いくつかのビールは、私がより良く、より長く働くのに役立ちます。

「ええ、1日で2000行のスパゲッティの巨大な混乱をリファクタリングできます...」

「そのためのテストがなくてもうまくいく。テストするのは難しすぎる」

それは邪悪な兄弟です

「テストの作成や理解がどれほど困難であっても、そのためのテストが必要です。」

先延ばしと楽観的なタスクの見積もりは私の最大の罪です。

ストレッチ、腕立て伏せ、またはプルアップ（またはその他の身体的運動）を行い、2番目の推定を行う前に悲観的な気分にします。

「既存のコードを理解するよりも、最初から機能を再実装するほうがはるかに簡単です。」

私が取り組んでいるプロジェクトが被った非常に有害な誘惑の1つは、「内部プラットフォーム効果」です。これは、長い間行っていたアーキテクトが無限の知恵で着手したアプローチであり、年間約2,000万ドルを生成するプロジェクトを作成しましたが、更新および保守には6,000万ドルかかります問題の）。

NIH -ここに発明されていません

サードパーティのソリューションに公平なチャンスを与えるのは本当に大変です。誰もが彼らのために作られたものではないサードパーティのソリューションに自然に懐疑的であるべきですが、私はそれについて100％客観的であるのに苦労しています。

時間の節約は、サードパーティのソリューションを避けるべき10のうちたとえ9回は、私は実現するのに十分な客観的である必要がほど巨大な可能1動作します。

顧客の実際のデータベースのコピーを分析する代わりに、提供された「サンプルデータ」に対する設計、コーディング、または単体テスト。期限は短く、彼らはそれが来ると言い続けましたが、決してしませんでした。それが展開されたとき、爆発は壮観でした。本当に、顧客に3人の親顧客がいると予想した人は誰でしょう。

実際のデータのコピーを取得するまで、プロジェクトを再開することはありません。

お奨めは、どこかのないライブラリもあり症候群。

密接に関連する

プラグインフェティッシュ

完全主義が殺す; おそらくプロジェクトが成功しない最大の理由です。

まあ、時にはプログラミングがボトルに私を駆動します。

リファクタリングではなく書き換え。

そこを考えることは、これを行うためのより良い方法でなければなりません。「十分に良い」何かに落ち着くつもりはありません。私は完璧に勝っています！通常、これは、問題について異なる視点を持つ可能性のある他の人と話したり、別の角度から解決策を見たりすることによって回避されます。

すべてを自動化して、実際の作業よりもツールの保守に多くの時間を費やします。

解決策：コードの最適化と同様に、最初に生産性のボトルネックを見つけ、それが発見されて初めて、いくつかの優れた自動化でそれらを修復します。

あなたのプログラミングの悪魔は何ですか？

他の一部の人が言及したことは別として。

優先順位付け：プロジェクトに関して優先度の高い作業を無視し、プロジェクト内の他の作業を最初に行うのは、それらがより興味深いからです！

それらをどのように回避しますか？

もう少し自己規律をもって。真剣に、正しいことをするための自制心と自発性は、これらの「悪魔」のほとんどを避けるのに役立ちます。

私たちはまだクライアントから承認を得ていませんが、締め切りが近づいているので、ここであなたが始めることができるようにいくつかの予備的なコンプがあります...

後で、コンプに一致するプロジェクトの構築が完了したら...

ああ、ここにクライアントのリビジョンがあります、彼らはいくつかの小さなものを変更したいだけです*

（*主要な機能はまったく異なります）

次に、短い期限のプレッシャーにさらされ、それらが最後のリビジョンであると仮定するため、ゼロから始めるのではなく、元の欠陥モデルに基づいて元のコードをリファクタリングし続けます。

私はいつもこれに少しずつ慣れます。Web開発者として避けることは困難です。最善のアドバイスは、より多くの時間をプッシュして、変更を正しい方法で行えるようにすることです。