Pythonコーディング標準と生産性

私は大規模な人道支援団体で働き、食糧の流通をスピードアップすることで緊急時に命を救うソフトウェアを構築するプロジェクトに取り組んでいます。多くのNGOは私たちのソフトウェアを必死に必要としており、私たちは数週間遅れています。

このプロジェクトで私が心配していることの1つは、コーディング標準に過度に焦点を当てていることだと思います。python / djangoで記述し、さまざまな変更を加えたバージョンのPEP0008を使用します。たとえば、行の長さは最大160文字で、可能な限りすべての行を長くする必要があります。クラス、問題を解決するための最良の方法などではない場合でも使用する必要がある多くのテンプレートなど。

あるコア開発者は、システムの主要部分を1週間かけて書き直して、当時の新しいコーディング標準に適合させました。その過程でいくつかのテストスイートを破棄しました。失われたすべての機能を書き直し、バグを修正するのに2週間を費やしました。彼は主任開発者であり、彼の言葉には重みがあります。そのため、これらの標準が必要であるとプロジェクトマネージャーに確信させました。ジュニア開発者は、言われたとおりにします。プロジェクトマネージャーは、これらすべてについて認知的不協和音を強く感じているが、それでも他に何をすべきかわからないと感じているので、激しく同意しているように感じます。

今日、キーワード引数のコンマの後にスペースを入れるのを忘れていたため、深刻な問題に直面しました。Skypeの通話中に、私は文字通り他の2人の開発者とプロジェクトマネージャーに怒鳴られました。個人的には、コーディング標準は重要であると思いますが、それらに夢中になるのに多くの時間を浪費していると思います。そして、これを言葉にすると怒りを引き起こしました。私はチームのトラブルメーカーとして見られています。チームはその失敗のためにスケープゴートを探しています。コーディング標準が導入されて以来、チームの生産性はかなり低下しましたが、これは強迫観念を強めるだけです。つまり、リード開発者は、標準に準拠していないことを進歩がないと非難します。彼は、私たちが慣習に従わないと、お互いのコードを読むことができないと信じています。

これは粘着性に変わり始めています。今、私はさまざまなスクリプト、autopep8、pep8ify、PythonTidyを変更して、規則に一致させようとしています。また、ソースコードに対してpep8を実行しますが、標準に対する暗黙の修正が非常に多いため、それらをすべて追跡することは困難です。主任開発者は、pep8スクリプトが検出しない障害を選択し、次のスタンドアップミーティングで叫びます。毎週、既存の動作するテスト済みのコードを書き換えることを余儀なくされるコーディング標準への新しい追加があります。私たちにはまだテストがあります（ありがとう、いくつかのコミットを元に戻し、彼が削除したコミットの多くを修正しました）。

その間、締め切りに間に合わせるように圧力が高まっています。

基本的な問題は、リード開発者と別のコア開発者が、他の開発者が自分の仕事をするのを信頼することを拒否していることだと思います。しかし、どのように対処するのですか？私たちはすべてを書き直すのに忙しすぎるので、仕事をすることができません。

私は、ソフトウェアエンジニアリングチームでこのようなダイナミックに遭遇したことはありません。彼らがコーディング標準を順守していることを疑うのは間違っていますか？他の誰かが同様の状況を経験し、どのようにうまく対処しましたか？（私は人々が見つけた実際の解決策だけの議論を探していません）

コーディング標準は問題ではありません。問題は、管理者が問題の内容を把握できないことです。これは、「何か...何でも！」につながります。モード。あなたは合理的な解決策を探していますが、それは不合理な問題です。できることは次のとおりです。

• 彼らのアイデアに対して建設的な批判をするが、決定が下されたら、それについて絶えず泣き言を言うな。
• 書き直しを簡単にするために、できる限りのことをしてください。
• ストレスをやめます。締め切りの遅れは経営者の問題であり、あなたの問題ではありません。最善を尽くしますが、彼らの貧弱な決定に対して責任を負いません。
• 役立つかもしれない何かを知っているなら、彼らに伝えてください。スタンドアップについての言及は、アジャイルをしようとしているように聞こえますが、残りはそれほどアジャイルに聞こえません。すべてを1つの大きな期限に合わせようとする代わりに、限られた機能を早期に提供できるかどうかを確認します。書き直し用のユーザーストーリーを作成して、バックログへの影響を明確にします。
• 別の仕事を探し始めます。真剣に。そのような状態の企業は、人々を解雇し始めることからそう遠くありません。
• 「教えて」Tシャツを印刷してもらいましょう:-)

出荷またはコーディング標準への奴隷的遵守が真の優先事項であるかどうかを決定する必要があります。私の好みが何であるかを知っています。ユニットおよび受け入れテストに合格している場合、私は船と言います。出荷されると、会社は技術的負債を修正するために時間とお金を費やすかどうかを決定できます。

カンマの後のスペースの問題は、コードをきれいにするツールで簡単に解決できます。すべてのコーディング規約を実施するツールを見つけて、ビルドおよびテストが行​​われる前に、変更されたすべてのコードでそのツールを実行します。あなたがコードを書いている間に、まともなIDEはすでにこれをしています。

彼らがコーディング標準を順守していることを疑うのは間違っていますか？

グループによって異なります。個人的に、私はすべてが疑問視されるべきだと思います。一部の人々はその質問をa辱だと考えています。私は彼らを信用していません。

他の誰かが同様の状況を経験し、どのようにうまく対処しましたか？

これらの標準が生産性をどのように改善するかを尋ねました。私は、標準と「物事を成し遂げる」ことをやりくりするのに費やした時間を測定しました。最後に、標準に固執することを決定した力。それは起こります。物事を成し遂げることができなかったが、仕事を成し遂げることに焦点を当てていたので、いつもよりも大きな声で不平を言った。物事について絶えず戦うことは生産性にとっても良くありません...

あなたが言うように、物事が標準のために測定可能なほど悪い場合、標準に従うことはリードの議論を無効にし、あなたのものを残すべきです。標準の実装と生産性の低下との間に（大部分）客観的な相関関係が見られない場合、それ以上のことはできません。それに対処することを学び、それができない場合は、官僚的でない場所を探してください。

標準は、期限が迫っているプロジェクトの後半に導入されるべきではないものです。これは、プロジェクトの早い段階で、または（潜在的に）大規模な問題のあるコードのリファクタリングのために、プロジェクトスケジュール（できれば初期出荷後）に時間を置いておく必要があります。

これが実際にプロジェクトの後半に投入された場合、それはあなたのリード（IMHO）が犯した間違いです。

ただし、これは、リードに同意しない場合は、反乱で先に進むべきだという意味ではありません。これがあなたの仕事です。あなたはチームとして働いています。あなたは持ってリードを。確かにチームにはある程度の民主主義が必要ですが、最終的にはリードが独裁者です。彼が何かをするように言ったら、あなたはそれをします。

最後に、彼の要求と基準を順守するために、あなたは彼/彼女に期限を逃すための簡単なスケープゴートを提供しません。

また、私は（特にチームの規模が大きくなるにつれて）コーディング標準の大擁護者ですが、理にかなっているときに実装する必要があります。

あなたの質問は、「彼らがコーディング標準を順守していることを疑うのは間違っているのですか？」 http://c0x.coding-guidelines.com/Introduction.pdf（Cプログラミング言語用）には、コーディングガイドラインの価値に関する参考文献がいくつかあります。39ページ以降のセクション9を参照してください。

コーディング標準は、理由のために実装されています。元の質問から欠落していると思われることの1つは、特定のプロジェクト（または特定の組織）におけるこれらの特定の基準の理由を理解することです。既存のコードにそれらを実装する決定は、いくつかのロジックに基づいていました。論理を知らなければ、その決定の「良さ」についてコメントすることは困難です。

次に、標準は「長期生産性」のために実装されていると誰かが言ったこと、つまりコードの保守性などの問題を取り上げます。混乱と誤解のためにプロジェクトをひどく元に戻す何らかのイベントが発生したのかもしれません。

両側に多くの感情があるように思えます-理にかなった議論に取り組もう。

おそらく他の回答やコメントで見たように、プロジェクトには大きな問題がありますので、私が提案することは大きな成功の可能性はありませんが、それについてはあまり大きなリスクなしで試すことができますあなた自身の肌。

主任開発者と4つの目で会うように依頼してください。コーディング標準を厳しくすることの利点と、コードベースを導入する前にコードベースがこんなに悪い形であった理由を完全に理解することに興味があるとしましょう。この議論の間、あなたが非常にオープンで「私は学ぼうとしている」態度を保つことは非常に重要です。あなたのリード開発者は、おそらくあなたやあなたのチームの他の誰よりもすでにストレスを感じており、批判を嗅ぐとすぐに非常に防御的になるでしょう。

共通の目標を達成する方法を見つけようとする方向に議論を少しずつ進めてください。実用的で保守可能なソフトウェアを迅速に提供します。

たとえば、いくつかの懸案事項は、コーディングガイドラインにこれ​​以上追加しないことです。それが起こるたびに、以前はガイドラインに準拠していたコードはもはや実行されず、その結果、コードのチャンクを書き直す必要があります。リード開発者は、追加されたルールが（彼の観点から）値を追加したとしても、すでに後期のプロジェクトのこの段階で書き直しを動機付けるほど良くないかもしれないことを願っています。

これが機能する場合、何らかのツールでは自動フォーマットできない、よりarbitrary意的なルールを削除してもらうことができます。

コーディング標準は良好です。コーディング標準の変更はコストがかかります（許容度を低くするとコストが高くなります。標準の変更によって既存のコードがすべて準拠している場合は問題ありません）。したがって、絶対に必要な場合にのみ実行してください。

たぶん、1つのことは、コミット/マージ/何でも前にすべてのコードをリードにチェックして、標準に準拠していることを確認することです。既存のツールチェーンは明らかにそれを自動的にチェックできないようです。

食料の流通をスピードアップすることにより、緊急時に命を救うのに役立つソフトウェア

私は良いコーディング標準を信じていますが、それも信じています ますが、命救うことの方がはるかに重要ます。

あなたの最大の優先事項は、人々の命を救うことですです。このソフトウェアがあなたの家族やあなたのチームに食べ物を配布していると想像してください。他のものは次に来ることができます。

良いニュース：テストがあります。テストは、機能を損なうことなくコーディング標準に準拠するのに役立ちますが、これは出荷前ではなく出荷後に行う必要があります。