誰かがあなたが作った良いものを拒否したとき、あなたはどのように進むべきですか？
Extjsでアプリケーションを作成しましたが、大きなJavaScriptファイルであったため、テクニカルアーキテクト、プロジェクトマネージャー、およびチームリーダーによって拒否されました。アプリケーションを開発するときは非常に気分が悪く、先輩に拒否されます。
気分が悪くなりたくないし、仕事に集中したいです。私の会社のコーディング構造は非常に悪いので、コードを再構築したいと思います。それを改善したいと思います。
より良く働き、成長したい-どうすればいいですか？
あなたの先輩がそれを見る前に、あなたはあなた自身が終わったと考えるポイントに決して到達するべきではありませんでした。拒否は設計時に発生するはずでした。
次に、許容できるものにリファクタリングできるかどうかという問題が発生します。最初の場合は、それを実行します。後者の場合、将来この状況を回避する方法について上司と話し合う必要があります。
誰かがあなたが作った良いものを拒否したとき、あなたはどのように続行すべきですか？
Ask受け入れ基準についてbeforeこれ以上コーディングを行う。
- この機能のスコープはどうあるべきですか？
- どのツールと言語が受け入れられますか（つまり、ExtJSを使用しても問題ありません）？
- 他にどのような制約がありますか（サポートされているブラウザ、コードサイズなど）？
あなたのプロジェクトが適切でなかった理由と、次回は別の方法で何をしてほしいかについて、高齢者に相談してください。どんなに良くても、それは適切ではなかったという態度をとってください。それについて対立しないでください。プロジェクトを却下するのは苦痛ですが、次回何をすべきかを学ぶことは、おそらく却下する理由がある人々とそれについて議論するよりもはるかに建設的です。
コードの品質について質問することもできます。具体的に：特定の部分を取り、なぜそうなのかを尋ねます。あなたがそれについて好きではない理由があるかもしれません。
また、すべてがどうあるべきかを知っていると思う経験のない新しい男として見られることは避けてください。物事が現状のままである理由を学びましょう。それらは正当な理由ではないかもしれません、そしてあなたはそれらに同意しないかもしれません、しかしあなたはそれらに特に対処することなしに何も変えるつもりはありません。
ExtJS ISかなり大きなライブラリであり、商用開発者にはライセンス料がかかります。ソリューションで使用する前に事前の承認を得ていなかったことに驚いています。
あなたも書く：
私の会社のコーディング構造は非常に悪いので、コードを再構築したいと思います。それを改善したいと思います。
これは簡単ではありません。チームの他のメンバーが問題がないと考える場合、それはおそらく不可能です。その場合、より洗練されたチームに適応するか、新しいポジションを見つける必要があります。
これはプログラマーに関連する質問よりもはるかに広い質問だと思いますが、一般的には、チームリーダーが好みがあると言った場合（小さいコードを好むように聞こえます）、続行するには、コードを好みに合わせます。または、同じように機能するチームに移動します。
一般的に、それを学習体験として扱います-彼らがあなたに何をしたいかを完全に説明してもらいます。
トピックのタイトルで、あなたはまだあなたが作成したものが「良い」と思うことを提案します。
最初にすべきことは、そうではないことを受け入れることです。私がそう言うからではなく、拒絶されたからです。他のみんなと同じように、あなたは学ぶ必要があります。他の回答で述べられているように、要件を取得します前開始します。彼らがあなたが作ったものを受け入れないときは、彼らに理由を尋ね、答えを受け入れ、それを修正して、もう一度配達してください。
私の最初の（そして現在の）仕事で人々が私に最初に教えてくれたことの1つは、特に最初は尋ねるです。誰かがあなたに何かをしてほしいと思ったら、もっと詳しく尋ねてください。実装のアイデアがあれば、遠慮なくshortを書いてください（誰もページを読みたくないのですが、通常は半分のページになります仕様を確認し、それで問題ないかどうかを確認します。あなたが考えたことが良ければ、彼らは感銘を受けるかもしれませんが、そうでなければ、あなたが説明する状況が起こる前に彼らはあなたに話すことができます。
extjs内のすべてを使用しているわけではないと確信しています。 extjsが長いファイルであり、ライブラリが多くの小さな関数で構成されている可能性が高いため、使用している関数を別のファイルに入れて、新しいソリューションで上司に戻るという言い訳がある場合（小さなファイルを使用します）。彼らの言い訳は意味がありません。
あなたが何かをするより良い方法があると思うなら、それを証明してください。ソリューションが何らかの形で優れているという確固たる証拠を作成します。これは、ロード時間の短縮、実行時のパフォーマンス、凝集性の向上、結合の低下、または任意の数のメトリックである可能性があります。チームや会社にとって重要な指標を調べて、説得力のある議論を行うものを把握することをお勧めします。それが何であれ、実験を考え出し、いくつかのデータを作成します。そして、それがあなたが間違っていることになった場合は、それを認め、経験から学びましょう。
次回は、次のことを検討してください。
- 何をしたいのか、どのモジュールを使用するのか、どのような外部依存関係が必要なのかを概説した設計提案を作成します。
- それが「見栄え」になったら、より詳細なデザインを書きます。
- それが「先に進む」（「先に進む」は「見栄えがする」よりも強い）が与えられたら、アプリケーションを作成し、プロセスを通じてフィードバックを求めます。
これにより、多くの時間を投資する前にフィードバックを得る十分な機会が得られます。それはあなたが彼らが承認しない道を進む前にあなたの先輩にガイダンスを提供する機会を与えます。また、「実際には、これはより良いでしょう...」と「もうこれは必要ありません、ごめんなさい...」に行く機会がある複数のポイントを提供します。
さて、jsファイルのサイズだけが問題になる場合は、どういうわけかそれを少し取り除いて小さくして、それによって彼らを幸せにすることができるかどうかを確認します。または、読み込み時間が問題ないことを人々が確認する実際のテストケースを作成します。その後、戻ってきて「ちなみに...私もこれとその機能を利用できます...それはとても多くのKBを必要とします」と言うことができます
受け入れられないソリューションに取り組む時間を無駄にする前に、最大ファイルサイズを尋ね、その要件を満たすことができる場合は、ソリューションを受け入れますか。
これはあなたにとって初めてですか、それとも拒否されたプロジェクトに取り組むことを許可する習慣がありますか？
残念ながら、あなたが心を読むことができるまで、それはおそらく悪化するでしょう。
私はいくつかのプロジェクトを作成しましたが、終了後にクライアントによって拒否されました。気分が悪くなりましたが、何もすることがなかったので、経験から学び、頭を高く上げ、自分を信頼し、新しいプロジェクトに取り掛かることが最善の方法です。