ベストプラクティスを採用する際の障壁は何ですか？どうすれば克服できますか？[閉まっている]

私たちはみな、多くの貧弱に書かれたコードを見てきました（そして、私たちのほとんどが書きました）。どうして？良いものよりも悪いものを採用する理由は何ですか？

（私にとって）最も明白な答えは「無知」ですが、それが唯一の理由ではないと確信しています。他に何がありますか？悪いコードを書く誘惑を克服するために何ができるでしょうか？

変化への抵抗。

それは、無知、貧弱な管理などの背後にある主要なドライバーです。

Peopleware 2nd Editionの第30章は、このトピックに専念しています。そして、それはもう少し前に書かれた別のかなり有名なコンサルタントによる本からの引用です：

そして、新しい注文の導入の先頭に立つことは、処理が難しく、成功を疑うことも、管理することも危険ではないことを考慮する必要があります。紹介者には、古い命令から利益を得るすべての人々が敵としており、新しい命令から利益を得る可能性のあるすべての人々に温かい防御者がいます。

ニッコロ・マキャベリ：王子（1513）

デマルコとリスターは、人々に変化を求める前に心に留めておくべきマントラを述べ続けています。

変化に対する基本的な反応は論理的ではなく、感情的です。

変化のプロセスが、現在の準最適な状態から新しい改善された世界へとまっすぐにスムーズに進むことはめったにありません。どんな些細な変更でも、新しい現状にたどり着くまでには常に混乱と混乱の期間があります。新しいツール、プロセス、考え方を学ぶのは難しく、時間がかかります。この移行期間中、生産性が低下し、士気が低下し、人々が文句を言い、物事の古き良き方法に戻ることができた場合にのみ望みます。よく知られている問題は、新しい、未知の、イライラする、恥ずかしい問題よりも優れていると感じているため、すべての問題が発生しても非常に頻繁に行います。これは抵抗であり、巧妙かつ穏やかに行う必要がありますが、成功するためには明らかに克服する必要があります。

忍耐と忍耐で、最終的にチームはカオスから次の段階であるプラクティスとインテグレーションに到着します。人々は、新しいツール/プロセスに完全に慣れているわけではありませんが、これらに慣れ始めます。肯定的な「アハ」体験があるかもしれません。そして徐々に、チームは新しい現状を達成します。

カオスは変化のプロセスの不可欠で避けられない部分であるということを認識することは本当に重要です。この知識、およびその準備がなければ、カオス段階に突入するとパニックに陥り、新しい現状と間違える可能性があります。その後、変更プロセスは中止され、チームは以前の悲惨な状態に戻りますが、何かを改善するという希望はさらに少なくなります...

参考までに、上記のフェーズは元々Satir Change Model（Virginia Satirにちなんで命名）で定義されていました。

PéterTörökは正しいが、1つの重要で楽観的な点を除外した。

• 人々があります彼らが関与しているというの変化を好まないが、彼らはほとんど決してただ彼らに「起こる」というの変化のような

参加して、彼らにアイデアを提供させ、彼らにそれへの利害関係を作らせてください。そうすればそれほど苦痛はありません。

注：これはプログラミングに関連します。多くの技術的に成功したソフトウェアプロジェクトはユーザーが拒否するために失敗するためです。

私が働いている時間は大きなもののようです。

たとえば、より多くのコードを記述する必要がある場合に単体テストを採用し、リリース可能な製品を入手するのに時間がかかるのはなぜですか？クライアントxは今それを望んでいます！コードの高速化！

（これは明らかにうまく終わりません）

これはまた、経営と経済の悪さの結果であり、適切な行動に時間を費やすだけの十分な費用を顧客に課していない。

反対の大規模な証拠にもかかわらず、人々は通常非常に合理的な生き物です。TDDなどのベストプラクティスを採用しない理由は、それが価値があるとは思わないからです。実際には、これらの慣行は最善ではないと考えています。そして、実際にそれらを救うよりも多くの費用がかかること。または、利益は非常にわずかであるため、変更のコストがわずかな利益を上回ると考えています。一番下の行は、ベストプラクティスの問題が一番下の行の問題であることです。

変化のエージェントになりたい場合、あなたの仕事は、収益に対する彼らの認識に欠陥があることを示すことです。ベストプラクティスが本当にベストであることを示す必要があります。利益が即時かつ重要であること。学習曲線が耐えられるほど小さく、少なくともいくつかの利点がすぐに始まることを示す必要があります。

これをどのように表示しますか？自分でベストプラクティスを採用することによって！あなた自身の行動以上に他人を納得させるものは何もありません。場合あなたがベストプラクティスに従ってください、そしてそれについてのボーカルあり、他の人がいることがわかりますあなたは経済分析を行なったし、反対の意思決定をしました。それは彼らに彼らの決定を再考させるでしょう。彼らは個人的にこれを行い、最初はそれを認めません。しかし、そのベストプラクティスを使用してあなたを見ている誰もが、自分の立場を再検討します。

それはあなたが期待できる最高のものです。ベストプラクティスがベストプラクティスである場合、残りは自動的に実行されます。おお、それは速くありません、そして、多くのホールドアウトがあるでしょう。移行は遅く、むらがあります。そして、あなたは多くの失望を経験するでしょう。しかし、移行も容赦なく避けられません。一世代かかるかもしれませんが、ベストプラクティスが勝ちます。

その証拠として、最後に誰かがgotoを使用しているのを見たときに自問してください。

それは、理想的な方法を知らないと思った、または考えた結果です。人々はコードを不完全に書くことを選択していません。もっとよく知らない場合です。「無知」とは対照的に、「素朴」はより良い言葉です。

良い習慣に従うための最も簡単な方法は、あなたが書いたばかりのコードを書くためのより良い方法があることを認め（ほとんどの場合）、それからその「より良い方法」が何であるかを学ぶことを目指しています。

2つの原因

• 無知。

• 傲慢。

どうすれば克服できますか？

• インセンティブ。

マネージャー（つまり、開発者のスキルを購入する人々）がソフトウェアの配信の一環としてベストプラクティスを必要とするまで、何も変わることはありません。多くの組織は明らかに統合失調症です。開発者にさまざまなテクノロジーを教育し、テストされていないソフトウェアまたはテストできない設計を要求しています。またはさらに悪い。

私にとってのベストプラクティスは、8人のチームが書いたソフトウェアです。書面による要件、コードレビュー、単体テスト、フォーマットリリースドキュメントはありませんでした。エンドユーザーのテストはありません。すべての本が私たちがすべきだと言っていることはありません。コードは急いでバグがあり、維持するのは不可能です。リリースから3年後に廃棄されたため、非常に悪かった。それで、それについてとても素晴らしかったです。最初のリリースから2年後、会社の所有者（自分の家に住宅ローンで開発資金を提供していた）は、3000万ドルから4,000万ドルのバックポケットを持って立ち去りました。

私たちはしばしば、ビジネスのためにお金を稼ぐソフトウェアを作るためにここにいるという事実を見失います。企業は、「ベストプラクティス」を使用してソフトウェアを開発する機会を提供するために存在するのではなく、お金を稼ぐために存在します。

ほとんどの「ベストプラクティス」プラクティスは、利益を改善しません。広く採用されている、すべき、そして採用されているもの。それが「ベストプラクティス」が実践されない理由です。

許容リスク

リスクを冒して何かに賭けたことはありませんか？時間の制約があるため、後でリファクタリングするという意図を持って動作するようにします（より早くリファクタリングするのではなく）。実際、これは一部の人にとっては良い習慣と考えられています。

最終的に、あなたは十分な回数燃え、あなたのやり方を変えます。そこにあるすべての「ベストプラクティス」を考えてください。いつもそれらすべてをフォローできますか？矛盾することはありますか？すべての外れ値を処理するのに時間を無駄にしたくありません。

動作する悪いコードを書いて、だれもそれをも​​う一度見ない場合、それはまだ悪いと考えられますか？（「悪いコード」が何であるかを議論することによって哲学的な議論を台無しにしないでください。）

IMEそれは他の人が言ったことの組み合わせです。無知（「これまでDataSetしか使用していなかったのに、なぜこのLINQに悩まされていたのですか？」、時間の不足（「上司はできるだけ早くそれを望んでいます。あまり時間をかけられません」）、欠如理解度（「コードビハインドですべてのコードを記述することの何が問題になっていますか？」）すべてが貢献しています。

皮肉なことに、一度その道を歩み始めると、あなたはただ自分自身を深く掘り下げます。今すぐ角を切り、アプリのすべてのコードをASPXファイルに放り込むと、後で修正することはできなくなります。新しいものがあなたに投げつけられ続けるので、あなたはそれらを素早くやらなければならないことを意味します。つまり、ASPXファイル内のすべてのコードを投げる必要があることを意味します（いつか修正することを誓います）など、それは決してありません-開発を停止することはできず、最初に修正する必要があると言うことができないため、スパイラルを終了します。

多くの場合、開発者は、より良いプラクティス、またはより重要なことには、より良いプラクティスを使用する利点を単に示されていません（さまざまな理由で「ベストプラクティス」という用語の使用をやめ始めています）。

開発者は「意図的に怠け者」であるという理論があります。言い換えれば、彼らは最も抵抗の少ない経路を選択する傾向があります。

優れたプラクティスのメリット（TDDなど、またはSOLID原則に従う）をすぐに示し、実際に優れた（ただし「怠stillな」）開発者になれるようになったら、抵抗が解消することがわかります。離れて。

それは教育の問題です:)

（不足）知識とスキル+投資時間

誰もこれを出していないことに驚いていますが、私の仕事の多くはシングルトンプログラマーであり、何かに苦労したときに（スタック以外）誰も行かないので、私には明らかかもしれません。私はTDDなどのより優れた手法を知っていますが、それらを使用するのに十分な知識がなく、使用を開始するのに役立つ情報を見つけるのに苦労しています。繰り返しになりますが、例としてTDDを使用すると、TDDの基本的な意味が理解できます-コードが特定の結果を出力することをアサートするテストをビルドしますが、実際に実装しますか？

最近、XCodeには単体テストが組み込まれているという事実を除けば、どこから始めればよいのか分かりません。作成するルーチンを実行した後、ビューにXボタンがあると断言できますか？rotateタグを呼び出した後、UIViewsが適切に再配置されたことをアサートするのはどうですか？

一体、どうすればXCodeで単体テストを書くことができますか？それは私が学習に時間を費やす必要がある他の何かです。

@Zuesと@Joshua Smith

はい、私は時間と予算が制約であり、あなたが知っているすべての「より良いプログラミング」原則をプログラムに入れることができないことに同意します。

もう少し時間があれば、現在のタスクをはるかに堅牢な方法で実行できることがわかります。しかし、（特に彼らが最初のiPhoneアプリを完成させている場合や、最初のカスタムメイドのビジネスインテリジェンスソフトウェアを入手している場合）ごく少数のクライアントは、より良い方法を見つけたので、すでにやったことを再実装していると言ったときに理解します。

単体テストでも同じです。残念ながら、私はまだそれらに予算を割り当てる準備ができているクライアントに会っていません。典型的な返信は、「自動回帰テストOKわかりましたが、単体テストですか？時間がありません！市場に迅速に投入する必要があります！」

私の経験のほとんどで2つの部分：

• 時間
• 現在の状況に最適なプラクティスについて同意するのに十分な人々を獲得する

「ベストプラクティス」は、多くの実際の状況で非常に主観的です。チームの半分がSOLIDとTDDを大量に実行しようとしているときに、残りの半分が60時間の週を使ってあちこちで実行時間を数秒短縮するために必要な手段を使用している場合次のリリースに間に合わないものを再設計すると、それほど遠くに行けなくなります。

チーム全体であまり意見の相違を経験していない場合でも、従うことを決定したポリシーに関する正式な合意、文書化、およびトレーニングを取得するのは多大な労力です。これは、ビジネスの観点から見て非生産的な時間の大きなブロックであり、慎重に正当化する必要があります。

時には、習慣がひどいコードを書く主な要因でもあることに気付くでしょう。

あなたは非常に経験豊富なプログラマであり、現在の業界のベストプラクティスについてすべてを知っているかもしれません。地獄、あなたもそのようなことについての専門家になることができます。経験上、そのような人々はひどいコードを書くことはあまりないが、それでも安全で便利だと感じるからといって、古い習慣に逆戻りして、ルールを破るということを知っていることをするのは簡単だと言う。そのような場合、無知と慢、そしてあなたが思いつくかもしれない他のすべての指さしの形容詞は本当に重要ではありません。そのようなプログラマーが自分の仕事に特に悪いというわけではありませんが（これがよくあるケースですが）、ひどい混乱を作りたいとさえ思っているわけでもありません。

私が数えたくないほど何度もこの出来事を個人的に目撃しているのは残念ですが、本当に才能のある人たちは、指と脳が数ヶ月間自動車で動いていたので、純粋なゴミを吐き出しました。ほとんどの場合、これは燃え尽き、悲しみ、ストレスの蓄積の証拠を見る場所です。時々、それは実際に日々の動きを通してそれらを運ぶ盲目的な習慣です。脆弱な人々に不必要にラベルを貼るリスクを回避するために、私はそれを注意深く見守ったことを学んだ。

単に否定的な結論に飛び込むのが簡単だと思う私たちにとっては、ちょっとした考えのための食べ物です...悲しいことに、あなたは頻繁に正しいでしょう。

リファクタリングに沿った何かというタイトルのプロジェクトに支払う関心を示す人はいません。「ビジネス」の利益に訴える言葉が必要です。刷新、再活性化、全体的なリメイク、ライフサイクルのアップグレードなどの言葉は私の職場で機能します。それらのほとんどすべてに、プロジェクトの主要部分としてリファクタリングがあります。

悲しいことに、経済的なヒットマンのおかげで、仕事は賃金がある場合にのみ起こります。たとえ仕事が長期的にビジネスの財産を救うことだけであっても。