流なコーダーがグッドプラクティスを無視する場合、彼の流fluさは彼に反していないでしょうか？[閉まっている]

私はかなり大きくてバグのあるアプリケーションに取り組んでいます-それが書かれている方法のために（詳細は省きますが、あなたが考えることができるほとんどの分野でルールに違反します）、大きなリファクタリングなしでそれを開発することはほとんど不可能です。

アプリの重要な部分は、インターン、n00bsなどによって作成されました。しかし、Master Developerの階級にプログラマーもいました。そして、謙虚に、彼が残したコードも、おそらくは別の方法で疑わしいです。

確かに、彼のコードはほとんどの場合、仕事を終わらせる傾向がありますが、通常はわかりにくく、車輪を再発明します（たとえば、通常のSQL dbバックアップを実現する大きなカスタムメソッド）など。基本的に、不必要な混乱と多くのオーバーエンジニアリング

そして、他の資質を伴わない場合、高度に熟練したコーダーであること（私は意図的に「開発者」という単語をより広いスキルのセットを示すと仮定して使用しません）が実際には有毒であると考えるようになりました。

それが真実だと仮定すると、私が考えることができるいくつかの理由は次のとおりです。

• 簡単にコーディングしている場合、ライブラリや既存の機能などを使用せずに、その場で独自のソリューションを簡単にスナップアウトできる（または実際には短期的には）と感じます。
• 複雑なプログラムのメンタルイメージを簡単に維持できる十分な経験がある場合、それをモジュール、レイヤーなどに分割する傾向は低くなります。

私のポイントは、流なコーダーが偶然悪い開発者である場合、流fluさは後者を補うだけでなく、実際にはむしろより多くの害をもたらすということです。

あなたはそれをどう思いますか？それは本当ですか？

簡単にコーディングしている場合、ライブラリや既存の機能などを使用せずに、その場で独自のソリューションを簡単にスナップアウトできる（または実際には短期的には）と感じます。

はい。私はその男でした。そして、私はそれがひどいことであることを学びました。

それはすべてあなたにとってとても良いことです。あなたは何か新しいことを学ぶ必要はありません。

しかし、チームの他の部分はどうですか？彼らはあなたに非常に依存するようになります。「Clive's Quicky ORM」をグーグルで検索して、作成したオブジェクトリレーショナルマッパーのヘルプを取得することはできません。

そして、新しい人を雇う必要があり、CliveのQuicky ORMで経験のある人を探すことができない日が来ます。

そしてついにあなたが去り、誰かがあなたのORMのバグに気付く日が来ます。そして、あなたの製品をテストし修正する人々のコミュニティ全体がないので、それはそこにあります。

はい、Hibernateの学習は、軽量なものを書くよりも時間がかかった可能性があります。しかし、そうすることの利益は無視できないほど大きいのです、私見。

•簡単にコーディングしている場合は、ライブラリや既存の機能などを使用せずに、その場で独自のソリューションを簡単に作成できるようになります（実際には短期的には）。

言語は習得できますが、ツールは習得できません。それは本当に強力なコーダーでさえありません。あるスキル（言語の知識）を磨き、別のスキルを錆びさせる（図書館の知識）だけです。他の方法は同じくらい悪いですが、見つけやすいです。

複雑なプログラムの精神的なイメージを簡単に維持できるほど十分な経験がある場合、それをモジュール、レイヤーなどに分割する傾向が少なくなります。

それはスキルに偽装した怠です。あなたが積極的に取り組んでいるものを頭の中に保持することは、それほど労力を必要としません。適切な継ぎ目を見つけて、それに沿ってコードを分割するには、スキルが必要です。すべてを1つの場所に残す方が速いか、または良いと言うコーダーは、多くの場合、どのアイテムを分割するかを見ることができません。

彼が「キーボードがクリックされないのなら、あなたは働いていない」環境で働いているからではありません。私たちは皆、コードを振り返り、私たちが何を考えていたのだろうと考えています。また、このショップはコードのリファクタリングを行っていますか？それは彼が与えられなかった贅沢だったかもしれません。

ただし、最初のアイデア（ただ座って打つことができるアイデア）から脱却し、もう少し計画、研究、思考を行う必要があります。それぞれの小さな問題を邪魔にならないように誘惑することは魅力的であり、プロジェクト全体がこのプラクティスに散らばっています。誰も「壊れていない」ものを修正するために人々にお金を払いたくないので、なぜリファクタリングします。

編集：たまたま答えを知っている人を罰しないようにしましょう。流fluentで、優れたコードを迅速に書く人がいます。重要なのは、この方法ですべての問題にアプローチすることではありません。

100％。

これを冷笑的に見ると、これらの種類のコーダーが実際に大部分の開発者を動かし、安定性、柔軟性、安全性に途中で到達することなく何千人もの開発者時間を費やすことができる非常に基本的なバグを修正します、モジュラー、または[お気に入りのソフトウェアプロパティ]システム。これらのシステムには非常に多くの特異性があり、機能の95％が既に配置されており、その背後に活気のあるコミュニティがあっても、他の何かに移行するという考えはばかげていると解雇の根拠のどこかにあると考えられています。

一言で言えば、流なコーダーは大勢の競合他社よりも多くの損害を与えることができますが、代償は通常長年にわたって支払われます。そして、彼らは通常、彼らの仕事を他の誰かによって定義されているように単純に行っていました。

あなたが開発者なのかコーダーなのかをどのように見分けるのですか？それは不可能だと思いますが、品質を落とすことなくコードをシンプルにする方法を見つけるたびに、啓発に向けて新たな一歩を踏み出しました。

あなたが説明した問題は基本的にNIH（「ここでは発明されていません」）でした-他の症状はありますか？

NIHは、特に1人または2人に分離されている場合、グループディスカッションで対処できます（「ここのジョーは、標準ライブラリを使用してSQLバックアップを行う経験があります-ジョー、どう思いますか？」）。これは、あなたが直接その人に行って、「ちょっと！標準ライブラリを使って、ダミーだ！」と言うよりも対立的ではないかもしれません。:)

あなたの状況にあり、同様の状況を引き起こしたことはあなたの不満を理解していますが、あなたの質問に対する答えはフラットな「ノー」だと思います。流Fluさは、プログラマが保守可能なコードを生成することを保証しません。多くの場合、組織は、ばかげた予算と時間の制約のために、プログラマーに設計と実装が不十分なソフトウェアを提供することを余儀なくさせます。流なプログラマーは、プログラマーだけが顧客が気にかけている何かを提供することに関心があるコーナーをカットしている可能性があります。明らかにこれは実際には良くありませんが、悲しいことに、ほとんどすべてのプログラマーはキャリアのある時点で対処しなければなりません。また、流なプログラマーが怠け者であったり、満足している可能性もあります。私は完璧な英語を話すことができますが、スラングを使用する方が簡単で楽しいです。

他人のコードを使用したり、独自の議論を展開したりすることに関しては、仕事が最もうまくいくものに本当に帰着すると思います。「ベスト」とは、2週間で6週間のプロジェクトを提供することを意味する場合、スタイルや保守性などを考慮しないこともあります。これがリファクタリングと改良の理由です。また、開発者は、サードパーティコードに関して利用可能なものを認識し、それを使用する方法を理解し、それが機能し、適切にサポート/維持されることを信頼する必要があります。そのようなものを使用する一般的な開発パラダイム用のオプションのフレームワーク、ライブラリ、およびAPIが何千もあることを考えると、単に独自のものを転がすよりも多くの時間、エネルギー、およびストレスがかかります。また、サードパーティのコードが必要なことを正確に行わない場合もあります。

私はその船に乗っており（レガシーで流writtenに書かれたコード）、しばらくの間は流fluentなタイプでした。

「迅速で汚い」ソリューションの最大のハードルは、後でさらに追加する必要がある場合です。より多くの機能が必要な場合。構造なしでできることはそれだけです。その後、それは壊れ、それを再配置するのに費用がかかります（まだ満足していますが、本当に感謝されていません）。

基本的に、熱心な営業担当者が販売できる「実行可能なソリューション」になる可能性のあるハックから身を守る必要があります。それは古い「準備ができていません！-しかし、動作しますか？」難問。