プログラマーにコードレビューを依頼する
私は、セミオープンソースプロジェクトへの寄付を開発者に支払うプロジェクトを実行しています。私の問題は、開発者を雇うのは簡単ですが、誰かにコードレビューをさせることは非常に難しいことです。私は上級開発者に後輩開発者のコードをレビューしてもらうことを繰り返し試みました。私は彼らにもっとお金を払ったり、彼らにもっと高いステータスを与えようとしたりしました。
現在、コードを書きたいすべての開発者にコードのレビューも強制することを検討していますが、それは悪い考えだと感じています。
したがって、私の質問は、有能な人々が他の人のコードをレビューするように動機を与えるにはどうすればよいですか？これは、Linux、PostgreSQL、LibreOfficeなどのオープンソースプロジェクトで成功しています。
コードレビューは問題の解決策です。問題があり、「コードレビュー」で解決しますか？他の人が悪いコードをチェックインしていますか？私の推測では、それらはある程度はあると思いますが、おそらく他のコーダーは、レビューを行う時間/努力に値するほど悪いものではないと考えています。システムにチェックインされる不良コードの量を制限するための解決策を考え出すようシニア開発者に依頼してください。彼らはより効果的な解決策を考え出すかもしれません。
不正なコードの問題を解決します（コードレビューはパズルのピースの1つです）。開発者の意欲を高める1つの方法は、バグ/不良コードが修正されるまで、新しい機能の追加を停止することです。ほとんどの開発者は新しいものの構築を好みます。高齢者にバグを修正させ、悪いコードをリファクタリングさせます。多分彼らはコードレビューでこれをキャッチする方が簡単であることを知るでしょう。
繰り返しますが、問題を特定し、高齢者に解決策を見つける機会を与えます。
あなたが彼らに言うことをしない人々にお金を払い続けることができないので、それらが非常に重要であることを確認してください。誰もが問題があることに同意し、解決に貢献する場合に役立ちます。結局、あなたは彼らに責任を持たせなければなりません。彼らはコードレビューをしません、彼らはより少ないポジションを取るか解雇されます。
将来的には、コードレビューを行うか、少なくともこれが仕事の一部であることを知らせて、情報に基づいた選択ができるようにする人々を雇う。
編集あなたのジュニアに問題がある場合。開発者のコード、あなたの先輩は品質がとても低いと感じるかもしれません、それはレビューと修正プロセスを経るよりもそれを書き直す方が速いでしょう。ジュニア開発者にフィードバックを提供して将来的に改善するために、今すぐ時間をかけて検討することの長期的なメリットを強調することが重要です。
開発者を雇うのは簡単です
これが問題です。あなたが雇う開発者は単に動機づけされていないか、コードベースを高品質に保つ経験がありません。コードの品質を高く保つために、自分自身を引き受ける開発者を雇うことに焦点を当てるべきです。そして、そのような開発者を見つけることは非常に困難です。どちらもそれほど多くないため、開発者がコードに関心があるとインタビューから理解するのは難しいです。
私はかつて、やる気のある開発者を雇い、それを維持する会社で働いていました。しかし、コードレビューにはまだ価値があると感じました。知識を広めるのに役立ち、自分が書いたものが優れたコードであると1人が感じたからといって、改善の余地がないというわけではありません。
そして、同様の問題に直面しました。コーダーはコーディングを好んだ。同僚が意図的にあなたの仕事に批判的であるタスクを実行するという複雑な力のダイナミクスを避けたくないということは言うまでもありません。
私たちが見つけた答えはビールでした。
これは冗談ではありません。 2〜3週間に1度、会社はビールを買うためにお金を払うことになります。そして、週の最後の1〜2時間をコードレビューに費やします。無料のビールは良い動機であり、穏やかな注油によって生み出された陽気さは、プロセスから多くのスティングを取り除きました。
すべてのプログラマーが避けたがっていた否定的なことは、毎月のハイライトの1つになりました。私たちは皆、無料のドリンクと快適な雰囲気を手に入れ、同時にコードを改善する必要がありました。
プログラマーにコードレビューを依頼する
これは文化的な問題であり、彼らは彼らの仕事の批判を与えたり受けたりする必要がないので、現在平衡状態にあります。文化をトップダウンから変えるには、必要に応じて、それを文化的な習慣として維持するために、指導、指示、および実施する必要があります。
最初にレビューをスケジュールし、最高のコーダーにコードを説明してもらい、他のフィードバックを提供することをお勧めします。投機的または非生産的な相互作用が多すぎると思われる場合は、軌道に戻します。その場で修正できる小さな問題が特定された場合は、その場で実行してもらいます。メモを取り、順守するために最善を尽くしていることを示す質問をします。対処する必要があることが明確にわかっている問題、つまり技術的債務を追跡し、技術的債務の問題に具体的に取り組むために時間を割いてもらいます。
全体的なアーキテクチャの概要から始めて、週単位または日単位で、作成した各モジュールを詳しく調べます。最高のコーダーから始めて、より若い開発者に至るまで作業を進め、他の開発者が批判を受け入れるのを見ても脅かされないようにしてください。
この時点で変更を得る唯一の方法は、問題の所有権を取得して変更を主導することです。
どの計画でも、優先度を高くしたいものと実際に優先度が高いものとの間に多少の違いがある傾向があります。あなたが支払っているので、あなたは優先度の高いものをほとんど決定することができ、優先度の高いものに取り組むためにあなたが支払っている人々にほとんど伝えることができます。
したがって、コードレビューを回避している場合は、次のいずれかを行います。
- より多くの新しいコードを書くよりもコードレビューを優先しません。あなたが実際に「明日の終わりまでにこれを成し遂げることができるか」と言っているとき、あなたはあなたがそう思うかもしれません。そして、彼らに「私たちが他のすべてを落とすなら、確かに」と答えさせる。 「その他すべて」とは、コードのレビューと、レビューが必要な最近行ったすべてのことをスキップすることを意味します。
- 彼らはあなたが彼らに頼んだことをしていなくて、彼らにそうするように彼らに支払いました。あなたはコードレビューに追加料金を支払う準備ができており、彼らはまだレビューなしで新しいコードを書くことを好むので、コードレビューが非常に不愉快な理由を彼らから知る必要があります。
どちらの方法でも、開発者を関与させるために、「完了の定義」というスクラムの概念を調べることができます。スクラムを実行していない場合でもこれを使用でき、チームの定義にコードレビューを含めます。つまり、Xがレビューされるまで、Xが終了したとは言えません。つまり、自分のコード（および担当する後輩のコード）をレビューする人を見つける必要があります。うまくいけば、これは彼らがお互いにレビューをトレードオフすることにつながるでしょう。
それを提示する別の方法は、コードをレビューすることにより、彼らが将来取り組む必要があるかもしれないシステムの部分に慣れているということです。コンポーネントの所有権ではなく、コードベース全体に対する責任の共有を奨励する場合は、各コードにさらに目を向ける必要があります。これは正式なレビューフェーズとは異なりますが、1人だけが正しいと考えるコードの使用を回避するという同じ目標を達成するため、正しい方向への動きです。
もちろん、彼らが本当にレビューを嫌うなら、彼らは完全に大雑把なレビューをすることを選択して、それを読むことなくすべてを渡すことができます。その場合は、問題をより深く掘り下げ、良い仕事をするように説得する必要があります。レビューが有益であることを実証するために、誰かが行うはずのレビューを間違えたことが原因で発生する問題を指摘できます。間違いが本当の問題を引き起こしていると見られると、専門家はうまくいけばかなり強く反応しますが、無意味なタスクとして認識しているものをチェックしないと、それほど強くないことがよくあります。少なくとも部分的にレビューの欠如が原因である可能性のある問題を見つけることができない場合は、レビューをどのように決定したかを再度検討してください本当にこのプロジェクトに有益です。
別の可能性は、あなたが質問で言うことを排除できないことです、あなたが持っているコーダーは単に非常によくないか、少なくとも追加のテクニカルサポートなしで作業プロジェクトを作成するのが非常に上手ではないということです。テスト、バグ修正、QA全般については何も言わない。彼らがやりたいすべてがコードを書くことであり、それを実際に確実に機能させたくない場合は、当然、コードレビューを行わないことがこれの一部になります。裏側は、おそらくあなたのプログラマーは普遍的に素晴らしいので、彼らのコードは常に初めて機能し、テスト、バグ修正、またはレビューを必要としないかもしれないと思います。それはありそうにない！
上級開発者にもっとお金を払う気があるなら、コードレビューをすることが必要な仕事であるとあなたがすでに決めたと思います。
ほとんどの開発者（私のjr開発者の経験では）は、自分または他の誰かがすでに実行したコードを振り返るのではなく、むしろ何か新しいものを開発します。そうは言っても、発生する必要がある余分なポイントがあるか、それはタスクを特に望ましくないものにします。
コーディング標準。コードが一般的にどのように表示されるかについては、ある種の標準が存在する必要があります。これにより、誰もがどこでも異なる方法で行うことはありません。準拠している場合、より良いコーディング標準は、より迅速で苦痛の少ないレビューを意味します。また、コードのレビュー担当者に、「やり直したい」と言わずに、なぜやり直す必要があるのかを開発者に伝える理由も提供しますorと言う人は誰もいません。
コードレビューに影響があります。コードレビュー後、結果はすぐに処理されます。何も変わらなければ、レビューを行う意味はありません。同様に、コードを作成した開発者必要なぜコードを変更する必要があるのかを知る必要があります。そうしないと、将来同じことを繰り返し続ける可能性があり、コードレビューアは同じことを繰り返し修正するのに飽きます。 。
公平に保つ。望ましくないタスクと同様に、同じ人が常にコードレビューを行うことは望みません。誰かがほとんどの場合それを行うことに行き詰まっている場合、他の誰もが積極的にまたはボランティアをしないことによって、その人にそれをプッシュしようとします。 「ターン」を設定する必要があります。または、レビューを信頼できる数人の人しかいない場合は、全員が同時にコードを実行するようにしてください。これにより、コーディング標準が確立され、新しい開発者がコードレビューを快適に行えるようになります。
結論として、コードレビューは多くの場合、関係者全員にとって苦痛のように思えます。それは一人またはカップルの人に割り当てられたタスクであってはなりません。痛みを分かち合い、結果に基づいて行動し、新しい開発者に間違いから学んでもらうことによってのみ、誰もが前に出ることができます。
以前はソフトウェア会社ではなく出版社で働いていましたが、原則は同じです。
出版会社では、管理（およびより高額な仕事）への道のりは、他のよりジュニアな専門家の作品を編集/レビューすることでした。何人かの人々は編集/レビューの責任がなく、上級作家であり続けることに満足していましたが、有能な人々の「ほとんど」（半分以上）がこれらのレビュー/編集の仕事を望んでいました。これらの仕事の1つを持たないことは、「キャリア制限」であり、ほとんどの「ジュニア」ができるだけ早く編集に進むことを試みたので、不名誉のようなものでした。
私は大手の小売店で働いています。古い習慣がハードに死ぬところ。本当に難しいです。だから私は自分の経験を共有するかもしれないと思いました。
私たちが抱えていた問題は視認性です。お互いに実際に見えるコードはありません。彼らはCVSを使用していて、すべてをgitを使用するように変換するという勝利を収めました。これは流れを変え始めました。 Gitlabを実装しました（githubに似ており、基本的にすべての機能はサーバーでホストされています）。私たちはマスターブランチ（プロダクションレディコード）を保護しました。これは一種のスノーボール効果を生み出しました。開発者が本番環境またはテスト環境のブランチにマージする必要があるものを持っている場合、2人の上級開発者がコードを見て、コメント、改善のための提案、質問などを行い、最終的にマージについて親指を立てる必要があります。リクエスト。そこから、環境にマージされます。
気に入らないコードを書き直すためにステップインしても、OR開発者を助けることにはなりません。狂気の定義です。
高品質のコードを確実に作成する方法の概要を以下に示します。
- 単体テスト-要件を小さな一口サイズのロジックの質問に分解し、アプリケーションチャンクが実行することを想定し、期待し、返すテストを記述します。
- ドキュメントを書く-新規採用者であり、Xの実行方法を尋ねられます。コードにドキュメントがない場合は、基本的に開発者がコードに介入します。 「うわー」のようなもので、通常、内部で何が起こっているのかを理解するために、かなりの立ち上がり時間がかかります。 「良いコード文書そのもの」という考え方は信じられません。
- Empower Developers-キーボードを使わないでください。思考に基づく決定をもたらすために、思考を刺激する質問をします。
- もっとドキュメントを書く-良いドキュメントを強調しきれません。人々が転職したり、辞職したり、解雇されたりすることがあり、時にはモジュールに関するすべての情報が彼らと一緒になるため、組織にとって文字通り非常に貴重です。
- バージョン管理の使用（Git + Gitlab）-これは非常に大きな助けです。このようなものを実装できる場合は、実装することを強くお勧めします。これにより、チームからコードベース、マージ要求、生産性などをより多くの目で見ることができます。すごい。
- コーディングスタイルガイド-他の人がコーディングしているときにフォローしたいスタイルガイドを作成します。結局のところ、すべてのコードは、一人で書かれたように見えるはずです。 100ではありません。
- Make it fun-何ですか？え？コーディングは楽しいですか？ゲームのようにすることができれば（xboxの成果を考えてみてください）、人々は少し頑張る傾向があり、仕事のようには感じられません。クライアント側のコードの一部をコンパイルするJenkinsビルドサーバーを使用します。このプロセスでは、CSS LintとJS Lintを使用して、コードベースの問題と悪い習慣を見つけ、文書化しました。あなたがコードを間違えたのがあなたなら、うんざりしてしまいました。コードをクリーンアップして問題を減らした場合、ポイントを獲得しました。私たちはすぐに、開発者がポイントを獲得できる問題を求めてコードベースを精査していることに気付きました。 （ 継続的インテグレーションゲームプラグイン ）
私はこれがあなたの状況にいくつかの価値を追加することを願っています、そしてこの投稿は何らかの形であなたを助けます。ここには非常に多くの素晴らしい反応があります。
まず、なぜ開発者にコードレビューを行わせたいのかという質問に答えてください。バグが多すぎないか、コーディング規約に従っていないか、知識が共有されていないか、コードがチェックインされてテストが不十分であるかなど。
次に、これについて開発者と話し合います。彼らにあなたが期待することを伝え、彼らがこれをどのように改善するかを尋ねます。彼らはすべて、これらの変更を実装することに同意する必要があります。そうしないと、変更を実施することが困難になります。
誰もがコードレビューが有用であることに同意する場合、彼らは通常そうであるように、新しいルールは、今後はレビューされたコードだけが製品になることができるというものかもしれません。
レビューを行えるようにするには、何が期待されているかを明確にする必要があります。したがって、コードに適用するルールを次のように定義します。
- コーディング規約（命名、コードスタイル）
- デフォルトのソリューション
- 避けるべき構成
優れたツールを使用して、レビューするコードを簡単に見つけ、変更を確認し、それらの変更について話します。
コードレビューは、変更を実装するための通常のワークフローの一部になる必要があります。これは次のように整理できます。
- 開発者は、含める変更のレビューを行う誰かを見つけることが期待されます。
- または、コミットされたすべての変更について、レビューを行う必要があります。