前文
こんにちは、％user_name％。 プログラミングの長年の経験を通じて、私は構造化に値するいくつかの観察結果を蓄積してきました。 今日は、プログラマーの仕事の中でトレーニングの必要性に触れる部分についてお話します。 私はいくつかのあいまいな原則を述べようとしますが、プログラミングにはそれらの多くがあります！
1.可能な限りプログラムしてください！
コーディング、コーディング、そしてコーディング。 これは、より成熟した開発者が初心者に最もよく推奨するものです。 そして、このアドバイスは効果的だと思われます。 それはそうですが、完全ではありません。 真実はもっと深い。
会社にとって、すべてのプログラマーが本番で使用されるツールを所有していること、そして可能であれば使用される可能性のあるツールを所有していることが重要です。 初心者のプログラマーの多くは、Android、Java EE、Qt、または実際に使用する他の何かに関する厚い本を購入します。 これらの本から、自分のプロジェクトで実際にテストして実際にテストする部分のみが学ばれることを誰もが理解していると思います。
ある程度の知識を身につけたプログラマーは、自分自身のタスクを楽しんでいることがあり、「私が知っている方法で実行できる可能性のあるものを選択して実行する」ように構成されています。 このアプローチは、若い世代の90パーセントにあります。 時間が経つにつれて、彼らが働いている分野の知識を磨き始め、プロとしての成長を非常に遅くします。
AndroidでSQLiteの作業を研究した人は、彼が関与している彼のプロジェクトに含まれていない場合、ORMliteとともにORMの研究を開始する人はほとんどいません。 もちろん、新しいプロジェクトごとに彼のコードはますます良くなりますが、...プログラマーがスレッドセーフシングルトンを作成することを学んだ瞬間から、それを作成する次のイニシアチブプロジェクトごとに、彼は単にアイドリングに時間を費やします（おそらくどこかに本当に静的ファクトリを使用する必要がありますか？！？）。
今日、自己開発にかなりの時間を費やし、特定のタスクに必要ではないため、実際にはマルチスレッドに非常に表面的に精通しているJavaの経験を持つプログラマーが大勢います。
自分よりも積極的に成長するには、たくさん書くだけでは不十分です。さまざまな方法で書く必要があります。 そして、これは、プログラマーが目を閉じて実装できる打ち負かされたトラックの代わりに、知られていない、理解しにくいものであり、適用された利点を常に持たないものを選択する必要があるという事実に関連しています（特定の場合）。 会社にとって有益ですか？ いや！ もちろん、そうではありません。そのようなプログラマーは締め切りを埋め、潜在的な問題を作成し、一般にコードの一部を再度書き換える必要がある状態に至る可能性があるためです！
プログラマーにとって有益ですか？ 肩に明るい頭があれば、1年か2年で真ん中（時には6月）からSinierに安全にジャンプできます！ はい、それはリスクですが、それだけの価値があり、最終的には、すべてのプログラマーが自分自身のために働いており、常にインテリジェントな従業員を雇いたい企業がたくさんあることを覚えておく必要があります。
2.期限を設定する
タイミングは重要なキャンペーンです。 それらは、プログラミングに精通していないマネージャーにとって重要です。 国際的な大企業では、プログラマーは、開発者に関係なく、純粋に「ビジネス」によって締め切りが一般に編集されるという事実に直面していることにしばしば不満を述べています。 後者がソフトウェア開発フェーズにテストが含まれる理由を説明することは困難です。テストがなければ、プロセスはより高速になります...
マネージャー/会社/ボスの位置にもかかわらず、コードはテストされなければなりません！ 単体テスト、これは万能薬ではありませんが、コードがテストでカバーされるまで、ケースがすでに完了していると言うことは不可能です。 プログラマーの作業は、「うまくいった」ときではなく、PPと一緒にプログラマーが次のデータを提供したときに完了します。
-ソフトウェアが機能する入力パラメーターの数と数。
-どのタイプの入力パラメータでも、出力で正しい結果が保証されます。
-プログラムの（メイン）モジュールで提供される不正なパラメーターの動作はどうなりますか。
これがなければ、時間通りにそれを行うことができますが、プログラムを最初に計画したよりもはるかに遅くリリースされることを理解する必要があります。
3.アーキテクチャを作成する段階で作成する
良いプログラムを書きたい、UMLを学ぶ。 キーボードの下から生まれた最高のソフトウェアは、うまく設計されています。 記述されたアーキテクチャは、アーキテクチャを変更することなく（まあ、または最小限の変更で）潜在的な変更（新しい顧客の要件）を簡単に含めることができるようにスケーラブルでなければなりません。 また、高品質のアーキテクチャにより、プログラムの主要な特性を作成し、最終製品の要件（パフォーマンスや機能など）を策定することができます。 ここで、TDDのすべてのテストをコンパイルできます。
アーキテクチャを開発したら、関与するテクノロジーを決定する必要があります。 その後、コーディングに移ります。そこでは、勉強に多くの時間を費やす必要がありますが（ポイント1を参照）、創造性ではありません！ もちろん、いくつかのことはさまざまな方法で実装でき、これも創造性ですが、私が今話していることは明確だと思います。 彼らは次の「スクイーグル」を思いついたので、すぐにそれを実装したいと思います。遅刻して、新しいソフトウェアや新しいバージョンのコンセプトを再び作成する瞬間まで待ってください。 開発段階では、新しいテクノロジーまたはソリューションを使用した概念の実装に関連するリスクがすでに十分にあります。
4.問題の原因を常に解決します。
多くの場合、プログラマは時間を費やす代わりにnull / NULL / 0 /などのチェックを行い、標準システム関数がこのゼロ値を返す理由を理解します。 本質を常に知ることが重要であり、結果に対処しないことが重要です。 はい、時には決定が今必要であり、マットのトレーニングと改善のための時間を与えません。 パーツ。 この場合、複雑な問題を解決する時間を確保するために、6月の位置に長く座ることをお勧めしますが、それでも学習と再学習が必要です。 プログラマが自分のアプリケーションが予測可能な理由を知っている場合にのみ、彼は落ち着くことができます。 ソフトウェアが予測可能であることを知ることと、予測できる理由を知ることとの間には、数百時間のトレーニングのギャップがあることを常に覚えておく価値があります！
あとがき
多くの人が言ったことの多くは意見の相違を感じさせます。 まず第一に、これらのすべての原則は、作業および戦闘プロジェクトで実施されるべきであるという事実の問題について。 スタイルの観点から多くの反対者の意見を聞いたことがあります。これはすべてはいですが、トレーニングプロジェクトにのみ適用され、明確な期限、要件、フレームワークが存在する場合は非現実的です。 そして、ある意味では、すべてのプロジェクト（労働者とトレーニングの両方）ですべてを使用し始めなければ、スペシャリストとしての成長率は急激に低下します。 個人的な時間と自由な時間は仕事の週ほどではなく、例外は仕事をする必要がない人です。人生は彼らに最も貴重なリソースを与えました-あなたが職場で自己開発と素晴らしいフレームワーク、スタートアップ、プロジェクトに変わる創造性に費やすことができる時間...これはすべて別の記事のトピックです。