コードの「建設的な」批判が役に立たなくなるのはどの時点ですか？
私は最近ジュニア開発者として始めました。私はチームで最も経験の浅い人の1人であるだけでなく、女性でもあります。この女性には、男性が主導する環境で働くためのさまざまな課題があります。私は最近、仕事に対して不当な根拠のない批判を受けているように感じているため、問題を抱えています。最近起こったことの例を挙げましょう。
チームリードは忙しかったので、私が作成したいくつかのブランチではプッシュできませんでした。そのため、彼は週末までそれらに到達しませんでした。私はメールをチェックしましたが、実際には何もする意味ではありませんでした。変数名に基づいて2つのブランチが拒否され、エラーメッセージがわかりやすくなり、一部の値が構成ファイルに移動されました。
これに基づいて私のブランチを拒否することは役に立たないと思います。週末はたくさんの人が働いていて、私が働くことになるとは決して言っていませんでした。変更を加えて再送信する時間がなかったため、事実上、一部の人々がブロックされた可能性があります。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントには透過的なものに基づいてコードを完全に拒否することは役に立たないように思えます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこのようなことを処理する必要があるようです。
現在、一部の環境では、これが標準であることがわかります。しかし、批判は均等に分散されていないようです。それが私の次の問題の原因です。これらの問題のほとんどの根拠は、私が他の誰かが書いたコードベースの中にいて、最小限の侵襲性を目指していたという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は率直に言われました、「他人をまねるのではなく、正しいことをしてください」。これはおそらく、私に言われたはずの最も役に立たないことです。すでにチェックインされているコードが受け入れられない場合、何が正しくて何が間違っているのかをどのように判断すればよいですか？混乱の原因が基礎となるコードにある場合、誰かが書いたファイル全体をリファクタリングして（そして完全にうまく機能し）、新しいバグなどが発生する可能性があるのは私の責任ではないと私は思います。
私はこの状況で本当に選び抜かれ、不満を感じています。期待される標準に従うことについてはずっと良くなりました。たとえば、以前欠落していたエラーチェックを追加するためにコードの一部をリファクタリングすると、私はそうしなかったとだけ言われました。エラーを十分に冗長にします（これに基づいてブランチは拒否されました）。最初から追加したことがない場合はどうなりますか？それがそれほど間違っていた場合、それはどのようにしてコードに入りましたか？これが、私が非常に独占されていると感じる理由です。私は常に、この既存の問題のあるコードに出くわします。私がそれを模倣すると、それは「間違った」ものになり、それをリファクタリングすると、十分に機能しなかったと非難されます（そして、完全に進んだ場合、バグを導入するなど）。繰り返しになりますが、これがそのような問題である場合、コードがコードベースにどのように取り込まれるのか、そしてどうやら彼らのコードをレビューされなかったと思われる誰かによって書かれたときになぜそれが私の責任になるのか、私にはわかりません。
とにかく、どうすればこれに対処できますか？冒頭で私は女性だと言ったことを思い出してください。他の人のコードをレビューしているとき、これらの人は無礼を心配する必要は通常ありませんが、正直なところ、それは私にはうまくいきません、それが原因で生産性が低下しています。上司に相談すると、環境に対応できないなどと心配になります。
あなたは女性として選ばれている可能性がありますが、あなたは単にジュニア開発者であり、仕事に慣れていない可能性もあります。
エラーチェックと表現力豊かなメッセージは重要です。コードに何かを追加する場合は、それが正しく、チームの標準に準拠していることを確認してください。同様に、他の誰かのコードを変更している場合は、可能な限り改善するようにしてください。全体を書き直すのではなく、見つけたよりも少しクリーンなままにしてください。
チームが従うコーディング標準の書面バージョンはありますか？そうでない場合は、それをすべて書き留めておくことをお勧めします。間違いを書き留め、チェックリストにまとめて、変更内容をレビューのために送信する前に参照できるようにすることで、作業の先頭に立つことができます。副作用として、その書面による基準を使用して、矛盾する場合は将来の拒否をアピールできます。
あなたとチームリーダーの間には理解が不足しているようです。彼との1対1のミーティングを依頼し、改善のために何ができるかについて話し合うと役立つでしょう。 「私がやるべきことの多くのニュアンスがまだ足りないようです。ジュニアデベロッパーとして成長し、改善したいのですが、そこにたどり着く手助けをしていただけますか？」そして何が起こるかを見てください。
個人的にはあまりにも多すぎるようです。しないでください。この種のことは常に起こります。
チェックインを拒否する理由（変数の名前、コメントの品質、構成の場所）は、私にはかなり標準的なようです。
そのタイミングはあなたのチームリーダーの決定でした、そして私があなたであったとしても私はそれを心配しませんでした。週末に誰かがブロックされた場合、チームリーダーはチェックインを許可し、後で修正するように依頼することができます。他の開発者をブロックする可能性があるとしても、彼がそれを元に戻すことが適切であると感じた場合、それは彼の責任です。
他のチームを模倣するのではなく、正しいことをするように指示するチームリードについては、コードベースを改善するためのイニシアチブを提供しようとしているようです。それは良い兆候です。彼はあなたがyour判断を使用することを信頼しているので、先に進んであなたが正しいと知っていることをしてください。それはあなたが他の人のコードを変更しなければならないという意味ではありませんが、あなたが書くコードの品質に責任を持つべきだという意味です。
他の回答への追加：
リード開発者として、私は通常、ジュニア開発者に対してよりうるさいです。なぜなら、彼らは数年働いてきた人々よりもはるかに順応性があるからです。 （私のpplスキルはそれほど良くありません...）
しばらく働いて（そしてまともな給料を稼いで）いる人にコードのレベルに満足している人を変更することは非常に困難です（品質は向上しますが）。あなたが彼らをより良い/偉大なプログラマーになるように導こうと試みても、それらの人たちは気にしない。彼らはコードファクトリーでの作業に満足しています。
あなたと同じように、OTOHのような新しい人たちは、通常、ガイダンスと何が適切で何が正しくないかを知りたいと切望しています。また、彼らはフィードバックを吸収し、より良い方法に変更することができます。それらは他の方法で設定されていません。
これらのアドバイスを心に留めて日常生活の一部にすると、既存のコードベースの多くより優れたコードをすぐに作成できるようになります。
そう ...
..何かを成し遂げる可能性があるからといって、より多くのフィードバックを得ている可能性があります。 :)
なぜなら、あなたはジュニア開発者だからです。
あなたの説明から、あなたは標準に従っていなかったようですチームリーダーがそれを認識しているように。
解決策は簡単です：
- それが標準であれば、それに従ってください。
- 標準を理解していない場合は、説明を求めてください。
- 標準または指示の解釈がチームリーダーの解釈と異なる場合は、説明を求めます
それから戦いを作らないでください。チームを「間違った」リードにしようとすると、たとえ勝っても負けます。適切なレッスンを学び、成長し続けます。
著者のメモ
何年か後;これを編集して、状況に対する自分の気持ちをより正確に反映しました。私はこれらの状況でニュアンスについてさらに学習しているので、私の答えにより多くのニュアンスを入れています。 「黒または白」の答えを主張するのは簡単ですが、それがそれほど単純ではないことは誰でも知っています。私の答えはそれを反映しています。
あなたが説明したことから;あなたが経験している行動は、あなたの性別とは何の関係もないようです。それは、あなたがジェンダー関連の治療を経験していないと言っているのではありません（あなたが経験していないことを願っています）。
私がチームのリーダーだったとき、私は皆を平等に扱いました。性別のせいで誰かをひどく扱う技術はありません。それがあなたに起こっている場合、私はそれに対処する方法を知りません。
チームリードが男性と女性を平等に扱うことを信頼することが重要です。彼がそうでない証拠がある場合は、古いことわざが当てはまります：環境を変更するか、環境を変更してください。
同様に私は彼が性別を尊重することなくすべての人を平等に扱うことを意味します。彼が彼の仕事を正しくやっているなら、あなたは彼が他の誰かを批判するのを見るべきではありません。そして彼らは彼があなたを批判するのを見るべきではない。他の人の前で、チームリーダーがプライベートで行動を正す前に最後の5分間を費やしたとしても、チームリーダーが自信を示すことは非常に重要です。
次に、提起した問題について説明します。
彼が設定した基準を満たしていないコードをチェックインしたので、彼はブランチを拒否しました。私が彼の立場にあるなら、私は同じ方法で同じことをしなかったでしょうが、私は部下（奇妙な言葉;私がリーダーを彼らの人々より「優れている」とは考えていないのでリード;しかし、それは正確に（適切ではない）状況を説明します）正しいことを知っています。彼らが標準が何であるかを知らなければ、それはリーダーとしての私のせいです。それを修正するのは私次第です。この場合、あなたは間違いを犯したかもしれませんが、それが起こったという純粋な事実は、1）正しいことを何も言わなかったか、2）適切に指導されていなかったことを意味します。あなたのせいでもありません。
プログラマーであることの最も重要な部分の1つは、作業するコードベースが多くの異なる人々によって保守可能でなければならないことを認識することです。変数messupsや、コードを読み取ることができなくなるものは、顧客に対して透過的ではありません。読みにくい。
チームがコーディングガイドラインを作成している場合は、それに従ってください。そうでない場合は、言語に何らかのコミュニティ規約があるはずです（.NETおよびC＃の場合、 Microsoftには標準があります 多くの企業が従います）。
コーディングのガイドラインがどこにあるかをチームリーダーに尋ねて、コードのガイドラインを確実に守れるようにします。他の2人の開発者が一貫してガイドラインに従っていない会議に2回チェックインします。そのため、彼が何もない場合、他の開発者もそれに問題を抱えているようであり、誰もがそれらのガイドライン。
彼があなたを公平に扱っているなら、彼はこれを見て、これは彼のやるべきことのリストの一番上にあるはずです。もし彼があなたを公平に扱っていないのなら、それが起こり続けるならあなたは弾薬を持っています。
「後でやる」って言うのは悪い。後で起こることはありません。時間をかけて正しく実行してください。プログラミングの後半はありません。
あなたがジュニア開発者であるとき、それは難しいです。あなたは実行するようにプレッシャーを感じ、多くの人があなたを見ていて、あなたが犯すすべての間違いはソース管理におけるあなたの名前に永遠に結びついています。
あなたの投稿のどこにも、周りの他の人たちがどのように扱われるかについて言及していません。あなたはあなたが「女性」であるので、あなたはあなたがあなたが「シングルアウト」されていることを「感じる」ことを繰り返し続けます。
あなたは性別に関係なく、ジュニアプログラマーのように扱われていると思います。平等とは、それが何を意味するかということですから、感謝するべきです。私はまた、ToDoリストに入れて決してそれらに近づくのではなく、今要求されている小さな5分間のコードの美的変更を大騒ぎしていると感じています。
あなたの投稿のどこにも、週末にこれらのことをするように命じられたとは言いませんでした。月曜日の朝に修正をチェックインすることは完全に良いかもしれません。
あなたのチームリードは私の好みに少し慣れているかもしれませんが、あなたの投稿から、私は彼または彼女のリクエストに何の問題もないと思います。
無料で性別カードの再生を停止してください。これは品位を欠き、ジェンダー平等の概念を損なうと感じます。
これに基づいて私のブランチを拒否することは役に立たないと思います。週末はたくさんの人が働いていて、私が働くことになるとは決して言っていませんでした。変更を加えて再送信する時間がなかったため、事実上、一部の人々がブロックされた可能性があります。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントに対して透過的なものに基づいてコードを完全に拒否することは役に立たないように思えます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこのようなことを処理する必要があるようです。
あなたのコードを見ていないか、あなたのプロジェクトのスケジュールについて何かを知らない人として役立つものを言うのは難しいです。しかし、もしあなたのリードが責任を持って振る舞い、良い仕事をするなら、彼は知っています、他の人は実際にはブロックされておらず、スプリントが遅れることはありません。ですので、心配する必要はありません。 おそらくあなたはあなたのコミットへの影響を過大評価しています。それ以外の場合：プロジェクトがタイムクリティカルですべてのテストに合格する場合、コードを拒否するのはうるさすぎて、リリース後に瞬く間に修正される可能性があります。
Make It Work Make It Right Make It Fast
したがって、もしあなたのリードがあなたのコミットを拒否する決定をした場合、彼が知っておくべき専門家として、彼が何をしていたか。
現在、一部の環境では、これが標準であることがわかります。しかし、批判は均等に分散されていないようです。それが私の次の問題の原因です。これらの問題のほとんどの根拠は、私が他の誰かが書いたコードベースにいて、侵襲を最小限に抑えようとしているという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は率直に言われました、「他人をまねるのではなく、正しいことをしてください」。
ジュニアとしては、企業のコードベースに入る方法を見つけるのは困難です。
最良：文書化されたコーディング標準があります-そしてうまくいけば、それらを理解することを学ぶでしょう。
通常：文書化されていないコーディング標準があります-そして、トライアルとエラーまたはcommitと_rejectのどちらを言うべきですか？これはしばしば痛みを伴う（あなたの場合のように）。これは、コード品質に関して危険であり、 貨物カルトプログラミング につながる可能性がありますmimics変数の名前付けだけでなく、構造とパターンをコードベースから誠実にコピーして貼り付けることも、そのようにする必要があります。やめてください！既存の変数名を模倣しないでください。
Clean Code に固執します。それは良い習慣であり、ポジションを簡単に守ることができます。読みやすく、テスト可能で、保守可能なコードであれば、ほとんどの議論に勝ちました。
そして、これは別の（最後の）アドバイスにつながります： ボーイスカウトルール に従ってください！
コードベースは常に、以前よりも良い状態にしてください。作業している周囲のコードが厄介な場合でも、コードをクリーンにします。時間がある場合は、周囲を修正してください。
少し時間をかけて、同僚の性格のさまざまなニュアンスを学習してください。私の経験では、同僚の癖を回避すれば、非合理的、不必要、一貫性のない、またはまったく価値のない批判を避けることができます。
たとえば、一部の同僚は月曜日に二日酔いになるかもしれません。それらは非常にいらいらし、特定のコードブランチまたはコミットを拒否することに過度に熱心である場合があります。このような人と作業する必要がある場合は、月曜日にコードをコミットしないようにしてください。
その一方で、二日酔いの同僚はエラーメッセージの冗長性を気にするのにあまりにも難解であるかもしれません...したがって、月曜日の朝はあなたのコードをコミットするのに最適な時間かもしれません:-p
オフィスや職場の個性の癖は文字通り無限です。うまくいけば、誰がいつ避けるべきかを学ぶことができます。また、自分に負担をかけすぎないでください:-)いつでも辞めて別の仕事を見つけることができます。