毎日の仕事で「正しく」と「できるだけ早く」のバランスをどのように取っていますか？[閉まっている]

私はこの質問を何度も何度も熟考しています。私は物事を正しい方法でやりたいと思っています：保守しやすい、クリーンで理解しやすい正しいコードを書くことです。しかし、私がやることは、パッチの上にパッチを書くことです。時間がない、クライアントが待っている、バグを一晩で修正する必要がある、会社がこの問題でお金を失っている、マネージャーが一生懸命押すなどの理由で。

長期的にはこれらのパッチにより多くの時間を浪費していることを私は完全によく知っていますが、今回は数か月にわたる作業なので、誰も気にしません。また、私のマネージャーの一人が言っていたように、「今すぐ修正しないと長期になるかどうかわかりません。」

これらの無限の現実/理想の選択サイクルに巻き込まれているのは私だけではないと確信しています。私の仲間のプログラマー、あなたはどのようにこれに対処しますか？

更新：この興味深い議論に感謝します。非常に多くの人々が、コードの量と品質の間で毎日選択しなければならないのは悲しいことです。それでも、驚くほど多くの人々が、この戦いに勝つことができると考えているので、この励ましに感謝します。

実際には、これは絶対に正しい答えがないため、非常に難しい質問です。私たちの組織では、より良いコードを生成するためにより良いプロセスを導入しています。グループとしてのコードの記述方法を反映するためにコーディング標準を更新し、非常に強力なテスト/リファクタリング/設計/コードループを導入しました。私たちは継続的に、または少なくとも試みます。少なくとも、2週間ごとに利害関係者に示すものがあります。私たちはソフトウェア職人であり、士気が高いと感じています。しかし、これらすべてのチェックとバランスにもかかわらず、私たちはあなたと同じ問題に苦しんでいます。

一日の終わりには、有料の顧客に製品を提供しています。この顧客には、現実的であろうとなかろうと、ニーズと期待があります。多くの場合、営業チームは手数料を得るためだけにトラブルに巻き込まれます。顧客が契約を締結しているにもかかわらず、非現実的または需要の変化である実稼働の期待がある場合があります。タイムラインが発生します。スプリント中にPTOやロストデイが発生する可能性があります。あらゆる種類のささいなことが、「正しくやる」または「できるだけ早くやる」という難問に追い込まれた状況で終わる可能性があります。ほとんどの場合、「できるだけ早く」を余儀なくされます。

ソフトウェア職人、開発者、プログラマー、仕事のためにコーディングする人々として、「正しくやる」ことが私たちの自然な傾向です。「できるだけ早く」は、私たちのほとんどがそうするように、私たちが生き残るために働くときに起こることです。バランスが難しい。

私は常に、経営陣（私はソフトウェア開発のディレクターであり、そのグループのアクティブな開発者です）にアプローチすることから始め、スケジュール、チーム、および行われている作業を守ります。通常、その時点で、私は顧客に今すぐそれを手に入れなければならず、動作しなければならないと言われます。交渉や寄付の余地がないとわかったら、戻ってチームと協力して、どのコーナーをカットできるかを確認します。顧客ができるだけ早くそれを取得する必要性を高めている機能の品質を犠牲にすることはありませんが、何かが実行され、別のスプリントにプッシュされます。これはほとんど常に問題ありません。

バグが多く、コードの品質が悪く、悪化し、タイムラインが短くなっているために配信できない場合、私が説明している状況とは異なる状況になります。その場合、現在または過去の誤った管理、コード品質の低下につながる不適切な開発慣行、またはその他の要因が、あなたを死の行進に連れて行く可能性があります。

ここでの私の意見は、良いコードとベストプラクティスを守るために最善を尽くして、会社を溝から引き離し始めることです。経営陣に対してグループの意見を聞いたり、話したりする意思のある同僚が1人もいない場合は、新しい仕事を探し始める時が来るかもしれません。

最終的に、実生活はすべてに勝ります。開発中のものを販売する必要がある会社で働いている場合、このトレードオフに毎日遭遇します。早い段階で優れた開発原則を達成するよう努力することによってのみ、コード品質曲線の先を行くことに成功しました。

開発者とセールスマンの間のプッシュとプルは、冗談を思い出させます。「中古車のセールスマンとソフトウェアのセールスマンの違いは何ですか？少なくとも中古車のセールスマンは嘘をついていることを知っています。」あごを上げたまま、「正しいことをする」ようにしてください。

私のキャリアで私が気づいたことの一つは、常にそれを正しく行う時間があるということです。ええ、あなたのマネージャーが押しているかもしれません。クライアントは怒っているかもしれません。しかし、彼らは物事がどのくらいの時間がかかるかを知りません。あなた（開発チーム）がそれをしなければ、それは成し遂げられません; すべてのレバレッジを保持します。

何が本当にあなたのマネージャーがあなたやあなたのクライアントに腹を立てさせるのかを知っているからですか？品質が悪い。

これは、私が「永遠の対立」（ビジネスとエンジニアリングの間）と考え始めたものに要約されます。解決策はありません。それは決してなくなることはないが、軽減するために役立つことはできるからです。

• 価値を伝える

多くの人が気付いていないことは、エンジニアとして、「ビジネスの成功」の問題を常に想定しているということです。新しい機能を追加し、既存の機能を迅速に調整し、より良いコードによって妨害された奇妙なフリンジケースを発見することにより、最小限の顧客が私たちのためにQAを行うことができるように、私たちのコードはすてきできれいで維持可能です。優れたコードが直接貢献し、そもそもより良いコードを必要とする多くの理由を伝えるビジネス上の勝利は、顧客を維持し、他の誰も十分に速く生産できない機能とフィネスで競争力を維持することです。

だからそれを綴りなさい。「コードベースでXを実行したいのは、Yが原因でビジネスに悪影響を及ぼさないから」または「...新しい改善や機能をより早く方向転換する能力を改善することにより、競争力を維持する能力を高めるためです」 」

そして、最善を尽くして、改善が機能しているという明確な証拠を得ようとします。アプリの一部のサブセットを改善することで機能/改善が高速化された場合、その証拠として使用している可能性のあるバックログツールを確認し、適切な会議で指摘します。

• 同じくそーページでチームを取得

自我はしばしば問題です。エンジニアリングチームが非常にひどく必要とすることの1つは、Kool Aid d'jourをよく知っているすべての人に対して、特定の種類の問題を解決するための何らかの合意された一貫したアプローチを持つことの価値を確立することです。他の人の好みがあなたよりも悪いと信じても構いませんが、彼のアプローチが実行可能であり、勝てない議論である場合、より適切であることよりも一貫性を重視します。一貫性を保つための妥協が重要です。物事が一貫している場合、一貫した確立された方法が通常最速の方法であるため、それらを間違えることはより困難です。

• 適切なツールを選ぶ

frameworks / toolsets / libraries / whateverの2つの学校があります。「99％を自分用に設定しているので、ほとんど知らない/やらなくてはならない」vs.「そこにいなくても邪魔にならないが、実際に欲しいものを非常に迅速かつ一貫してDIYで手伝ってくれるスティックの原理ではなく、ニンジンで使用します。」2番目のものを好む。迅速な転換の祭壇では、柔軟性ときめ細かな制御を決して犠牲にすべきではありません。ビジネスにとっては、「独自のツールでは許可されないため、これを行うことはできません」は決して受け入れられない答えであり、些細な/使い捨ての製品エンジニアリング。私の経験では、柔軟性に欠けるツールはほとんど常に大々的に開かれたり、巧妙に回避されたりして、大きな巨大なメンテナンス不可能な混乱を引き起こします。多くの場合、柔軟で簡単に修正できるソリューションは、いずれにせよ、短期的には同じか非常に高速です。適切なツールを使用すれば、高速で柔軟性があり、保守が可能です。

• FFS、エンジニアが決定しない場合、少なくともツールの選択に関するエンジニアの意見を得る

これは開発者の観点からの質問であるという感覚が得られますが、技術者の判断なしでテクノロジーの決定が行われる状況は非常に多くあります。地獄は何ですか？はい、最終的に誰かが最終的な電話をかけなければなりませんが、あなたが非技術的なマネージャーである場合、セールスマンやデモサイトが自社の製品について言っていることではなく、適格な意見を得る必要があります。人々はそれほど賢くする必要がないため、または開発者を自分自身から保護するため、お金を節約することを約束するものはすべて、不潔で汚い嘘です。信頼できる人材を雇います。スタックまたはその他の技術ソリューションから何を望むかを彼らに綴り、彼らの意見を真剣に受け止めてから、どの技術の時流に乗るべきかを決定します。

• 実装上の設計に焦点を当てる

ツールは実装用であり、そのために役立ちますが、そのアーキテクチャを構築するためのおもちゃのセットに関係なく、アーキテクチャを最優先する必要があります。結局のところ、KISSとDRY、そしてそれらが.NETかJavaか、あるいは無料で吸わないものであるかどうかよりも、それらの問題から拡張されるすべての優れた哲学。

• 懸念事項を記録する

事業者側があなたがそれを悪いやり方で行うと主張するとき、その電子メール、特にあなたがなぜあなたに費用がかかるかと言った部分を保存してください。すべての予測が実現し、ビジネスに重大な損害を与える問題が発生した場合、エンジニアの懸念をより深刻に受けとめるための大きな議論が山積みになります。しかし、慎重に時間を計ってください。燃え盛るインフェルノの真ん中では、次のファイアーコードに関する「I-told-you-so」にとって悪い時期です。火を消し、過去に無視された懸念のリストを回顧会議/会話に持ち込み、表現され無視された工学的懸念と、実際の人々の名前ではなく、なぜ彼らが無視されたのかを理解した推論に焦点を当てようとする無視する決定を下す。あなたはエンジニアです。人々ではなく、問題にとどまります。」Xに対する懸念を表明したのは、Yの問題につながるのではないかと恐れたためです。私たちはZに、それを処理するのを先送りするように言われました。」

唯一の解決策があります。リファクタリングのためにプロジェクト/作業時間の約10〜20％を確保します。正当なタスクであると経営者に確信させるのが難しい場合、彼らに唯一の真の議論を与えてください。リファクタリングを行わないと、コード保守のコストが指数関数的に増加します。マネージャーとのミーティング中にこの論文をバックアップするために、いくつかの指標/記事/研究結果を持っているのは良いことです:)

編集：このホワイトペーパーで言及されている「リファクタリングとメンテナンスのコスト上昇」に関するいくつかの優れたリソースがあります：http : //www.omnext.net/downloads/Whitepaper_Omnext.pdf

正しいことをする時間があるときはいつでも、それを使用してください。可能な限り最高のコードを書き、着実に改善してください。ずさんなことをして、必要がないときに技術的な負債を持ち込んで、仕事を難しくしないでください。

重大なバグを修正するための緊急電話は、自分で制御できるものではありません。発生した場合、できるだけ早く対応する必要があります。これが人生です。もちろん、あなたの仕事全体が緊急電話で構成されているという印象を受けており、あなたが正しいことをするのに十分な時間がないなら、燃え尽きる道にあり、上司と話すべきです。

それが役に立たない場合でも、物事を正しく行うための十分な時間を得るための「スコッティの戦略」があります。すべての推定値を4倍にします。

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

私の仕事は、プロジェクトで許可されている時間の制約内で可能な最高品質のソフトウェアを提供することです。品質レベルが低くなることが懸念される場合は、プロジェクトオーナーに連絡します。私は自分の懸念を説明し、その状態でソフトウェアを展開する潜在的なリスクについて議論します。この時点で、次の3つのいずれかが発生します。

1. プロジェクトオーナーはリスクを受け入れたくないため、スケジュールを元に戻して、ソフトウェアの品質により多くの時間を費やすことができます。

2. プロジェクトオーナーはリスクを受け入れたくないが、スケジュールを元に戻すことはできません。これが発生した場合、アプリケーションの主要部分のソフトウェア品質により多くの時間を費やすために、プロジェクトスコープから削除する機能/機能について交渉する必要があります。

3. プロジェクトオーナーはリスクを受け入れ、低品質のソフトウェアは予定通りに出荷されます。何も展開しない（または遅れて展開する）ビジネスリスクは、低品質のソフトウェアを展開するビジネスリスクよりもはるかに大きい場合があり、プロジェクトオーナーのみがその決定を下すことができます。

ソフトウェアを書くことは、ポートレートを描くことによく似ています。肖像画が「正しい」または「完璧な」ものであると言うことは不可能です。完了は敵の敵です。文字通り、1つの方法で1か月を費やすことができますが、それでも「完璧」とは見なされない人もいます。私の仕事は、顧客が満足しているポートレートを描くことです。

これはすべての場合に機能するわけではありませんが、問題が緊急に修正する必要がある壊れた生産問題である場合、この戦略を使用していくつかの運がありました。実稼働を開始するための迅速な修正を行う時間と、将来の品質修正を行う時間を見積もります。見積もりを上司/クライアントに提示し、両方の時間を承認します。次に、緊急の時間的プレッシャーがオフになったときに、すぐに本番稼働を実行するための迅速な修正と、その後すぐに長期的な修正を行います。仕事を正しく行うために今回が必要なときに提示するが、それができるまで一時的な修正を行うことができ、クライアントがそのアプローチを好むようです。製品が再び稼働し、長期的なニーズに対応します。

最適なバランスは、正しく行うことで排除したバグを修正するのに無駄になるほど余分な時間を費やすことです。ソリューションに金メッキをしないでください。ほとんどの場合、適切に行われたフォルクスワーゲンのソリューションは、キャデラックのソリューションと同じくらい良いです。通常、キャデラックが必要であることが証明されたら、後でアップグレードできます。

ベストプラクティスに従っていないコードの修正には、多くの場合、さらに時間がかかります。呼び出しがabcde（）のように見えるときにnullがどこから来ているのかを見つけようとすると、長い時間がかかる可能性があります。

DRYの適用と既存のコードの再利用は、通常、別のソリューションのコーディングとテストよりもはるかに高速です。また、変更が発生した場合に変更を簡単に適用できます。変更してテストする必要があるのは、2、3、20個ではなく、1セットのコードのみです。

強固な基本コードを目指します。完璧にしようとすると、多くの時間が無駄になります。コードを高速化するベストプラクティスがありますが、必ずしも最速とは限りません。それ以上に、ボトルネックを予測し、ビルド時にコードを最適化しようとすると、時間を無駄にする可能性があります。さらに悪いことに、最適化によりコードが遅くなる可能性があります。

可能な限り、最小限の作業ソリューションを提供してください。何週間も金メッキ液が無駄になるのを見てきました。スコープに非常に注意してください。

私は6か月かかるはずのプロジェクトに時間を費やしました。私が参加したとき、それは1年半の間進行中でした。プロジェクトリーダーは、プロジェクトマネージャーに最初から1つの質問をしていました。1週間で、月曜日、水曜日、金曜日に機能が実装されました。火曜日と木曜日に機能が削除されました。

編集：コードが満足のいくレベルまで完了したら、そのままにします。あなたがそれを行うためのより良い方法を思いついた場合、それを修正するために戻って行かないでください。自分でメモを作成する必要がある場合。変更が必要な場合は、アイデアを検討し、それがまだ理にかなっている場合は実装します。

今後の機能の拡張機能を実装する場所がある場合は、拡張機能を実装しないでください。変更を加える場所を思い出させるために、マーカーのコメントを残すことができます。

動作させてから完璧にする

これには多少の余裕がありますが、時間が重要な場合は、それを簡単に機能させることが主な優先事項です。コードの欠点について広範囲にコメントし、使用しているプロジェクト/時間管理ソフトウェアで行ったことをメモします。

うまくいけば、これらの問題に戻って、それらを完璧にするためのより多くの時間を与えるでしょう。

明らかにこれに対する絶対的な正しい答えはありませんが、それは私が試してみて固執する答えです。ただし、現在の作業スタイルに適しているとは限りません。それは私を代替に導きます...

あなたに合った方法を見つけてください。そして、それに固執します。誰もがプロジェクトに対処する独自の方法を持ち、「万能な」アプローチはありません。アプローチを見つけて、あなたのものにしましょう。

「正しく実行する」とは、特定の状況で適切なトレードオフを行うことを意味します。それらのいくつかは次のとおりです。

1. 開発時間とコスト
2. コードの読み取り、デバッグ、および後からの更新の容易さ（変数名からアーキテクチャまですべて）
3. ソリューションの完全性（エッジケース）
4. 実行速度

明らかに、コードの一部が一度使用されて捨てられた場合、＃2は他のコードのために犠牲になる可能性があります。（しかし、注意してください：それを捨てるだろうと思うかもしれません、それからあなたはそれを使い続け、維持しなければならないことに気付くかもしれません。

あなたやチームがコードの使用と更新を続けようとしている場合、ショートカットをとることは、後で自分自身の速度を落とすことを意味します。

現在、バグのあるコード（＃4の弱点）を提供していて、それを行うのに長い時間（＃1の弱点）がかかっている場合、それは＃2の弱点であるコードを更新しようとしているからです。あなたの実践を変えるための堅実で実用的な議論を得ました。

バグの場合はできるだけ早く、新機能の場合は時間をかけてください。

また、開発者の仕事を尊重しない会社で働いている場合、選択を迫られることもありますが、それは迅速に行い、品質を犠牲にすることです。

私は、プロジェクトからプロジェクトへと進み、すべてを迅速に行う多くの企業で働いてきました。最終的に、（プログラミングだけでなく）実装が急いで行われたため、彼らはすべてのプロジェクトでほとんど成功しませんでした。

優れたソフトウェアは、時間と職人の手間がかかることを理解しています。

緊急時にパッチ適用ソリューションを作成します。これに言及したバグ追跡で新しいバグを作成します。適切な時間があるときはいつでも、それを正しくしてください。

私は、この業界で働いて立ち往生しているすべての人がしていることをしていると思います。私はできるだけ早くそれを完了させ、将来の問題を防ぐのに役立つ素晴らしいもののいくつかを省かなければならない場合、または将来の問題解決を容易にする場合、私はします。最適な状況ではありませんが、多くの未知の変数に基づいた推定値に基づいた推定値に基づいた締め切りに悩まされている場合、それはあなたができる最善の方法です。

良い計画は次のとおりです。

1. do-it-right計画とdo-it-asapとまったく同じ時間をかけてください。
2. 環境が満足するまで、時間を最適化してください。品質を保つ
3. ???
4. 成功

私はほとんどのことを日常的な方法で、最初に思い浮かぶ方法で行います。それは迅速であり、私はまともなプログラマーであり、最初の試みでほとんどのことを合理的にOKだと思うのが好きです。

ときどき（1日に2回言いたいが、1週間に2回のほうが現実的だ）、特に日常的に非常に退屈なことを見つけたときは、「これを行うには素晴らしい方法は何だろう？」そして、より良い方法を見つけたり発明したりするために余分な時間を費やしています。

これを何度も繰り返し続けると、日常のコーディングが改善され続けると思います。

ソフトウェアは奇妙なものであり、ソフトウェア開発プロセスは奇妙です。

実生活のほとんどのものとは異なりますが、コンピューターに関するほとんどのことは好きです

速いほど信頼性が高い

これは、あなたのこれまでの人生が教えてくれたすべての直感に反し、高度に調整された車は標準的な車よりも頻繁に故障し、素早く建てられた家はより速く崩壊し、スクールバスの後ろで行われた宿題は高い評価を得ません。

しかし、系統的な手順が遅いと、より良いソフトウェアは作成されません。要件文書の作成に数週間を費やし、コードを書く前にクラス図に何日も費やす人は、より良いソフトウェアを生産しません。基本的な要件を取得し、いくつかの問題を明確にし、ホワイトボードにクラス図を落書きし、チームコーディングにより、ほぼ常により信頼性の高い優れたソフトウェアを作成し、数か月ではなく数日で作成します。

仕事はあなたに合っていません。

「時間がなく、クライアントが待機しているため、バグを一晩で修正する必要があり、会社はこの問題でお金を失い、マネージャーは一生懸命に働いているため」と書かれた低品質のコードは、管理が不十分な会社の症状です。

自分の仕事に誇りを持ち、高品質のコードを書くことをいとわないのであれば、それを理解し、それを行うためにお金を払う雇用者を見つけることが最善です。