これらの悪い開発者の兆候はありますか？[閉まっている]

以前は、ビジネスモデルが変化することを認識せずに、クライアントからの仕様の変更を非難し、適応可能な方法で開発することが私の仕事です。私は今、それを悪い開発者の兆候として見ています（変更しました！）。

しかし今、私は自分の中に他の「泣き言」を見る。最近、「丸い穴に四角い釘を嵌めようとするようなものだ」と言っていることに気付きました。また、プロジェクトが進行していないことに対するクライアントの優柔不断を非難しています。

態度を変えるべき場所に注意すべき兆候はありますか？クライアントは常に正しいですか、それともイライラすることを正当化できますか？

あなたが悪い開発者だとは言いません。問題に気づくと、すでにこの定義を超えてしまいます。

要件の変更。それは当然です。優れた開発者はこれを考慮する必要があります。多くの最新のプログラミング技術は、それに対処するのに役立ちます。

元の仕様に忠実であることは現実的ではありません。また、要件を常に変更することは現実的ではありません。

クライアントは間違いなく常に正しいとは限りません。しかし、私たちが望んでいるよりも頻繁に「正しい」です（例えば、彼が完全に休んでいない場合は、彼に対応するようにしてください）。しかし、彼がプロジェクトを間違った方向に動かしているのを見たら、あなたが正しいと思うことを主張してみてください。

これらのことについて厳しい規則はありません。また、優秀で経験豊富な開発者でさえ、完璧な「Zen」を達成していません。唯一の間違ったアプローチは、これらを改善しようとしないことです。

クライアントである場合があります。しかし、それもあなたの問題です

それが開発者である場合と、顧客である場合があります。しかし、通常は両方ともあなたの問題であるため、無力な指さしではなく問題解決の側に誤りがあるため、自分を非難する態度はより成功する傾向があります。そのため、経験豊富な開発者によく見かけます。

さらに良い態度は、非難せずにそれを見ることが私見です：「彼は常に要件を変更するため、私はお粗末なコードを持っているため、顧客のせいです」完全性、堅牢性、速度よりも重要です。」

一種の禅の心：それを判断するのではなく、ただそれが見えるようにしてください。

まず、クライアントは、それが表示されるまで何が欲しいかを知りません。これは、クライアントの関与が多いアジャイルパラダイムの小さな反復の魅力の一部です。第二に、コードが完成しているときに製品が「完成」することを期待しないでください。

Microsoftは、問題をクライアントに直接トレースバックするために、「Watson」（Windowsが爆発したときに表示されるフィードバックメッセージを送信）と呼ばれる製品を採用しています。トレーサビリティは、問題を追跡するユーザーに問題を追跡するための良い方法です。尋ねることでトレーサビリティを得ることができます。または、リソースがある場合は、機能を製品に統合します。重要なのは、問題/改善点を追跡して対処できるようにすることです。

最後に、クライアントが気まぐれになることを確認してください。そのような場合、私は氷山の秘密に集中しようとします。

要件の変更は、人生の厳しい事実です。しかし、コードの腐敗はそれが原因ではありません。

コードの腐敗は、頻繁に実行しないコードの一部があるときに発生します。そのため、「他に影響を与えない」変更を行うと、バグが発生する可能性があります。言い換えれば、日光が見えないコードはゆっくりと分解し、いつ機能しなくなったかは言えません。

はい、それはあなたのせいであり、ユーザーのせいではありません。

本当の解決策は？すべてのコードを頻繁にテストします。もちろん、最善の方法は、カバレッジが良好な自動テストを行うことです。

クライアントの優柔不断は大きな問題になる可能性があり、あなたがクライアント関係の管理を担当しているのでなければ、対処するのは非常に難しいかもしれません。クライアントに対処する人と話をして、クライアントが決定を下すまで進歩が起こらないことを冷静に説明できます。クライアント関係を担当している場合は、プロジェクトを続行する前に決定を下す必要があることをクライアントに伝える必要があります。それはあなたの態度がオーバーホールを必要とするということではないかもしれません、ただ落ち着くために瞑想のほんの一分。;）

Javierは、要件の変更が人生の厳しい事実であることを指摘しています。開発者が決定を下さなければならない製品に取り組んでいることが多いため、私もこれらの状況に不満を感じています。私の意見は、「なぜ管理者がクライアントでこれを理解できないのか？」、または「クライアントが望んでいることを知らないのになぜこのプロジェクトを始めたのですか？」、「彼らがそう変わると頭が痛い」開発の後期」。

簡単な事実：これは、プログラミング/ソフトウェア開発だけでなく、あらゆる人生において常に起こります。人々が心を変えず、順応せず、変化に対処しなければ、世界は単純に非常に退屈で非常に異なる場所になります。人々は与えられたものを見て、それを改善する傾向があります。コードで同じことをしませんか？私が満足していないコードのブロックがある場合（それは非効率的で厄介です）、改善します。（オペレーティングシステムは私に文句を言いますか？...時々、特定の名前のないOSを使用しているが、通常はそうではない場合）

プログラマーとして、私たちは物事を改善する機会をつかむ必要があり、彼らに落ち込んだり悩まされたりすることはありません。機会を利用して、人と話をし、スタイルを改善し、仕事の倫理を改善し、オープンマインドで物事にアプローチし、昨日よりも良くなるように自分自身を押してください。あなたのキャリアを前進させ、簡単に解決しないでください。

誰もがこの答えに同意するわけではないことを理解していますが、この質問に対する答えがより広い視野をカバーすることが重要だと思います。

クライアントと対話しているときは、プログラミングではありません。あなたは学び、教えています。

クライアントに情報を提供し、プロセスについて教育します。変化が起こるでしょう。それらを実装しようとすることを彼らに知らせてください、しかしそれはより多くの費用がかかります。彼らに決めさせてください。

彼らが尋ねる質問が本質的に技術的なものであっても、技術的な詳細に入らないでください。あなたは少し防御的に感じるだろうし、挑戦に挑戦したい/あなたのオタクになりたいので、あなたは誘惑されます。しないでください。彼らは詳細を気にせず、45秒後にリスニングを停止します。

前もって彼らに伝えなかったなら、彼らが業界標準やベストプラクティス、またはあなたがしていることをするための他の言い訳について知ることを期待しないでください。業界の標準だと営業担当者に言ってもらうためだけに最後まで料金が表示されない場合、私はそれを嫌います。私はそれを知ることを期待されるべきではありません。私の回答は、「私も馬鹿げていると感じさせるのですか？」

クライアントと一緒にいるときは、部屋にいる誰よりも、彼らにもっと注意を払ってください。飼いならされた犬はこれで天才です。特に食べ物がある場合。

要件管理や分析が悪いです。ビジネスアナリスト（もしあれば）または要件を取得した人は、クライアントと一緒に座って、クライアントが考えていないものも含めて、すべての要件を取得しようとする必要があります。クライアントは通常、自分が望むすべてのことを知っているわけではありません。優れたビジネスアナリストが、すべてを把握するのに役立ちます。

このため、アプリケーションがプロトタイピング/研究フェーズを終了する前に、常にビジネス要件ドキュメントのセットアップを取得してサインオフする必要があります。

さて、このドキュメントが実際に最終版であるという考えは誤りですが、これは顧客が実際に何を望んでいるかをより良く理解するのに役立つはずです。そして、保守性を念頭に置いてコードを記述している限り、問題を最小限に抑えることができます。

そして、フォールバックするための言い訳が必要になった場合、BRDの遅延、クライアントがサインオフしたこと、そのような機能などを含めないことを責めることができます。

（もちろん、これはあなたがそれを必要とする場合の言い訳にすぎません。あなたは常に彼らが何かを変えることを計画すべきです）

エマーソンの引用では、「愚かな一貫性は小さな心のホブゴブリンです...」最も見落とされがちな言葉は愚かです。一貫性は特定の設定では交渉できませんが、多くの場合、批判的思考と分析の代わりになります。

一方では、多くの開発モデルは、説明している環境で役立つように特別に設計されています。そのため、モデルに違反しなければならない場合、そもそもモデルを正しく実装していないか、間違ったモデルを使用していることになります。

しかし、一方で、ルールに違反する正当な根拠と支持できる正当性があり、不正なメソッドがよりクリーンでメンテナンス可能なコードを生成することを示すことができる場合、賢明なルートを取ることを恐れてはいけません。