Pythonコーディング標準と生産性
私は、大規模な人道支援団体で、食料の配布を迅速化することで緊急時に命を救うのに役立つプロジェクト構築ソフトウェアに取り組んでいます。多くのNGOは必死に私たちのソフトウェアを必要としており、私たちは予定より数週間遅れています。
このプロジェクトで私が心配することの1つは、コーディング標準に過度に焦点を合わせていることだと思います。私たちはpython/Djangoで記述し、PEP0008のバージョンを使用しています。行の長さは160文字まで可能で、すべての行は可能な限り長くする必要があります。インポート間に空白行はありません。特定の種類のクラスにのみ適用される行折り返しルール、使用しなくても使用する必要のある多くのテンプレート問題などを解決する最良の方法.
1人のコア開発者が1週間を費やしてシステムの主要部分を書き換え、当時の新しいコーディング標準に適合させ、プロセスのテストスイートをいくつか破棄しました。私たちは2週間かけて、失われたすべての機能を書き直し、バグを修正しました。彼は主任開発者であり、彼の言葉は重要であるので、彼はこれらの標準が必要であるとプロジェクトマネージャーに確信させました。ジュニア開発者は言われた通りにします。プロジェクトマネージャーは、これらすべてについて認知的不協和の強い感情を持っているように感じますが、それでも、彼が他に何をすべきかわからないと感じているので、激しく同意します。
今日、キーワード引数のコンマの後にスペースを入れるのを忘れていたので、私は深刻な問題に直面しました。 Skypeの通話中に、文字どおり他の2人の開発者とプロジェクトマネージャーに怒鳴られました。個人的にはコーディング標準が重要だと思いますが、それに取り掛かるために多くの時間を浪費していると思います。私がこれを言葉で表現すると、怒りを引き起こしました。私はチームのトラブルメーカー、障害のスケープゴートを探しているチームと見られています。コーディング標準の導入以来、チームの生産性はかなり落ち込んでいますが、これは強迫観念を強めるだけです。彼は私たちが慣習に固執しないとお互いのコードを読むことができないと信じています。
これは粘着性に変わり始めています。現在、さまざまなスクリプト、autopep8、pep8ify、PythonTidyを変更して、規則に合わせようとしています。また、ソースコードに対してpep8を実行しますが、標準に対する暗黙の修正が非常に多いため、すべてを追跡することは困難です。リードデベロッパーシンプルは、pep8スクリプトが検出しない障害を選択し、次のスタンドアップミーティングで私たちに叫びます。毎週、コーディング標準に新しい追加があり、既存の動作するテスト済みのコードを書き換える必要があります。私たちにはまだテストがある天国に感謝します（私はいくつかのコミットを元に戻し、彼が削除したものの一部を修正しました）。
その間、締め切りに間に合うようにプレッシャーが高まっています。
根本的な問題は、リード開発者と別のコア開発者が他の開発者の仕事を信頼することを拒否していることだと思います。しかし、それに対処するにはどうすればよいですか？すべてを書き直すのに忙しいので、私たちは仕事をすることができません。
ソフトウェアエンジニアリングチームでこれほどダイナミックに遭遇したことはありません。彼らがコーディング標準に準拠していることを疑うのは間違っていますか？他の誰かが同様の状況を経験しましたか？彼らはどのようにうまくそれに対処しましたか？ （私は人々が見つけた実際の解決策だけの議論を探しているのではありません）
コーディング標準は問題ではありません。問題は、経営陣が問題が何であるかを理解できないことです。これは「何かをする…何でも！」につながります。モード。あなたは合理的な解決策を探していますが、それは非合理的な問題です。あなたができる最善は：
- 彼らのアイデアに対して建設的な批評を与えますが、決定が下された後は、それについて絶えず駄々を言うな。
- 書き換えを簡単にするためにできることは何でもしてください。
- ストレスをやめる。期限を逃したのは経営者の問題であり、あなたの問題ではありません。最善を尽くしますが、彼らの不十分な決定に対して責任を負いません。
- あなたが役立つかもしれない何かを知っているなら、彼らに教えてください。スタンドアップについて言及すると、アジャイルを実行しようとしているように聞こえるかもしれませんが、残りはあまりアジャイルに聞こえません。すべてを1つの大きな期限に合わせるのではなく、限られた機能をより早く提供できるかどうかを確認してください。リライト用のユーザーストーリーを作成して、バックログにどのように影響しているかを明確にします。
- 別の仕事を探し始めます。真剣に。そのような州の企業は、人々を解雇し始めるのにそれほど遠くない。
- 「そう言った」Tシャツをプリントアウトしてください:-)
誰かが出荷するか、コーディング標準への順応が真の優先事項かを決定する必要があります。私は自分の好みがどうなるか知っています。単体テストと受け入れテストに合格した場合は、船と言います。出荷後、会社は技術的負債を修正するために時間とお金を費やすかどうかを決定できます。
カンマの後のスペースの問題は、コードを整えるツールで簡単に解決できます。すべてのコーディング規則を適用するツールを見つけ、ビルドとテストが行われる前に、変更されたすべてのコードでそのツールを実行します。まともなIDEはすでにこれを行っていますコードを書いている間
彼らがコーディング標準に準拠していることを疑うのは間違っていますか？
グループによって異なります。 個人的に、すべてが問われるべきだと思います。一部の人々はその質問を侮辱と見なします。私はそれらを信用しないこと。
他の誰かが同様の状況を経験しましたか？彼らはどのようにうまくそれに対処しましたか？
これらの規格がどのように生産性を向上させるかを尋ねました。私は、標準をいじる時間と「物事を成し遂げる」時間を測定しました。結局、基準に固執することを決定する力。それが起こります。彼らが私が物事を成し遂げなかった原因であるとき、私はそれらがいつもよりも大声で不平を言いましたが、それ以外の場合私の仕事を成し遂げることに集中しました。生産性のために...
あなたが言うように、基準のために物事がかなり悪い場合、基準を守ることはリードの議論を無効にし、あなたの意見を残すべきです。標準の実装と生産性の低下との間の（大部分）客観的な相関関係を人々が理解できない場合、これ以上できることはありません。それを処理する方法を学び、もしできない場合は、官僚的ではない場所を探してください。
標準とは、締め切りが迫っているプロジェクトの後半に配置すべきではないものです。これは、プロジェクトの早い段階で、またはプロジェクトスケジュール（できれば初期出荷後）に（潜在的に）大規模な問題のあるコードリファクタリングのために時間をとっておく必要がある場合に設定する必要があります。
これが実際にプロジェクトの後半で行われたのであれば、それはあなたのリーダー（IMHO）が犯した間違いです。
ただし、これは、リードに同意しない場合、反乱を先に請求する必要があるという意味ではありません。これはあなたのjobです。あなたはteamとして働いています。 リードがあります。チームには確かにある程度の民主主義が必要ですが、結局のところ、独裁者がリーダーです。彼が何かをするように言うなら、あなたはそれをします。
結局のところ、彼の要求と基準に準拠することで、あなたは彼/彼女に期限を逃すための簡単なスケープゴートを提供しません。
また、私はコーディング標準の巨大な擁護者です（特にチームの規模が大きくなるにつれて）が、それが理にかなっている場合は実装する必要があります。
あなたの質問は、「コーディング標準への準拠を疑うのは間違っているのですか？」でした。 http://c0x.coding-guidelines.com/Introduction.pdf （Cプログラミング言語用）には、コーディングガイドラインの価値に関する参考研究があります。 39ページから始まるセクション9を参照してください。
コーディング標準は、理由のために実装されています。元の質問から欠落しているように見える1つのことは、特定のプロジェクト（または特定の組織）に関するこれらの特定の基準の理由の理解です。既存のコードにそれらを実装する決定は、いくつかのロジックに基づいていました。論理を知らなければ、その決定の「良さ」についてコメントすることは困難です。
標準が「長期的な生産性」のために実装されているという誰かが言ったことを2番目に説明します-コードの保守性のような問題です。たぶん、混乱と誤解のために、プロジェクトを大幅に後退させる何らかのイベントが発生しました。
双方に多くの感情があるように思えます-合理的な議論に取り掛かってください。
おそらく他の回答やコメントでご覧になったことと思いますが、プロジェクトには大きな問題があるため、私が提案することは成功する大きなチャンスはありませんが、それはあなたが大きなリスクなしに試すことができるものですあなた自身の肌。
リードデベロッパーと4つの目の間のミーティングを依頼します。コーディング標準を厳しくすることの利点と、コードベースを導入する前にコードベースがこのように悪い形になっていた理由を完全に理解することに興味があるとします。このディスカッションの間は、非常にオープンで「学びたい」という姿勢を保つことが非常に重要です。あなたのリード開発者はおそらくあなたやあなたのチームの他の誰よりもすでにもっとストレスを受けており、彼が何らかの批判を嗅いだらすぐにおそらく非常に防御的でしょう。
共通の目標を達成する方法を理解しようとする方向に議論を微調整してください。機能し保守可能なソフトウェアを迅速に提供します。
たとえば、ぶら下がっている果物の中には、コーディングガイドラインにこれ以上何も追加しないというものがあります。そのたびに、以前はガイドラインに準拠していたコードは実行されなくなり、その結果、コードのチャンクを書き直す必要が生じます。うまくいけば、あなたのリード開発者は、追加されたルールが（彼の観点から）価値を追加したとしても、すでに遅れたプロジェクトのこのフェーズで書き換えを動機づけるほど効果がないかもしれません。
これが機能する場合は、ツールでオートフォーマットできない任意のルールを削除するように試みることができます。