こんにちは、私の名前はドミトリー・カルロフスキーで、プロのサイクリストです。 私のキャリアの中で、大小さまざまで、速くて快適で、曲がってまっすぐな自転車をたくさん作りました。 したがって、スマートプログラマーが大規模で複雑なアプリケーションを作成し、同時に自分の手でいくつかの簡単な行を書くのではなく、 別の左パッドをプロジェクトに接続するのを見るのはかなりワイルドです。 この理由は、プログラマーの間で開発され、それ自体をサポートしている生産中の自転車に対する恐怖です。

プログラマーの進化

プレゼンテーションを簡単にするために、プログラマーの3つの条件付きグループを区別します。 条件付き。明確な境界線がなく、異なる地域の同じ人物が異なるグループに属することができるため。

初心者

• 彼はまだ経験と知識がほとんどありませんが、習慣を確立していないため、すぐに新しいものを学びます。
• 斬新な効果のため、彼は既存のソリューションの欠点をよく理解しており、これらの欠点なしで自分でやろうと強く望んでいます。
• 彼は、これらまたは他の慣行および原則がどのように、そしてなぜ形成されたかを知らず、もしそうなら、彼はそれらが自分の肌に現れる理由を感じなかった。
• 彼が書いたコードの大部分は捨てられるか、認識できないほどリファクタリングされます。 せいぜい、経験豊富な同僚の指示の下で自分の手で。
• サードパーティのライブラリは多くの基準の点で優れていると判明する可能性が高いため、自転車を書くことについて容赦なく執筆しています。

スペシャリスト

• 人気のある図書館の大部分は、自転車とソースコードを開くためにまだ手を打っているので、主な仕事から余暇に彼によって書かれました。
• 原則として、コードの品質はエコシステム内のコードの平均品質に対応しています。 誰もがコールバックから麺を書く場合、彼のために何も残っていません。
• 原則として、サードパーティのコードを使用します。これは、時間制限のために独自のコードはそれほど良くないか、さらに悪いためです。
• したがって、自転車を明示的に（コードレビューで）または暗黙的に（バグレポートで）受け取り続けます。
• 何らかの問題が彼を完全に捕らえたとき、彼は自転車を見ました。 そして、そのようなプログラマーの大多数がいるので、それは1.5人の開発者によってサポートされて、互いに互換性のない100,500台の自転車であることがわかります。

プロ

• 彼は病院の平均よりも問題を解決できますが、リソースが限られているため、何に時間を費やすかを選択せざるを得ません。
• 習慣から、彼らは彼に手を打ちました。 特に、Dunning-Kruegerの影響を受けて、すべての意思決定が多数派によって行われるスクラムを会社が行っている場合。
• 多くの場合、最初の2つの段階で形成された複合体のために、彼は自分自身を制限し、「テスト済み」、「考え出した」、「多数の開発者によってサポートされている」サードパーティのライブラリよりも良いことはできないと考えています。

恐怖の原因

プログラマーの進化をたどると、最初はスキルはほとんどないが、恐れはないことに気付くのは簡単です。スキルを習得すると、自転車に対する恐怖が現れて激化します。 この恐怖に対処するには、その原因を分析する必要があります。

うまくできない

初心者は本当にできません。 彼は、経験豊富な同僚や図書館の開発者に新鮮な表情で見た問題の本質と重要性を説明するために努力を向けるべきです。

スペシャリストは、問題に精通しており、他のスペシャリストや専門家と相談すれば、おそらく成功するでしょう。

専門家は、ほとんどの場合、トピックに精通しており、包括的な分析のスキルさえ持っているため、ほとんどの場合、よりうまくやることができます。 残念ながら、他の専門家はほとんどいないため、通常、彼と相談する人はいません。彼らは他のトピックに取り組んでいます。 そして、専門家には視野がありません。

欠陥を修復する人はいません

通常、自転車の作者は、彼の発案の欠陥を修復する意欲があります。 しかし、遅かれ早かれ、彼が数時間後にやるなら、この動機は過ぎ去ります。 そして、ここではサードパーティのライブラリを使用するとリソースを節約できるように思えます。なぜなら、支払う必要のない他の人々がそのサポートに従事しているからです。 しかし、それらに影響を与えることはできません。したがって、期限をキャッチするには、袖をまくり上げて自分で欠陥を修正する必要があります。その後、成功を保証することなく、パッチをメインリポジトリに分割することは長く困難です。

誰も改善も開発もしません

ここでは、状況は欠陥の場合と同じです。 しかし、欠陥がある場合、通常、修理が必要であることは誰にとっても明らかであり、開発の方向性に関する見方はすべての人で異なります。 サードパーティの開発者は、あなたのためではなく、必要な場所でライブラリを開発します。 あなたにとってではなく、彼にとって便利な速度で。 したがって、特定の開発ベクトルが必要な場合、自転車は制御と予測可能性を提供します。これは、時間とお金よりも管理にとってはるかに重要な2つの品質です。

私はそれを他のどこでも使用できません

社外で自転車を使用する場合は、自由時間に自転車を開発するか、ソースのオープンに同意する必要があります。これは通常、より困難ですが非常に可能です。 結局のところ、会社は潜在的な従業員の間でほぼ無料でPRを受け取ります。また、他の自転車ユーザーの人の無料のベータテスター（または貢献者でさえも、あなたはそれを当てにしてはいけません）。

時間とお金が無駄になる

ここでは、まず第一に、他の選択肢と比較する価値があります。 何もなければ、選択の余地はありません-あなたはそれを切らなければなりません。 選択肢がある場合、お金と時間の点で比較する価値があります。

• あなたの自転車を書くコストは良質です。 これには、コードの記述、テストの記述、プロジェクトの自転車への転送、導入された欠陥のコストの評価が含まれます。
• 自転車がもたらすメリット。 これは、特定の機能、欠陥の減少とコスト、およびその他の要因による節約になる場合があります。
• サードパーティのソリューションを統合するコスト。 繰り返しますが、テストのコストと導入された欠陥の評価を含みます。
• サードパーティのソリューションによって課される制約。 サードパーティのソリューションがまったく適合しないことが判明する場合があります。 または、開発が2倍遅くなること。

また、一部の制限が受け入れられないことが突然判明した場合、サードパーティのソリューションから自転車に切り替えるコストを個別に評価する価値があります。 サードパーティソリューションを実装し、必要に応じて（必要に応じて）すぐに自転車に移す方が、今すぐ自転車の構築に時間を費やすよりも、今では収益性が高いことがよくあります。

この評価は、ゲームがロウソクに値するかどうかを理解し、他の人の（またはその逆）をとらないで自分で書く価値がある理由を経営者に説明するのに役立ちます。

私は前任者を呪ったように呪われます

自転車がプロジェクトのかなりの部分を占めていることは疑わしい。 したがって、彼らは残りのコードに対してもっと呪いをかけます。 そのため、自転車は少なくとも悪化することはありません。 そして、誰もそれをサードパーティのライブラリや別の自転車と交換したくない場合はさらに良いです。 これを行うには、次のものが必要です。

1. プロジェクトの明確で重要な利点の存在。
2. ラッパーを使用する必要がないように、シンプルな使用インターフェイス。
3. 柔軟性のあるAPIにより、要件がわずかに変更された新しい自転車を見る必要がなくなります。
4. テストカバレッジが良好です。これにより、バグレポートのフラッシングが少なくなり、リファクタリングをうまく再現できます。
5. 自転車の作者を探して乗る方法を理解する必要がないように、包括的なドキュメント。

責任を取りたくない

あなたが取り組んでいるプロジェクトについて気にしないなら、これは正常です。 1日の3分の1の時間を何に費やしてもかまわない場合は、視点を守る必要があります。 そして、あなたの地位が高いほど、言うべきことに近づく価値があります。 実際、あなたがどのように働くかだけでなく、他の人がどのように働くか、そしてプロジェクト全体がどこに行くかはあなたの声に依存します。

推奨事項

私は自転車に対する根拠のない恐怖を示すことができたと思います。 プロ意識に近づくほど、野心的な自転車に乗ることができます。 リスクは低いが、この分野でかなりの経験を積む小型の自転車から始めることをお勧めします。 そして、このポートフォリオで、ますますクールで面白いものを引き受けます。 真のプロはクールなことをするだけでなく、自分の創作をいつ放棄するかを知っていることを忘れないことが重要です。 したがって、常にあなたが正しいことをしているという自信を与える分析を実行し、管理はあなたの側にあり、あなたの後に来る人はそれがどんな自転車であるのか、なぜここにあるのか、そうでなければそれが不可能だったのかを理解します。

さて、サードパーティライブラリの分析を支援するために、夕方にGitHub上のプロジェクトの問題を解決する時間を見積もることができるアプリケーションを書き留めました。 数値が大きいほど、サポート付きのプロジェクトが悪化し、問題の解決を待つ時間が長くなります。 例： Angular、VueJS、React、そしてもちろんこのバイクが書かれている$ molの比較 。 Angularのすべての未解決の問題を解決することはGitHubのすべての制限を使い果たすため、最後のリンクは1回限りであることに留意してください。