ITで働いている間、私はさまざまな分野の活動に参加しました。 私はチームリーダーであり、開発者兼プロジェクトマネージャーでもありました。 彼は大規模なプロジェクトを率いていましたが、なかでも成功し、あまり成功していませんでした。 私は最高クラスの専門家（少なくともそれが私が考慮し、まだこれらの人々であると考えているもの）とあまり経験のない同僚と働いた。 私は、これまでずっとITに携わってきた人たちと、まったく異なる分野に興味と活動がある人たちの両方と協力しました。
この間ずっと私は何かを勉強し、今日まで勉強を続けています。
各プロジェクトが完了した後、行われた作業の喜びに加えて、何がうまく行われ、何がより良くできるかについての理解もありました。
今日は、私が始めたばかりのときに聞いて喜んでいるであろうヒントを共有したいと思います。
ソリューションが単純であればあるほど、信頼性は高くなります。
多くのコードを使用するソリューションでは、間違いを犯しやすくなります。 さらに、正しい決定は明白で理解できるものでなければなりません。
発明者の自転車の価値はありません
既製のフレームワーク、または使用できるライブラリがある場合は、それを使用します。 自分で書いてはいけません。
ロジックとデータ型は、別々のアセンブリに配置するのが最適です。
それほど大きくないプロジェクトを開発する場合でも、ロジックとタイプを別々に分ける価値があります。 これにより、将来、コードのテストと再利用が容易になります。 プロジェクトを拡張する必要がある場合は、時間コストも削減されます。
オープンソースは賢明に使用されなければならない
製品の基盤としてオープンソースプロジェクトを採用している場合、すぐにそのプロジェクトに突入して大量のコードを記述しないでください。 メイン製品の新しいバージョンがリリースされると、マージが頭痛の種になる可能性があります。 可能であれば、コードをモジュールと個々のコードファイルに割り当てる必要があります。 コードを根本的に変更する場合は、将来のすべてのリスクと考えられる問題を完全に評価する必要があります。
すぐにプラットフォームを作成しないでください
問題を解決することをお勧めします。 多くの開発者（私も含めて同じアプローチに苦しむことがあります:)）すぐにすべての万能ソリューションを作成しようとします。 これをしないでください。 多くの場合、特定の問題を解決して結果を得ることをお勧めします。 普遍的なソリューションの作成に費やした時間は報われない可能性があり、多くの場合、将来的には需要がなくなるでしょう。 さらに、ソリューションがより普遍的であるほど、より複雑で使用が制限されることが多くなります。
多くの場合、このアプローチは初心者の開発者に起こります。そのため、アドバイスはまず、彼らに適用されます-そのようなソリューションを書き始める前に-チームのシニアフレンドに相談します-それが有用で需要があるかどうか。 そして、あなたが肯定的な答えを得た場合にのみ、そのような仕事を始める価値があります。
CMSは万能薬ではありません
人気のあるCMSがインストールされ、製品がコードを「ラップ」することで開発されたという事実から始まるWebプロジェクトをよく見ました。 結果は、CMS機能を10％使用するフロッピーメカニズムであり、コードの90％が過負荷で読み込めなかったため、CMS自体の構造とそのデータベースの構造を考慮する必要がありました。
このために不器用なCMSを適応させるよりも、特定の問題の解決策を書く方がはるかに効果的です。
最も重要な主題分野
すべてのプロジェクトの優先順位を確認します。サブジェクトエリア->アーキテクチャ->管理タスク
製品は、開発者やシステム管理者向けではなく、クライアント向けに作成されます。
管理者が開発者に、製品のAPIを作成する方が良い方法を伝えるようになると、状況に直面する必要があります。 開発者が作業方法を知っているCMSは彼をサポートしていないため、クライアントが機能を放棄することを提案した開発者もいました。 高品質の製品を本当に作成したい場合、このアプローチは受け入れられません。
ソリューションは主にクライアント向けに作成されており、プログラマや管理者向けではありません。
最適化は必要な場合にのみ必要です
「Entityフレームワークを使用せず、非効率的なSQLを生成する」または「linqの使用は構文上の砂糖です！」と言う開発者に会うことがあります。 「はい、時々、便利なものすべてが速度の面で最も効果的であるとは限りません。 しかし、パフォーマンスのパーセンテージは、使いやすさを低下させ、コードを増やす価値がありますか？
多くの場合、2つまたは3つの「重い」関数をストアドプロシージャに分離し、その呼び出しをEntity Frameworkでラップするか、コードの特定のボトルネックを最適化するだけで、新しいテクノロジが提供する利点を完全に放棄できます。
再最適化されるよりも読みやすいコード
ほとんどの場合、読みやすく理解しやすいコードは、高度に最適化されているが理解できないコードよりも優れています。
ツールは快適でなければなりません
新しいテクノロジーが登場したり、ツールや製品が登場して、広く知れ渡り、レビューを喜ばせることがあります。 しかし実際には、ツールはまだ技術的に準備ができていません。 このようなツールの導入は、明らかな約束と技術的有効性にもかかわらず、チームの生産性に悪影響を与える可能性があります。 そして、利点は欠点と重ならないかもしれません。
ツールは何よりもまず便利で、問題を解決する必要があります。
TKは
貧弱なTKでさえ、誰よりも優れています。
また、プロジェクトのドキュメントがまったく入手できず、口頭での合意のレベルにあるようなプロジェクトにも出会いました。 同時に、そのようなプロジェクトのサイズは非常に異なっていました-小さいものと非常に大きいものの両方。
顧客と良好な関係にあり、顧客を完全に信頼している場合でも、すべてのポイントを修正する必要があります。 そして、これでも常に助けになるとは限りません。 同じ用語と説明を理解することは、プロジェクトの参加者間で根本的に異なる場合があります。
だから私はたまたまドメイン用語の基本的な理解だけが数時間議論された会議にいた。 同時に、開発も始まっていません。
自分で書くよりも完成品を使うほうがいい
開発者またはクライアントが彼の決定を書く価値があるものを決定する多くの状況があります。 実際、半分のケースのどこかで、これを行う価値はありません。
開発は常に長くて費用のかかるプロセスです。 したがって、たとえ自分のアナログを書くほうが簡単で安価に思えたとしても-90％で幻想に過ぎません。
市場に同様のソリューションがある場合は、購入することをお勧めします。 すでに存在し、すでに機能しています。 ここと今。
すべてのプロジェクト参加者がリスクを認識していて、プロセスが長くて費用がかかることを理解している場合にのみ、決定を書く価値があります。
書くよりも購入して実装する方が良いという明確な兆候：
- 意図されたユースケースをカバーする製品があります
- 特定の構成後に意図されたユースケースをカバーする製品があります
- 相互作用と統合を通じて、目的のユースケースをカバーする製品がいくつかあります。
- 特定の機能で拡張できる製品（CRM用のモジュールを追加）があり、その後、ユースケースをカバーします
自分で書くことが理にかなっている場合：
- 意思決定者は、開発を開始する理由を正確に知っています。
- 必要な機能を実装できる製品は市場にありません
- 同社は、製品に長期間投資するだけでなく、後でサポートに従事するのに十分な資金を持っています
- あなたは新興企業であり、まったく異なる基準があなたのために働いています
ITに加えて、人生にはもっと多くのものがあります
このヒントはリストの最後ですが、重要ではありません。 記事の冒頭で、Artemy Surinが企画したONE☆LIFE Everest Expeditionの写真を載せただけではありません。 私たちの職業の多くにとって、ITは仕事だけでなく、生活そのものになっています。 私自身はラップトップ/タブレット/電話の画面の後ろで多くの時間を過ごします。 しかし、これ以外にも、私たちの多くに多くの喜びを与えるものがあります。 一部の人にとっては、これはハンググライディングです。一部の人にとっては、本を読んだり、スポーツをしたり、旅行したり、新しい人とチャットしたり、収集したり、絵を描いたり、書いたりします。
仕事だけでなくライブもみんなにお願いしたいです！
PS MarcusAureliusに感謝し
ます -記事の予備的なレビューと有用なコメントについて。