コーディング標準に関するプロジェクトリーダーとの不一致[終了]

そのため、私は過去1年間、プロジェクトリーダーと共に新しいプロジェクトに取り組んでいます。

最初は、別のgitリポジトリにある独自のサブプロジェクトがありましたが、彼のコードとのやり取りはほとんどなかったので、コードのにおいは気にしませんでした。約6か月後、プロジェクトでより大きな役割を担っていたため、彼のコードの機能を維持および追加し始めました。

私は両方のサブプロジェクト（チームが成長しようとしています。彼はまだ私の上にいます）の主任開発者です。

1. 中括弧、大文字の関数、二重引用符の使用法（二重および単一の隠しロジック付き）、===を使用しない、巨大な関数を持つ巨大なクラスはありません。一番下の行は、より良いかもしれません。
2. 通知/警告をオフにするPHPのオプションへの依存。コードには、変数と配列キーの未使用の使用法がたくさんあります。変数はifの内部で定義されます。

上記の2つの問題に対する議論：

1. 人々にコーディングスタイルを強制したくない。
2. より短い/より効率的なコードに適した言語機能とみなされます。

いくつかのルールが必要であり、コードは防御的である必要があると思います。PHPStormのデフォルト設定をフォーマットに使用し、中括弧とコミュニティで受け入れられている命名規則を使用することを申し出ました。

私は両方のプロジェクトを切り離せないので、同じガイドラインを使用するように調整したいと思います。

私は間違っていますか？個人的な好みを課しますか？

自分の方が優れている理由（および彼を使用することで生じる大きな問題）について強力な主張をすることができれば、個人的な好みを課しているのではなく、成功のためにプロジェクトを設定しようとしています。

彼がなぜ彼の方が優れているのか、どのような問題があなたのできないことを防ぐことができるのかという強い主張をすることができれば、彼はあなたに勝ちました。

そこそこの上級管理職はその点でメリットを見ることができるはずですが、それらは開発者にとって簡単であるか「誰もがロボットのように働くことを強制したくない」かどうかではなく、彼らが気にする（そしてすべき）ポイントです馬鹿げたポイントですが、上級管理職への痛みポイントとしてそれを使用しないでください。彼らは、プロジェクトの継続的な安定性を気にする必要があります。

上記の私のコメントごとに：

彼がプロジェクトリーダーである場合、それは基本的に彼の呼び出しであることを暗示しているようです。

それが私の考えでした。あなたが標準を変えたいが、彼がそれに慣れていない場合、a）彼を乗り越える方法を見つけ、b）どこか他の場所で仕事をするか、c）彼をいらいらさせずにできることをしよう過度に。

彼を乗り越えることは、より良い基準があるべき理由を強く主張する場合にのみ機能します。

基本的に：

• あなたは彼のコーディングスタイルが好きではありません。それはあなたの権利です。
• 彼はそれがそうであるように大丈夫だと感じ、スタイルを調整するだけで時間を費やす日/週/より多くを過ごすことを見つけます。それは彼の権利です。

彼の靴に身を置きます。会社に多額の費用（給与）を支払うことに加えて、あなたの努力の利点は何ですか？彼はいつもとてもつまらないですか？彼は今やるべきより重要なことがあるとは思いませんか？

基本的に、あなたはあなたが生きることができる何らかの妥協を見つけなければなりません、さもなければあなたの関係は酸っぱくなります。彼とのコミュニケーション方法にも大きく依存します。最後に、あなたが彼に物事を求めているので...さておき、あなたの自我を入れて、参考にしてみてくださいあなたは、彼が興味を持っていることを何かではなく、希望を。言い換えれば、あなたは彼に好意を求めています。

また、多くの場合、あなたが尋ねる方法に依存します。例：

あなたが欲しいもの：

コードをきれいにする

言ってはいけないこと：

あなたのコードはそのままです

なんて言うか：

両方のプロジェクトの一貫性を保ち、基本だけを実現できれば、本当に感謝しています。1日だけで済みます。

あなたが欲しいもの：

未チェックの警告はもうありません

言ってはいけないこと：

あなたのコードはそのままです

なんて言うか：

私はこれとその警告を取り除く簡単な方法を知っています。その後、それらを再度有効にすることにより、将来何かが壊れる可能性があるかどうかをより迅速に検出できます。

そして最後に：

私はそれが優先事項ではないことを知っています。したがって、優先度の高いものが最初にテーブルから外れたら、喜んでそれを行うことができます。

または、それがうまくいかない場合、または彼との関係が悪い場合は、辞めることを検討してください。今あなたが物事を整理できない場合、将来的に良くなることはほとんどありません...そしてあなたのエゴを脇に置きます。

サイドノート

高齢者の方が寛大になるのが一般的だと思います。とにかく、彼らはコードが10年か2年でゴミになることを知っています（技術の変更、APIも、チーム、ビジネスパートナー、要件、グローバルな決定など）彼らは自我が少なく、完璧ではなく機能することに集中しています。私は自分自身を完璧にする傾向がありますが、私はそれらを責めることはできません。

これはおそらく議論の余地があるだろうが...

私たちは話し合い、反対し、それを上級管理職にエスカレートすることに同意しました

決して。今まで。行う。この。今まで。これを行うたびに、私たち全員が10年前に戻ってきます。これはこれがどのように展開するかです：

• シニアマネージャー1：「この問題に対処するように依頼されました。なんとか、コーディング標準と時間の浪費についてです。」

• シニアマネージャー2：「そして、彼らは私たちにオタクの芝生戦争を解決するように求めています。

• シニアマネージャー3：「彼らはコミュニケーションができず、ビジネスバリューが何であるかを気にかけない/理解できない、ひどい赤ちゃんだからです。*」

• シニアマネージャー2：「それはそれであるに違いありません。ゴルフは誰ですか？」

次に、あなたとあなたの上司のパフォーマンスレビューの時間が来ます。

「[上司のシニアマネージャー]：申し訳ありませんが、直属の部下を管理できず、ベストプラクティスに従わない可能性があるという懸念があります。ソフトウェアが動作するようになります）」

「[シニアマネージャー]：申し訳ありませんが、同僚との関係がうまくいかず、直属の上司の指示に従うことができないという懸念があります。」

そして、これが、私たちが作成する価値と比較して、ほとんどが低賃金である理由です。**

A）それを乗り越えるか、B）好みに少し近い基準に調整されたショップに移動する必要があります。FWIW、私はBをやります（そして、できればそのような残虐行為を許可しない言語に移ります）。しかし、違法または潜在的に壊滅的なもの（セキュリティホールの隙間）が関与する場合を除き、技術的な紛争を訴訟にエスカレートすることはありません。単にうっとうしいことはそれを削減しません***。

*これを読んで誤解する人々のために、私はOPと彼の上司がこのようなものだと言っているのではありません（コードの品質/読みやすさがビジネスの最終利益に直接影響することを理解しています）彼らはこのように非技術的な管理によって認識されます。

**私の上級管理職の肖像が無知なa-holeであると考える人にとっては、管理者が（理想的には）コードの管理を気にする方法で人を管理することを気にしていることを理解してください。彼らは技術的な問題については無知かもしれませんが、人々を知っているので、A）彼らはおそらく解決する資格がないとB）あなたの二人は間違いなく助けなしに解決できたはずだという論争を彼らにもたらすより多くの理由です見た目が悪くなります。

***はい、私は技術的な負債がビジネスを沈めるポイントまで積み上げることができることを理解しています。中かっこがあなたを救うとは思わない（言われているように、私は中かっこを決して省略せず、他の人もどちらもしないことを強く望んでいる）。

私見、あなたは「それが働いている」開発者に直面している、彼らの後を行く次の世話をするものではありません。彼の議論は価値がない。

彼のコードについてあなたが言うことはすべて、彼の生の怠lazです。同じコーディング標準に従うプロジェクトを作成することは厳密です。あなたはロボットではありません。あなたはエンジニアです。あなたは厳格であることになっています。

あなたは彼のコードを読むのに苦労していることをいくつかの例で指摘することができ、それはあなたにとって生産性の大きな損失ですが、私はそれを彼にもたらす方法がわかりません。

しかし、私はおそらくあなたに何かトーンを答えます：

それは機能しています、変更するポイントはありません

私のアドバイス：もし彼が本当に鈍くて、何も頭にしたくないなら、手放してください。彼のプロジェクトでエラー/バグ/進化が起こるのを待ちます。それが来たら、適切な方法で修正/追加されたコードの部分を修正して書き直してください。彼について何も言わないでください。あなたはとにかくロボットではないので、彼はあなたに彼のコーディングスタイルを強要しません。

プロジェクトで作業するときは、優先順位を設定する必要があります。

優先事項1は、同僚と仲良くすることです。優先度＃1の後には大きなギャップがあります。次に、動作、テスト可能、テスト済み、文書化、保守可能などのコードのようなものに優先順位が付けられます。次に、別の大きなギャップがあり、コーディング標準が来ます。

また、既存のコードを新しいコーディング標準に準拠するように変更することは、優先順位リストでは非常に低いです。

PS。「マイクロ最適化」と「超高速コンピューター」：完全に間違った議論。マイクロ最適化に対する議論は、コンピューターが高速であるということではなく、マイクロ最適化に時間を浪費するということは、本当の節約をする時間がないということです。

PS。コードの見栄えを良くする変更を加えるのに1日しかかからないが、同僚を動揺させて敵にした場合、1日は生産性の低いものに無駄になります。

PHPは、私たちの職業で最も優れたグループではありません。実際、彼はおそらく苦労して獲得したソフトウェアシステムを批判しています。あなたの職業基準は彼のものよりも高くなっています。

次に、あなたの責任の下でコードを改善するために何の余裕を持っていない場合は、そこに最後の一つだけ解決策：に移動。

あなたの現在のPHP市場については知りませんが、最初は多少多様化するかもしれません。誇大広告の言語、またはC＃のようなニッチも学習してください。

あなたはそのような素晴らしい仕事を得ることはないかもしれませんが、あなたは専門的にさらに先に来るでしょう。忍耐を持ち、自己学習をしてください。安全なお金。次に、プロジェクトに余裕を持たせるか、仕事を提供します。

＃1がコーディング標準を変更したくない本当の理由だとは信じがたい。コードベースを所有している場合は、あなた（および他の開発者）が同意したコーディング標準をすべて実施できるはずです。他の開発者とコンセンサスを達成した場合（リードがもはや開発作業を行っていないと仮定すると）、彼が本当に気にする理由はありません。

コードベースのスタイルを修正することは、今あなたの時間を最大限に活用していますか？

成果物があると確信しています。他のコードベースの至る所でスタイルを改善して改善するのにどれくらいの時間がかかりますか？スタイルを誤って修正してバグを導入したらどうなりますか？ボブおじさんから：

もちろん、不正なコードはクリーンアップできます。しかし、それは非常に高価です。コードが腐敗するにつれて、モジュールは互いにほのめかし、多くの隠れた複雑な依存関係を作成します。古い依存関係を見つけて壊すことは、長くて骨の折れる作業です。

このようなコードスタイルの改善は、スタンドアロンのスプリントアイテムとして時間を有効に使用することはほとんどありません。私がこの種の改善を行うのが好きな方法は、私が「良い隣人ポリシー」と呼んでいるものです。見つけることができるすべてのスタイルと論理構造を修正することは避けてください。できません。代わりに：コードの一部に変更を加えるときはいつでも、そこにいる間にスタイルを修正し、見つけたものよりも良いままにしておきます。コードの設計が不適切であるために機能の実装に苦労している場合は、スタイルを修正して、頭を打たずにブロックを解除してください。

このようにして、それぞれの変更：

1. 技術的な完璧主義の動機に加えて、ビジネスの動機がある
2. 大きな時間の投資とはみなされません（そうではないからです！）
3. あなたとあなたのチームが時間をかけてやっているからこそ、良いスタイルの習慣を確立します
4. 一度にあまり変更しないので、コードベースに大きなリスクを与えません

数か月後、「ひどいパッケージ」はそれほど悪くなく、上司は彼のチームが幸せであることに気付くでしょう。しかし、それは直接の対立ではなかったので、すでに行われています、そして彼はあなたがto-doリストに大きなリファクタリングプロジェクトを追加することによって（彼の心で）時間を浪費しなかったので不平を言うことは何もありません。彼はおそらくあなたが正しいとあなたに言うことはないでしょうが、それはとにかく目標ではありません（そうでしょう？）

リードについて次の質問をしてください。

• 彼らは一人で仕事をするのですか、それとも非常に小さなチームで仕事をするのですか？
• 彼らは主にこの1つの店でコーディングされていますか？
• 彼らは意思決定に慣れていますか？
• 彼らは「ただそれを成し遂げる」ことに慣れていますか？
• 彼らはほとんどのコードを書きましたか？

答えが「はい」の場合、特定のタイプのリードプログラマーの絵を描きます。それがあなたが経験したものと一致するなら、多分それは彼らの頭に入るのを助けるでしょう。そうでない場合は、この回答を無視してください。

これは、初日からそこにいて、同じコードベースで同じ仕事に何年も費やし、自分のやり方に慣れており、他の方法で多くの経験がない人です。

彼らはコードを書くときに他の人を考慮しません。それは彼らにとってすべて理にかなっているからです。もちろん、彼らはそれを書いた、または彼らはそれを理解するのに何年も費やした。

彼らはコーディングスタイルは個人的な好みであり、メンテナンスやバグを減らすツールではないと考えています。コーディングスタイルについて議論するとき、彼らはあなたの議論を聞くのに苦労します。なぜなら彼らはおそらく彼らが自分たちのやり方で何かをする理由についてあまり考えたことがないからです。彼らが聞くのは、「自分のやり方でやりたい」または「新しい、おしゃれでトレンディなやり方でやりたい」ということです。

彼らは彼らの方法で設定されています。なぜなら、彼らはすべてのツールとエディターで長い間同じ方法でそれを行っており、彼らのスタイルに正確にマイクロ構成されているからです。このスタイルからの逸脱は、慎重に配置された、しかし非常に脆弱な作業方法と矛盾します。変更しようとすると、編集者、ツール、作業方法、または「読みにくい」という苦情が寄せられます。彼らは変化を拒否します。なぜなら、彼らは変化することができない現状で非常にきつく締められているからです。

これは、ソフトウェアエンジニアリングとソフトウェアアーキテクチャを適切に学習したことがない人です。彼らは、うまくいくものは何でも一緒に並べます。

技術的な問題ではなく、人の問題があります。

リードを再トレーニングするか、やめなければなりません。

管理に行くことは最後の手段です。両方のための指摘@JaredSmith理由から、あなたが失うことになるので。この男は彼らのためにお金を稼ぐのに何年も費やしました。彼は彼らの会社を書いた。彼は多くの火事で消火しました。あなたにとって彼はスパゲッティを作るカウボーイシェフです。彼らにとって、彼は会社を建設し、救ったヒーローです。

再トレーニングするには...

• 彼の信頼を得る。
• 彼の考えを理解してください。
• 彼の変化に対する恐れに対処してください。
• 変更を簡単にします。
• これが彼にとってどう良いか示してください。

彼のスタイルを真剣に考え、彼の頭の中に入る。それについて彼に尋ねてください。なぜ彼は彼のように物事をするのですか？彼はそれを読んだときに何を見ますか？それは彼のツールとどのように相互作用しますか？彼はどのようにコードを移動しますか？これらすべてを知ることで、彼の異議を理解し対処することができます。

彼の主観的な異議の客観的な根源を見つけ、それらを実行可能にします。「読みにくい」は主観的であり、情報を提供しません。それについては何もできません。「私は色覚異常で、構文の強調表示は機能しません」は客観的であり、情報を提供し、それについて何かをすることができます。詳細については、Getting To Yesという本をお勧めします。

根本的な問題、つまり彼が経験している実際の問題に到達したら、それを修正または軽減できるかどうかを確認します。その後、それは問題ではありません。彼らはおそらく、変化に関して感情的な問題を抱えているでしょうが、少なくとも彼らはそれが実際の問題だと主張することはできません。

少しずつやってください。これは何年も同じ方法でやっている人です。彼はコード内の特定のパターンを見て、それを使ってそれを理解することに慣れています。これらのすべてのパターンを突然変更すると、混乱を招きます。既知のグッドプラクティスでゆっくりとスピードを上げていくのはイライラするので、彼にそれを説明しなければなりません。

標準的なコミュニティスタイルの支持者。これは、個人的な好みに関する議論を排除し、彼らの異なるスタイルが非常に優れている理由を正当化するよう彼らに圧力をかけます。採用を計画している場合、新規採用の統合が容易になります。

自動化されたコードスタイルの擁護者。正しいスタイルに従ってボタンを押すだけです。標準スタイルで始まるツールを使用し、好みに合わせて設定し、ボタンを押すだけでコードのスタイルを変更できます。スタイルに従うことを可能な限り簡単にすることは、それがどれほど難しいかについての多くの議論を取り除きます。好きなようにコーディングできます。完了したらボタンを押し、他の人が読むことができるスタイルに従います。

この人は他人のことを考えているわけではないので、これらの変化が彼らにどのように役立つかを示す必要があります。「これが今の標準だから、あなたが次に雇う人と再びこの戦いを経験する必要はないだろう」と同じくらい簡単です。または、「テストがある場合は、コードの変更に対してより積極的になり、変更の心配を減らすことができます」。または「良いドキュメントがあれば、人々はコードがどのように機能するかについての質問で悩まされ続ける必要はありません」。これが効果的であるためには、彼らが何を望んでいるかを知る必要があります。

長い長い道のりです。上司を管理して再訓練する忍耐があるかどうかを判断する必要があります。自分のことを、イライラした部下というよりも教師だと考えてください。

私は間違っていますか？

私はPHPを知らないので、直接判断することはできませんが、議論のために、あなたの好みのコーディングスタイルはあなたが遭遇したコードよりも「良い」と仮定します。既存の自動化ツールを使用します。

コーディングスタイルの改善を提案するのは間違いではありません。

要するに、私が作業したいコードではありません

好みの基準を満たしていないコードの使用を拒否するのは間違っているかもしれませんが、会社で働くことで最初にコードを使用することに同意した場合に限ります。最終的には、自分の好みに合わない要求があった場合に仕事を辞めることは「間違った」ことではありません。それはあなたの権利であり、結果としてより良い仕事を見つけることができるからです。

個人的な好みを課しますか？

いいえ。彼はプロジェクトリーダーであり、あなたはそうではありません。それは彼の呼びかけですが、この場合、彼は「上向きに委任されています」。

サブプロジェクトの主任開発者として、彼はあなたに下向きに委任することを決定したかもしれません。そして、将来それらに取り組んでいるサブプロジェクトと同僚のコーディング標準を自由に設定できるようになります。しかし、何らかの理由で、彼はあなたが標準化すべきでないと非常に強く感じています。彼がコーディングスタイルについて間違っていたとしても、彼があなたに許可していない権限を主張することは期待できません。

ただし、「コーディングスタイルを強制するのは好きではない」と彼は言うので、少なくとも好みのスタイルで新しいコードを書くことができます（そして、そうしました）。最終的に、これはあなたのスタイルの客観的な利点を示す機会をもたらすかもしれません。それはあなたの主張をすることでもう一度行くのに良い時間でしょう。

また、ファイルを編集している人に、ファイルが既に書き込まれているスタイルで行うよう合理的に依頼することもできます（と思います）。これにより、作成したファイルの標準を維持できます。残念ながら、これの裏側は、彼が彼のスタイルに似たもので書いたファイルを編集しなければならないということです。

非常に優れたテストスイートがあり、それゆえ比較的安全にリファクタリングできると仮定しても、ファイル全体をブラストしてスタイルを変更しない理由は（明らかにかなり限界がある）ままです。主なものは、大きな構造変更の前後に行われた変更をマージ、並べ替え、または元に戻そうとする悪夢です。しかし、この特定のプロジェクトではほとんど起こりません。

私のマネージャーは、私たちがロボットではないため、コーディングスタイルを人々に強制したいと考えています。

コンパイル後にすべてのテストに合格しただけでソースコードを破棄しないのはなぜだろうか。ソースコードは人間向けであり、人間が書くだけでなく読むこともできます。

遅かれ早かれ、誰かが戻ってコードを読む理由を持つことになります。たぶん、彼らはそれを変更する必要があるでしょう、多分それを文書化するか、多分それを再利用するでしょう。なんでも。それは起こりそうであり、コードがすべて一貫したスタイルであれば、コードは読みやすく、操作しやすくなります。

悪いスタイルであっても、まったくスタイルがないよりはましです。