品質/標準を無視するソフトウェア開発者は会社にとってより良いのでしょうか？[閉まっている]

コードの最適化、標準、ベストプラクティスを最優先しないことを選択したソフトウェア開発者は、最適化、コーディング標準の実装、時間どおりにタスクを完了することを実践したい開発者よりも有用なコードを作成しますか？

個々のパフォーマンスレビューに関して、これらの異なる方法論はどのように比較されますか？

これらのスタイルはピアレビューでどのように比較されますか？

SDLC中により多くのベストプラクティスを実装するためにチームに影響を与える最良の方法は何ですか？

いいえ、彼らはプロジェクトの現在の所有者からのみ尊敬を得ます。

彼らは何年もの間ゴミにされるでしょう：

• 将来のメンテナー、
• 将来のテスター、
• 将来のプロジェクトオーナー
• 将来のマネージャー、
• そして、将来的にコードベースに関わるほとんどの人。

彼らは同じ治療を受けるかもしれません：

• 現在のテスター、
• 現在の技術文書ライター。

誤った二分法：品質は直交しています。

                高品質低品質

お得なAWESOME Sketchy

不採算のIffy FIRE FIRST

いいえ。ベストプラクティスは、定義により、プロジェクトをより正確に、より短時間で、より迅速に修正できるので、ベストプラクティスがベストです。これらを無視すると、利益が減少することが保証されます。もちろん、マネージャーはベストだと思うが実際はそうではないプラクティスを処方するかもしれませんし、顧客が支払うものとそうでないものを誤って判断するかもしれません-そしてすべての賭けはオフです。

コーディング標準はよりトリッキーです。コーダーに過度の詳細を指定することは可能であり、効率の低下につながります。しかし、経験があれば、肛門保持型のマイクロ管理から有用なガイドラインを伝えるのが非常に簡単になるため、同じことが当てはまります。実際のベストプラクティスは常に価値があり、疑似ベストプラクティスは通常そうではありません。

あなたはしていない限り、コードの最適化は、通常、やる価値はない測定あなたのボトルネックが何であるかを、確認した最適化を行うことが必要であるとことを測定し、あなたの巧妙なトリックは、実際にpreformanceののrquirementを満たしていること。それ以外の場合（ほとんどの場合）、実行する価値がないため、最適ではありません。

コードの最適化と実践を気にしない開発者に同意しますか？ 番号。

彼らは彼らがする必要がある仕事をしますか？はい。

ビジネスはお金を稼ぐことであり、お金を稼ぐ唯一の方法は製品をリリースすることです。これは通常、プロジェクトのスケジュールが厳しいことを意味します。つまり、何かを行うための最良の方法は、何かを行うための最も速い方法ではない可能性があります。

私はこの開発スタイルに同意しませんが、製品がリリースされている場合、会社からは尊敬されると見なされる可能性があります。

いいえ、私は、最短ルートを見つけるだろう離れて、これらの悪徳を高く評価した会社から。

はい、いいえ、これは少し希望に満ちたワッシーですが、これはベストプラクティスであり、完全なプラクティスではありません。理想的には、常にそれらをフォローする必要がありますが、製品のニーズよりもビジネスのニーズを優先したいという状況が常にあります。

あなたはメンテナには嫌われますが、上司からは愛されます。

ベストプラクティスはやや常識のようなものです。2人が詳細に話し合うまでは、誰もがそれを知っておくべきだということに全員が同意しています。2人が完全に定義に同意することはなく、すべての状況に当てはまる論理的な根拠はありません。

宇宙衛星の誘導システムを書いていますか（おそらくそうではありません）？次に、地獄は、この種の作業では決して不十分な品質/パフォーマンスのコードを受け入れることはできません。

使い捨てのウェブサイトを1回のマーケティングプッシュで作成していますか（おそらくこれも行っていないか、質問をしなかったでしょうが、サテライトよりも可能性が高いです）。その後、地獄はい、締め切りに間に合わせるために必要な手段を通じて、その綿毛をドアから取り出します。次のマーケティングディレクターは、おそらく別の会社と別のことを行うでしょう。アートやサイエンスではないこと-支払いを受ける。

それ以外のすべて：交渉可能、特に開発者が初期サポートのオンフックである限り。

あなたが好む聖なるものが再来して、彼/彼女/彼ら/それが奇跡的な方法で開発実践を定義するまで、生死の決定に直接責任のないプロジェクトについては議論の余地がかなりあります使い捨てであるにはそれほど重要ではありません。

生命にかかわるラベル付きのベストプラクティス以外のすべては、通常、会社のポリシー、クライアントの仕様、または個人的な意見のようなものです。それらの多くは、現在多くの人々が同意している個人的な意見ですが、それがすべての状況で不変のガイドになるわけではありません。

彼らが会社のためにどれだけのお金を稼ぐかは議論の余地があります。問題のコードを再検討するレベルがある場合、メンテナンスコストが上昇し、誰かが満足することはありません。長期のメンテナンスコストが高いと、事前に適切に行うよりも費用がかかります。

彼らがどの程度尊重するかは、おそらくケース固有です。ただし、ある時点で誰かが気付くでしょう。

これらのことを気にしないと、会社は短期的にはより多くのお金を稼ぐかもしれませんが、より多くのバグ修正と保守コーディングのために長期的に会社に多くのお金をかける可能性があります。

競合する企業が同じような製品を同時に市場に出すために急いでいる場合、迅速で汚い仕事が必要になることがありますが、そのような行動の将来のコストは慎重に検討する必要があります。

それはすべてお客様に依存します。

迅速で汚い（そして通常は安い）ことを好む顧客は、将来問題が発生することを気にしません。

キャビネットの構造を考えてください。

いくつかは、高品質の特注のキャビネットを支払い、感謝します。彼らは広葉樹の引き出しと一流のハードウェアの余分な費用を気にしません。ビルドとインストールにさらに1週間または1か月かかることを気にしません。

多くはしません。多くの人が、大きなボックスショップから手に入る安価なパーティクルボードの大量生産品を選びます。彼らはそれらを2日でインストールしたいと思います。あちこちの小さなギャップは完全に許容できます。彼らは彼らが10年後に崩壊することを気にしていない。

ですから、あなたのマネージャーが開発者を称賛しているなら、それはあなたの顧客が高品質を望んでいないか、マネージャーが顧客に嘘をついているかのどちらかです。

時間だけが教えてくれます。マネージャーが望むことをするか、別の仕事を見つけます。

いいえ、ありません。IMOコードの最適化は、ベストプラクティスは、実際の職人技があるMOSTコードベースを持っているべき重要なこと。それがなければ全体がスラッジに変わり、ダクトテープで固定されます。それは持続不可能なデザインです。腫瘍は小さくて健康なので、腫瘍を無視するようなものです。今は健康ですが、数年後には無視していたのでターミナルになります。

私はこれらのことを気にしない開発者に同意しないだけでなく、彼らが起動することをまったく尊敬していません。組織を離れることを検討するための確実な方法は、私がそこにいた短い時間に関係なく、気になる唯一の人（会社全体で唯一の人ではないにしても）であるチームに囲まれることです。適切なソフトウェアエンジニアリングの概念について。

良い読み物：http : //www.joelonsoftware.com/items/2009/09/23.html

しかし、私見、ある人のベストプラクティスは別の人の悪夢です。そして、自明ではないすべてのコードベースは、部外者にとって悪夢になります。

あなたが何を考えていても、それについてジャークしないでください。

編集：私はどちらの側にも寄りかかるかもしれないタスクに応じて、ポジションを守っていません。

会社に良いですか？場合によります。

資金が限られているスタートアップの場合は、それを実行して実行します。乱雑であるかどうかは関係ありません。後でリソースが増えたときに修正できます。

多くのユーザーがソフトウェアの品質に依存している成熟した製品の場合、すべてが「適切に」行われる必要があります。

個々の開発者にとってより良いですか？実際には関係ありません。同僚がしていることと同じようにして、管理者に放射性降下物を処理させてください-それはあなたの仕事ではありません。あなたがいつも他の人のがらくたを修正しているなら、あなたは遅いと見られ、他の人があなたの上に昇格されている間、あなたはまだそこにいる人になります。プログラムを入手するか、それが悪い場合はできる限り外に出てください。

開発者とプロジェクト/状況によって異なります。

異常な時間には異常な対策が必要です。

したがって、何かを今すぐ配信する必要があり、誰かが最新の流行語フレームワークを14以上活用しているエンタープライズグレードのJavaアプリケーションを過剰設計している場合、単純なpythonスクリプトがその仕事をしますが、開発者が手抜きして考えているのと同じくらい悪いですバグのあるコードは通常の時間に実行されます。

開発者であることの一部は柔軟です。あなたはツールの奴隷になってはならず、盲目的に慣行に従うべきではありません-それらがあなたを失敗させるケースは常にあります。ルールを破って折り曲げるタイミングを知ることは、多くの経験に伴う価値のあることの1つです。

あなたの場合-速度が重要であるために彼があなたよりも多くの価値を提供する場合、将来のメンテナンスの増加したコストを考慮した後でも、彼はより良い補償に値します。反対側で-あなたが彼の混乱を掃除することに行き詰まっているなら-あなたは経営者とのコミュニケーションの問題を抱えています。

ケースバイケースです。コーディングスタイルを除いて-言い訳はありません。

申し訳ありませんが、この質問へのほとんどの回答に同意する必要があります。

ソフトウェアの主な価値は、柔軟であることです。

正当な理由がない限り、他の人のコードを書き換えるべきではないと思います。機能を実装するために何らかの理由でモジュールを変更する必要がある場合、あなたは現在、そのモジュールの所有者です。それを変更し、一部を書き換え、すべてを書き換えます。

これまでにない柔軟性の観点から低品質を生成することはありません。ソフトウェアに何かを捨てるようなものはありません。クライアントが一時的なものであり、特定の日付以降は必要がなく、品質を気にしない場合は、「悪い」と言うか、コードがあなたや他のプログラマによって一度は変更されないことを書面で伝えます本番環境に展開されているか、訴訟を起こす権利が​​あります。

これらの回答のいくつかで私が見ている最も悪い仮定は、いくつかのクリーンなコードがどういうわけか開発の速度を低下させるということです。実質的なプロジェクト（6時間を超える作業）の場合、クリーンなコードは長期（1週間を超えるもの）の開発を高速化します。私はそれを何度も何度も見ました。

品質の悪いコードは、職業や同僚に失礼です。申し訳ありませんが、本当です。

ですから、柔軟性の点で、品質が悪いことはありません。