より経験豊富な開発者がいない場合、実際のプロジェクトで作業しながらスキルを向上させるにはどうすればよいですか？
私は小さな会社の主任開発者で、C＃とASP.Netを使用しています。私たちのチームは2〜3人の小さなチームで、開発と設計の経験はあまりありません。私はより多くの上級開発者から学ぶ機会がありません。自分のプロジェクトのほとんどを自分で担当しているので、私のチームには誰も私を導き、最良のアプローチを選択するのを手伝ってくれません。
経験豊富な開発者がいない場合、実際のプロジェクトで作業しながらソフトウェア開発スキルを向上させるにはどうすればよいですか？
本、熟練した開発者のブログ、Stack Exchange、講義/会議など、他にも経験豊富な同僚から学ぶべき情報源はたくさんあります。コードレビューも重要であり、 CodeReview.SE は貴重なリソースです。
例でどのように機能するか見てみましょう。
例
あなたが読んでいるのはブログ投稿で、「ETL」という用語について言及しています。あなたはそれの意味を知りませんが、この記事から、データをあるデータサポートから別のデータサポートに移動する一種のプロセスまたはワークフローであることを漠然と理解しています。
Wikipedia and other resourcesにアクセスして、より正確なビジョンを得ることができます。 ETLを使用することがいつ役立つかはまだはっきりしていません。結局のところ、実際のETLの作成に時間をかけすぎるよりも、すべての作業を実行するSQLクエリを作成する方がはるかに簡単です。
これらの質問に答えるには、ローカルライブラリからETLについてbookを借ります。一部の抽出変換ロードプロセスは、単純なSQLクエリでは簡単に実行できないことを説明しています。抽出フェーズでは、リレーショナルデータベースだけでなく、複数の多様なデータサポートを処理できるだけでなく、変換ステップも非常に複雑になる可能性があります。データの検証/正規化とマッピングの両方。
これで、ETLとは何か、どのように使用するか、特にETLが必要な場合や、ETLが適切なツールではない場合の明確なビジョンが得られました。その間、個人的なプロジェクトとして小さなETLを実装しました。このプロジェクトでは、あなたには明確ではなく、本ではカバーされていないいくつかのポイントを発見することができます。これらの点はかなり抽象的であり、ソースコードに関連していないため、Programmers.SEに質問を投稿します。
会社でそれを構築する機会があれば、それを作成し始めます。いくつか問題があります。一部はコードに関連しています。 Stack Overflowに質問を投稿します。その他はデータベースに関連しています。 DBA.SEで質問します。
最後に、ETLを最適化する方法について、非常に熟練した開発者によってconferenceが行われます。この会議に参加すると、プロジェクトに実行できる機能強化について貴重なヒントが得られます。
また、何年もさまざまなETLに取り組んできた開発者のblogをフォローし始めます。さまざまなアプローチを見るのは興味深いです。このブログを通じて、ECCDについて学びます。興味があるので、Ralph KimballのデータウェアハウスETLツールキットbookを借りて、「抽出、クリーン、適合、および配信」プロセスについて詳しく説明します。同じブログでは、プログラミングスキルなしでETLを作成することを目的とした多くのアプリケーションについても触れています。これは、あなたの会社で行ったETLに特に役立ちます。上司である技術者ではない人が、あなたが行ったことに少し変更を加えるよう常に求めているからです。
発見する
私見、メンターや経験豊富な同僚がいない場合の難しい部分は、発見することであり、発見することで、「私はこれについて聞いたことがない」から「聞いたことはあるが、よく分からない」まで。
誰かが私のコードをレビューして、私が本当にいくつかのスタイル規則を使い始めるべきだと言った場合、少しの好奇心で、プログラミングにはさまざまなスタイルのコードがあり、特定の言語およびコードベースのスタイルに固執する必要があります。多くの言語には、スタイルを適用するツールがあります（C＃のStyleCopなど）。
誰も私にそのスタイルについて教えてくれないのなら、どうしてそのようなものが存在することを知ることができるでしょうか？
ブログやStack Exchangeなどのリソースが便利な場所です。ウィキペディアは役に立たないでしょう（プログラミングについてランダムなページに何日もぶつからない限り）、本がそれらについて話すことはめったにありません。
同じことは、コードとの関連性が低いパターンやプラクティスや事柄にも当てはまります。たとえば、ある開発者が朝目を覚ますと、ITILについてこれまで気にしたことがない一方で、ITILについて何かを学ぶ必要があると自分に言い聞かせることはほとんど想像できません。
新しい用語を発見したら、それについて学ぶのはかなり簡単です。 「コードコントラクト」という新しい用語を指定し、C＃開発者であれば、MSDN（または、Jon Skeetの本）で十分な情報を自分で簡単に見つけることができます。
好奇心が役立ちます
インターンと一緒に仕事をしているとき、講義の外で好奇心が強い人が一番いいことにいつも気づきます。彼らは、関数型プログラミングと呼ばれるものが存在しないことを知っていても、関数型言語を知らなくても、一般的な用語でFPと説明することはできます。他のパラダイムとどう違うのですか？彼らは、単に講義に出席するのではなく、ブログを読んでStack Exchangeを使用していたからといって、アジャイル、Unicode、または部分信頼/サンドボックスモデルについて知っているかもしれません。
メンターがいなくても、大学で教えられていないことはすべて学んでいます。
私も同じような状況にあります。私たちは小さなチームであり、私たちのコア開発製品の作業は、ほとんどが数年前のコードベースの増分変更です。
最新の状態を維持し、スキルを向上させるために使用しているいくつかのテクニック。
オンザジョブ：
- 読む：本、ブログ、PR資料。私はいくつかのRSSフィードをフォローしています。その日のO'Reillyの契約が、私が聞いたことのないテクノロジーに関するものであるとき、私はその本の説明を読みました。テクノロジーが私が取り組んでいるものと関係がある場合、MainMaの回答と同様に、5分から10分かけて、もう少し深く調査します。これをいくつかの異なるRSSフィードで繰り返します。
- 会社のリソース（時間および/またはお金）でサポートできる経営陣とのトレーニング計画を作成する
- ほとんどのプログラマーの傾向に反して、変更と新しい設計オプションを受け入れるようにしてください。 変更のための変更は良くありませんが、変更のために、開発者が新しいデザインやフレームワークの使用を避けることがあまりにも多いと思います。これは歩むべき細い線であり、拘束力のある決定を急ぐのではなく、物事を実行する新しい方法に注意してください。変更によっては、予期しない利点が生じる可能性があります。DVCSに移行すると、コードベースをより簡単に試して、新しいテクノロジーを試すことができます。
- 会議が好きな人もいます。投資された時間の見返りは小さいことがわかりました。
仕事外：
日々の業務以外で自分のスキルに取り組むことが重要であることがわかりました。実験し、間違いを犯し、興味を追求する自由は、私をITに引き込み続けます。仕事中のプロジェクトしかなく、すぐに役立つものに限定して学習する必要がある場合、すぐに燃え尽きてしまいます。
- 非作業プロジェクトに参加します。私にとって、これは個人的な興味に関連する機能的なウェブサイトを開発しています。私は自由にリファクタリングし、さまざまなテクノロジーを積極的に試しています。オープンソースに貢献すると、他の人のコードにも触れることができます。これは、経験豊富な開発者がいる会社とのインタビューのために共有するための良い資料も提供します。
- コードキャンプ： コードキャンプ が エリア に参加している場合。これらは勤務時間外ではなく無料なので、個人的に興味のあるトピックのセッションに自由に参加できます。通常の会議と比較すると、これらは通常ローカルであり、テクノロジーの広い範囲をカバーしているため、より集中した価値があると思います。
SOまたはProgrammers.SEに頻繁にアクセスすることを忘れないでください。
ここでの回答は大いに役立つでしょうが、私は何かを強調したいと思います。1日8時間、週5日間、あなたよりも優れた人との仕事（勝手で個人的な定義の場合）に勝るものはありません。それだけは確かです。
あなたが常に良くなりたい、いつも学びたいと思っているタイプの開発者なら、結局は別の会社に行かなければならないでしょう。これは避けられないことであり、計画する必要があります。
自分に合った会社を見つけたら、そこから成長するのではなく、その中で成長し続けることができます。
提案をする前に、私は1年ほど前に非常に似た立場にあったと言わなければなりません。
プロジェクトを完了しているが、改善する余地はたくさんあると感じている場合は、それよりも良いことです。
あるとき、私はプロジェクトを完了する技術的能力と自信がありませんでした。多くの場合、私は本を購入し、かなり技術的なブログを読んで、自分のことを「自分の深みから」見つけました。私にとって最大の問題は、大規模なエンタープライズアプリケーションに触れたことがないということでした。多くの場合、私は何かをうまくやりますが、私がやったことを検証するために私の側に誰もいません。
これはやる気があり、やりがいがあったので、あなたがどこから来たのかわかります。この問題にどのように対処しましたか？私は会社を辞めて、定評のあるソフトウェア開発会社に参加しました。これは、この1年で多くの経験を積むのに役立ちました。
会社を辞めたくないのであれば、業界の先駆者たちが書いた本をお勧めします。まず、Andrew HuntのPragmatic Programmerから始めます。この本には、覚えやすい非常に便利な類推が数多く含まれています。この本の最初のいくつかの章は、私が職場で使用しているものとは非常に異なるプログラミング言語を採用するように私を促しました。私は非技術文献を読み始めました-私は今、小説やSFを読むことで私はより優れたプログラマーになると信じています。エッセイを書くことは、きれいなコードを書くことから遠くないです。一部の作家は良い人もいれば悪い人もいます。この本は私が書いたものを気にさせてくれました。アナロジーの1つは「壊れたウィンドウ」と呼ばれます。あなたは何日も通りに放置された車を放置しても何も起こりません。 1つのウィンドウを壊すと、車はおそらく翌日に破壊されます。コードも同じです。コードが壊れていたり不十分に書かれている場合は、すぐに修正してください。遅らせたり遅らせたりするので、そのままにしないでください。この本を読み始めると、コードについて別の方法で考えるようになる数十の類似した例が見つかります。
次に、Robert C. MartinによるClean Codeに進むことをお勧めします。この本は、悪いコードと良い（クリーンな）コードを読むように強制するので、より実用的です。著者は、オープンソースプロジェクトの1つからのコードサンプルを使用します。あなたを導く人はいないとあなたは言う。他の誰かのコードを見て自分のコードと比較し、どのようにしてそれを改善できるかを知る絶好の機会があります。この本を読んでいると、プロジェクトに携わっている誰かをシャドウイングするようなものでした。この本はまた、最も簡単な最も難しいこと、つまり懸念の分離に重点を置いています。著者は、業界のパイオニアに「クリーン」なコードであると考えるものを尋ねました。彼らの答えを読んだら、あなたはそれらをあなたの意見と比較することができるでしょう。
最後に、オープンソースプロジェクトに取り組むことを検討しましたか？他の、おそらく経験豊富な開発者と協力して、コードをレビューして正しい方向に向けることができます。
私の最初の答えで述べたように、それは一晩では起こりません。私は数年前からこれを行っており、ほとんど毎日、自分が間違っていることを知っています。
幸運を！
ソフトウェア開発はチームスポーツです。スポーツのように、非常に高いレベルでプレーするには、同じことをする他の人と一緒になり、競争する必要があります。移動する機会を探してください。
練習は永続的なものになることを忘れないでください。したがって、常により良い技術と知識に向けて取り組んでいない場合、批評家やロールモデルなしで孤立して取り組むと、スキルが上がらないことがあります。
世界中で競争が激化しているため、ニッチな状況は一時的なものであり、満足のいく仕事の基準を満たすような機会を準備すると同時に、優れたチームと仕事をするために快適なゾーンの外に連れて行ってくれます。
問題解決の練習。他のコードを読んで理解し（githubはこのための優れたリソースです）、コードの改善を送信します。コンサルティング業務を行うことで、スキルセットをさらに広げることができます。