Le cycle de vie du logiciel est connu de la plupart des programmeurs modernes.
Même un écolier écrit son premier programme
<?php echo "Hello, ! " ?>
ou
fprintf( ' !\n');
comprend le processus.
- Réflexion sur la tâche - l'étape de l'idée
- Il réfléchit à la tâche et à la manière dont elle doit être mise en œuvre - Analyse et élaboration des exigences,
élaboration d'un modèle logiciel et d'un plan de mise en œuvre. Bref, la scène architecturale. - Programmation
- Test. "Que s'est-il passé là-bas"
- Opération.
Entre les étapes 1 à 5, nous avons des processus en interaction continue.
Pour cela, il y a toutes sortes de cascades, Scrum, etc.
Donc, le fait est que lorsque votre projet se déploie sur plusieurs types de frontend,
comme le monde informatique moderne l'exige, le client souhaite maximiser l'audience pour maximiser ses propres profits.
Et pour cette raison, nous observons tous une abondance de projets dans lesquels il existe plusieurs types de frontaux qui interagissent via l'API avec un backend centralisé.
De manière générale, un «projet solide standard» comporte trois types de fronts:
- Le site
- Application mobile sur Android
- Application mobile IOS
Avec une seule API développée pour l'échange de données via REST.
Un bon exemple sur lequel je vais m'appuyer est celui des médias sociaux (voir mon précédent article sur votre propre lecteur basé sur des vidéos YouTube)
Un grand projet a trois options pour réaliser un profit ou tout critère qui
conditionnellement Web, apple et android.
Il est pratique pour les programmeurs d'interagir avec l'architecture du backend centralisé et de se concentrer sur leur front personnel qu'ils développent.
Et ici, le point culminant de l'article apparaît.
Le fait est qu'au niveau le plus élevé de la prise de décision parmi les supérieurs
une nouvelle fonction se forme, qui va à l'arrière. Mais comme le "patron" est une personne imparfaite,
il doit ensuite réduire ses pouvoirs aux niveaux inférieurs.
Par conséquent, dans notre cas, en règle générale, au-dessus de chaque front apparaissent également leurs chefs «de bas niveau» selon des motifs hiérarchiques ou formels. Quelque chose
type de timlides pour plus de simplicité.
Et la tâche de développer un grand projet sous la forme d'une sorte de "cycle de vie de développement"
et le fonctionnement du logiciel est divisé en cycles de vie.
Et la question se pose de synchroniser les processus des «mini» cycles de vie, car si vous êtes en avance par exemple sur un développeur web d'une nouvelle fonctionnalité, vous devez attendre un développeur mobile.
Sinon, le sens de la nouvelle fonctionnalité en tant que telle est perdu en priorité, car nous sommes tous maintenant sur le web et dans les applications mobiles depuis les smartphones.
Réfléchissons à la façon d'évaluer l'introduction de nouvelles fonctionnalités afin de minimiser les ressources humaines dans une telle situation.
Ici, je vais exprimer les thèses:
- Lors de l'implémentation d'une fonctionnalité dans l'un des fronts, nous devons prendre en compte les cycles des autres fronts, ou programmer des stubs standard, afin que plus tard nous puissions «rattraper» les fonctionnalités des autres fronts et même les égaliser.
- Vous pouvez créer un schéma pour le cycle de développement logiciel dans son ensemble afin que tout le monde réussisse conditionnellement, puis la fonctionnalité sera mise en œuvre à temps, mais au moins l'indépendance des équipes frontales entre elles sera perdue - puis le flux et l'agile pour l'ensemble du système perdront leur pertinence, ou augmenter le temps d'itération par développement. En bref, plus de bavardages se produiront et le code sera écrit plus lentement.
- Les fronts isolés, en principe, sont plus rapides, mais des tests d'intégration des coûts humains supplémentaires sont nécessaires.
- Les schémas actuellement mis en œuvre - chaque front est développé séparément et indépendamment les uns des autres avec un minimum d'interactions, mais ici certaines des bases de l'informatique sont perdues - nous obtiendrons en quelque sorte un groupe d'utilisateurs non nul qui verra parfois des bogues.
Ici, la philosophie de la question est que les utilisateurs n'aiment pas les bogues par définition. Et le client cherche à maximiser les profits, donc une grande complication du système ralentira en quelque sorte cette maximisation, car il s'agit du cycle de vie final du logiciel.
Dans les petits projets, ce processus est encore pire - de nombreux clients donnent le développement mobile au site distant, bien que le back-end et le web soient menés seuls et reçoivent régulièrement un freinage uniforme sur la mise en œuvre des fonctionnalités.
D'un autre côté, il y a un obstacle dangereux à l'automatisation formelle du processus d'implémentation - il est habituel parmi les développeurs de demander à l'utilisateur de rouler les mises à jour, donc en mode silencieux, il ne fonctionnera pas pour reconduire les modifications sans consentement.
Mon idée est une telle idée - tout en conservant le principal type de cycle de vie et en ayant des sous-types dans ce cas de fronts indépendants, vous devez garder à l'esprit une priorité
type de front (pour de l'argent, pour des raisons historiques ou autres), mais ils devraient être une unité en dessous du type de cycle de niveau supérieur.
Autrement dit, si le front Web prioritaire fonctionne sur une mêlée hebdomadaire, alors la mêlée intérieure sur le front mobile devrait avoir avec elle la première double mêlée, deux semaines, sinon
la confusion va commencer. Mais le déploiement d'une grande version commune des fronts doit être fait en même temps, sinon vous aurez l'auteur de l'article qui l'écrit. Pensons ...