プロジェクトであまりにも多くの実用主義に対処するには？
私のチームと私は、前の技術主任が退職した1年以上前に中規模のコードベースを引き継ぎました。人間力の欠如に端を発する私は、ベストプラクティスよりもpragmaticのソリューションを少し多めに採用することを恐れています。
今、私はコード品質の一定の低下と日々のプロセスのある種の有機的成長に対処しなければなりません。 1年前にコード規約を尋ねられたとき、私は基本的に常識を唯一のルールとして与えたことを後悔しています。すぐにプログラマーはさまざまな構文スタイルを使用し、マージプロセスでこれが引き起こす困難を理解できなくなりました。別の例は、データベース移行スクリプト用の私のプッシュです。私は Flyway をプロセスに組み込もうとしましたが、わずか1週間で上司にすぐに却下されました。データベース移行スクリプトの今後の必須の使用について警告し、移行の欠落または失敗が原因でアプリケーションが起動しないという問題を軽減するための手がかり、ヒント、およびツールを提供したにもかかわらず、彼らは私に不満を言うのが最善であると判断しました彼らが仕事をすることができないことについてのボス。 Flywayを再び強制的に無効にしたところ、適切なタイミングでそれぞれのデータベースに適用することを忘れてはならない、ネットワーク共有上の任意の名前付きSQLファイルでの移行手順について説明します。
私たちのプロセスの1つの問題は、正式なコードレビューを行ったことがないということです。そのため、hacksの多くがレーダーの下でコードベースに侵入し、誰かが時間に気づくことはありませんでした。現在、私は時間があるときにチームメイトのチェックインを読む傾向がありますが（多くの場合そうではありません）、不要な変更を防ぐための自動プロセスはありません。問題の開発者のところに行き、彼らが彼らのコードがなぜ悪いのかを認めるのを容易にするように試みるのは私次第です。 FindBugsやCheckstyleのような糸くずのようなツールを導入することを考えましたが、データベースの移行で行ったのと同じ心理的な問題に直面するのではないかと心配しています。結局、私は彼らのために彼らの仕事を難しくします、そして、これがなぜ誤解につながるかもしれないか理解できます。
だから私の質問は：仕事を終わらせるが正しく実行していますか？
推測してみましょう...発生する問題のストリームは無限であり、誰もより戦略的なことに取り組むことができないため、毎日のプロダクションサポートに夢中になっている開発者のチームがいますか？
どのような答えが得られるかを知りたいと思いますが、あまり悲観的になることはありませんが、主に私の最初のアドバイスがget managementあなたの側で、そしてこれらの引用は私にそれが難しいだろうと思わせます：
私はすぐに上司に却下されました
そして
仕事を成し遂げることが、正しく行うよりもはるかに高く評価される環境
これを決定と結果のギャップと呼びます。決定を下す人々は、決定の結果に苦しむ必要はありません。決定が悪い場合、フォールアウトはしばしば他の誰かの問題です。決定が良かった、または悪かった、そして他の人のハードワークがそれを良さそうに見せたなら、もちろん、意思決定者は信用します。
私はここであなたを悩ませているわけではありません。これらの問題は、ほとんどの企業のITショップや企業の世界全体で見られる悲しいことに体系的な問題です。それが彼らがすべてのプロジェクトで品質よりも納期を狭くする原因となっています。そしてもちろん、彼らは最初に上司によって最初に判断されるので、そうします。彼らの誰もがソフトウェアの欠陥に耐える必要がないので、品質は彼らにとって本当に重要ではありません。
理想的なソリューション
とにかく、「ハッピーパス」のシナリオは、経営陣が同意することです。
- コードの主要な欠陥を修復およびリファクタリングすることに集中して取り組む間、新機能の開発を中止します。
- 彼らはそれに取り組んでいる間、ベストプラクティスの価値を認識するほどスマートではなく、ハックスタイルのコーディングを変更したくない人をチームから解放する力を与えます。くだらない開発者を取り除くことは、リファクタリング自体よりもおそらくチームにとってさらに価値があります。優れた開発者は、時間とともにリファクタリングし、時間の経過とともに物事を自然に改善する方法を見つけるでしょう。
このシナリオの管理者は、戦術的な問題（ユーザーの手持ち、データの修正、難解なタスク、およびその他のさまざまなおむつ）によって混乱しているチームに支払うと、ボートのリークを修復する必要があるか、多くの時間とお金が失われることを認識しています。変更）戦略的ではありません（ユーザーの効率を可能にし、顧客に向けた出力の品質を向上させ、新しい収益の流れを可能にする新しい機能）。
実用的なソリューション
見てください、あなたがすでに私たちに言ったものに基づいて、上の理論的な理想が起こりそうにないことを知っています。これにより、あなたとあなたのチームは自分でこれを処理する方法を見つけることができます。
- 必要な基準を確立します。あなたはそれをあなたの投稿で述べました。それらを公開し、チームにその価値を理解してもらい、今後のすべての作業の実装を開始します。新しい機能が問題を追加しないため、コードが成長しても問題を安定した負荷に保つことができる場合、それは厳しい状況に対して小さいながらも称賛に値する勝利です。
- リファクタリングはおそらく最良のアプローチの1つです。修正に取り掛かる必要があるときはいつでも、そのスクリプトをクリーンアップして改善する機会を利用してください。管理者が指示された修復作業をサポートできない場合は、コードをゆっくりと進化させてください。少し残業をする必要があるかもしれませんが、改善はなしよりもましです。ここでの問題は、それが個々のスクリプトに対して機能することですが、大量に同時に発生する必要があるシステム全体の変更にはあまり適していません。ただし、新機能のリクエストがあった場合は、さらに大きな変更を加えることができます。あなたは機知に富む必要があります。承認されていない作業を実際に承認していると思ったプロジェクトマネージャーが手を叩いたことがあります（私はそうではありませんでした。システムの一部を修正し、新しい要求された機能を有効にする変更を実装していたため、重要な部分でした）プロジェクト）。
- 人員配置を変更しますか？チームの背後にある完全な話がわからないので、順番に話をしたくはありませんが、ずさんなクイックフィックスに非常に慣れており、コードレビューなどのベストプラクティスを高く評価していないようです。解決するよりも多くの問題を引き起こしている人々を特定した場合、おそらく彼らは別の場所に置くことができます。これは政治的に正しくないため、最近の経営陣は人を無能な状態で解雇することを好まないため、これは難しい問題です。彼らは誰かの感情を傷つけただけで人々を解雇します。しかし、それは要因なので、私はこれについて言及します。貧しい開発者は、チームの残りの努力を妥協します。あなたは彼らに改善するよう説得しようとするのに何時間も費やします、そして彼らが生産に入るように管理するどんな仕事でもより多くのサポートを作成します。
本当に実用的なソリューション
Stackexchangeサイトの人々の多くは、せっかちでもあり、すぐに「立ち去るだけで、お店がこれ以上良くならないことは明らかです」とすぐに頭が良い人です。
あなたが本当に良くならないだろうと本当に感じているなら、私は彼らに同意します。ただし、少なくとも私の経験では、同じ問題が発生する可能性があるため、注意が必要です。
また、このサイトのサイドバーには、アドバイスを求めて調べることができるいくつかの同様の質問がリストされています。
あなたは技術的負債を回避するつもりはありません、それは商業的に必要です。あなたがそれを手に入れる上司を持っているのに十分幸運であっても、彼らは私が昨日それを必要としていると言います、または彼らが奇妙な難解なプロペラの頭の美学であると考えるもののためにそれを改善するためにレガシーコードを再加工するリスクはそうではありません許容できる。
あなたがCIOであったとしても、同僚にベストプラクティスを課すという非常に困難なタスクがあり、それが彼らが「最高」であることに同意できたとしてもです。
最良のアプローチは、特に食物連鎖の最下位にいる場合、自己防衛です。
彼らがこのようにそうするなら、アイデアを得ることができます。それはあなたの仕事をより簡単にします。それらをすべて難解なものにしないでください。適切なネーミングプラクティス（ハンガリー語の表記ではありません）と一般的なアーキテクチャは、あらゆる種類の理解の問題を軽減できます。エンティティをフォームに表示するルーチンのように単純なものは常にDisplaySomeEntityNameと呼ばれます。単純なものから始めようとしないでください。有機的に一緒に構築します。
それは私が得ている印象にすぎないかもしれませんが、重要な点は、コードレビューを、お互いを批判せずにお互いを助けられる時間にすることです。あなたがそれを間違ったのではありません。あなたが何をしたのか理解できません。
したがって、あなたが彼らのコードをレビューする代わりに、彼らにあなたのコードをレビューしてもらいます。それが良い習慣であり、それが物事をより簡単にするなら、彼らはそれを始めるでしょう。あなたがそれを間違っているかもしれないことを知らないでください、私はこの種のことについて少し頭がおかしいですが、私がそれを書いた直後に私のコードが私に理解できるだけであるということで私は数回以上プルアップされました。 ...