Java エンタープライズレベルのプロジェクト開発のアイデア。偶然出会って、読んで学んだことがあるから、この記事は事例ではなく、考え方や概念についてのみ話していますので、困っている人は参考にしてください。
エンタープライズレベルのプロジェクト開発とは
「エンタープライズレベルのプロジェクト」、エンタープライズレベルのプロジェクト開発、Javaもエンタープライズレベルのプロジェクト開発です、私たちはどこでもそれについて話します、それを聞きます、そしてそれについて話します毎日行われていますが、「エンタープライズレベル」とはどのようなプロジェクトですか?私が取り組んでいる小規模または大規模なプロジェクトは、エンタープライズ レベルと見なすことができますか?言い換えれば、GXPT はエンタープライズレベルのプロジェクトと考えることができます。次に、私はあなたとコミュニケーションをとり、学びます。
1. プロジェクト開発の現状
私たちの上級クラスでは大小さまざまなプロジェクトを行っており、全員が常にプロジェクトに取り組み、プロジェクトのキャッチアップを行っています。みなさんもプロジェクトをやり始めてからこれまで、大小さまざまなプロジェクトをこなしてきて、大なり小なり成功して誇りに思っているプロジェクトがあると思います。今、誰もが振り返って、私たちのプロジェクトが通常どのように作られているかを考えています。それぞれの開発チームが違っても、プロジェクトの納期や顧客のニーズの変化、さまざまな監督があっても、最低限の実装や全体の設計は同じです。ただし、拡張性や柔軟性は多少異なります。
プロジェクトが来るたびに、数回のミーティングの後、プロジェクトが開始され、人が割り当てられ始め、顧客からのいくつかの要件が分析され始め、その後、主要な開発者がプロジェクトのフレームワークを構築し始めます。そこで、あるプロジェクトが進行中です。プロジェクトのフレームワークを構築するということは、専門的に言えば、アーキテクチャを構築することを意味します。このアーキテクチャが良いかどうか、リスクは何かについては、実際にはプロジェクトをいくつかの論理層に分割することになります。使用されるテクノロジーのリスクと実現可能性の分析はほとんど考慮されません。その理由は非常に単純です。一般的にこのように開発されており、大きな問題は発生しないはずです。実際、多くのプロジェクトがこの方法で開発され、その多くが成功しています。これに問題はありません。標準であるかどうか、開発原則に従っているかどうかについては、多くの人は気にしません。それが何であれ、プロジェクトは成功します。
プロジェクト開発では、単一責任、依存関係の逆転、テスト容易性、保守容易性など、多くの原則を明確にしています。コーディングすると、これらのオリジナルの作成物が最終的には冗長になることがよくあります。特にプロジェクトを急ぐ過程では、コードの蓄積の効果がさらに顕著になりました。機能が完了していれば、残りは後で議論できます。多くの場合、この「後で言う」が「二度と言わない」になってしまい、何も問題はありません。
このようにして、毎年、私たちはプロジェクトを開発し、プロジェクトを実行し、プロジェクトをキャッチアップします。 Primary Key の多くの人は、プロジェクトが進むにつれて、後の段階ではソフトウェア開発にあまり興味がなくなるでしょう。私は当初、ソフトウェア開発は高度な知性を必要とする活動だと思っていましたが、今では肉体労働に似ていると感じています。毎年、毎月、私たちはさまざまな顧客向けにさまざまなシステムを開発しています。
情報は以下を示しています: 社内では...
多くの企業が多くの非常に「魅力的な」スローガンを頻繁に提唱していると思います: 多数のプロジェクトを実行し、共通コンポーネントを蓄積および開発することで、より多くのコンポーネントが存在します。とブロックは積まれていきますが、実際のプロジェクトでは顧客からも催促され、上司からも催促され、最終的には普遍的かどうかなんて誰も気にしません。 。プロジェクト開発はますます面倒になってきており、これが多くの開発者が転職や変革を起こす理由の 1 つであると私は考えています。
2. エンタープライズレベルのプロジェクトとは何ですか?
Java の学習がますます近づいています。この問題についてよく考えますか?エンタープライズ レベルのプロジェクトとは何ですか? 企業、機関、クライアント企業向けに開発されたプロジェクトはエンタープライズ レベルのプロジェクトとみなされますか?非常に大規模なプロジェクトはエンタープライズ レベルのプロジェクトですか?小規模プロジェクトはエンタープライズレベルのプロジェクトとみなされませんか?数万または数十万のコードを含むコードはエンタープライズ レベルのプロジェクトですか?混乱した!
実は私自身、「エンタープライズレベル」という概念があまり明確ではありませんでした。これは私が毎日言っていることであり、ミー先生も私にエンタープライズレベルの開発のアイデアを教えてくれました。最初は本当に少し満足していましたが、それは非常に奥深いものに聞こえました。
エンタープライズ レベルのプロジェクトに関しては、エンタープライズ レベルのアーキテクチャ、エンタープライズ レベルの開発など、多くの概念が付属しています。
しかし、何があっても、エンタープライズレベルの概念はプロジェクトの規模とはまったく関係がありません。
実際、エンタープライズレベルのプロジェクトは実際には「エンタープライズレベル」の考え方を持つプロジェクトです。
記事の最初の部分では、現在のプロジェクトのやり方、つまりコード関数の「スタッキング」に到達しました。このような蓄積によって蓄積されたコードは、そのプロジェクトでのみ使用され、今後の他のプロジェクトではほとんど役に立たないということは、コードが十分に再利用されていないことを意味し、プロジェクトには多くのコードが雑多に存在することがよくあります。はい、同様の関数の多くは独自のコード セットを必要とします。このような問題により、プロジェクトはますます一般的なものになり、多くの美しいスローガンが泡と化してしまいました。
エンタープライズレベルのプロジェクトには、少なくとも次の特性があります:
安定性
柔軟性
分離性
再利用性
保守性
誰もがこれらの特性を持っているわけではないと思います。これらの機能は馴染みがないため、詳しくは説明しません。誰もが知っている機能です。ここまで言うと、ナンセンスなことを言っていると思われるかもしれませんが、一つ言えることがあります。今、私たちはプロジェクトを開発する際にこれらのことをよく無視していますが、この無視のおかげでプロジェクトの開発は確かに加速しています。長期的には、状況から判断すると、プロジェクト開発は依然としてますます困難になっています。開発時に毎回このように考えて、その特性に準拠したコードを書こうとすると、ゆっくりと、ある種の「エンタープライズレベルのマインド」が徐々に出てきます。よく似た比喩です: プロジェクト中、難しい技術的な問題に遭遇し、それを克服するのに多くの時間を費やし、最終的には解決しました。実際、この思考の克服プロセスは次のように分析できます。私たちの思考と問題の答えの間には壁があります。問題を克服するためにさまざまな解決策を何度も試みると、私たちの思考は何度もこの壁にぶつかります。ついに壁が壊れ、問題が解決されました。
同様に、「エンタープライズレベル」の考え方をプロジェクトに持ち込んで、少しずつ「壁」にぶつかっていき、最終的には、共通の機能が共通のコンポーネントにカプセル化されます。 。
まとめ
これに関して私自身の感想は、「企業レベルのマインド」を持っているわけではなく、少しずつ積み重ねてきただけですが、この考えでプロジェクトに取り組んでいるので、人事面ではメンテナンス、ヨンヘのメンテナンス、親切コミューンの開発、試験システムの問題の修復はすべて、度重なるコードの修正、Web サイトの再リリース、柔軟な機能、柔軟なコンポーネントの追加をエンタープライズレベルの考え方で十分に解決できることを深く認識しました。 Mi 氏は、ユニバーサル Web サイトを通じて、この開発コンセプトを何度も根気強く深めてくれました。個人的には、コンポーネントが必要ですが、私の考え方が改善されたと思います。改善されましたが、すでにある程度の甘さがあります。エンタープライズ レベルの開発アイデアは、Java 学習においても包括的であり、その後のシステムのメンテナンスのコストも大幅に削減されます。
以上がJava エンタープライズレベルのプロジェクトの開発アイデアの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。