上司を説得してコードの品質を向上させるにはどうすればよいですか？
私が働いている場所はサービスプロバイダーです。締め切りに対応するために書かれたサービスがたくさんあるので、それらのコードは本当にひどいです：
- コーディング規約はありません、誰もが自分のスタイルでコーディングします
- 単体テストなし（これは本当に悪い）
- リファクタリングなし（本当に悪い）
- 自動化ビルド/デプロイメントなし
等
そして、これらのコードは何度も何度も使用されているため、悪いコードが私の部門全体に広がっています。
すべての人に「ルール」に従うことを要求することで、コードに標準品質を設定したいのですが、規則に従わないすべてのコード行は拒否され、ユニットテストに合格しないコードのすべての関数はコミットされません。 、...でも、上司にこれを許可するように説得する方法がわかりません。私は比較的新しい人なので、私の作品から人々を刺激することは本当に難しいです、そして私の上司がこれをサポートしてくれればもっと簡単だと思います。
アドバイスありがとうございます
私はあなたの上司から始めません。あなたの会社の他の開発者も、あなたのコードの品質について同様に懸念していると思います。昼休み中に彼らと一緒に座り、問題について話し合い、共有スタイルガイドに同意します。
しばらくの間、新しいコーディング規則を使用して、会議中に結果を提示します。「[勇敢な同志]と一緒に、これらの規則[スペックファイルへのリンク]の使用を開始しました。これにより、生産性が本当に向上し、簡単になりました。コードのレビュー中にタスクを分散し、バグを見つけます。」.
コード規約のエントロピーの減少と、より整然としたマージリクエストを熱心に検討するなどのソフトテクニックを併用すれば、残りの同僚を正しい道に導くのに十分である可能性があります。
これはうまくいくはずではありません。一貫したスタイルがどのようにしてより安定した、より理解しやすいソフトウェアにつながるかを上司に示すのに十分な経験的データを収集しているでしょう。また、スタイルチェックをマージの前提条件として提案することもできます。
彼女が同意する場合、あなたはあなたが言及した他の問題のためにプロセスを繰り返すことができます-余分な先行投資がないので、私は最初にコーディングスタイルに取り組むことを提案しました。
技術的負債について彼に説明し、常に「頭金」を支払うことによってそれを抑えることが重要である理由を説明する。そうしないと、家賃を払って何もせずにすべての時間を費やす必要があります。
彼らの財布に直接話しかけるので、私はその比喩が本当に好きです。
利益を得るためのコストがすべてです。ほとんどの経営陣は、開発グループでこれらのものを開発するために、時間、労力、および費用を前もって投入することで、後でより低いコストで彼らに報いることができるとは考えていません。彼らは当面のコストのみを計画し、当面の最短かつ最安の道を歩みます。ほとんどのビジネス環境でその考え方を変えようとすると、多くの時間と労力が必要であり、これらの新しいアプローチの金銭的なメリットが実証されてから、最終的には沈み込みます。
あなたの会社の目標はおそらく美しく完璧なコードを生成することではないことを覚えておく必要があると思います。個人的には、コーディング標準（特に厳格なもの）は、アプリケーションの品質への有用な貢献というよりは、マイクロマネージメントツールであると思います。ほとんどの場合、コーディング標準は非常に最小限に抑える必要があります。
たとえば、左中かっこで改行するかどうかの基準を設定すると、コードの可読性がどういうわけかばかばかしくなります。整合性はいいです、見た目はきれいですが、実際に組織に追加の価値を生み出していると主張できますか？
リファクタリングに関しては、それは許可よりも許しを求めるほうが良いことの一つに過ぎません。それらはあなたが進むにつれてリファクタリングすることを積極的に妨げますか？本当に？多くの場合、開発者が山頂から石のタブレットを待ち望んでいるときに、リファクタリングなどの優れたコーディング手法を採用するのを待っています。上司が肩越しに見ていて、リファクタリングしているように見えるときに頭の後ろを平手打ちしている場合は、問題がある可能性があります。けれども、プログラマーが自分でそれを行うのに十分な自律性を持っていないという店はめったにありません。見積もりにその時間を含めることを忘れないでください。
ユニットテスト：ユニットテストの欠如が重大な品質問題を引き起こしている場合、上司に販売するのに苦労することはないと思います。そうでない場合は、なぜ不平を言うのですか？ちょうどそれを提案し、あなたのケースを作り、あなたの人生を続けてください。
一番下の行は、会社の一番下の行に関してあなたの主張をする必要があるということです。あなたが提案することはすべて目的を達成するための手段に過ぎず、その目的はユーザーのニーズを満たすのに十分な品質のアプリケーションです。現在のリリースの問題（品質または納期）に関して正当化できない場合は、作業成果物ではなくツールにこだわっていると考えるかもしれません。最終的な成果物に関して正当化を見つけることができる場合は、それらの苦情とビジネスへのコストを指摘し、それらを改善するために提供できるあらゆるコーディングプラクティスに結び付けてください。
結論：問題を上司の問題に変えようとしないでください。彼/彼女の問題の1つを取り、あなたがより良い実践でそれらを解決する方法を説明してください。
管理者に何かを行うか行わないかを納得させる唯一の良い方法は、それが収益にどのように影響するかを示すことです。
あなたとあなたのチームおよび/または技術リーダーは、コーディング規約、ユニットテスト、および自動化されたビルド/導入ツールがチームの時間を節約するか、生産性を向上させる方法を示す必要があります。リファクタリングに費やす時間を正当化するために、新しい機能を追加せずに既存のコードをクリーンアップするために今すぐn時間費やすと、実装とデバッグの時間をm時間節約できる（m> n）ことを示す必要があります。
たぶん、1つのステップでやりすぎているでしょう。 「慣例に従わないコード行はすべて拒否されます」と、自分のやり方で自由に慣れている人にとってはかなり威圧されるかもしれません。また、あまりにも制御しすぎているように思われ、他のシステムとのやり取りがほとんどない短いコードでは、正式なレベルのソフトウェアエンジニアリングは必要ありません。また、SEを深く適用することはコスト効率がよくないでしょう。
たぶん、企業のSE環境/文化の段階的な改善がより実現可能です。比較的議論の余地のないいくつかの改革を見つけ、その価値を明らかにしてから、次のステップに進みましょう。
場合によります ;）
製品を提供してきた歴史を教えてください。安定した製品で目的の機能を時間どおりに提供しますか（つまり、安定した状態で、内部で起こっている恐ろしいことを見ることができないエンドユーザーは、安定していると認識していますか？）
そうでない場合は、上司にあなたが提供している製品に満足しているかどうか尋ねます。もしそうなら、私は別の仕事を見つけるでしょう。しかし、おそらく彼はそうではありません。そして、私は彼にそれらを確実にすることができるプロセスがあることを啓発します。
Steve Mcconnelの より優れたソフトウェアプラクティスのビジネスケース と ソフトウェア開発の懸案事項 を参照してください。
1つ目は、生産性、スケジュール、および欠陥の改善を示しています。
ゴールドラッシュ後の開発手法に投資する企業は、投資が報われることを発見しました。 1994年、James Herbslebは、体系的な改善プログラムを採用した13の組織の平均「ビジネス価値」（投資収益率とほぼ同じ）は約5対1であり、最高の組織が9対1の利益を実現すると報告しました。 1995年、ニールC.オルセンは、人員配置、トレーニング、および作業環境に多大な投資を行った組織に対して同様の利益を報告しました。 1997年にRini van Solingenは、平均ROIが7対1で、最高の組織が19対1の利益を実現していると報告しました。2000年に、Capers Jonesは、プロセス改善からの投資利益率が2桁になる可能性があると報告しました10以上1）。 Watts Humphreyによる最近の分析では、改善されたソフトウェアプラクティスのROIは5対1またはそれ以上に近い可能性があることがわかりました...
2番目のリストには、コーディング基準、Daily BuildおよびSmoke TestおよびTest-First Coding、あなたが尋ねた3つの問題。
Steve McConnellは、短期間でスケジュール、品質、開発コストを改善する戦略について説明しています。 McConnellは、投資収益率が最も高く、採用のリスクが最も低く、より成功するソフトウェアプロジェクトへの最短経路をもたらす特定の技術的慣行を特定します。マコネルは、短期的対長期的な改善戦略の背後にある理論を説明し、これらの戦略を採用する際の成功の可能性を最大化するためのヒントを提示します...