基本的なルールに従うようにプログラマーを説得する方法

プログラマーに非常に頻繁に従うことを求めなければならないいくつかのルールがあります。彼らはコードを書き、それがうまくいけば、仕事は完了です。最も基本的なルールは次のとおりです。

• 変更をコミットする
• ビューまたはコントローラーでモデルの問題を記述しない
• ハードコーディングを避ける

あなたの経験を教えてください。これをどのように管理しますか？

すべての知識労働者は質の高い仕事をするために挑戦する必要があります。任意の時間的制約が課せられていると感じると、品質が低下します。誰もが仕様を満たし、期限を守ることに関心があるときに、「十分に」良いものを作るだけではどうですか？

苦情のリストは、短期的な目標の達成に報いるだけで、高品質を強調したくない企業の症状です。あなたは5つ星ホテルを運営していますか、それともトラック停留所ですか？

基本的なルールに従うためには、ルールが何であるかを知り、それに同意する必要があります。

これを処理する方法は、全員が同意できるコーディングガイドラインドキュメントを共同で作成することです。彼らにこれを強制しようとしないでください、そうすれば裏目に出ます。

チームを結集して、基本的なルールの共通の定義に取り組み始めましょう！

すべての声が聞こえるワークショップとしてそれをしてください。無限の議論を避けるためにタイムボックス。あなたはいくつかの心を一緒にしようとしているので、あなたはすべて敬意を払うべきであり、心を開いておくべきであるという肯定的なノートで舞台を設定したいかもしれません（コード作成は個人的な...）。

これらのガイドラインは、追加または明確化すべき何かがあるとチームが感じるたびに変更される必要があります。

あなたの役割は何ですか？あなたがコード品質に特に強い関心を持っている別の開発者である場合は、おそらく彼らにあなたの意見を聞く権限がありません。おそらく、これらのアイデアを管理者にバブルして、あるべき/必要なコード標準を確立する必要があります続きました。あなたがマネージャー/チームリーダー/アーキテクトであり、何らかの権限を持っている場合は、自分でそれらのプラクティスを確立できます。これらを取り除くために、標準文書とコードレビュープロセスを策定します。

オンにできる魔法のスイッチではありません。処理が遅くなり、100％になることはありません。とにかくそれは私の経験でした。

これまでのすべての答えの賢明な組み合わせである必要があります。最後に、賢い人々（開発者）のグループについて話しているとき、行動が重要である理由を彼らに伝え、彼らが正しく行動するために投資されるようにその行動がどのように実装されるかを十分に制御する必要があります。頭のいい人は一般的に上記の任務は緩いです。なぜなら、問題が問題であることに同意していなければ、ルールに従うよりも任務を回避するのに多くの時間を費やす可能性が高いからです。

これが私の戦術の一部です。

変更のコミット：

まず、チームは、いつコミットするか、何をコミットするかについて合意する必要があります。絶対に不可欠なのは、理にかなったビルドのセットアップです。そのため、人々は、どこに何かを置くべきかわからないからといって、先延ばしになりません。そして、いつ/どのくらいの頻度でチェックインするかについてのコンセンサス。「ビルドを壊さない」ことは明らかな良いルールですが、どのようにチェックされ、誰がそれについて通知されますか？もう1つのベースラインは、「チェックインしないと実行されない」です。

私が知っているほとんどの開発者は、コードIFをチェックインするのがうれしいです：

• チェックインプロセスは簡単です
• 同期プロセスは簡単です（他の開発者からの変更を考慮に入れます）
• 変更を確認してバージョン間を移動するのは簡単です

私が最近気づいたことの1つは、新しいCMツールを楽しみにすると、チェックインが頻繁になり、痛みが少なくなったことです。私たちのチームは、以前Clearcaseを使用していたRational Team Concertの先駆者です。私はツールを宣伝するつもりはありませんが、多くの小さくて速いマージを伴うストリーミングチェックインの新しい（私にとっての）波により、早期かつ頻繁にチェックインすることがより魅力的になります。

開発者にCMの痛みの解消を任せると、一般に、発生するチェックインの量が増えます。

アーキテクチャの遵守-ビューおよびコントローラーでモデルの問題を記述しない

私はそれを「アーキテクチャを正しく行う」という一般的なまとまりに入れています。私はピアレビューを言った人に同意します-これにはピアのプレッシャーが大きいです。私が一般的に人々がこの分野のベストプラクティスを求めて折り畳まれていると感じる方法の1つは、同僚がなぜ他の方法でそれをしたのかを尋ねるときです（そうではない方法）。一般に、「なぜ」の質問は、人々がなぜ違うやり方をするべきなのかを自覚する道に人々を導くでしょう。人々がベストプラクティスの十分に理解された理由を持っている場合、それに従うことははるかに簡単です。

また、人を決定に結び付ける何らかの形式がある場合、その領域にバグを割り当てるのが簡単になる可能性があります...そのため、人が欠陥のあるデザイン領域のバグを修正する責任がある場合、直前に何かを取得する必要があります彼らは何か新しいことに刺激を与えることができ、エキサイティングなことが大きな動機になります。

ハードコーディングを避ける

明確なコーディング標準から始め、コーディングレビューをピアレビューに統合します。ハードコーディングは、ピアレビューの議題のチェックボックスに簡単にできるものの1つです。

私は、この種のことが、ルールを施行するチームリーダーの役割になることを見たことがあるのではないかと考えています。私が実行したチームでは、通常、コードのピアレビューからのコメントを修正するまで、先に進むことはできません。また、「ハードコーディングなし」は、ピアレビューの頻繁なコメントです。

一般に

ほぼすべてのベストプラクティスで、戦いを選択する必要があると思います。絶対に完璧になるチームはありません。しかし、あなたはあなたの主要な痛みのポイントに目を光らせて、それらをクラスタで取り組み始めることができます。特定の個人の迷惑な癖とチームの苦痛のポイントを本当に知ることは、リーダーの役割になると思います。

あなたのチームが特定のベストプラクティスを実行できなかった場合、最初の質問は「これがどの程度の損害を引き起こしているのか」だと思います。答えが「最小」の場合、おそらく時間の価値はありません。一部のベストプラクティスは、特定の種類のシステムに最も関連しています。全体的には優れていますが、プラクティスが頻繁に発生したり、システムの大部分を占めていないシステムの戦いに値しない場合があります。

「どれだけダマンジしますか？」に対する答えが 「ALOT !!!」である場合、ベストプラクティスでこの1つのスラックポイントを修正することにより、このような痛みと苦しみをすべて取り除くことができることをチームに示すためのケースの作成を開始できます。ほとんどの人は痛みや苦しみを避けて喜んでおり、それは対話を「私があなたに言ったのでこれをする」から「より良いのでこれをすることを決めた」に変えます。

コードレビュー。エラーのない適切に記述されたコードのみを受け入れます。

少なくとも ：

• 彼らがコードライン（resharper、StyleCopなどのツール）をたどることを簡単にします。簡単であれば、採用する可能性が高くなります。

それに加えて、組織、開発者、チーム内での役割に基づいて機能するものを選択します。

• 定期的にバグ修正と変更リクエストを行う
• 経験豊富な開発者とのペアプログラム
• 建設的な方法でのコードレビュー
• コードウォークスルー
• トレーニングを開始し、Code CompleteやThe pragmatic Programmerなどの本を使用してください。

私の役割はマネージャーですが、小さなチームとして開発し、コーチとして管理することを好みます。

コードパーサーに接続された椅子の電極はすでに指摘されていますが、プログラマーは恐れていないようです。発砲は価値のある資産を失うことを意味するため、良いアプローチとしては聞こえません。

これらすべてのツールを見ていきますが、あなたが私に教えてくれた他のすべてに対しては、私はオープンなままです。

この問題に対処するには、次の3つの方法があります。

1. コーディング規約の問題をチェックするためのソースコードの静的分析。以下のようなツールを使用しcppcheckとから、それらのgrammatechを。ウィキペディアには、http：//en.wikipedia.org/wiki/List_of_tools_for_static_code_analysisという優れたリストがあります。通常、ほとんどのソース管理システムには、チェックイン時にそのような問題を直接確認できるフックがあります。：CVSのためのフックは、このリンクを調べるhttp://goo.gl/F1gd2。コンプライアンス違反はチェックインの失敗を意味し、3回以上の失敗は開発者がチームに自分自身を説明しなければならないことを意味します。

2. コーディングプロセス中に、開発者に問題のフラグを立てます。選択したIDEに統合されたカスタムスクリプトを持つことは、これを行うためのクールな方法です。このリンクをチェックしてください：http : //goo.gl/MM6c4

3. アジャイルプロセスに従い、コードレビューがスプリントの一部であることを確認してください

これが私の3段階の計画です。

1. プログラマーを解雇する
2. ソフトウェアエンジニアを雇う
3. ...
4. 利益！

：D

真面目な話ですが、彼らがコードを書く以外に何もしないと信じるなら、よりバランスの取れたチームが必要です。私が働いていたプログラマーは、コンピューター上の異なるディレクトリを彼女のCMとして使用しました。プログラマーとほぼ1年間戦いました（古いコードをコピーして貼り付けると、変更によってバグが発生するため）。最終的にそれらを解雇しました。

1. 彼らが基本的なルールに違反しているとき、彼らに指摘してください。
2. 追跡できないバグが発生するのを待つか、柔軟性のないコードのために実装できない機能の要求に直面するのを待ちます。
3. 前に言ったことを思い出させます。
4. 彼らはしばらく自分のたわごとにdrれさせます。
5. 問題のコードをリファクタリングし、バグを特定し、インフラストラクチャを提供して新しい機能をプラグインします。あなたがしたことを説明するのに時間をかけてください。

あるいは、最も残酷だが非常に説得力のあることは、厳しいスケジュールを考慮して、非常に不十分に記述されたコードベースを維持させることです。：D
そして、変更のために、厳しいスケジュールを考慮して、彼らによく書かれたコードベースを維持させます。

一般的に、特定の基準に適応したくないということは、チームワークの経験が不足していることを意味します。

結局、人々は間違いから学ぶだけです。他人の頑固さに基づいた問題を決して修正しないでください。プロジェクトにとって非常に重要な場合（つまり、N日以内に納品しないと会社が訴えられる場合）、まずプロジェクトから先送りします。

プログラマーは、これらの問題が彼らに利益または利点をもたらすことに気付くまで、あなたが言及したこれらの問題に対する態度を変えることはないと思います。あなたが彼らにこれらのことをさせたい理由を説明してみてください。さらに良いことに、彼らに利点を体験させます。

プロのソフトウェアエンジニアを1人雇います。そして、最も弱い発砲。次に、採用できない人をゆっくりと交換します。そのような人々がいることは、長期的に利益よりも害をもたらすことがあります。

ここでの主な考えは、プロがほとんどの仕事を始め、他の人を解雇しても貴重な人的資源が減らないということです。

それは少しひどいですが、私は数ヶ月間、トイレにCode Completeを置いていきました。効果的かどうかはわかりませんが、当時は良いアイデアのように思えました。

では、ルールに従わなかった場合の結果と、ルールに従った場合の報酬とは何ですか？答えが同じである場合-何もない-幸運を得ることができます。階層的なアプローチをお勧めします。最初にそれらをまとめて、ルールに同意するかどうかを話し合います。次のステップは、コードレビューにそれらを含めることです。ニンジンとスティックを試すこともできます。一晩ファイルをチェックアウトしたままにする人のように、次の毎週の会議にドーナツを持ち込む必要があります。ニンジンは、ラスベガスで週末を過ごすために1か月間ルールに従う人なら誰でもかまいません。二人用。

または、最悪の犯罪者を解雇し、残りの人に発汗させます。

小さな制御された混乱します：彼らはあなたがこれらのルールを使用することによって回避したいconsecuencesを受けてください、それは彼らが本当に例えば、あなたが求めている理由を理解しようとしている唯一の方法である、彼らは正しいにしています。

この乗組員が変更のチェックに本当に苦労していて、マジック定数をハードコーディングせずに懸念の分離に固執している場合、私は乗組員全員を解雇し、実際に彼らの技術をできるだけ早く気にする実際のプログラマー^1に置き換えます。一度に1つずつ、またはまとめて言うことはできませんが、これらのジョーカーは行かなければなりません。

説明している種類のコーディングは、使い捨ての使い捨てスクリプトに適しています。実際のアプリケーションを構築する方法ではありません。彼らがプロのプログラマーとして報酬を得ているなら、この種のことを知ることは彼らの仕事です。

¹これは、バイナリまたは同様にばかげたコードを直接記述する架空の人々の冗談の用語としてよく使用されます。ここでは、冗談ではありません。私はかなり新人のプログラマーであり、自分の技術を気にしているので、これらのことを言われる必要はありません。これらはあなたが扱っている本当のプログラマーではありません。

マネージャーの仕事は従業員の友人になることではなく、時には悪人にならなければならないこともあります。コーディング標準とコミットの強制、プロシベッドアーキテクチャに従うことの拒否、規定のツールの使用の失敗などは、不人気にならなければならないときです。

ポリシーを明確に表現します。正式なコードレビューを行い、ポリシーに従っているかどうかを確認します。コードレビューからのすべての問題が裁定されるまで、彼らが別のタスクに移動することを許可しないでください。

ポリシーがコードをコミットしないことに関するものである場合、要求されたときに実行できない場合は、書面による警告を要求します。彼らがコードをコミットしていない場合、あなたが懸念している限り、彼らは何も書いていません。

合理的な改善の機会を与えられても改善しない場合は、それらを解雇します。プロフェッショナルではない開発者は、どんな種類のコードを書いても、チームを引きずります。彼らはプロフェッショナリズムの欠如により他の人々に影響を与えており、それは容認されるべきではありません。彼らはどんなイベントでも保持する良い人ではありません。優れた開発者はコードをコミットし、優れた開発者は同意しない場合でもアーキテクチャの決定に従い、優れた開発者はハードコーディングしません。カウボーイコーダーを排除することで、頭痛以外の何かを見逃すことはありません。