回答:
一言で言えば、はい。そうでないとあなたに言った人は誰でも、せいぜい間違いかもしれません。
ただし、キーがある書き込みコードにあなたの経験の上に構築することである少ない悪いです。可能な限り「機能する」ようにするために何かを入れる誘惑に抵抗します。あなたはまだ何らかのプロセスに従う必要があります（それはあなた自身のものでも、あなたの会社のものでも、あるいはそれらの混合物でも）。
経験から言うと、特に「プレッシャー」が生産への迅速なリリースを意味する場合、数週間の修正を防ぐために数日間スケジュールをずらすこと（gasp）の方がはるかに良いことがわかります。あなたがコードをリリースすることを急いでいるなら、テスターもおそらくそれをゴム印に急いでいるでしょう。
締め切りがないことは、計画と見積もりが不十分であることを示しています。締め切りに間に合わないことを確認し、問題を解決します。計画や見積もりを制御できない場合があります。誰がそうであるかを特定し、これが誤って行われたことを知っていることを確認します。
期限を変更できない状況では、高度にカフェインを含んだ飲料を取り出して急いで行きます。犠牲にできるものは何でも特定し、切り取ってください。残っているものを取り出して、できるだけ早く実装します。これは、不安定性、奇妙なエラー、非効率的なコーディング慣行、バンドエイドの修正、その他あらゆる種類の恐怖などの問題を引き起こします。必ずしも悪いコードではありませんが、理想的ではありません。
人々が実際に持っている50％の優れたソリューションは、あなたが研究室で絶え間なく磨き上げているので、誰も持っていない99％のソリューションよりも多くの問題を解決し、長く生き残ります。発送が特徴です。
ソフトウェアのジョエルからダクトテーププログラマー。
処理された場合、理想的なコードは処理できません。処理されていないコードは山積みになり、不可能ではないにしても追加の変更が難しくなります。アプリケーションが相互依存的にテープで固定されているので、非常に慎重なプログラマーだけが法外な時間コストで追加を行うことができます。配送は機能ですが、メンテナンス性も向上します。
私はソフトウェアクラフトマンシップの大ファンです。できる限りきれいなコードを書くなどしていますが、時間が足りず、締め切りが迫っている瞬間に急ぐ必要がありました。できる限り最善を尽くさないように心がけていますが、時には逃げられないこともあります。
一部の人々は「まあそれは人生だ、船に乗らなきゃ」と言うだろうが、私はこの態度に本当に反対する。
急いでコードを書くとき、ソフトウェアを時間通りに外に出してしまうかもしれませんが、次の数日間に、ソフトウェアのバグに関連するサポートコールを受け取るとどうなりますか（これらのバグは同じ部分に住んでいます）終了するために急いだコードの）。それとも、リリース日に問題ないことを約束していても、レポートモジュールが機能しなくなった理由を尋ねる怒っているクライアントがいますか？
「あなたは船を買わなければならない」と言っているのはとても良いことですが、効率的に見えることと、ずさんな労働者のように見えることには違いがあります。
私がストレス状態にあるとき、私のコードは仕事を成し遂げるためのものです。それでおしまい。私の意見では、効率やその他の問題に集中していませんが、これは悪いことです。
私はそれに取り組みます。
私が個人的に著しく悪いコードを書いているとは思わないが、悪い製品を提供している。
arbitrary意的で不可能な期限に直面したとき、私たちは開発プロセスをスキップします。さらに表面的なコードレビューを行います（または、スキップします）。テストを少なくし、スポットチェックタイプの統合テストの詳細なユニットテストをバイパスしてから、統合テストを正式な資格としてカウントしようとします。合格基準に直接結び付けられていない場合、テスト中に異常を見落とす傾向があります。ドキュメントの更新をスキップし、リリースノートを再確認せず、不要になったファイルの成果物のリストをスクラブすることを忘れないでください。
クランチ中に記述するソースコードは高品質である場合がありますが、ほとんど間違いなく見掛け倒しの製品の一部として出荷されます。
依存します。
プレッシャーは、すべてを成し遂げる方法がなく、リリースの数時間前に主要な新機能が追加されているためですか？
悪いコードが登場！
しかし、スケジュールが本当に本当にきついが、全体的な計画がしっかりしているためである場合、いくつかの機能を調整しながら、いつもよりも一生懸命作業し、集中し続ける必要があります...スケジュールが膨大な時間を許す場合。たとえそれがすべての単体テストを書かなくても、コードの大部分をカバーすることを意味していても。