コードの「建設的な」批判はどの時点で役に立たなくなりますか？

私は最近、ジュニア開発者として始めました。チームで最も経験の浅い人の1人であると同時に、私は女性でもあります。男性が支配的な環境で働くことには、あらゆる種類の課題が伴います。私は自分の仕事に対して不当な教訓的な批判をしすぎているように感じるので、最近問題を抱えています。最近の出来事の例を挙げましょう。

チームリーダーは忙しくて、私が作ったいくつかのブランチをプッシュすることができなかったため、週末まで彼らに連絡しませんでした。私は自分のメールをチェックしましたが、実際には作業を行うつもりはありませんでした。変数名に基づいて2つのブランチが拒否され、エラーメッセージがわかりやすくなり、いくつかの値が構成ファイルに移動しました。

これに基づいてブランチを拒否することは有用ではないと思います。週末に多くの人が働いていましたが、私が働くとは言いませんでした。事実上、変更を行って再送信する時間がなかったため、一部の人はおそらくブロックされました。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントにとって透過的なものに基づいてコードを完全に拒否することは役に立たないと思われます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこの種のことを処理する必要があるようです。

今、私はいくつかの環境ではこれが標準であることがわかります。しかし、批判は平等に分配されているようには見えず、それが私の次の問題につながるものです。これらの問題のほとんどの原因は、私が誰か他の人が書いたコードベースにいて、最小限の侵入を試みているという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は「他人を真似しないで、正しいことをしてください」と率直に言われました。これはおそらく私が言われたかもしれない最も有用なものです。すでにチェックインされているコードが受け入れられない場合、何が正しいか、何が間違っているかをどのように伝えるのですか？混乱の原因が基礎となるコードに由来するものであった場合、私はそうは思わない

私はこの状況で本当に選び抜かれ、イライラしていると感じています。期待される標準に従うことについてはずっと良くなったし、たとえば、以前は行方不明だったエラーチェックを追加するためにコードの一部をリファクタリングするとき、私はそうしなかったと言われただけでイライラするエラーを十分に冗長にします（これに基づいてブランチは拒否されました）。そもそも追加したことがない場合はどうなりますか？それがとても間違っていた場合、どのようにして最初にコードに入りましたか？だからこそ、私はあまりにもひたむきだと感じています。私は常にこの既存の問題のあるコードにぶつかって、模倣したりリファクタリングしたりしています。私がそれを模倣するとき、それは「間違っている」。そして、それをリファクタリングするなら、私は十分なことをしないことを恐れる（そして、私がずっと行くなら、バグを導入するなど）。繰り返しますが、これがこのような問題である場合、コードがコードベースにどのように侵入するかわかりませんが、

とにかく、どうすればこれに対処できますか？私は女性だとトップで言ったことを覚えておいてください、そして、これらの人は他の人のコードをレビューしているとき、通常は礼儀について心配する必要はないと確信しています、そしてそれは私に生産性を低下させています。私はそれについて上司に話したら、彼は私が環境などを扱うことができないと思うだろうと心配しています。

あなたが女性として選ばれている可能性はありますが、あなたがジュニア開発者であり、仕事に慣れていない可能性もあります。

エラーチェックと表現力豊かなメッセージは重要です。コードに何かを追加する場合は、それがチームの標準に合っていることを確認してください。同様に、他の人のコードを変更する場合は、可能な限り改善するようにしてください。全体を書き直さないでください。しかし、あなたが見つけたよりも少しきれいにしておくようにしてください。

チームが従うコーディング標準の書面バージョンはありますか？そうでない場合は、すべて書き留めておくことをお勧めします。あなたが犯した間違いを書き留めて、チェックリストにまとめ、レビューのために変更を送信する前に参照できるようにすることで、努力の先頭に立つことができます。副作用として、その書面による標準を使用して、矛盾する場合は将来の拒否をアピールできます。

あなたとチームリーダーの間に理解不足があるかもしれません。あなたが彼と1対1の会議を依頼し、あなたが改善するために何ができるかを議論することはあなたにとって役に立つかもしれません。「やるべきことのニュアンスがまだ足りないように感じます。ジュニア開発者として成長し、改善したいと思っています。そこに着くのを手伝ってもらえますか？」そして何が起こるかを見てください。

このようなものを少し個人的に取っているようです。しないでください。この種のことは常に起こります。

チェックインを拒否する理由（変数の命名、コメントの品質、構成の場所）は、私にはかなり標準的なようです。

それのタイミングはあなたのチームリーダーの決定であり、私があなただったら心配しません。週末に誰かがブロックされた場合、チームリーダーはチェックインを許可し、後で修正するよう依頼することができます。他の開発者をブロックする可能性があるにもかかわらず、彼がそれをキックバックすることが適切であると感じた場合、それは彼の責任です。

チームリーダーが他の人を真似せずに正しいことをするように言っているのは、コードベースを改善するためのイニシアチブを与えようとしているようです。それは良い兆候です。彼はあなたにあなたの判断を使うと信じているので、先に進み、あなたが正しいと知っていることをしてください。それは、他のすべての人のコードを変更しなければならないという意味ではありませんが、あなたが書いたコードの品質に責任を持つべきであることを意味します。

他の回答への追加：

主任開発者として、私は通常、ジュニア開発者の方が好きです。なぜなら、彼らは数年働いている人たちよりもずっと柔軟だからです。（私のplplスキルはそれほど良くありません...まだ。）

しばらく働いていて（まともな給料を稼いで）、コードのレベルに満足している（品質は改善できても）人を変えるのは非常に難しいです。あなたが彼らをより良い/偉大なプログラマになるように導こうとしても、彼らは気にしません。彼らはコード工場で働いて幸せです。

あなたのような新しい人、OTOHは、通常、ガイダンスを求め、何が正しいかを知りたいと切望しています。また、彼らは報酬を吸収し、より良い方法に変更することができます。それらは他の方法で設定されていません。

これらのアドバイスを心に留めて、日常生活の一部にすると、すぐに既存のコードベースの多くより優れたコードを書くことになります。

そう ...

..何かをする可能性があるからといって、より多くのフィードバックを得ている可能性があります。:)

なぜなら、あなたはジュニア開発者だからです。

あなたの説明から、あなたはチームリーダーがそれを認識しているので、あなたは標準に従わなかったように聞こえます。

解決策は簡単です。

• それが標準であれば、それに従ってください。
• 標準を理解していない場合は、説明を求めてください。
• 標準または説明の解釈がチームリーダーのものと異なる場合は、説明を求めてください

それから戦いをしないでください。チームを「間違った」リーダーにしようとすると、勝ったとしても負けます。適切なレッスンを学び、成長し続けます。

著者のメモ

何年か後; この状況をより正確に反映するように編集しました。これらの状況でニュアンスについてより多くを学んでいるので、答えにもっとニュアンスを入れています。「黒か白」の答えを主張するのは簡単ですが、私たちは皆、それがそれほど単純ではないことを知っています。私の答えはそれを反映しています。

あなたが説明したことから。あなたが経験している行動はあなたの性別とは何の関係もないようです。それは、あなたが性別に関連した治療を受けていないということではありません（あなたがそうでないことを願っています）。

私がチームリーダーだったとき、私は皆を平等に扱いました。性別のために誰かをひどく扱うための技術の余地はありません。それがあなたに起こっている場合、私はそれをどのように処理するのか分からない。

チームリーダーが男性と女性を等しく扱うことを信頼することが重要です。彼がそうでない証拠がある場合、古い格言が当てはまります：あなたの環境を変えるか、あなたの環境を変える。

同様に、私は彼が性別を尊重せずに平等にすべての人を扱うことを意味します。彼が彼の仕事を正しくしているなら、あなたは彼が他の誰かを批判するのを見るべきではありません。そして彼らは彼があなたを批判するのを見るべきではありません。他の人の前で、プライベートに行動を修正する前に最後の5分間を費やしただけでも、チームリーダーが自信を示すことは非常に重要です。

次に、提起した問題について説明します。

彼が設定した基準を満たしていないコードをチェックインしたため、彼はあなたのブランチを拒否しました。私が彼の靴にいたなら、私は同じことを同じ方法でやったことはなかったでしょうが、私の部下（奇妙な言葉;私はリーダーを彼らの人々の「優れた」とは思わないためリード;しかし、それは状況を正確に（適切にではなく）記述します）正しいことは何かを知っています。彼らが標準が何であるかを知らないなら、それはリーダーとしての私のせいです。それを修正するのは私次第です。この場合、あなたは間違いを犯したかもしれませんが、実際に起こったという事実は、あなたが1）正しいことを何も言わなかったか、2）適切に指導されなかったことを意味します。どちらもあなたのせいではありません。

プログラマーになるための最も重要な部分の1つは、作業するコードベースが多くの異なる人々によって保守可能でなければならないことを認識することです。読みにくいコードの問題を修正するのに時間がかかるので、コードを読むことができないことを損なう可変のメスサップやその他のものは、顧客には見えません。

チームがコーディングガイドラインを作成している場合は、それらに従ってください。そうでない場合は、言語に何らかのコミュニティ規約が必要です（.NETおよびC＃の場合、Microsoftには多くの企業が従う標準があります）。

コーディングガイドラインがどこにあるかをチームリーダーに確認して、それらに従うようにしてください。他の2人の開発者がガイドラインに一貫して従わなかった場合、会議に2つのチェックインを行います。そうしないと、他の開発者も問題を抱えているように見えることを指摘できます。それらのガイドライン。

彼があなたを公正に扱っているなら、彼はこれを見るでしょう、そして、これはするべきことの彼のリストの一番上にあるべきです。もし彼があなたを公平に扱っていないなら、それが起こり続けるならあなたは弾薬を持っています。

「後で行きます」と言うのは悪いことです。後で起こることはありません。時間をかけて正しく実行してください。プログラミングの後半はありません。

あなたがジュニア開発者であるとき、それは難しいです。実行するようにプレッシャーを感じ、多くの人があなたを見ていて、あなたが犯すすべての間違いは、ソース管理においてあなたの名前に永遠に結び付けられています。

あなたの投稿のどこにも、周りの人がどのように扱われるかについて言及していません。あなたは「女性」だから、「シングル」になっていると「感じる」ことを繰り返します。

性別を問わず、あなたはジュニアプログラマのように扱われていると思います。それは平等の意味なので、感謝する必要があります。また、5分間の小さなコードの見た目の変更について、大騒ぎをしているのではないかと感じています。

あなたの投稿のどこにも、あなたが週末にこれらのことをするように命じられたことを言及していません。月曜日の朝に修正プログラムをチェックインしても問題ありません。

あなたのチームリーダーは私の好みに対して少しつまらないかもしれませんが、あなたの投稿からは、彼または彼女のリクエストに何の問題もありません。

性別カードのプレイを何もしないでください。これは無礼であり、男女共同参画の概念を損なうものだと思います。

これに基づいてブランチを拒否することは有用ではないと思います。週末に多くの人が働いていましたが、私が働くとは言いませんでした。事実上、変更を行って再送信する時間がなかったため、一部の人はおそらくブロックされました。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントにとって透過的なものに基づいてコードを完全に拒否することは役に立たないと思われます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこの種のことを処理する必要があるようです。

あなたのコードを見たことがなく、プロジェクトのスケジュールについて何も知らない誰かとして有用なことを言うのは難しいです。しかし、あなたのリードが責任を持って行動し、良い仕事をすれば、他の人が実際にブロックされず、スプリントが遅れないことを彼は知っています。だから、それを心配しないでください。おそらく、コミットへの影響を過大評価しています。それ以外の場合：プロジェクトがタイムクリティカルであり、すべてのテストに合格した場合、コードを拒否するにはあまりにもうるさいため、リリース後すぐに修正できます。

動作させる正しく動作させる高速にする

だから、あなたのリードがあなたのコミットを拒否する決定を下した場合、彼は専門家として彼が何をしていたかを知っているべきです。

今、私はいくつかの環境ではこれが標準であることがわかります。しかし、批判は平等に分配されているようには見えず、それが私の次の問題につながるものです。これらの問題のほとんどの原因は、私が誰か他の人が書いたコードベースにいて、最小限の侵入を試みているという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は「他人を真似しないで、正しいことをしてください」と率直に言われました。

ジュニアとして、企業のコードベースを見つけるのは困難です。

ベスト：文書化されたコーディング標準があります-そして、あなたはそれらを理解することを願っています。

通常：ある文書化されていないコーディング標準は-あなたは経由で学ばなければならトライアルとエラーまたは私が言うべきコミットと_reject？これは多くの場合（あなたの場合のように）苦痛です。これはコードの品質の点で危険である場合があり、カーゴカルトプログラミングにつながる可能性があります。変数の命名を模倣するだけでなく、誠実にコードベースから構造とパターンをコピーして貼り付けるため、そのようにする必要があります。そんなことしたらダメ！既存の変数の命名をまねてはいけません。

クリーンコードに固執します。それは良い習慣であり、防御しやすい立場を与えます。読み取り可能、テスト可能、および保守可能なコードであれば、ほとんどの議論に勝ちました。

そして、これは別の（最後の）アドバイスにつながります：ボーイスカウトのルールに従ってください！

常にコードベースを以前よりも良い状態に保ちます。作業している周囲のコードが厄介な場合でも、コードをきれいにしてください。時間があれば周囲を修正してください。

同僚の性格のさまざまなニュアンスを学ぶのに少し時間をかけてください。私の経験では、同僚の癖を回避すれば、不合理、不必要、一貫性のない、または単なる価値のない批判を避けることができます。

たとえば、一部の同僚は月曜日に二日酔いになります。彼らは非常にいらいらし、特定のコードブランチやコミットを拒否することに過度に熱心であるかもしれません。このような人と仕事をする必要がある場合は、月曜日にコードをコミットしないようにしてください。

一方、二日酔いの同僚は、エラーメッセージの冗長性を気にするのが面倒かもしれません...月曜日の朝は、コードをコミットするのに最適な時期かもしれません:-p

オフィスや職場での性格の癖は文字通り無限です。誰がいつ回避すべきかを学ぶことができれば幸いです。また、自分自身にあまり厳しくしないでください:-)いつでも辞めて別の仕事を見つけることができます！

特定の規則に従わないという理由でコードが拒否される環境で働いたことはありません。もし私があなたの立場にあったなら、私は正しい決定を下すためにより力を与えられ、コードではなく顧客が第一の焦点である場所で雇用を探したいと思うでしょう。

きれいなコードと標準は重要ではないと言っているわけではありませんが、非技術者、顧客、または幹部がこれまで目にすることのないもののスペルミスが原因で、顧客と製品のタイムラインが損なわれるべきではありません。

そうは言っても、何らかの理由で期待が明確でない環境で作業している、または要件を完全に理解していないように思えます。

状況に関係なく、管理し、明確な質問をするのはあなた次第です。まだプロアクティブでない場合。チームメンバーとチームリーダーは、チェックインのルールを明確にするために質問することであなたをより尊敬するでしょう。また、あなたとチームリーダーが代わりに何をすべきかを議論する「アフターアクションレビュー」を求めることもできます。特定のアクションを実行するタイミングと実行しないタイミングに関する違いを判断できます。

あなたは新しいので、時間を与えて、ハードルを乗り越え、経験、コミュニケーション、標準を学ぶことでこれらの問題を解決できるかどうかを確認することをお勧めします。ただし、数か月後も状況が変わらず、環境が依然としてあいまいさに悩まされている場合は、別の会社に就職する時が来るかもしれません。

すべての組織がこの過酷な仕事をしているわけではなく、あなたの性格、スタイル、およびコミュニケーションの要件により適した他の作業環境を見つけることができます。