Idées de développement pour les projets Java au niveau de l'entreprise

Idées de développement de projets Java au niveau de l'entreprise. Je me suis rencontré par hasard et j'ai appris quelque chose en lisant, donc je le partage avec tout le monde. Cet article ne concerne pas de cas, mais ne parle que de pensées et de concepts. Les amis dans le besoin peuvent s'y référer.

Qu'est-ce que le développement de projets au niveau de l'entreprise

　"Projet au niveau de l'entreprise", développement de projets au niveau de l'entreprise, Java est également le développement de projets au niveau de l'entreprise, on le dit partout, écoutez, on en parle tous les jours, mais quel genre de projet est considéré comme « au niveau de l'entreprise » ? Les petits ou grands projets sur lesquels j'ai travaillé peuvent-ils être considérés comme au niveau de l'entreprise ? En d'autres termes, GXPT peut être considéré comme un projet au niveau de l'entreprise. Ensuite, je communiquerai et apprendrai avec vous !

1. État actuel du développement du projet

Nous avons réalisé beaucoup de grands et petits projets dans notre classe d'amélioration. travailler sur des projets tout le temps et rattraper leur retard sur les projets. Je crois que depuis le moment où nous avons commencé à travailler sur des projets jusqu'à aujourd'hui, nous avons réalisé de nombreux grands et petits projets, et il y a des projets plus ou moins réussis dont nous sommes très fiers. Maintenant, tout le monde regarde en arrière et réfléchit à la façon dont nos projets sont habituellement réalisés ! Même si chaque équipe de développement est différente, notre mise en œuvre minimale et notre conception globale restent les mêmes malgré les délais du projet, les changements dans les besoins des clients et les diverses supervisions. C'est plus ou moins la même chose, mais l'évolutivité et la flexibilité sont quelque peu différentes.

Chaque fois qu'un projet arrive, après quelques réunions, le projet démarre, alloue le personnel, commence à analyser certaines exigences des clients, puis certains développeurs clés commencent à construire l'étagère du projet. Un projet est donc en cours. Lorsqu'il s'agit de construire le cadre d'un projet, professionnellement parlant, cela signifie construire une architecture. Ce que nous appelons architecture consiste en fait à diviser le projet en plusieurs couches logiques selon la convention. Quant à savoir si cette architecture est bonne, quels sont les risques, et si elle peut s'adapter aux changements futurs., L'analyse des risques et de la faisabilité de la technologie utilisée est rarement prise en compte. La raison est très simple : elle est généralement développée de cette manière, et il ne devrait pas y avoir de problèmes majeurs. En effet, de nombreux projets sont effectivement développés de cette manière, et nombre d’entre eux aboutissent. Il n'y a rien de mal à cela. Quant à savoir si la norme est standard ou non et si elle suit des principes de développement, peu de gens s'en soucient. Quoi qu'il en soit, le projet réussit.

Dans le développement de projets, nous sommes très clairs sur de nombreux principes : responsabilité unique, inversion des dépendances, testabilité, maintenabilité... Souvent, lors du codage, ces originalités deviennent redondantes, et le projet finit par devenir une accumulation de codes fonctionnels. Surtout dans le processus de précipitation du projet, l'effet de l'accumulation de codes devient encore plus évident : tant que les fonctions sont terminées, le reste sera discuté plus tard. Souvent, ce « dis-le plus tard » devient « ne le dis plus jamais » et contente-toi de ça. Il n'y a rien de mal à cela.

Ainsi, année après année, nous développons des projets, réalisons des projets, et rattrapons notre retard sur les projets. De nombreuses personnes chez Primary Key seront moins intéressées par le développement de logiciels au cours des étapes ultérieures à mesure que le projet avance : je pensais au départ que le développement de logiciels était une activité à haute intelligence, mais maintenant je trouve que cela ressemble un peu au travail manuel. Année après année, mois après mois, nous développons différents systèmes pour différents clients.

L'information montre : dans l'entreprise...

Je crois que beaucoup d'entreprises mettent souvent en avant de nombreux slogans très « attractifs » : en réalisant un grand nombre de projets , accumulation et développement Composants communs, plus il y a de composants, le développement futur ne sera qu'un tas de blocs... Mais dans les projets réels, les clients continuent d'exhorter, et les supérieurs insistent aussi, et à la fin personne ne s'en soucie que ce soit universel ou non. Le développement de projets devient de plus en plus fatiguant. Je pense que c'est l'une des raisons pour lesquelles de nombreux développeurs changent de carrière et se transforment. ​

2. Qu'est-ce qu'un projet au niveau de l'entreprise

L'apprentissage de Java se rapproche de plus en plus, pensez-vous souvent à cette problématique ? ? Qu'est-ce qu'un projet au niveau de l'entreprise ? Un projet développé pour une entreprise, une institution ou une entreprise cliente peut-il être considéré comme un projet au niveau de l'entreprise ? Un très grand projet est-il un projet au niveau de l’entreprise ? Un petit projet n’est-il pas considéré comme un projet au niveau de l’entreprise ? Un code comportant des dizaines de milliers ou des centaines de milliers de codes est-il un projet au niveau de l'entreprise ? Confus!

En fait, personnellement, je n'ai pas été très clair sur la notion de "niveau entreprise". C'est juste que je dis cela tous les jours, et Maître Mi m'a aussi inculqué l'idée du développement au niveau de l'entreprise. Au début, j'étais vraiment un peu satisfait, et cela semblait assez profond.

Lorsqu'il s'agit de projets au niveau de l'entreprise, de nombreux concepts l'accompagnent : architecture au niveau de l'entreprise, développement au niveau de l'entreprise.

Mais peu importe : la notion de niveau entreprise n'a rien à voir avec la taille du projet. On peut même dire qu'elle n'y est presque pour rien.

En fait, les projets au niveau de l'entreprise sont en fait des projets avec une mentalité « au niveau de l'entreprise ».

Dans la première partie de l'article, nous sommes arrivés à la façon dont nous faisons des projets actuellement : l'"empilement" de fonctions de code. Le code accumulé grâce à ce type d'accumulation n'est utilisé que pour ce seul projet et est presque inutile pour d'autres projets à l'avenir. Cela signifie que le code n'est pas suffisamment réutilisé et que souvent dans un projet, une grande partie du code est diverse. Oui, de nombreuses fonctions similaires nécessitent leur propre ensemble de codes. De tels problèmes ont rendu les projets de plus en plus génériques et de nombreux beaux slogans se sont transformés en bulles.

Les projets au niveau de l'entreprise présentent au moins les caractéristiques suivantes :

Stabilité

Flexibilité

Isolation

Réutilisabilité

Maintenabilité

Je pense que ces fonctionnalités sont familières à tout le monde, je m'en fiche. analyse détaillée, tout le monde le sait. Cela dit, vous penserez peut-être que je dis des bêtises, mais il y a une chose que je peux dire : De nos jours, nous ignorons beaucoup ces choses lors du développement de projets. À cause de cette négligence, le développement des projets s'accélère. , mais à long terme, le développement de projets deviendra de plus en plus fatiguant. Si vous pensez un peu comme ça à chaque fois lors du développement et essayez d'écrire du code conforme à ces caractéristiques, lentement, une "mentalité de niveau entreprise" émergera lentement, une métaphore très similaire : Lors d'un projet, nous rencontrons un problème technique difficile. Nous passons souvent beaucoup de temps à le surmonter, et enfin à le résoudre. En effet, nous pouvons analyser ce processus de dépassement de la pensée comme ceci : Il y a un mur entre notre réflexion et la réponse au problème. Lorsque nous essayons encore et encore diverses solutions pour surmonter le problème, notre réflexion se heurte encore et encore à ce mur. le mur finit par s'effondrer et nous obtenons la solution au problème.

De même, nous avons apporté la réflexion "au niveau de l'entreprise" au projet, et nous avons heurté le "mur" petit à petit, et finalement Le Le résultat est que les fonctions communes sont encapsulées dans des composants communs, qui peuvent être accumulés pour des projets futurs.

Résumé

Mes propres sentiments et mon "esprit d'entreprise" ne sont pas là, petit à petit Mais parce que je En travaillant sur des projets avec cette idée en tête, j'ai profondément réalisé que les idées au niveau de l'entreprise peuvent résoudre les problèmes pratiques de maintenance du personnel, de maintenance de Yonghe, de développement de Kindness Commune et de réparation des problèmes du système d'examen que j'ai rencontrés. modifications répétées du code, rééditions de sites Web, fonctions flexibles et ajout flexible de composants. Grâce au site Web universel, Teacher Mi a également patiemment approfondi ce concept de développement pour moi, encore et encore. Personnellement, je pense que ma réflexion s'est améliorée, et elle s'est améliorée. également amélioré. J'ai vraiment eu beaucoup de composants communs. Bien que les composants doivent être perfectionnés, ils ont déjà une certaine douceur. Le coût de la maintenance ultérieure du système est également considérablement réduit. Les idées de développement au niveau de l'entreprise sont complètes dans l'apprentissage Java. Les enseignants des collèges GXPT utilisent également ce concept de développement au niveau de l'entreprise pour montrer leurs compétences.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!