4

私たちの主任開発者の何人かは、彼らのためにコードを文書化するジュニア開発者を割り当てるよう経営陣を説得しました。

彼らの議論は次のとおりです。

  1. すべてに精通した 2 人のプログラマーがいます。
  2. ペアプログラミングですね。
  3. 費用対効果が高くなります = 彼らはより多くのことを成し遂げます。
  4. 彼らのコードが読みやすく、保守可能であることを示しています。
  5. どんな質問にも喜んでお答えします。つまり、メンタリングの一種です。

ただし、最新の状態を維持するために忙しくしているプログラマーの数は、時間の経過とともに増加しているようです。

これは良い考えですか？

わお！これは私たちの経験ではありません！

重要であることが判明したいくつかの説明を次に示します。

  1. 上級開発者は反射的なセルフドキュメンターです。採用の核となる質問です。「これは後輩に任せて」と言われることもある。

  2. これは、上級者向けの検証ツールとして表示されます (そして、私たちの後輩はクリアするのにかなり高いハードルを持って雇われています)。

  3. はい、コードは単一目的で自己文書化する必要があります。後輩がなかなか言い出せないことは、先輩が真摯に受け止めるフィードバックです。

  4. ジュニアはこれをリファクタリングの演習として扱うことが期待されており、予想よりも頻繁にそのように機能します。特に、YAGNI の問題や過剰なスコープなどをキャッチします。実際、彼らは変化を引き起こしました。（彼らが本当に反対し始めたら、私たちはそれを撤回します。上級生は喜んで順応します。彼らは後輩の成功に誰よりも責任があることを理解しています。）

  5. あなたの先輩は自分のコードを説明したくありませんか?

  6. 私たちは、「誰もがコードを所有している」というアジャイルの原則に強くコミットしています。これがプロセスを加速すると考えています。

最後に、個人的なメモ - 私が他の人のコードを理解しようとしているとき、私が最初にやりたいことは、理解しようとするときに再度コメントすることです。コメントすることはなぜ面倒だと見なされるのですか?

これが私たちの仕事のやり方であることを明確にするため、一部の若手応募者を除外する場合があります。しかし、それは売上高の問題ではありません。（でもまだ3ヶ月しか経っていません。）

4

11 に答える 11

13

おそらくそれほど素晴らしいアイデアではありません。いくつかの理由から:

  • 彼らの後を「一掃」する一連のジュニアがいる場合、リードが適切なコードを書くインセンティブは少なくなります。ドキュメントであろうとなかろうと。品質を下げるインセンティブが答えられないままになっているのを見たことがありません。

  • チーム リーダーが喜んで質問に答えてくれるなら、ペアリング セッションで質問に答えてみませんか? 先週何をしたかを思い出そうとせずに、すぐに質問に答えることができるので、実際には時間がかかりません。

  • ペア プログラミングは、後輩の開発者がじっと座って先輩を見守るだけではありません。最も経験豊富なプログラマーでさえ、後輩から学ぶことができます。たとえそれが彼らの長年の仮定に異議を唱えることによるものであっても. 問題が発生した場合は、ジュニアにキーボードの制御を任せてください。これで通常は解決します。

  • コードは「自己文書化」する必要があります。Javadoc などのようなものは、付加価値がほとんどないため (常に時代遅れであるなど)、近年流行り廃りを遂げています。理解しやすいようにコードを再構築することに時間を費やす方がはるかに理にかなっています。

  • 私は「より生産的」という議論には賛同しません。5 人の上級者が全速力で進み、5 人の後輩がその後ろで掃討している場合、コードを作成する開発者は 5 人しかいません。2/3 レートで 10 の開発者がいる場合、全体的な容量が大きくなります (最大 6 つのフルスピード開発者)。

于 2010-02-07T03:40:38.220 に答える
4

それは恐ろしい考えではありません。優れたコードを読むことは学習の良い方法であり、他の誰かがコメントするのに十分なほどフォローできるコードを書くことができることを確認することは役に立ちます。

ただし、上級開発者は、コメントが正しいかどうかを読んで確認する必要があります。そうしないと、これは時間の無駄になります。

また、ジュニア開発者向けの値には時間制限があります。後輩にとって真の価値がなくなるまでにはせいぜい 6 か月かかると思います。

だから私はこれにおそらく資格を与えます。後輩や新入社員がインターンシップ期間をコードのコメントに費やさなければならない場合は、問題ありません。しかしその後、彼らはやめてしまい、先輩たちは自分のコメントを書くことに戻らなければなりません。

于 2010-02-07T03:40:04.413 に答える
2

追加の考え - 一般に、エンジニアは、コードに追加したりテストしたりするまで、コードの断片が何をしているのかについての完全な概念を持っていません。はい、観察によってコードの目的の要点を理解することは可能です。しかし、文書化の目的は、明白ではないニュアンスや懸念事項をカバーすることです。ジュニアであろうとなかろうと、コードを見て有用なドキュメントを書くだけの開発者はいないと思います。

後輩の開発者が他のタスクを実行している間にドキュメントを強化するように奨励することは、良い計画です。しかし、バグを修正したり、機能を強化したりして、コードが計画どおりに機能しない理由が分からない限り、文書化する理由は明らかになりません。

于 2010-02-10T19:35:34.730 に答える
2

タイトルの質問に答えるには、

あるプログラマーが別のプログラマーのコードを文書化すべきか

コードが何をしているのかを理解するにつれて、見ているコードを文書化します。

誰が書いたかは気にしない。

于 2010-02-07T03:35:10.307 に答える
2

うわあ！！コードを文書化するのは、キーを叩き始める 前だと思うのは私だけですか?

主任開発者がコード作成前の設計 (および設計レビュー) の概念を理解していない場合、重大な問題が発生します。コードが作成された後に後輩にコードが何をするかを書いてもらうなどの応急処置を適用します。 、役に立ちません。

プロセスはありますか? SQA?

于 2010-02-09T02:05:08.733 に答える
1

コードを文書化しないよりはましです。あなたがそれをするつもりなら、私は役割を拡大しようとします。開発者にバグを見つけてもらい、コードを改善し（危険ですが、リードのガイダンスが必要です）、テストケースや、最初に実行する必要のあるすべてのことを記述してみてください。

ジュニアが見つけることができるほとんどの問題に対して、ある種のインセンティブを設定します。後輩にもっと一生懸命に見えるように促し、コードを書くときに基本的な義務を放棄する前に、リードにもう少し考えさせます。

于 2010-02-09T01:16:53.853 に答える
1

私は自分で答えを書くほど賢くないので、私より賢い人を引用します。

ジョエルは言った：

大学の CS の卒業生に、あなたのために働くことができると伝えようとすることさえ考えないでください。私はこれをたくさん見てきました。プログラマーは優れたテスターに​​はなりません。代わりになるのがはるかに難しい優れたプログラマーを失うことになります。

程度は低いかもしれませんが、ジュニア開発者にも同じことが当てはまると思います。ときどき遭遇したことを文書化することは問題ありませんが、自分の仕事を上級従業員の片付けだけで構成したくはありません。

Yeggeは次のように述べています。

私がインタビューしたばかりの UW の学生は、彼の友人がこの夏に Intel のインターンシップを行ったが、それがとても嫌で、彼らからのかなり儲かるフルタイムのオファーを断ったと語った。その友人は、Intel の従業員が映画 Office Space の脚本を書いたと確信していると語った。そこにいる人々には、報告する上司が5人または6人いるだけでなく、これは十分に悪いことです。彼らは実際にTPSレポートを持っており、誰もがそれをしなければなりません。また、表紙のフォーマットを変更すると、メモが表示され、全員に通知されます。

これはおそらく、私が聞いた中で最もシュールなインターンシップ体験の 1 つですが、インターンシップの恐怖の話はかなり一般的です。そして、インターンが学校に戻って誰にも言わないわけではありません. 言葉はすぐに広まります。多くの企業は、主要な大学で自社を事実上ブラックリストに載せています。この話をしてくれた UW の学生は、今では CS 部門の誰も Intel で働くことに興味を持っていないと言っています。インテルはまだキャンパス内で狂ったように人材を募集していますが、パイプラインは事実上閉鎖されています。

要するに、ジュニア開発者がそこで働きたくないようにしたら、彼らは... そこでは働きません。経験の浅い開発者がいなければ、最終的には上級開発者がいなくなり、開発者がまったくいないことになります。

考えられる唯一の説明は、あなた、善良な旦那様が Google で働いているということです。実際の問題は、優秀な人材を雇うのが簡単になりすぎたということです。彼らの裏の動機は、中小企業の競争条件を平等にしたいということです。（優秀な人材を採用するのを難しくするようなことを敢えてする人は他にいません。）そして、私の会社は Google ではありません。より多くの有能な候補者が私たちのドアを通り抜けるのを楽しみにしています。 .

于 2010-02-09T02:29:23.810 に答える
1

明確にリファクタリングされたコードを書く場合、コメントがあったとしてもごくわずかです。

于 2010-02-09T02:39:55.343 に答える
1

それは悪い考えです。経験の浅い開発者であろうとそうでない開発者であろうと、コードに直接影響を与える必要があります。通常の開発者が最小限の初期費用でコードを操作できる場合、それはコードが保守可能であることの大きな証拠となります。初心者の開発者が何かを壊す可能性がある場合は、単体テストにもっと注意を払う必要があります。しかし、最終製品の一部ではない余分なアーティファクトを作成し続けると、チームとして理由もなくコストが増加します。

于 2010-02-09T01:28:50.610 に答える
0

これは、メンタリングから抜け出すための巧妙な方法のようです。残っている問題がいくつかあります。

  • ジュニアプログラマーがドキュメントとして書いたものをレビューするのにどれくらいの時間が費やされていますか? これは、たとえば、母国語が英語でないジュニア プログラマーの場合、かなりの時間を浪費する可能性があります。
  • これは、どのようにしてジュニア開発者がソフトウェア開発の経験を積むことになっているのでしょうか? この形式のメンタリングは、仕様から設計、実装への推論の飛躍に対応していません。
于 2010-02-07T03:37:27.760 に答える