コーディング標準に関するプロジェクトリーダーとの不一致
それで、私は過去1年間、私のプロジェクトリーダーと共に新しいプロジェクトに取り組んでいます。
最初は、独立したgitリポジトリに常駐する独自のサブプロジェクトがありましたが、彼のコードとのやり取りはほとんどなかったので、コードのにおいは気になりませんでした。約6か月後、私はプロジェクトでより大きな役割を担っていたため、彼のコードの保守と機能の追加を開始しました。
現在、私は両方のサブプロジェクト（チームは成長しつつありますが、彼はまだ私より上にあります）の主任開発者です。
- 中括弧、大文字の関数、混合引用符の使用（二重および単一w /隠しロジック）、===を使用しない、巨大な関数を持つ巨大なクラス。結論としては、もっと良いかもしれません。
- 通知/警告をオフにするPHPのオプションへの依存。コードには、変数と配列キーのチェックされていない使用法がいっぱいです。変数はifs内で定義されます。
上記の2つの問題に対する議論：
- 人々にコーディングスタイルを強制したくない。
- 言語機能と見なされ、より短い/より効率的なコードに役立ちます。
いくつかのルールが必要であり、コードは防御的である必要があると思います。書式設定にはPHPStormのデフォルト設定を使用し、中括弧とコミュニティで受け入れられている命名規則を使用することを提案しました。
どちらのプロジェクトも切り離せないため、同じガイドラインを使用するように調整します。
私は間違っていますか？個人的な好みを課しますか？
why yoursの方が強い場合（そして彼を使用することでどのような大きな問題が発生する可能性があるか）は、個人的な好みを課しているのではなく、プロジェクトを設定しようとしていると思います成功のために。
彼がより良い理由と、それがあなたのできないことを防ぐどんな種類の問題を防ぐことができるかについてより強力な主張をすることができれば、彼はあなたを騙します。
きちんとした上級管理職はその点でメリットを理解できるはずですが、それらが気にすべき（そしてすべき）ポイントです。それは、開発者にとって簡単であるか、「誰もがロボットのように働くように強制したくない」かどうかではありません（これはばかげたポイントですが、上層部の悩みの種として使用しないでください）。彼らは、プロジェクトの進行中の安定性を気にかけるべきです（すべきです）。
上記の私のコメントごとに：
彼がプロジェクトリーダーである場合、それは基本的に彼のコールであることを意味するようです。
それが私の考えでした。基準を変更したいが、彼がそれに気を取られていない場合は、a）彼を上回る方法を理解する、b）他の場所に移動して作業する、またはc）彼を苛立たせずにできる小さなことを試す過度に。
whyに対して強い主張をする場合にのみ、彼を超えることができます。より良い基準があるはずです。
基本的に：
- yoしないlike彼のコーディングスタイル。それはあなたの権利です。
- he見つけます[〜＃〜] ok [〜＃〜]それは好きで、費やす日/週/もっと見つけますスタイルを調整するだけです廃棄物時間の。それは彼の権利です。
彼の立場になってください。会社に多額の費用（給与）を支払う以外に、あなたの努力の利点は何ですか？彼はいつもそんなにつまらないですか？彼は今やるべきもっと重要なことがあると思いませんか？
基本的に、あなたはする必要があるあなたが一緒に暮らすことができるある種の妥協を見つけるか、あなたの関係は酸っぱくなります。それはあなたが彼とどのようにコミュニケーションするかにも大きく依存します。自分のエゴを脇に置いて助けようとする...最後にあなたは彼に何かを尋ねているからですあなたは彼が興味を持っている何かではないです--言い換えれば、あなたは彼に尋ねています好意。
それはしばしばhowにも依存します。例：
あなたが欲しいもの：
コードの作成prettier
言わないこと：
あなたのコードはそれがそうである方法を吸います
なんて言うか：
両方のプロジェクトに一貫性を持たせることができ、基本的なものにできれば、本当にありがたいです。1日で十分です。
あなたが欲しいもの：
未チェックの警告はもうありません
言わないこと：
あなたのコードはそれがそうである方法を吸います
なんて言うか：
私はこれとその警告を取り除く簡単な方法を知っています。次に、それらを再度有効にすることで、将来何かが壊れるかどうかをより迅速に検出できます。
そして最後に：
私はそれが優先事項ではないことを知っています。ですから、優先度の高いものが最初になくなると、喜んでそれを行うことができます。
または、それがうまくいかない場合、または彼との関係が悪い場合は、離れることを検討してください。今、あなたが物事を整理することができないならば、それは将来的に良くなることはありそうにありません...そしてあなたの自我を脇に置いてください。
サイドノート
高齢者の方が寛大であることが一般的だと思います。彼らはコードが10年か2年でtrashedになることを知っています（テクノロジーの変更、APIも、チーム、ビジネスパートナー、要件、グローバルな決定など...）。彼らは自我が少なく、完璧ではなく機能することに焦点を合わせています。私は自分で完璧にする傾向がありますが、私はそれらを責めることはできません。
これはおそらく論争になるでしょうが...
私たちは話し合い、同意せずにそれを上級管理職にエスカレーションしました
決して。ずっと。行う。この。これまで。あなたがこれをするたびに、それは私たち全員を10年前に戻します。これは、これがどのように行われるかです：
シニアマネージャー1：「私たちは、この問題を何とかして、コーディング標準と時間の浪費について処理するように求められました。」
上級管理職2：「そして、彼らはsにオタクの芝生戦争を解決するように求めていますか？」
シニアマネージャー3：「彼らはコミュニケーションがとれず、ビジネスの価値が何であるかを気にせず/理解できない愚かな赤ちゃんなので*」
シニアマネージャー2：「それはそれであるに違いない。誰がゴルフをするのか」
次に、あなたとあなたの上司のパフォーマンスレビューの時間になります。
「[上司のシニアマネージャー]：申し訳ありませんが、直属部下を管理できず、ベストプラクティスに従っていない可能性があるという懸念があります（私はいくつかのマンボジャンボを入力する以外は何をしているのかわかりませんが）ソフトウェアが機能します）」
「[シニアマネージャーからあなたへ]：申し訳ありませんが、同僚との関係がよくなく、直属の上司の指示に従えないという懸念があります。」
そして、これが、私たちが生み出す価値と比較して、私たちがほとんど過小支払している理由です。
あなたは、A）それを乗り越えるか、B）基準があなたの好みに少し近く調整されたショップに移動する必要があります。 FWIW、私はBをします（うまくいけば、そのような残虐行為を許可しない言語に移ります）。しかし、技術的な論争が訴訟にエスカレートすることは決してありません。違法なものや壊滅的な可能性があるもの（セキュリティホールの隙間）が含まれる場合を除きます。煩わしいだけでは効果はありません***。
*これを読んで誤解する人々のために、私はOPとその上司がこのようであるとは言っていません（コードの品質/読みやすさがビジネスの最終利益に直接影響することを私は理解しています）。それらはperceivedのように、非技術的な管理によってこのようになります。
**私の上級管理職の肖像画が無知なa-holesであると非現実的であると考える人にとって、マネージャーは（理想的には）管理に関心があることを理解してくださいpeopleコードの管理に注意する方法。彼らは技術的な問題については無知かもしれませんが、彼らは人々を知っています、そしてそれが彼らに論争をもたらす理由であるA）彼らはおそらく解決する資格がないとB）二人は間違いなく助けなしで解決できたはずですあなたを悪く見せる。
***はい、技術的な負債がビジネスを沈滞させるほどに積み重なる可能性があることを理解しています。私は中括弧があなたを救うとは思わないだけです（言われているように、私はneverは中括弧を省略し、他の人がしないことを強く望みます）。
私見、あなたは「それは機能している」開発者に直面しています。彼の議論はただ価値がない。
彼のコードについてあなたが言うことは、彼の側の単なる怠惰です。同じコーディング標準に従うプロジェクトを持つことは厳密です。あなたはロボットではありません。あなたはエンジニアです。あなたは厳格であることになっています。
いくつかの例を挙げれば、彼のコードを読むのに苦労していること、そしてそれがあなたにとって生産性の大きな損失であることを指摘することができますが、私はそれを彼にもたらす方法を実際に知りません。
しかし、私はおそらくあなたに何かトーンで答えます：
機能しており、変更する必要はありません
私のアドバイス：彼が本当に率直で何も率いてほしくない場合は、手放してください。彼のプロジェクトでエラー/バグ/進化が発生するのを待ちます。それが来たら、修正または追加されたコードの一部を適切な方法で修正して書き直します。それについて何か言うために彼のところへ行ってはいけません。とにかくあなたはロボットではないので、彼はあなたに彼のコーディングスタイルを課しません...
プロジェクトで作業するときは、優先順位を設定する必要があります。
優先事項＃1は、同僚と仲良くすることです。優先順位＃1の後には大きなギャップがあります。次に、機能している、テスト可能、テスト済み、文書化済み、保守可能などのコードの優先順位が決まります。次に、もう1つの大きなギャップが生じ、次にコーディング標準が登場します。
そして、新しいコーディング標準に準拠するように既存のコードを変更することは、優先順位のリストでは本当に低いです。
PS。 「マイクロ最適化」対「超高速コンピューター」：まったく間違った議論。マイクロ最適化に反対する議論は、コンピュータが高速であるということではありません。マイクロ最適化に費やされた時間は、realの節約に費やす時間がないということです。
PS。コードの見栄えをよくする変更を加えるのに1日しかかからないが、同僚を怒らせて敵にしてしまうと、逆効果になる何かに1日無駄になってしまいます。
PHPは、私たちの職業で最もエリートグループではありません。実際、あなたは彼がおそらく勝ち取ったソフトウェアシステムを批判しています。あなたの職業基準は彼のそれよりも高いです。
次に、自分の責任の下でコードを改善する余裕がない場合は、解決策が1つだけ残ります：移動。
私は現在のPHP=市場については知りませんが、最初にいくらか多様化するかもしれません。誇大宣伝言語またはC＃のようなニッチな分野も学びます。
あなたはそのような素晴らしい仕事を得られないかもしれません、しかしあなたは専門的にさらにやって来るでしょう。だから忍耐を持ち、いくつかの自習をしてください。安全なお金。次に、プロジェクトに余裕を求めるか、求人を依頼します。
コーディング標準を変更したくない本当の理由が＃1であるとは信じがたいです。コードベースを所有している場合は、自分（および他の開発者）が同意したコーディング標準を適用できるはずです。他の開発者とコンセンサスを得た場合（リードがもはや開発作業を行っていないと想定している場合）、次の場合を除いて、彼が本当に気にする理由はありません。
コードベースのスタイルを修正することは、今のあなたの時間の最善の使い方ですか？
あなたは成果物を持っていると確信しています。他のコードベースのあらゆる場所でスタイルを見直して改善するには、どれくらいの時間がかかりますか？スタイルを誤って修正してバグを導入するとどうなりますか？から ボブおじさん：
もちろん悪いコードは片付けることができます。しかし、それは非常に高価です。コードが腐敗すると、モジュールは相互に影響し合い、多くの隠れたもつれた依存関係を作成します。古い依存関係を見つけて破壊することは、長く困難な作業です。
このようなコードスタイルを改善することは、スタンドアロンのスプリントアイテムとして時間を有効に使用することはほとんどありません。これらの種類の改善を行う方法は、私が「グッドネイバーポリシー」と呼んでいるものです。見つけることができるすべてのスタイルとロジック構造を修正することは避けてください。行われません。代わりに：コードの一部に変更を加えるときはいつでも、そこにいる間にスタイルを修正し、見つけたよりも良いままにしておきます。実装に苦労している場合機能はコードの設計が不適切であるため、スタイルを修正して自分のブロックを解除するのではなく、ブロックを解除します。
このようにして、各変更は次のようになります。
- 技術的な完全主義の動機に加えて、ビジネスの動機を持っている
- 大きな時間の投資とは見なされません（そうでないためです！）
- あなたとあなたのチームが時間をかけてそれをやっているので、良いスタイルの習慣を確立します
- 一度にあまり変更しないため、コードベースに大きなリスクをもたらすことはありません
今から数か月後、調べてみると、「恐ろしいパッケージ」はもうそれほど悪くなく、上司は彼のチームがより幸せであることに気付くでしょう。しかし、これは直接的な対立ではなかったため、すでに行われています。また、To Doリストに大きなリファクタリングプロジェクトを追加することによって（彼の心の中で）時間を無駄にしていないので、彼は何も文句を言うことはありません。彼はおそらくあなたが正しかったとは決して言わないでしょうが、とにかくそれが目標ではありません（正しいですか？）。
私は間違っていますか？
私はPHPを知らないので、直接判断することはできませんが、あなたの好みのコーディングスタイルは、あなたが遭遇したコードよりも「優れている」と仮定します。既存の自動化ツールで。
次に、コーディングスタイルの改善を提案するのは間違いありません。
結論：処理したいコードではありません
希望の基準を満たしていないコードでの作業を拒否するのは間違っているかもしれませんが、会社で働くことによって、最初からコードを使用することに同意した場合に限られます。結局のところ、それがあなたの権利であるので、それがあなたの好みに合わないあなたの要求をする場合にあなたの仕事をやめることは「間違った」ことではなく、結果としてあなたはより良い仕事を見つけるかもしれません。
個人的な好みを課しますか？
いいえ。彼はプロジェクトリーダーであり、あなたはそうではありません。それは彼の呼びかけですが、この場合、彼は「上向きに委任」されています。
彼はサブプロジェクトの主任開発者としてあなたに下に委任することを決めたかもしれませんし、それらに将来取り組むサブプロジェクトと同僚のためにコーディング標準を設定するための自由な手助けをあなたに与えるでしょう。しかし、何らかの理由で、彼はあなたが標準化すべきではないと非常に強く感じています。 彼がコーディングスタイルについて間違っていても彼が許可していない権限を主張することは期待できません。
しかし、彼は「コーディングスタイルを強制したくない」と言っているので、少なくとも好みのスタイルで新しいコードを書くことができます（そうすることもできます）。結局、これはあなたのスタイルの客観的な利点を実証する機会をもたらすかもしれません。それはあなたのケースを作るのにもう一度行くのに良い時でしょう。
（私が思うに）ファイルを編集する人に、ファイルが既に書かれているスタイルでそうするように頼むこともできます。これにより、作成したファイルの標準を維持できます。残念ながら、これの反対側は、彼が書いたファイルを彼のスタイルに似たもので編集する必要があるということです。
本当に優れたテストスイートがあり、したがって比較的安全にリファクタリングできると仮定しても、ファイル全体をブラストしてスタイルを変更しない理由は（確かにかなり限定的です）まだあります。主なものは、大きな構造変化の前後に行われた変更をマージ、並べ替え、または元に戻そうとする悪夢だということです。しかし、この特定のプロジェクトでは、これまでほとんど起こらなかったのかもしれません。
[私のマネージャーは、私たちがロボットではないため]人々にコーディングスタイルを強制したくないと言っています。
コンパイルしてすべてのテストに合格した後で、なぜソースコードを破棄しないのか疑問に思ったことはありませんか？ソースコードは人間用であり、人間が書くだけでなく、readにも対応しています。
遅かれ早かれ、誰かが戻ってコードを読む理由があるでしょう。多分彼らはそれを変更したり、多分それを文書化したり、多分それを再利用したりする必要があるでしょう。なんでも。それは起こりそうであり、コードがすべて一貫したスタイルであれば、コードは非常に読みやすく、扱いやすくなります。
悪いスタイルであっても、まったくスタイルがないよりはましです。
リードについて次の質問をします。
- 彼らは一人で働いているのですか、それとも非常に小さなチームで働いているのですか？
- 彼らは主にこの1つの店でコーディングしましたか？
- 彼らは意思決定に慣れていますか？
- 彼らは「それを成し遂げるだけ」に慣れていますか？
- 彼らはほとんどのコードを書きましたか？
答えが「はい」の場合は、特定のタイプのリードプログラマーの写真を描きます。それがあなたが経験したものと一致するなら、多分それは彼らの頭に入るのを助けるでしょう。 そうでない場合は、この回答を無視してください。
これは、最初からそこにいて、同じコードベースで同じ仕事に何年も費やしていて、自分のやり方に慣れていて、他の方法での経験があまりない人です。
コードを書くときに他の人を考慮しません。もちろん、彼らはそれを書いたか、彼らはそれを理解するのに何年も費やしてきました。
彼らはコーディングスタイルを個人的な好みであり、メンテナンスやバグを減らすためのツールではないと考えています。コーディングスタイルについて議論するとき、彼らはおそらく彼らが自分のやり方で物事を行う理由についてあまり考えたことがないので、あなたの議論を聞くのに苦労します。彼らが聞くのは「私は自分のやり方でやりたい」または「新しくて派手でトレンディな方法でやりたい」です。
彼らは彼らのやり方で設定されています。彼らは長い間同じようにそれをやってきたので、彼らのすべてのツールとエディターと脳は彼らのスタイルに正確にマイクロ構成されました。このスタイルからの逸脱は、注意深く調整された、しかし非常に壊れやすい作業方法と矛盾します。変更しようとすると、編集者、ツール、作業方法、または「読みづらい」という苦情が寄せられます。彼らは現状を把握することができず、変更できないため、変更を拒否します。
これは、ソフトウェアエンジニアリングとソフトウェアアーキテクチャを適切に学習したことがない人です。彼らは何でもうまくいくように一緒に強打しています。
技術的な問題ではなく、人々の問題があります。
あなたはあなたのリードを再訓練しなければならないだろう、またはあなたはやめなければならないだろう。
管理に行くことは最後の手段です。 @ JaredSmithが指摘した理由 の場合と、失うことになるためです。この男は彼らのためにお金を稼ぐために何年も費やしてきました。彼は彼らの会社を書いた。彼は何度も火事に出された。あなたにとって、彼はスパゲッティを作るカウボーイのシェフです。彼らにとって、彼は会社を築いて救ったヒーローです。
再訓練する必要があります...
- 彼の信頼を得る。
- 彼の考えを理解する。
- 変化についての彼の恐れに取り組みます。
- 変更を簡単にします。
- これが彼にとってどのように良いかを示してください。
彼のスタイルを真剣に受け止め、彼の頭の中に入りなさい。それについて彼に尋ねなさい。なぜ彼は彼のように物事を行うのですか？彼がそれを読むとき、彼は何を見ますか？それは彼のツールとどのように相互作用しますか？彼はコードをどのように移動しますか？これらすべてを知ることで、彼の異論を理解して対処することができます。
彼の主観的な異議の客観的な根を見つけ、それらを実行可能にします。 「読みにくい」は主観的なものであり、情報を提供するものではありません。それについては何もできません。 「私は色覚異常で構文の強調表示が機能しません」というのは客観的であり、情報を提供し、それに対して何かを行うことができます。詳しくは Getting To Yes という本をお勧めします。
根本的な問題、彼が経験している実際の問題に到達したら、それを修正または軽減できるかどうかを確認します。その後、それは問題ではありません。彼らはおそらく変化に関してまだ感情的な問題を抱えているでしょうが、少なくとも彼らはもはやそれが実際の問題であると主張することはできません。
少しずつ行います。これは何年も同じやり方でやってきた人です。彼はコードの特定のパターンを見て、それらを使用してそれを理解することに慣れています。これらすべてのパターンを突然変更すると混乱を招きます。既知の優れたプラクティスでゆっくりと速度を上げていくのと同じくらいイライラするので、彼にそれを説明する必要があります。
標準的なコミュニティスタイルを支持する。これは、それが個人の好みに関するものであるという主張を排除し、彼らの異なるスタイルが非常に優れている理由を正当化するように彼らに圧力をかけます。採用を計画している場合は、新規採用の統合が簡単になります。
自動化されたコードスタイルを支持します。ボタンのプッシュを正しいスタイルに従ってください。標準のスタイルで始まり、好みに合わせて構成でき、ボタンを押すだけでコードのスタイルを変更できるツールを使用します。スタイルにできるだけ従うようにすることで、従うことがどれほど難しいかについての多くの議論がなくなります。彼らは好きなようにコーディングすることができ、完了したらボタンを押すと、他の人が読むことができるスタイルに従います。
この人は他人のことを考えているわけではないので、これらの変化が彼らにどのように役立つかを示さなければなりません。 「今ではこれが標準なので、次に雇う人とこの戦いを繰り返す必要はありません」のように、それは単純なことです。あるいは、「テストがあれば、コードの変更に積極的になり、変更を心配する必要がなくなる」こともあります。または「良いドキュメントがあれば、人々はコードがどのように機能するかについての質問で悩まされる必要はないでしょう」。これが効果的であるためには、彼らが何を望んでいるかを知る必要があります。
長くて長い道のりです。 manage up に対する忍耐力があるかどうかを判断し、上司を再訓練する必要があります。欲求不満な部下ではなく、自分を先生として考えてみてください。