より経験豊富な開発者がいない場合に、実際のプロジェクトで作業しながらスキルを向上させるにはどうすればよいですか？[閉まっている]

私はC＃とASP.Netで働いている小さな会社の主任開発者です。私たちのチームは、開発と設計の経験が少ない2〜3人の小規模です。私はより多くの上級開発者から学ぶ機会がありません。自分のチームの誰も私を導き、最良のアプローチを選択するのを手伝ってくれる人はいません。

経験豊富な開発者がいない場合、実際のプロジェクトに取り組みながらソフトウェア開発スキルを向上させるにはどうすればよいですか？

経験豊富な同僚以外にも、書籍、熟練した開発者のブログ、Stack Exchange、講義/会議などから学ぶべき情報源がたくさんあります。コードレビューも重要であり、CodeReview.SEは貴重なリソースです。

例でどのように機能するかを見てみましょう。

例

「ETL」という用語に言及しているブログ投稿を読んでいます。その意味はわかりませんが、この記事からは、あるデータサポートから別のデータサポートにデータを移動する一種のプロセスまたはワークフローであることを漠然と理解しています。

ウィキペディアやその他のリソースにアクセスして、より正確なビジョンを得ることができます。ETLを使用するのがいつ役立つかはまだ明確ではありません。結局のところ、実際のETLの作成に時間をかけすぎるよりも、すべての作業を実行するSQLクエリを作成する方がはるかに簡単に思えます。

これらの質問に答えるには、地元の図書館からETLに関する本を借ります。一部の抽出-変換-ロードプロセスは、単純なSQLクエリでは簡単に実行できないことを説明しています。データの検証/正規化とマッピングの両方。

ETLとは何か、それを使用する方法、特にETLが必要な場合と適切なツールではない場合について、明確なビジョンがあります。一方、あなたは個人的なプロジェクトとして小さなETLを実装しました。このプロジェクトでは、あなたにとって十分に明確ではなく、本でカバーされていないいくつかのポイントを発見することができます。これらの点はかなり抽象的であり、ソースコードに関連していないため、Programmers.SEに質問を投稿します。

社内で作成する機会があれば、作成を開始します。いくつか問題があります。一部はコードに関連しています。Stack Overflowに質問を投稿します。その他はデータベースに関連しています。DBA.SEで質問します。

最後に、ETLを最適化する方法について非常に熟練した開発者によって行われた会議があります。この会議に参加すると、プロジェクトで実行できる機能強化に関する貴重なヒントが得られます。

また、何年もさまざまなETLに取り組んでいる開発者のブログをフォローし始めます。さまざまなアプローチを見るのは興味深いことです。このブログを通じて、ECCDについて学ぶことができます。興味があるので、Ralph KimballのThe Data Warehouse ETL Toolkitを借りてください。この本は、「抽出、クリーン、適合、配信」プロセスについて詳しく説明しています。同じブログでは、プログラミングスキルなしで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のThe Pragmatic Programmerから始めます。この本には、覚えやすい非常に多くの便利な類推が含まれています。この本の最初の数章では、職場で使用しているものとは非常に異なるプログラミング言語を選択するように勧められました。私は非技術文献を読み始めました-今、小説や空想科学小説を読むことで私はより良いプログラマになると信じています。エッセイを書くことは、きれいなコードを書くことからそう遠くありません。良い作家もいれば、悪い作家もいます。この本は私が書いていることを気にしました。類推の1つは「壊れたウィンドウ」と呼ばれます。何日も路上に放置された車を放置しても、何も起こりません。1つのウィンドウを壊したら、車はおそらく翌日に破壊されます。コードも同じです。壊れたコードや不完全に書かれたコードを見つけた場合は、すぐに修正します。遅かれ早かれ「お化け」に戻ってくるので、そのまま残さないでください。この本を読み進めていくと、コードを別の方法で考えさせる類似の類似点が何十個も見つかるでしょう。

次に、Robert C. MartinによるClean Codeに進むことをお勧めします。この本は、悪いコードと良い（クリーンな）コードを読むことを強制するため、より実用的です。著者は、オープンソースプロジェクトの1つのコードサンプルを使用します。あなたはあなたを導く誰もいないと言います。他の誰かのコードを見て、自分のコードと比較し、どのように改善できるかを知る絶好の機会があります。この本を読んでいる私にとって、プロジェクトに取り組んでいる誰かを隠すようなものです。この本はまた、最も簡単な最も難しいことである懸念の分離にも力を入れています。著者は、私たちの業界の先駆者に、彼らが「きれいな」コードであると考えるものを尋ねました。回答を読んだら、クリーンコードとは何かについての自分の意見と比較することができます。

最後に、オープンソースプロジェクトに取り組むことを検討しましたか？コードを確認して正しい方向に導くことができる、おそらく経験豊富な他の開発者と協力することになります。

私が最初の答えで言ったように、それは一晩で起こりません。私はこれを数年前からやっており、ほぼ毎日、私が間違っていることを知っています。

幸運を！

問題解決の練習。他のコードを読んで理解し（githubはこのための優れたリソースです）、改善を送信してください。コンサルティングの仕事をすることは、あなたのスキルセットを広げるのに本当に役立ちます。