ロープの終わりに[閉じた]

私は大企業の請負業者です。現在、プロジェクトには3人の開発者がいますが、私も含めています。

問題は、他の2人の開発者が実際に理解していないことです。「それ」とは、次のことを意味します。

• 彼らは私たちが使用している技術のベストプラクティスを理解していません。私と他の人が彼らに例を与えてから6ヶ月後、ひどいアンチパターンが使用されています。
• 彼らは、主にスパゲッティコードを生成する「コピーアンドペースト」プログラマです。
• 彼らは絶えず物事を壊し、変更を実施しますが、すべてが良いかどうかを確認するための基本的な煙のテストを行いません
• 彼らは、コードレビューの依頼を拒否/​​まれにしています。
• 彼らは、コードのフォーマットなどの基本的なことを拒否/まれに行います。
• クラスに関するドキュメントはありません（jsdocs）
• 何もしないコードを削除することを恐れる
• バージョン管理を行っていても、コメントされたコードブロックはどこにでも残します。

他のコードをフォーマットし、バグを修正し、壊れた機能を発見し、スパゲッティを削除するための抽象化を作成するにつれて、私はますますイライラしています。

私は本当に何をすべきかわかりません。欲求不満にならないようにしていますが、それは単なる混乱です。私はこれらの人々を人間として気に入っていますが、コーディングの状況がひどく、一日中ウェブを閲覧していれば、より速く動くことができると感じています。

マネージャーに他のsvnコミットアクセスを確認するように依頼するのは行外でしょうか。コミットは、私たちがやっていることに精通している人によるレビュー後にのみ行うことができますか？請負業者として、それが最善の策かどうかはわかりません。

修正しているものの数を明確にする微妙な/それほど微妙でない方法はありますか？

私は自分のチームでこのようなことをしています。人々に正しいことをさせようと懸命に努力しましたが、期待通りに機能しなかったため、別のソリューションに移行しました。

まず、マネージャーに行き、取引を行いました。単体テストでカバーされていない限り、ソース管理にコードは一切入りません。単体テストなしでコードが入った場合、私はすぐにコミットを取り消すことができ、テストに取り組んでコードをプッシュできる担当者にpingを実行する拒否権があります。

このルールを導入して、コードカバレッジツール（この場合はsbtビルドのjacoco）を定期的に実行して、ピースが正しくカバーされていることを確認し、それらによってプッシュされたコードでリファクタリングとコードレビューを常に行っています。これは通りのJavaとScalaのプロジェクト私はすべきではないか、それはあなたと同じことを行うことができる方法ではないことを確認、我々はそれが必要だと思うように動作しませんヘルプ私のキャッチのものにツールがたくさん持っているJavaScriptの多分そこにあるの解決策。

私がこれに遅れずについていくのを助けると信じている主なことは、私がプロジェクトに期待していることとそれがメインのアーキテクチャであるという明確な見方を持っているということです。修理する。同じことを行い、ビュー、使用するパターン、コードの記述方法を定義し、その上に自分自身を置いて、常に何が起こっているのか、何がプロジェクトを進めないのかを彼ら（および管理者）に知らせる必要がありますもっと早く。

彼らが断念して正しいことをするか、経営陣がメッセージを受け取ってプロジェクトから削除する瞬間が必ずあるでしょう。

私のコメントや他の投稿を見たことがあると思いますので、実際に答えを知っているふりはしません。私が提供できる最高のものは、他の人から聞いた/読んだものの要約であり、自分の経験の一部をミックスに追加します。

まず、少し前に、私たちのプログラマーSEメンバーの1人であるMartin BloreとIMOに属するブログに出会いました。TDDの自己実現に関するこの特定の投稿は非常に正確です。TDDはすべてを結び付ける最後の最高レベルですが、以前のレベル、特に最大のもの、明確で読みやすいコードを生成する原則と慣行がなければ、TDDを機能させることは不可能ではないにしても非常に困難です。

私の会社では、アジャイルとTDDの両方が経営陣から課せられました。最初は、アジャイルの反対であると言われたため、最初にそれを行いました。私たちはTDDを2回試しましたが、私は自動化されたテストの使用を強く支持していますが、前回のリリースでチームが平手打ちしたものをすべて捨てました。彼らは壊れやすく、巨大で、ワズーをコピー/ペーストし、スリープステートメントでいっぱいで、本当にゆっくりと予測不能に実行しました。あなたのチームへの私のアドバイス：TDDをしないでください...まだ。

あなたは、あなたが会社に6ヶ月しかいなかったとあなたが請負業者であると言ったので、あなたの状況が何であるか分かりません。あなたの長期的な目標はこの会社にとどまることですか、それとも契約は切れるでしょうか？あなたが何かをしたとしても、実際に結果を見るにはかなり時間がかかるかもしれないので、私は尋ねています。

また、チームに参加するとき、チーム（開発者と管理者）が提案するものを検討する十分な信頼性と尊敬を得るまでには通常時間がかかります。私の経験では、ほとんど火を消さず、他の人が頼ることができるスキルと知識を持っていることを実証するのに役立ちます。6か月で十分かどうかわかりません。かなり頻繁に、新しい野心的な人がチームに参加し、ここで彼らが世界を変える方法を尋ねる投稿をします。悲しい現実は、彼らが単にできないということです。

だから、あなたはあなたのチームの尊敬と注意を持っていると仮定します。それで？

まず、管理者と開発者の両方が問題があることを認識する必要があります。管理対策は、成果物の観点から結果をもたらします。彼らが機能の現在の量と品質に満足しているなら、悲しい現実は彼らが聞かないということです。他の人が指摘しているように、経営陣のサポートなしでは、何らかの変更を導入することは非常に困難です。

管理サポートを取得したら、次のステップは、チームがそのように運営する理由の根本原因を深く掘り下げて特定することです。この次のトピックは、少し前の私の個人的な探求です。これまでのところ、これが私の旅です。

1. 経営陣のサポートが得られたら。MainMaが私の質問に応じて提案した、中央で指示された多くのプラクティス/プロセスの導入を開始できます。私たちはそれらの多くを行いました（ペアプログラミングを除く）。あなたには間違いなく利点があります。コードレビューは、スタイリング、ドキュメントの標準化に特に役立ち、チーム間で知識/技術を共有することもできました。コードレビューは口述されたものの、チームは実際にそれらを気に入っており、チェックインされたすべての機能をレビューします。しかし...
2. 一般的に書かれているコードはまだ結合しすぎており、設計が悪いか、完全に欠けていることに気づきます。コードレビューはその一部をキャッチしますが、書き直すことができるのはそれだけです。そもそもデザインが悪いのはなぜですか？-多くの開発者がグッドプラクティスを紹介されたことはなく、そもそもOODを正式に教えられたことはありません。多くの人は、与えられたタスクを「単純にコーディング」します。
3. 管理者のサポートにより、コーディングを行う前に設計について議論するなど、より多くのプロセスを導入できます。しかし、あなたはたった一人であり、あなたが注意を払わないとすぐに、チームは彼らがいつもやったことへと戻るようです。どうして？
4. 常に監視する必要がないように、より良い実践や習慣を導入して教えることができますか？-この部分はそれほど簡単ではないことがわかりました。
5. 他のチームメンバーが新しいプラクティスを学び、習得するのを嫌がるのはなぜですか？また、現代のソフトウェア方法論の文献で多くのことが書かれているのに、なぜ彼らはSOLIDやDRYにそれほど抵抗しているのでしょうか？2週間前にチームで行ったすべての前向きな変更により、同じ15行のコードを持つ2つの関数をリファクタリングし、レビュアーはそれをコピー/貼り付けだけで何も悪いことはないので、英雄的で不必要な努力と呼びました15行。私はそのような意見に強く反対しますが、今のところ私たちは反対することに同意しました。 - んで、どうする？これで、もう1つの投稿のトピックに到達しました。
6. 以下のようmaple_shaftとnikieがその答えで指摘（申し訳ありませんが、MainMa、あなたが最も多くの票を得たが、あなたがそう背後:) 5段階ある）、あなたは「プロセス」は、あなたとこのフォーラム上の誰も、もはや助けをすることができ、ステージに達しています「修正」とは何かを伝えることができます。次のステップは、多分一対一で、多分チームとして、おそらくいつか両方で、彼らに話しかけることです。何が機能し、何が機能しないかを尋ねます。何が彼らを動かしているのかの根本原因を特定する唯一の方法は、彼らと個別に話し合ってそれを見つけることです。このステップの一環として、最近、まったく異なるチームの問題に遭遇しましたが、ジョエルの答えはここにあると思います、これは非常に詳細で洞察に富んでおり、この場合にも当てはまります。要約すると、「ショートリーシュ」として管理を使用することはほとんど何でも可能なアプローチですが、純粋な管理や技術的リーダーシップよりも精神分析に深く入り込まなければならない動機を真に理解するために、人間を扱っていることを覚えておく必要があります。
7. だから今、あなたはあなたのチームメイトと話していますか？何を頼みますか？私はここに行ったことがないので、この次の部分についてはわかりません。考えられるシナリオは次のとおりです。Q：どうしてソリッドがないのですか？A：必要ありません。Q：役に立つかもしれません。A：私は大丈夫です。-どういうわけか、口から出る一連の音を生成する必要があり、リスナーは、あなたが行商をしているものを何でも与えれば物事が良いかもしれないことを認識するようになります。あなたがここで失敗した場合、彼らは「プロセス」が彼らにさせるものが実際に価値があると確信することはありません。一方、この点を超えると、おそらく「プロセス」さえ必要ないことに気付くでしょう。
8. 根本的にIMOは、あなたのチームメイトが彼らの現在の習慣/慣行に何も問題がないかどうかを学ばないでしょう。したがって、このすべての次のステップは、問題を説明し、強調表示して、それらを明らかにする方法を見つけることです。結局のところ、読みやすいコードを書いたり、SOLID / DRYの原則を使用したり、ドキュメンテーションを維持したりするのは、温かくてあいまいな感じがするからです。より良い品質のコードを生成し、率直に言ってコードを高速化するためです。それは測定できますか？たぶん、これがソフトウェアメトリックの出番でしょうか？
9. これはクレイジーなアイデアであり、実際に機能するかどうかはわかりません（標準的な業界慣行かもしれませんし、完全に無効かもしれません。過去24時間以内に作り上げただけです）。来年が始まるとすぐにテーブルに：
   • 他の多くの意見に反して、すべてのソースファイルについてAuthor / Ownerのアイデアを紹介します。実用的なプログラマーが示唆これは、ソースコードの一部を担当する一人に所有権と責任感を与えます。他の人がコードを変更できないという意味ではありません。私たちは全員チームとして働いていますが、結局のところ、コードを所有している人が変更をレビューする責任があります。
   • すべてのチェックインを監視し、特にバグ修正であるものを探すソースリポジトリトリガーを作成します。すべてのバグ修正がチェックインの説明の前に参照識別子を持つように、それをプロセスにします。次に、変更されたファイルのリストを解析し、ファイルヘッダーのコメントブロックから「作成者」を取り除くスクリプトを記述します。ファイルごと、プロジェクトごと、作成者ごとにチェックインされた欠陥の数を追跡するSQLデータベースを作成します。
   • 十分な統計情報が得られたら、他のコードよりもコードの欠陥/変更が少ないことに気付くでしょう。これは、使用できるハードデータです。1つのプロジェクトの平均不良率が大幅に高い場合は、技術的な負債を返済するための次のクリーンアップ/リファクタリングの候補として取り上げてください。
   • プロジェクトまたはファイルの平均不良率が著しく高く、所有者が1人いる場合は、その人と1対1で話し合ってください。これに対処するために何ができるかを、非常に丁寧に、非対立的に尋ねてください。彼らは所有者であるため、彼らは変化を促進する必要がありますが、あなたの側からのすべての助けを提供します。うまくいけば、所有者が自分のスパゲッティコードの原因の多くを追跡し、助けを求めるとすぐに、それがあなたが行動を起こし、いくつかの固いものを置くときです。

マネージャーに問題について話をすることをお勧めしますが、彼はすべてのチェックインを確認したいとは思わないでしょう。

代わりに、SVNにフックし、チェックインごとに実行する一連のユニット/回帰テストを提案することをお勧めします。少なくとも、ビルドが壊れないようにするのに役立ちます。他のベストプラクティスを徐々に提案できます。

もし彼が全く受け入れられないことがわかったら、彼の頭を越えて行くべきかもしれません。あなたがそうすることに決めた場合、あなたはあなたの最高のゲームを持参する必要があります。あなたがそれをするならば、あなたは基本的に経営陣に高いレベルで雇われるために投げかけるでしょう。