sdlc - 良いコードにどのようにインセンティブを与えますか？

Question

開発チームのメンバーに「良い」コードを書いて彼らのコードにコメントを追加するように動機付けるために実施している方法/システムはありますか？「良い」は主観的な用語であり、良いコードの1つの測定値としてのコードの保守性の測定に関する以前の質問に関連していることを認識しています。

score 6 · Accepted Answer

インセンティブペイは有害であると考えられているため、これは困難です。私の最良の提案は、悪用できる目標ではなく、すべてを同時に達成しなければならないいくつかの目標を選ぶことです。

score 5 · Accepted Answer

ほとんどの人は、コードレビューは高品質のコードを確保するための良い方法であると答えていますが、当然のことながら、そこに到達するための直接的なインセンティブにはならないように思えます。ただし、優れたコードの概念には意見の領域に入る広い領域があり、ほとんどすべてのシステムを操作できるため、優れたコードに対する積極的なインセンティブを考え出すことは困難です。

私が経験したすべての仕事で、優れた開発者は本質的に優れたコードを書く動機を持っていました。ニワトリと卵、フィードバック、キャッチ 22、好きなように呼んでください。優れたコードを作成する最善の方法は、やる気のある開発者を雇うことです。優れた開発者が働きたいと思う環境を作ることは、おそらく私が考えることができる最高のインセンティブです。環境を作るのと、開発者を探すのと、どちらが難しいかわかりません。どちらも簡単ではありませんが、長期的にはどちらも価値があります。

優れた開発者が働きたいと思う環境を作るには、開発者がコードについて話す状況を確保することが含まれることを発見しました。自分のコードに対する適切な批評を評価しない熟練したプログラマを私は知りません。これは、最高になりたい人がより良くなるのに役立ちます。この取り組みの小さなサブ部分として、つまり優れたコードを作成するための間接的なインセンティブとして、コードレビューは素晴らしく機能すると思います。そしてもちろん、コードの品質にも直接的なメリットが得られるはずです。

良いコーディング習慣を伝えるために同僚と私が使用しているもう 1 つの手法は、コードのグループレビューです。それは形式的ではなく、人々が新しいテクニック、ツール、機能を披露することを可能にしました。批評がなされ、賞賛が公に与えられ、ほとんどの開発者は、全員を知っている小さな開発者グループの前で話すことを気にしないようでした。経営陣がこれにメリットを見出せない場合は、サミッチを求めて茶色のバッグと呼んでください。開発者も無料の食べ物を好むでしょう。

また、コードイベントに参加してもらう努力もしました。確かに、トピックにどれだけ精通しているかにもよりますが、あまり学ばないかもしれませんが、コードについてしばらく考え続け、よりリラックスした環境で人々が話すようになります. その後、1杯か2杯の飲み物を手に入れることを申し出た場合、ほとんどの開発者も現れます.

ちょっと待って、別のテーマに気付きました。無料の食事！真剣に、重要なのは、既に優れたコードを書いている人や、熱心に学びたい人が働きたいと思う環境を作ることです。

score 4 · Accepted Answer

うまく行われたコードレビューは、大きな違いを生む可能性があります。誰もが目を出血させるコードを提示する人になりたくありません。

残念ながら、レビューは必ずしもスケールアップ（料理人が多すぎるなど）またはダウン（コーディングが忙しくてコードをレビューできない）のどちらかであるとは限りません。ありがたいことに、 StackOverflowに関するヒントがいくつかあります。

score 3 · Accepted Answer

正式なコードレビューがこの目的を果たしていると思います。私のチームの他の少なくとも2人の開発者がそれをレビューしようとしていることを知っているので、見栄えの悪いコードをコミットしないようにもう少し注意しています。

score 2 · Accepted Answer

基準を公開し、インセンティブをあらゆる種類の自動化に関連付けないでください。探しているものの例を公開します。親切にして、人々が自分の悪い例 (およびそれらをどのように修正したか) を公表するように奨励してください。

チームの文化の一部は、「良いコード」とは何かです。多くの人にとっては主観的なものですが、機能しているチームには、チームの全員が同意する明確な答えが必要です。同意しない人は、チームを崩壊させます。

score 1 · Accepted Answer

これは上司ではなく、あなたに向けたアドバイスです。

あなたがさらに一歩進んで、今できる限り良いコードを書くと、後で1週間リファクタリングをしなくても報われるという事実を常に思い出してください。

score 1 · Accepted Answer

良いコードを書く最大の動機は、一緒に良いコードを書くことだと思います。プロジェクトの同じ領域でコードを書く人が増えるほど、コード規則、例外処理、コメント、インデント、および一般的な思考プロセスが互いに近くなる可能性が高くなります。

すべてのコードが統一されるわけではありませんが、スタイルを把握してチームとしてベストプラクティスを考え出すことができるため、人々が一緒に多くの作業をコーディングした場合、維持は通常簡単になります。

score 1 · Accepted Answer

お金はいい考えではないと思います。その理由は、それが外発的な動機であるからです。金銭的なインセンティブがあるため、人々はルールに従い始めますが、これが常に機能するとは限りません。調査によると、年齢が上がるにつれて、金銭的なインセンティブはモチベーションを低下させます。そうは言っても、この状況での作業の質は、報酬を受け取るために設定したレベルにのみ等しくなります。それは短期的な勝利であり、それ以上のものではありません。

人々が正しいことをするように動機付ける本当の方法は、彼らの仕事がよりやりがいのあるものになると彼らに納得させることです. 彼らは何をするか、どれだけ効率的であるかが向上します。人にやる気を起こさせる唯一の本当の方法は、やる気を起こさせることです。

score 1 · Accepted Answer

1

良いコードを書かないものを取り除きます。

私は完全に真剣です。

于 2008-09-24T17:59:39.867 に答える

score 1 · Accepted Answer

ビル・ザ・リザードに同意します。しかし、私はビルが言わなければならなかったことに付け加えたかった...

できること (リソースが利用可能であると仮定) は、他の開発者 (あなたの仕事について何か知っている人、あなたの仕事をよく知っている人、そしてほとんど知らない人) を集めて、あなたが歩くことです。あなたのコードを通してそれらを。プロジェクターを使用して部屋に座って、すべての変更を実行できます。このようにして、入力を提供し、質問をし、何よりも優れた開発者にすることができるさまざまな群衆ができます.

否定的なフィードバックだけである必要はありません。ただし、それは時々起こります。否定的な意見を建設的なものとして捉えることが重要であり、フィードバックを提供する際には建設的な方法でフィードバックを伝えるようにしてください。

ここでの考え方は、関数のコメントブロック、トリッキーな数学演算を説明するコメントブロック、または選択した言語に応じて日付形式を変更する必要がある理由を説明する単純なコメント行がある場合...その場合、コードが何を行っているかをグループに 1 行ずつ指示する必要はありません。これは、あなたが行った変更に注釈を付ける方法であり、他の開発者があなたのコメントを読んで他の場所で何をしたかを見ることができるため、以前の関数にあったファジーロジックについて考え続けることができます。

これはすべて実際の経験から得たものであり、私たちはこのアプローチを私の仕事で使い続けています.

これが役に立てば幸いです、良い質問です!

score 0 · Accepted Answer

うーん。

たぶん、開発チームはお互いのコードのコードレビューを行う必要があります。それは彼らがより良いコメントされたコードを書くように動機づけるかもしれません。

score 0 · Accepted Answer

私は通常、チームの金銭的賞を提供しません。なぜなら、彼らはあまり役立たず、実際にそれらを買う余裕がないからです。しかし、私は通常、各チームメンバーと一緒に座って、何がうまくいくかを指摘しながら、チームメンバーと個別にコードを調べます（「良い」コード）とそうでないもの（「悪い」コード）。このプロセスを開始する前に取得したほど多くのジャンクコードを取得していないため、これは非常にうまく機能しているようです。

score 0 · Accepted Answer

テクニカルサポートコールの原因となったビルドまたは出荷されたコードを壊した最後の人は、他の誰かが次にそれを行うまでお茶を飲む必要があります。問題は、この人はおそらく、本当に良い一杯を作るために必要な注意をお茶に与えないということです.

score 0 · Accepted Answer

コードの品質はポルノグラフィーのようなものかもしれません - ジャスティスポッタースチュワートの有名な言葉にあるように、「見ればわかる」という言葉があります。

そのため、コードの品質について他の人に尋ねるのも 1 つの方法です。それを行ういくつかの方法は...

同僚によるコードレビュー (および彼らによる他のコードのレビュー)。理解の容易さはレビューチェックリストの基準の 1 つです (個人的には、必ずしもコメントを意味するとは思いません。コメントがなくてもコードが完全に明確になる場合があります)。

コードの品質に起因する問題をふりかえりで提起するように要求します (ふりかえりを開催しますよね?)

コードへの変更が最初に機能する頻度、または数回の試行が必要かどうかを追跡しますか?

年次 (または何でも) のレビュー時にピアレビューを依頼し、質問の 1 つとして、レビュー対象者のコードを操作するのがいかに簡単かについての質問を含めます。

score 0 · Accepted Answer

インセンティブの付与には十分注意してください。「測定されるものは実行される」。コード行に報酬を与えると、肥大化したコードが得られます。コメントに報酬を与えると、不要なコメントが表示されます。コードにバグが見つからなかったことに報いると、開発者は低賃金の QA スペシャリストが行うべき独自の QA 作業を行うことになります。プロセスの一部にインセンティブを与える代わりに、チーム全体または会社全体の成功に対してボーナスを与えます。

IMO によると、優れたコードレビュープロセスは、高いコード品質を確保するための最良の方法です。ペアプログラミングも、チームによっては、優れた実践方法を広める方法として機能します。

sdlc - 良いコードにどのようにインセンティブを与えますか？

15 に答える 15

Related

Reference