高速でバグの多い開発を行ってから、エラーを修正するか、コードの各行に注意して遅くなるか。
重複の可能性：
率直に言って、カウボーイコーディングを好みますか？
初期段階でのプロトタイピングとクリーンコード
優れたデザイン：どれだけハックが許容されますか？
職人の技は報われますか？
どちらが良いですか：
- 可能性のあるエラーや制限を気にせず、コーディングを高速化します。タスクを完了するため、またはマイルストーンに到達するために、入力、NULLリターンなどをチェックすることを忘れて、起こり得るすべてのエラーを修正します。
- コーディングが遅く、何度も書いたすべての行をチェックし、テストを書いて、可能な限りすべての入力をチェックして、コードをできるだけバグのない状態にしますが、作業プログラムを書くのに数週間かかります。
実際、私は2番目の方法を使用していますが、仕事、仕事、仕事に毎日いらいらしているのにイライラしています...
これは[〜＃〜]完全に[〜＃〜]が作業のタイプに依存します。多くの状況で、現在行っているように、テスト駆動開発は間違いなく進むべき道です。全体的に、プロジェクトに費やす時間はlessです。これは、最初から考慮していなかったバグやEdgeケースを常に戻って修正する必要がないためです。最初のオプションでは、はい、記録的な速さで終了しますが、戻ってすべての間違いを修正するのにかなりの時間を費やします。
言われていること、あなたが製品を入手する必要がある状況にいる場合ドアの外できるだけ早く（たぶんあなたは競争を打ち負かそうとしているのかもしれません） 「最初に市場に出す」利点）、TDDを窓から放り出し、何かを機能させ、そこから出してください。 lot素晴らしい製品がこのようにして生まれました。 「十分に良い」製品を使用している競合他社が昼食をとっている場合、バグを際限なく修正して修正していると、製品はどこにも届きません。
Facebookを検討してください。 Mark Zuckerbergは、寮の部屋にPHPとMySQLを使用してFacebookを作成しました。当時、おそらく他の20人の人々または組織がソーシャルネットワーキングサイトを計画しているか、すでにリリースしていました。Facebookが成功した理由の1つは、彼はドアの外を急いで手に入れ、大学市場に初めて参加したという理由だけで、競争のかなりの部分を打ち負かしました。
時間がある場合：単体テスト。
レースに参加している場合：code、そしてそれを機能させる-後で間違いを心配します。
編集：明らかに、バグが多く使用できない製品はリリースできません。 「戸外」の方法を使用する場合、追加のバグを探して修正すると、現在のリリースと比較して製品にわずかな価値しか追加されないことを理解する必要があります。
私の意見では、2番目の方法の方が優れています。速度は遅くなりますが、やり直しや修正、再テストの量が大幅に減り、最終的にはより良い製品につながります。プログラムの作成には「数週間」かかるとおっしゃっていますが、最初の方法を使用すると、プログラムを「日数」で作成して、「数週間」を「考えられるすべてのエラーを修正する」段階で費やすことができることはすでにご存じでしょう。
メソッド＃1を推奨するのは、単一のウィンドウまたは非常に狭いパラメーターで動作する関数を示すために使用される使い捨ての概念実証コードの場合のみです。
速く行く唯一の方法は上手く行くことです。
「おじ」ボブ・マーティンが会議で一度これを話すのを見ました。幸いなことに その引用 がオンラインになっています。
ソフトウェアには迅速で汚いものなどありません。汚れは遅いことを意味します。汚れは死を意味します。
悪いコードはみんなを遅くします。あなたはそれを感じました。感じました。私たちは皆、悪いコードによって遅くなっています。 1か月前、2週間前、昨日も、私たちが書いた悪いコードに悩まされてきました。ソフトウェアには確かなことが1つあります。悪いコードを書くと、遅くなるでしょう。コードが十分に悪い場合は、単に停止して停止することができます。
速く行く唯一の方法は上手く行くことです。
私はすべてのケースを事前に定義するテスト駆動開発を行っています。これにより、高速で緩いコードを記述して、見落としたものを確認できます。次に戻って、私がめちゃくちゃにしたものをリファクタリングします。私の意見は常に、何をすべきかを理解し、それを紙に「スケッチ」して、私の仮定がどこで間違っているのかを理解してきました。初めて完璧なものを作ろうと何度も試みましたが、自分の側の誤った仮定のために戻ってやり直さなければならないことに気づきました。
あなたの質問は、誤った二分法のようなものを作成すると思います。実際には、決定は二元的ではありません（「ゆっくりと慎重に、または迅速かつ無謀にコーディングしますか？」）ではなく、スペクトルに基づいています。あなたが提示した2つのオプションはどちらか極端です。
正確にどこになりたいかは、取り組んでいる特定の製品と顧客があなたに何を期待しているかに大きく依存します。使用している制約を調べ、使用するプロセスの種類についてインテリジェントな決定を行う必要があります。
たとえば、ミスを修正するのに非常にコストがかかる場合、または障害が壊滅的になる可能性がある場合は、オプション＃2に近づく必要があります。組み込みソフトウェア、ミサイルガイダンスコード、医療ツールは良い例です。バグを修正することは、数百万ドル相当のハードウェアをリコールすることを意味するか、またはその間違いが人々を死に至らせる可能性がある場合、最初に正しくそれを確実にする必要があります。
スペクトルのもう一方の端は、ビジネス環境が迅速なコード変更を要求するときですが、ミスを修正するのは簡単であり、失敗のペナルティは低くなります。 Webアプリケーションはしばしばこの説明に適合します。ユーザーは新機能やビジネスロジックの変更を強く求めており、昨日それらを実装したいと考えています。コードに小さな間違いがあった場合、問題のあるスクリプトを編集して変更コードを確認し、修正するのに15分かかります。この場合、ユーザーの期待を適切に管理している限り、ユーザーはoccasionalバグを無視することを学習しますが、ユーザーのニーズに対応している限り、迅速なターンアラウンドタイムを維持します。もちろん、このアプローチを採用する場合でも、壊滅的な障害を防ぐための予防策を講じる必要があります。バックアップを保持し、コードレビューを行い、適切な修正プログラム/元に戻すプロセスがあることを確認してください。
ソフトウェア開発の現実は、ほとんどのプロジェクトがこの2つの両極端の中間にあるということです。通常、バグの防止に勤勉になりたいですが、厄介なQAプロセスのために、1年間のリリースサイクルを望まないかもしれません。
先ほど述べた環境要因は別として、ユーザーがどこにいるかを正確に把握するには、ユーザーからのフィードバックを評価することが最善の方法だと思います。新機能の待ち時間が長いことにイライラしている場合は、応答性を高めるためにQAプロセスを少し調整することをお勧めします。導入する可能性のあるバグの修正がextraであることを確認してください。一方、絶対的な信頼性を要求している場合は、その要求にできる限り対応するために十分な安全対策を講じていることを確認してください。
2のために行きます。
Think -> think further -> do a peer discussion, for complex devs -> code -> test -> eventual fix.
よりはるかに良い
Code -> code more -> realize it won't work -> fix -> discover a new bug the first code raised -> go back to scratch
テスト駆動開発（TDD）アプローチに従っていますか？このアプローチで開発した1〜2か月後には、1をフォローしているかのように速く、2の高品質バーを維持していることがわかります。また、変更を加えることもできます（再-要因）恐れることなく、将来の時間を節約できると考えてください！
また、オプション1に進むことができることも追加します。実際のRushで市場に参入する場合、またはプロトタイピングを行う場合。その作品の最終成果物は理想的にはrm -rf *
依存します。多くのことについてですが、他の人が見逃していたことの1つは、プロジェクトのサイズに依存するということです。大規模で複雑なプロジェクトの場合、デバッグは膨大なものになり、深刻な影響を与える可能性があります。適切な計画と構成により、時間を大幅に節約できます。一方、小さな単純なプロジェクトはデバッグが容易です。可動部分は非常に多くあります。
プロジェクトが大きくなるほど、大きな頭痛の種に身を任せないように注意する必要があります。
ジャロッドはビジネス状況の次元に沿ってこれに答えました。
それは妥当ですが、答えはプログラムのタイプ、あるいは同じ大きなプログラムの異なる部分や「レベル」によっても異なると思います。
プログラムで広く使用されている「エンジン」の奥深くでは、ゆっくりと、着実に、注意深く進むことで成果が得られます。テストを利用する。自分でお願いし、過剰な順列をカバーするためのバジリオンテストが不要になるように、インターフェースを十分に狭く定義してください。
ただし、UIや進化する外部APIへのインターフェースなど、プログラムの「エッジ」に近いほど、高速化する方が賢明です。結局のところ、要件は変更される可能性が高くなります。さらに、完全なカバレッジを取得する見込みの少ない精巧なテストスイートを書き始めるよりも、自分とベータテスターによる直接観察によって問題を見つける可能性が高くなります。
基本的に、これは常識であり、プログラムの特定の部分がどれほど安定しているか、または明確に定義されているかについての評価に基づいています。
これら2つだけを選択する必要がある場合は、間違いなく1を選択します。しかし、私は選択しない2を選択します。説明から、それはほとんどのように聞こえますあなたが行う作業の大部分は概念的であり、コードとそれがどのように機能するかについて考えます。私にとって、開発プロセスの重要な部分は、コンパイル時にコードが実際に何を行うかを確認することです。もちろん、私はcan頭の中でうまくいきますが、それは必ずしもコンパイラが私が思うように行うことを意味するわけではありません。基本的に、コード、コンパイル、およびテストループで、1行のコードを調べるのに1時間も費やすことなくエラーを早期に発見できます。このようにして、結果をより速く生成し、高品質を維持できます。現在、TDD環境ではありませんが、TDDの実装に取り組んでいます。
個人的に、私は＃2をします。テストに合格することがわかっていない限り、何かが行われたとは言いません。はい、原因により時間がかかり、チケットの割り当てられた時間を頻繁にやり過ぎます。
チケットをクローズするときに、QAがチケットを送り返すことは非常にまれです。したがって、私の時間を節約するだけでなく、バグがある場合に再テストする必要がないため、QAチームの時間を節約できます。
私のマネージャーは、私が今行く時間ごとに、テストに無駄にしない2時間以上であることを受け入れました。
遅いですか？ええ、時々。しかし、私はそれが長期的にはより速いことを発見しました。今、余分な労力を費やすことで、プロジェクトのすべての欠陥を修正する前に、週末の1〜2週間作業する必要がなくなります。それは私には価値があります。 :)
あなたのコンセプトを証明するために、最初にそれを素早くそして汚いことをしてください。証明しようとしている概念を実際に証明したことを確認してから、破棄してください（つまり、削除します）。
今度はそれをもう一度行いますが、今回は正しいプロセスと防御的プログラミングに従います。あなたはすでに何をしているのかわかっているので、あなたのコードはあなたが思っているよりもはるかに長くかかりません、そしてあなたのコードはあなたが迅速で汚いだけをすることで思いつくことができたどんなものよりもずっと良いでしょう。