上司に彼のプログラミングスタイルが本当に悪いことを伝える方法は？
私は学生です。暇なときに、大企業でJava開発者として働いています。仕事はいいですが、問題は、上司が非常に奇妙なコードを書いていることです。私はそうではありません。文句を言いたくないが、いくつかの問題は私の意見では本当に奇妙です。例えば：
彼はブール値を知りません。すべてのブール条件は「YesOrNo」と呼ばれる文字列であり、次の条件で使用されます（YesOrNo == "Yes"）
メソッド名やéõôやèのような変数には非常に奇妙な文字がたくさんあります
すべてのループは、for（;;）のスタイルの無限ループです。次に、ループの最後で条件がテストされ、条件が満たされている場合は中断します。と呼ばれます。
彼は私のボスであり、どうやって、何をすべきかを決めるので、これは良い習慣ではないと思うかどうか彼に言うべきかどうかわかりません。一方、彼の例のいくつかは本当に非常に奇妙です。
対処方法のヒントはありますか？そして、これは悪いスタイルだと思う私だけですか？
彼にコードを説明してもらう
Xがそのようにプログラミングされたのを見たことがないことを彼に伝え、なぜXがそのようにコーディングされているのかを尋ねてください。コーディングの方法を示し、なぜそのようにするのかを説明します（ベストプラクティス、パフォーマンスの向上、エラーの可能性の低下、他のプログラマによる読み取り/保守の容易さなど）。
必ず事前にすべての議論を準備し、彼の方法が最悪である理由ではなく、なぜあなたの方法が最も優れているのかに焦点を当ててください。その後、彼がまだ自分の方法をサポートしているかどうかを確認します。
改善の余地がある場合は、コーディング方法を変更する可能性があります。彼があなたよりも彼のコーディングスタイルを使用することを好む場合、あなたは彼の意見を変える可能性は低いです。
自動静的分析およびリンターやバグファインダーなどのスタイルチェックツール（使用する言語にかかわらず）の使用を促進します。会社の全員がそれらを使用し始めた場合（たとえば、チェックイン前に義務付けられている場合）、彼は特定されません。
私がこれを提案している理由はそれです：
1）人々は一般に、同僚や部下よりも、自動化されたツールからの非難に向いています。
2）これらのツールは、貧弱なスタイルと見なすことができる多くの問題をカバーしています。
3）ツールに組み込まれているものを超えて、彼の悪いスタイルの背後にあるルールを調整することができます。たとえば、特定のスタイルの変数を適用します。
4）一部の人々は、自分のコードがあまり良くないことに気づき、実際にはリンターでカバーされていないものにも注意を向け始めます。
かなり尊敬されている会社（私の雇用主など）が、チェックイン前にリントチェックを強制しています。悪い見方は技術的な負債であるとの見方です。 「ええと、XとYとZがそれをしているのなら、それはおそらく良い考えです」を常に使用できます。
私はあなたは間違いなく彼にそのようなものを何も言わないでください。そのような発言は、彼に防御反応を簡単に引き起こす可能性があり、それは彼が学ぶ可能性をほぼ確実に締め切り、あなたに問題を引き起こす可能性さえあります。
代わりに、コーディングスタイルとイディオムの問題について気軽にディスカッションする機会を探して（さらには作成してみてください）、彼が知っている "ベストプラクティス"について言及してください。もちろん、最初に、提案するものが実際に広く知られ、受け入れられているベストプラクティスであることを確認する必要があります。
また、他のチームメンバーと同じ問題について話し合うようにしてください。 コーディングスタイルと品質について、チーム内の（口頭または非口頭）「コンセンサス」を理解することが重要です（-===-）。 （他の誰もがクリーンで高品質なコードを書いている場合、グループの残りのメンバーが誇らしげにFORTRANプログラムを任意の言語で作成している実際のプログラマーで構成されている場合とは大きく異なります。）彼らはまた、プロジェクトの歴史的背景についてより多くを伝えるかもしれません。上司のコーディングスタイル。
もう1つの方法は、より良いプログラマーになるために必要だと感じているため、彼に Effective Java を注文するよう依頼することです。 （まだ読んでいない場合でも、実際にそれを必要とします。）次に、この本のすばらしい解決策と実践について彼と話すことができます。
彼が自分自身を向上させることにオープンであるなら、彼はあなたの提案（そして本）をピックアップします。そうでない場合は、顔を失うことなく、あなたの関係に負担をかけることなく後退できます。
あなたの上司がクールな人なら、単に彼に尋ねてください：「おい、WTF？」
あなたが「私のほうがいい」と思うすべての例では、誰かにあなたがそう思っていると決して言ってはいけません。
繰り返しますが、表示しないでください。
行動について、大声で、言葉について言っているのは本当です。
あなたの上司は正確にどのような地位を占めていますか？彼は開発者、技術リーダーですか？会社には他に何人の開発者がいますか？会社にはコーディング標準とコードレビューがありますか？
上司に彼（私見）の悪い習慣を変えさせることはまずありませんが、同僚グループや会社の標準を使って彼に影響を与えることができるかもしれません。彼のコードdoesが標準に従い、ピアがすべて同じである場合、オプションは制限されます。
これが私の推奨です：
- あなたのケースをよく述べてください。
- あなたのマネージャーがあなたの見解を受け入れていない*場合、あなたが正しいと感じているなら、より環境に配慮した牧草地を求め、言い訳をしないでください。
次の3つの理由により、緑の多い牧草地を探すことをお勧めします。
- 長い目で見れば、悪い習慣を永続させることはプログラマーのキャリアにとって有害です。悪い習慣の永続化は悪い習慣を生みます。
- 別の視点を受け入れないプログラミングショップは、想像力を抑えます。
- あなたが悪い習慣を永続させており、チームが別の見方を受け入れていないことを知っている場合、あなたの士気は低下し、これはあなたの人生を悲惨なものにします。したがって、できるだけ早く残してください。
*重要な区別：誰かがあなたの見解を受け入れてくれることを期待することは、誰かがあなたにyieldを期待することと同じではありません視点。私は常に自分の視点を考慮してくれる人に感謝していますが、十分な理由なしに私の視点にやさしくて利回りである人にはほとんど敬意を払っていません。そうする証拠。
アクションは言葉よりも大声で話す：
別のアプローチ：
- 例としてleadにする必要があります。
- あなたがしているプロジェクトが、あなたができるbestであることを確認してください。
- パフォーマンス、バグの減少などの点でExcelにする必要があります。
- あなたのアプローチとスタイルが上司より優れていることを実証できたら、彼/彼女が非常に傲慢でない限り、その人は当然、最も効果的に機能するものなら何でも従うと思います。
彼が何か悪いことをしているのを見たら、私は彼に少量のポインタを与えるだけです。
「うーん、そのためのこのアプローチを確認してください。{彼の画面を指して}、私は何とか何とか何とかしてこの方法でそれをするのが好きです。」
これを1日おきに1回だけ行ってください。彼があなたの提案を受け入れない場合、それを再び言及することは決してありません（数週間）。いくつかは固執します。そして、彼は徐々に良くなるでしょう。
上司に、あなたが教えてきた別の方法と比較してもらいます。彼には正当な理由があるかもしれません。あなたが尋ねるまで、あなたは知ることはできません。彼女が維持しようとしている古いコーディング標準があるか、彼女は気にしないかもしれません。上司が自動的に間違っていると思う兆候を与えないでください。ああ、それを個人的にやる。これはあなたの教育目的のためです。
場合によります。レビューするコードが新しいコードである場合は、「スピードアップ」に役立ち、学習に興味があることを示しているため、コードレビューを依頼してください。上司は、あなたが正しいことをしようとしていることを彼に示すので、これが役立つと思うかもしれません。これが偶然偶然見つけた古いコードであり、それを維持することを余儀なくされている場合は、遅いリファクタリングを行うようにしてください。手元のタスクを完了しながら、あちこちで型宣言。ここでの問題は、文字列YesOrNoがMaybeなどの他の値をとることがあるため、注意しないとコードが壊れる可能性があります。
私が最初にすることは、彼が批評家にどう反応するかを知ることです。私が上司になるとしたら、まあ私は何も悪いことはしないでしょうね。 -私は、私の顔の中で、一度に、しかし敬意を表して、伝えられることを望んでいます。気質や文化によって上司は違うかもしれません。
しかし、それらのほとんどはいくつかの尊敬を必要とします。あなたが彼を尊重していることを示す良い方法は、以前に提案されたことです：あなたはあなたの意味を説明しますが、彼に決定を任せます：「これは私の理由ですが、おそらく私は何かを見ました。私の説明の後：」
if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null
「あなたは何を提案しますか？」
そして、あなたは前にメタ質問をするかもしれません：「Xさん、私がコードで何かを見つけた場合、それは一般に改善可能なプラクティスと報告されています-どのようにそれをあなたに報告するべきですか？一度に、または段階的に？または私は絶対に言及しないでください？黙ってコードを改善しますか？」
それは、私がどの言葉遣いを選ぶか、そしてどのアプローチをするかという私の関係に依存するでしょう。
あなたの上司はプログラミングの方法を知りませんし、彼はそれをすべきではありません。私の経験から、ボスと呼ばれる人もあなたよりも経験が豊富であると仮定することは誤りです。彼は他の点で優れているかもしれませんが、管理と階層のポイントは、最も適切な人に物事を委任することです。上司とは、起業する機会があった人、または最終的にはプログラミングスキルではなく、管理スキルのために管理職に就いた人です。
ガソリン発電機に接続しているときにコンピューターをインストールしたふりをした上司がいたのは、マシンがまだ保護されていないときにハッカーが電気ネットワーク経由で侵入できるとのことでした。私はすぐにやめました。当時、私は貴重な教訓を学びました。上司はいつも正しいとは限らず、時には辞めることだけが貴重な対応です。
したがって、あなたのケースに戻るために、別の仕事（そう、危機、yadda yadda ...私が知っている）を探すことだけが最善の治療法であるかもしれないケースがあるかもしれません。貴重な時間を無駄にしないでください。
同様のことを達成する評判の良いサイト/場所/本などからの短いサンプルコードを彼に見せてください。
私は上司の過ちを見つけることができない業界に住んでいます。だから、私は彼に必要な変更と考えられる理由についてあなたに提案するよりも、コードにエラーが表示されるケースを生成して彼にエラーを表示させるでしょう。エラーのD]。開発者は、良いか悪いかに関わらず、バグを見るまで間違いを受け入れません。
私はかつて、ボスのスタイルに大きな問題を抱えていました。
これには2つの問題があります。まず、彼の顔にそれを言ったことはないと思いますが、彼が知っていたと思います。彼はプロであり続けた、そうではなかった、IOW。
第二に、彼がしたことには理由があり、私の「これが正しい道」である「解決策」がどれほど複雑で厄介なものであるかを理解するのに時間がかかりました。
質問の3つのポイントのうち、発音区別符号は誰にとっても奇妙なものではありません。私はそれをforループで使用しませんが、Cファミリーにイライラします...私のインデントスタイルなので、多分それがどこから来たかを見ることができます。
ブールの事柄でさえ、他の言語から持ち込まれた習慣に関して説明があるかもしれません（もちろん正当化されません）。
これはうまくいくと思います-
- マネージャーに、間違いがないコードをレビューするよう依頼してください。
- 次に、マネージャーから「彼の」やり方でやってみないかと尋ねられたかどうかを確認します。
- 彼がこの質問をした場合、なぜそれがより良い方法であるかを彼に尋ねることができます。
このようにして、あなたは彼が彼のやり方が正しいと思う理由を知るようになります。
以前行ったことがある。私はまっすぐUniから出て、1年ほど男性と働いた後、私はプログラミングについて彼よりもずっと知っていることに気付きましたが、それは彼のビジネスであり、彼はショットを呼びました-そして彼を怒らせたくありませんでしたとにかく！私はそれを回避する最善の方法は、私たち全員が固執しなければならない会社全体で共通のコーディング規則を持つことの利点を議論し、彼がどのように反応するかを確認することであると決定しました。驚いたことに、彼はそれを素晴らしいアイデアだと思って、規格のリストを作成するように私に頼みました。それを私たちが一緒にレビューし、最終決定などしました。
ここで重要なことは、あなたが彼のように単に誤りやすいということ、そして彼のやり方のいくつかが奇妙で間違っているからといって、それらのいくつかはあなたのものよりも優れているということです。
私の個人的な経験から、しかしそれはうまくいきませんでした。標準とコーディング規約の優れたドキュメントの調査とコンパイルに2日を費やしましたが、彼はすでに自分のやり方に慣れており、コーディング規約にメリットがあるとは思いませんでした。迅速かつ簡単に、コストを削減します。
結局、開発をもう少し深刻にした場所を見つけるために去りました。私がコーディング規約で行った調査が今日に本当に役立つので、それはすべて悪いことではありませんでした。