シニアプログラマーは、常に本を使うことについてのアドバイスは良い考えですか？[閉まっている]

私はジュニア開発者であり、業界に5年間しかいません。私の現在の会社には上級者がいます。彼をInfestusと呼びましょう。ときどき、まったく新しいことを一からやり直す機会を与えられています。

最近の例の1つは、マルチスレッドアプリケーションでシングルトンを作成する必要があったことです。この方法を使用することにしました。Infestusがそれを見るとすぐに、彼はすぐに私を愚かだと呼び始め、このアプローチを使うように言った。なぜ彼がこれを改善したのかを尋ねたところ、これがJavaについてのこの本の方が優れていると言っているのです。

そして、それは一般的なパターンです：新しいことをする機会が得られるたびに、私はすぐにInfestusに打撃を受けます。彼の方法が優れている唯一の理由は、それらの本が有名なプログラマーによって書かれたからです。彼はいつも本を読んでくれて、どの方法を「学ぶ」かを考えています。

私は5年間だけお金のためにプログラミングをしてきましたが、問題を解決するための最良の方法について本を盲目的にたどることは常に良い考えですか、それとも時々実験してみるべきですか？Infestusからの苦情の絶え間ない弾幕により、私は決して新しいことを何も試みず、本の例に従うようになり始めています。

編集：私は完全に失われました。はい、盲目的に何かをフォローするのは悪い考えであることを知っています。しかし、この神のようなプログラマーであるInfestusは、適切にプログラムする唯一の方法は、本を読んでTにすべて従うことであると教えてくれます。本が唯一の正しい方法である場合。

EDIT2：Infestusは私の上司ではありません。彼はコードのレビューを担当する上級開発者の1人にすぎません。そして、レビュー後の彼のコメントの大部分は、そのような方法が間違っている本名で構成されています。

このようなキャリア全体でプログラマーに出くわすでしょう。実験と学習を自分で行うのに何も問題はありません。確かに本は素晴らしい。多くの場合、例はクリーンな環境で機能しますが、別の会社の開発者である場合、クリーンな（他者からの干渉のない）環境はありません。

「正しい」方法で物事を行う方法を知ることは常に素晴らしいことですが、意見は年々変わります。だからあなたができることを学ぶ。上級開発者からできることを取り入れ、自分で学んだ知識と混ぜてください。最終的に、あなたは上級開発者になり、これらの経験から学び、ジュニア開発者に教えます。

ただ気を悪くしないでください。

彼は本当にあなたを馬鹿だと言ったのですか、それとも彼はコードを軽disしただけなのですか？愚かなものを呼び出すことは無頓着ですが、それは提案を無効にしません。Infestusは貴重な提案をしてくれたと思うので、将来的には彼の提案を真剣に検討すべきです。彼は多くの読書をしているようであり、少なくともこの場合、彼の意見は十分に知らされている。同期は高価で扱いにくいものです。彼の推奨する実装は、あなたよりも効率的でシンプルであり、動作することが保証されています。

彼はいつも本を読んでくれて、どの方法を「学ぶ」かを考えています。

それは彼のようなものです。彼は積極的にあなたを助けようとしていますが、あなたはあなたのエゴを邪魔させているようです。コードを個人的に批判しないでください。コードは安価に作成でき、変更も簡単です。誰かがもっと簡単な方法を教えてくれたら、彼らに感謝します。

そして、はい、読書はあなたをはるかに優れたプログラマにします。私が知っているすべての専門家が広範囲に読んだ。あまり読んでいない場合は、せいぜい平凡であり、さらに5年後にはもはや市場性がなくなっていることに気付くかもしれません。

本を読むことは盲目的ではありません。著者は、彼が提示するアプローチのメリットをあなたに納得させるよう努めるべきです。先輩が自分で説明するように頼むのではなく、自分の好きなアプローチを説明する本を指すようにするのは理にかなっています：本に頼らずに好みの利点を説明できるはずですが、それは努力の重複でもあります本の著者はすでに作成しています。

だから、本を読んで、本の著者が言っていることを見て、それがあなたを混乱させるか、あなたの理解を確認したい、または同意しない場合は、それについてあなたの先輩に話してくださいより生産的な議論ができます。

健康な関係には3つの重要な要素があります。コミュニケーション、誠実さと信頼。それはすべての関係、仕事上の関係でも重要です。これらの懸念について上司に相談する必要があります。

特定のデザインを提唱する彼の理由がわからない場合は、そのことを伝えてください。あなたは本を読んでいないこと、そして彼がそれをする方法の方が良い理由を理解したいことを彼に伝えてください。重要なのは、あなたが彼の物事のやり方を理解しようとしていることです。

この人をもっと尊敬して扱うべきだと思います。あなたの頭の中で、あなたは彼を軽rog的な名前と呼び、あなたが「学習」と考えるものに対する彼のアプローチを批判しています。気をつけて。一方、あなたは彼があなたを愚かだと言ったと言っていました。それはクールではありません、そしてあなたは彼を愚かな誰かと呼ぶのはクールではないことを伝えるべきです。

アイデアは愚かかもしれません。私たちは皆、間違いを犯し、年配の人でさえ物事を逃します。設計に欠陥がある場合、尋ねるべき最良の質問は「なぜあなたはこのようにそれをしているのか？それは状況X、Y、Zで壊れないのか？設計Bは良くないのか？」である。

あなたは他の人とこのソフトウェアに取り組んでいることに留意してください。それは学ぶのが難しいスキルです。ゼロから何も書いていないことは問題ではありません。コードを可能な限り最高のコードにすることで、常に輝きを放つ余地があります。

そして、「最良」とは、非常に多くの場合、読み取り可能で理解可能なことを意味します。私たちプログラマーは、他の人のコードを読むのに多くの時間を費やします。そのコードが明確で読みやすい場合、それはコードを本当に価値のあるものにします。優れたコードを書く方法の1つは、多くの優れたコードを読むことです。あなたは非常に頻繁に本で非常に良いコードを見つけます。したがって、1つか2つの優れたプログラミングの本を読むことで、より優れたプログラマになる可能性があります。

あなたが働いている会社では、おそらくそうです。これは彼らがあなたがすることを要求するものです。

このエンジニアのInfestusは、「これは本に書かれています。だからこそ」と言うことで、ジュニア開発者を教育するという非常に貧弱な仕事をしています。彼は説教者ではなく、技術者でもあり、後輩が彼の経験から学ぶことができるように、それを分解して概念を提示できるはずです。

社内の知識のある開発者と話をして、さまざまなプログラミング技術の長所と短所などについて質問することをお勧めします。これは本やブログを読むことと一緒です（Joelをソフトウェアでお勧めします-Googleのみ、必須です）よりよく理解できるはずです。

私見、ここには2つの側面がありますが、それらは別々に対処する必要があります：

• 彼ができるからといって、彼があなたの名前などを呼んでいるのは、彼がジャークであるという事実です（彼は先輩です、あなたはどちらか一方に不満を言うなら、彼は疑いの恩恵を受けるでしょう）いじめのような行動、そしてただ悪い。

これで彼のレベルに身をかがめないようにしてください。彼をいじめたり、上司などに「教えて」はいけません。彼の行動のこの側面を無視するために最善を尽くします。極端になりすぎることを念頭に置いて（つまり、生産性などに影響する場合）、それについて何かをすべきです。

• 彼はあなたのコードが悪いとあなたに言っているという事実（そしてそれを適切に行う方法）。正直言って、男の口調を無視して、彼の行動のこの側面はそれほど悪くはありません。物事をはるかに速く学び、自分を修正し、自分が間違ったことだけでなく、それを正しく行う方法を教えてくれる人がいると、適切なコンテキストでそれらを見ることができます個人的な試行錯誤の実験などから）。

私が最初に「私の完璧なコード」だと思っていたものを誰かに修正してもらい、その人が後で自分が正しいこと、私のバージョンが悪い、良い、そして彼がそれを見た神に感謝します！:)だから、私は最初の衝動を和らげることを学びました。代わりに、誰かが私を修正するたびに、最初に本当に客観的に、コードを再確認してから、彼を確認して、彼が本当に正しくないことを確認してください。それが私のせいだったなら、私は彼に助けてくれたことに感謝し、彼の解決策がどのように機能するかを本当に理解していることを確認します。

そしてねえ、時々、私は提供された修正が私が最初にやったことよりも実際に悪いことがわかったので、その時点で私は他の人とこのすべてを話してみます。正直なところ、間違えたときに修正されることを受け入れることができると思うよりも早く他人の尊敬を得るものはないことに気づきましたが、同時に、あなたが自分だと言うことを恐れていません自我だけでなく、実際の研究に基づいて肯定を証明していることをすぐに証明できるので、そうだと思うときに誰が正しいのか。

この点で、彼が提案していることや、提案していることなどについて、実際に試してみてください。自分の考え、特定の解決策にたどり着いた理由、そしてそれが彼よりも優れていると思う理由（正直かつ客観的に考えたとき）を見せてください。または、彼の提案があなたの提案よりも優れていることがわかった場合は、そのことを伝えて、その支援に感謝します。これにより、焼けた橋が再建される場合があります。

自分で試して、できることをすべて学んでください。十分な本を読んだ後、特定の主題に関する複数の本があり、それらが互いに矛盾する可能性があることを発見するでしょう。最適だと思うものを試してみて、時間がある場合、または比較/コントラストしたい場合は両方を試してください。

上司とのやり取りは、まったく異なるテーマとアプローチです。もし誰かが本に書かれている通りに何かをしたいなら、私は彼らに言ったでしょう。マインドリーダーとは関係ないので、それは私だけです。上司はこれを習慣にします。新しいプロジェクトを取得するときに、本や参考文献を勧めるかどうか尋ねてください。

何をするにしても、新しいプロジェクトに取り組むのをやめないでください。私たち全員がこの状況に対処する方法についてのヒントを与えるのは簡単であり、彼らはうまくいくかもしれないし、うまくいかないかもしれませんが、あなたはそれと共に生きなければならず、否定性に苦しむ人です。良くなりますが、それは通常、新しい事柄についてより多くのコードを書き、成功と失敗から学ぶことから来ます。

本を盲目的にフォローすることは悪い考えですが、本を正確にフォローすることと盲目的にフォローすることには違いがあります。

本の内容を理解しようとするときは、一般的に最初に正確にそれに従うことは適切ですが、あなたがそれを教えようとしていることの感覚を得ている間です。オッズは、あなたが終わってもまだすべてを理解できないということです-それがこのようなものが通常どのように行くかです-しかし、あなたがあなたの質問を理解しようとするとき、最初に本に正確に従うことはあなたに実験する何かを与えるでしょう。本の内容に反対する方法を見つけることができるのは確かですが、本が対処しようとしていた問題を理解できるので、自分のコードを書くときがきます。それらの問題を後であなたに噛み付かせるのではなく、あなた自身の方法で（または少なくとも部分的にはその方法で）対処してください。

本質的にJavaに固有のものではありませんが、それでもそのコミュニティでは特に一般的なものです。あなたが話している本は推測できると思いますし、それらはJavaコミュニティの辞書の主要な部分を形成しています。それらを理解し、それらが物事を記述する方法は、見つけた他のJavaコードを理解する必要があるときに非常に役立ちます。それはそれ自体で価値のあるスキルです。

本やブログの投稿を読むことは、プログラミングに非常に役立ちます。すべての開発者が読むべき本がいくつかあります。

ただし、さまざまなプログラミングの概念と技術を学ぶ唯一のソースは本ではありません。最近では、オンデマンドのビデオベースのトレーニングが非常に人気を集めています。Pluralsightをチェックすると、専門家に質の高いトレーニングを提供できます。

実際、もしあなたが助けにならない本だけを読むなら。読むだけでなく、他にもやらなければならないことがあります。詳細はこちらをご覧ください。

あなたは彼にあなたの方法で特に何が悪いのか尋ねるべきです。彼が明確に答えることができない場合、あなたはそれが優れていると感じるのが好きなただの普通の人であることをかなり確信しているかもしれません。

本に関することは、ほとんどの場合、改訂を通過することです。これにより、悪い慣行や誤解を見つける可能性が高くなります。また、「ビッグネーム」とは、本を売って余分なお金を稼ぐことを善に頼っている経験豊富な人々です。したがって、彼らが言うことについては最低限の品質保証があります。

そうは言っても、本、論文、およびその他の情報源を読むことは、実践によって確認された場合、もちろんプロとして成長する良い方法です。ですから、これらの本（Infestusが推奨する本も）を読むのは良いことです。ただし、ほとんどの場合、同じ問題を解決する他の方法があるため、本は主に主題に関する理解を拡大する必要があります。

「自分で行く」アプローチについて、ポイントは次のとおりです。あなたの視点を維持できますか？他のどのソリューションよりも優れているソリューションをどのように証明しますか？自分で明るい解決策を考案できる場合もありますが、他の既知の解決策と比較すると、少なくとも他の方が有利なユースケースがあるため、自分の方が優れている理由を主張できる必要があります。次に、創造的かつ思慮深く、しかし最も重要なことは、効果的であることです。

もしそうなら、あなたはそれらの本を読んだでしょう。それはあなたにもっと多くの議論を与えることによってあなたを助けるでしょう、そして同時に、Infestus-多分-間違ってそれらの本を議論として取っていることがわかります、そして誰もそれらの本の内容を知らないので彼はまだ発見されていません。または、彼が実際にk

私の経験では、主題をプログラミングする場合、インターネットで同じ主題情報を検索するよりも、本の適切な説明を含む情報の質と表示の方がはるかに優れています。インターネットには、適切な説明、文脈、品質が欠けていることがよくあります。

インターネット上の上記情報の量は多くなります。

したがって、私の一般的な戦略は、書籍から学習してより深い理解を得、その後インターネットから学習してさまざまな実装にさらされ、私の経験を広げることです（そして、多くの場合、物事をしない方法を参照してください）。

私はそれぞれのアプローチのメリットを研究し、あなた自身の判断に至ります。自分のアプローチが優れていると思う場合は、どちらかが納得するまでInfestusと話し合ってください。合意に達することができない場合は、セカンドオピニオンを求めるか、Infestusのアプローチを受け入れることができます。

シングルトンの場合、列挙型アプローチに対して行うことができる引数の1つは、列挙型がクラスを拡張できないことです。私はよくこのようなコードを書きます：

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

これは列挙型ではできません。列挙型のアプローチはすべての場合に機能するわけではないため、一貫性をextends保つために、句が不要な場合でも避ける必要があると主張できます。

列挙型の使用に対して行われる可能性のある他の引数：

• それはハックです-意図していないものに列挙型を使用しています
• これまで見たことのない読者にはわかりにくい

私は知識の源として本に大きく依存しています。これらは優れた基盤であり、Infestusは、空いた時間にかなりの量の本を消費するべきであるという点で正しいと思います。情報源は書籍だけではありませんが、消費すべきだと思います-ローカルユーザーグループに参加し、関連する技術ニュースレターを受信トレイに配信して、ブログを読んでください。

しかし、私はそれが本の中で特定の方法で書かれているので、それはそれをしなければならない方法であるという主張に反対します。はい、本は素晴らしいアドバイスを提供し、それらは専門家によって書かれ、専門家によって査読されますが、比較的単純な本に関与したことがあるので、通常、本の執筆、編集、およびリリースには少なくとも2年かかります。テクノロジーの変化のペースは急速であり、2年前のアドバイスは今日の正しいアドバイスではなくなっている可能性があります。一般的なプリンシパルは時の試練に耐えることがよくありますが、特定のアクティビティの最適化は、新しいハードウェアや新しいソフトウェアリリースによって無効になる可能性があります。

Infestusにあなたと提案をするように頼むという提案は素晴らしいものです-立ち去って、すべてを読んで、あなたがすでにあなた自身のためにあなたが答え/解決しようと試みた思慮深い質問の束を持って戻ってきてください方法。

5年後、なぜあなたはまだジュニアだったのかという疑問がありました。私にとって、誰かが後輩であるかどうかの重要な尺度は、長年の経験ではなく、スプーンでの食事がどれくらい必要かということです。中級レベルの開発者は、比較的自給自足で、知識源を思慮深く消費し、それに基づいて行動し、自分の状況にそれを広げることができると期待しています。また、物事を明確に説明できるように、トピックをしっかり理解しているため、後輩に教えることができる段階にいる必要があります。もう1つのコアコンピテンシーは自信です。仕事をして、内容を読んで、まともなものを作成したら、後輩が検証を必要とするので、開発者はコンセンサスを要求するので、議論の場でそれに立ち向かうことを恐れないでください。

職場のマナーを捨て、上級開発者が持つメンターの役割の現実を捨て、探求したいという欲求を捨て、,辱的な行動を捨て、本のフェチを捨てます...

チームでのコードレビューの目的は、1）コードを検証すること、2）コードを書いている人がコード改善の背後にある意味を確実に理解できるようにすることです。「Martin FowlerがGoFの本でそう言ったので、これを変えてください」と言う場所ではありません。ただし、「[簡単な説明]でこれを変更してください。これについては、GoFの本で詳しく説明しています」と言ってください。

あなたの上級開発者が、少なくとも単純かつ微妙に、変更の説明を提供せず、「[本]のせいで」という言い回しを使用することを主張していない場合、彼はちょっと賢くて気まぐれです。どのように対処しますか？チームミーティングで口頭で言及し、チームメイトに、変更の利点または必要性を簡潔に説明する声明を1つか2つ提供し、その参考資料を提示するよう依頼します。本を参照してくれたことに感謝するようにしてください。

それに直面して、あなたの目標は、変更の提案を理解し、あなたの仕事や仕事にやる気を起こさせないことです。彼に言って。「コードを確認するときに変更の利点または必要性を簡単に説明できれば、変更の提案をもっと感謝します。少し参考になるだけで、あなたの本の参考文献を見つけているからです。」

彼が彼の本の参照で簡単な説明を提供することを拒否し続けている場合、業界で同等またはそれ以上の悪名の別の本またはリソースを異なる意見で提供でき、それがあなたのシナリオに一致する場合、あなたはあなた自身の本を追加できるかもしれません元のコードを保持することを考慮して、レビューコメントで参照してください。これを十分に行うと、彼は後退するかもしれません。反論は正しく、非常に重要であることに注意してください。上級開発者が間違っていても自分の道を歩んでも大丈夫です。これは私が学んだことであり、学ばなければならないことです。

本からプログラミングを学ぶことは不可能だと思いますが、良い本はあなたに大きな後押しを提供します。それは空手のようなものです-あなたはそれについて読んでいるだけで黒帯を取得することはありません;）私はこの特別なケースで、Infestus氏はJoshua Blochによる「Effective Java」に言及していたと思います。これは本当にJava開発に関する素晴らしい本であり、まだ読んでいないのであれば必ず読むべきです。