Je travaille en tant que développeur iOS depuis plus de six ans. Il m'est arrivé de travailler dans plusieurs entreprises et équipes différentes. J'ai travaillé à la fois en sous-traitance et en outstaff, j'ai même eu la chance de participer au démarrage. Et maintenant, après plusieurs années de développement commercial, ainsi que quelques années de programmation à l'université, j'ai commencé à identifier certains principes ou règles pour une approche qualitative du développement d'applications. Au début, c'était un conseil à mon ami. En lui donnant des conseils, je pensais que je manquais de ces conseils lorsque je commençais à peine mon chemin de développement. Que puis-je dire, certains moments que j'ai réalisé pour moi relativement récemment, et certains sont déjà dans un nouveau lieu de travail. Et donc l'idée m'est venue de faire une liste de conseils que j'aimerais partager avec moi-même il y a cinq à six ans. Je suis sûr que dans cinq ans, j'aurai quelque chose à me dire aujourd'hui. Mais nous allons probablement laisser cela pour l'avenir.
Votre code est mauvais
Et la première chose que je voudrais me dire comme avant est: "Votre code est mauvais!". Chez les gens du commun, «govnokod». Et mes collègues étrangers dans l'atelier de développement ont un «code de singe».
Non, ce n'est pas ce que tu pensais. Je ne veux pas souligner que j'étais un mauvais codeur, et maintenant mon code est parfait. Je veux reformuler ce message et transmettre trois points clés dans le sens de ce conseil.
"Votre code était et sera mauvais!"Le premier moment: il n'y a pas de code parfait, personne ne pose l'architecture idéale et il n'y a pas de code dans lequel il n'y aurait pas de bugs. Je pense que beaucoup se sont surpris à penser qu'ils ne pouvaient pas comprendre la nouvelle bibliothèque ou la nouvelle technologie. Ou certains d'entre nous sont allés à l'extrême en essayant d'écrire parfaitement la fonctionnalité, en suivant tous les principes de la POO, SOLIDE. Ce qui à son tour a conduit à beaucoup de temps et parfois à une impasse. Parfois, dans des tentatives pour écrire le code parfait, des monstres sont nés qui portaient une liste complète de modèles que le développeur connaît, ou peut-être même plus.
Avec ma phrase, je voudrais transmettre l'idée que vous ne devez pas tout d'abord vous inquiéter, être nerveux quant à la qualité de votre code. Il est impossible de tout prévoir. Et il vaut mieux simplement se détendre, écrire plus facilement, et comme vous le savez, que de souffrir et de vous inquiéter en vain. Avec l'expérience, les décisions viendront d'elles-mêmes. Parfois, il est nécessaire de "nagovodnodit", ils rencontreront des problèmes que ce shitcode causera et comprendra une fois pour toutes qu'il vaut mieux ne pas le faire.
Le deuxième moment, que j'ai mentionné plus tôt, est qu'il est presque impossible de tout prévoir. Oui, avec l'expérience vient la compréhension de ce que vous faites et vous pouvez prédire le chemin de développement du projet. Mais cela vient avec l'expérience. Et si l'expérience ne suffit pas, vous ne devriez pas essayer de rendre le code universel. Il y a des cas fréquents où votre fonctionnalité, que vous avez longtemps réfléchie et si soigneusement au début, puis écrite, est simplement rejetée de l'application. De plus, il y a des cas où les applications ne changent que parce que, dans l'esprit du client, tout semblait différent. Et après de longues heures de transfert minutieux de l'interface de la conception au code, 100 500 changements apparaissent soudainement. Ce n'est que le début, car après le premier refaire, de plus en plus de nouvelles modifications viendront. Et dans le cas où le développeur n'a pas assez d'expérience, ce processus peut prendre non seulement beaucoup de temps, mais aussi n'apporter pas les sensations les plus agréables qui sont déclenchées par des pensées désagréables quelque part dans les coins secrets de l'esprit, transformant le processus de développement d'une leçon amusante en une douleur infernale. Par conséquent, prenez soin de vos nerfs et ne conviennent pas à l'idéal. Parfois, vous pouvez parler un peu.
Troisième point: il s'agit là encore d'un moment purement psychologique, à savoir la critique des autres développeurs. Comme tout le monde le sait, tous les développeurs nationaux considèrent tout autre code - du code de merde. Même si on lui montre son propre code, qu'il ne reconnaît pas, il est susceptible de l'appeler une merde. Souvent, une telle critique s'accompagne de la satisfaction morale du critique lui-même. Comme l'ont noté des développeurs expérimentés, ce sont les gens qui appellent le plus souvent le code de quelqu'un d'autre govnodkod exactement ceux qui à un moment donné novnokovodil plus que. Et plus quelqu'un crie fort «govnokod», plus il laisse de «gâteaux» sur son passage.
De plus, toute vierge qui se rappelle jeune doit nécessairement admettre qu'il a été un novocode célèbre.
Par conséquent, je vous conseille d'utiliser l'expression "Votre code a été et sera une merde", comme un bouclier contre les critiques pas toujours constructives. Je veux également noter que votre code sera toujours de la merde car le développement ne s'arrête pas. Chaque année, la qualité de votre code ne fait que s'améliorer. Ainsi, le code actuel finira par devenir govnokod.
Diviser et conquérir
Je ne veux pas donner l'impression que je ne conseille que govnokod, donc je vais commencer à donner des conseils sur la façon d'éviter ce mauvais code. Et je voudrais commencer par le principe que je me suis réservé. Non, ce n'est pas de l'hérédité ou du polymorphisme, et pas l'un des principes de SOLID. J'appelle ce principe Diviser pour régner.
Oui, la décomposition existe.
Décomposition - la division de l'ensemble en parties. De plus, la décomposition est une méthode scientifique qui utilise la structure du problème et vous permet de remplacer la solution d'un gros problème par une série de tâches plus petites, bien qu'interconnectées, mais plus simples.
Comme le dit Wikipedia. Mais ce n'est qu'une partie de ce que j'ai mis dans le sens de mon principe. Certainement oui, vous devez diviser le projet et les tâches en parties plus petites. Mais je veux dire l'approche conceptuelle de la séparation des groupes logiques dans le projet.
Et la première chose que je fais référence à ce principe est la séparation de l'interface utilisateur ET de la logique métier de l'application. Il semblerait que je sois maintenant directement capitaine des preuves. Mais! En pratique, ces limites sont souvent floues et il s'avère que le ViewController ou Activity contient un élément de logique métier.
Je pense qu'un exemple de l'écran «Login» sera simple et compréhensible. Ici, le développeur commence à implémenter l'architecture MVC. Il semble qu'il y ait une vue séparée, comme l'ajoute Controller with Model, comme il se doit. Mais à un moment donné, ils pensent: "Pourquoi dois-je ajouter plusieurs classes pour l'écran avec un seul bouton?" et en ce moment, je recommande fortement d'abandonner ces pensées vicieuses et d'adhérer strictement au principe de «Diviser pour régner» pour séparer l'interface utilisateur et la logique métier. Et même si l'architecture nécessite l'ajout d'une classe ViewModel, dans laquelle il y aura une deux lignes de code, vous devez le faire. Parce qu'il y a souvent des cas où un écran dans lequel il y avait à l'origine un bouton, au fil du temps, devient des difficultés impensables. Si vous suivez à l'avance la séparation des composants logiques, cela facilitera grandement la vie à l'avenir.
Vous pouvez particulièrement ressentir l'essence de la séparation stricte de l'interface utilisateur et de la logique, dans les cas où vous devez transférer des écrans d'un projet à un autre. Ou dans une situation où, dans des conditions différentes, différents algorithmes sont utilisés dans la logique métier. Par exemple, en divisant l'écran d'autorisation en composants, nous pouvons remplacer l'un des composants à l'avenir sans affecter l'autre. Nous pouvons remplacer View ou Model par de nouvelles méthodes d'autorisation pour les mêmes données.
Ne limitez pas le principe de «diviser pour mieux régner» uniquement à ces deux couches. A la séparation stricte, j'ajouterais la séparation des écrans et de la logique de navigation pour les applications mobiles. Qu'est-ce que je veux dire par là?
Ma pratique m'a incité à faciliter le codage d'un écran particulier en supprimant la logique de navigation séparément. Un écran, spécifiquement View, pour iOS est un UIViewController, et parfois un UIView, et pour Android Activity, ou Fragment, ils ne devraient pas être engagés dans une fonction pour s'afficher, ainsi que basculer vers d'autres écrans. Chacune de ces classes ne doit se soucier que de ce qui se passe sur un écran particulier, ou plutôt, uniquement pour le rendu d'un écran spécifique et l'interaction avec une classe de logique métier (Presenter, ViewModel et autres).
Ce ne sont que deux des nombreux exemples où vous devez suivre fondamentalement la séparation. Le respect de ce principe facilitera grandement la poursuite des travaux avec le projet. Même si govnokod est obtenu dans l'un des composants séparés.
Style unique
En continuant avec les conseils précédents, je veux passer au suivant, à savoir le strict respect d'un style unique dans le projet.
Qu'est-ce que je veux dire par là?
Pour commencer, le mot clé ici est strict, du mot du tout. Au départ, nous sélectionnons une approche unique pour organiser un projet, pour la gestion des fichiers, pour le style de code, etc. Cela améliorera considérablement l'apparence générale du projet et facilitera considérablement la navigation du projet, la recherche par code et accélérera le processus d'introduction d'un nouveau développeur dans le projet. Je pense que cela ne vaut pas la peine de rappeler qu’après un certain temps, nous pouvons nous-mêmes devenir cette nouvelle personne avec notre ancien code.
Le choix de l'architecture et son suivi
Encore une fois, en partant du conseil précédent, nous passons en douceur au suivant, le choix de l'architecture. Et l'idée principale que je veux transmettre n'est pas de parler des meilleures architectures ou de dire que vous devez choisir celle-ci et pas une autre. Non! Pour commencer, il n'y a pas d'architecture idéale qui couvrirait complètement tous les cas possibles du projet. J'ai entendu une fois ces mots: "s'il y avait une architecture idéale, alors nous, les développeurs, seraient licenciés comme inutiles et remplacés par des scripts qui génèreraient l'architecture idéale."
Le point principal, je crois, n'est pas le choix de la meilleure architecture, mais encore une stricte adhésion à l'architecture qui a déjà été choisie et a commencé à être appliquée. Que ce soit VIPER, REDUX, MVP ou MVC. Il y a bien sûr des avantages et des inconvénients à chacune des architectures ci-dessus. Au fil du temps, de plus en plus de nouvelles approches pour la conception de l'architecture du projet.
Je vais parler plus précisément de mon idée. Si vous avez déjà commencé à utiliser VIPER, suivez strictement ses principes. Même s'il semble que pour un écran à un bouton, il y a trop de fichiers pour créer des unités de lignes de code, ne contournez en aucun cas ces règles. Parce que, dans de tels moments comme celui-ci, le govnokod est né, qui alors, comme une boule de neige, tout grandit et grandit.
Je vous conseille de vous familiariser avec les architectures les plus populaires et de choisir celle que vous aimez ou la plus populaire avant de démarrer un nouveau projet. Je recommande fortement de choisir la deuxième option, à savoir commencer par l'architecture la plus populaire, car il sera facile de trouver des réponses à de nombreuses questions. Lors du choix d'une architecture, une attention particulière doit être portée aux inconvénients de cette architecture et dans quels cas il est recommandé de l'utiliser.
Par exemple, si un petit projet, sur lequel il y a un seul développeur, vous ne devriez pas prendre VIPER car c'est une architecture assez lourde, qui est très bonne pour les grands projets et les grandes équipes. Il n'y a donc aucun cas où le code de création de VIPER est plusieurs fois supérieur au code de la logique métier elle-même.
Personnellement, je préfère maintenant l'architecture MVVM + Router. Cela fonctionne bien sur un petit projet où je suis un développeur unique.
Conclusion: l'essentiel n'est pas l'architecture que vous avez choisie, mais comment la suivez-vous exactement.
Je veux également ajouter que si le projet n'est pas développé à partir de zéro, vous devez d'abord vous familiariser avec l'architecture actuelle et le style général du projet et commencer à le suivre. Vous ne devriez pas éclater avec des cris qu'il y a du govnokod (revenir au premier conseil) et commencer à tout refaire. Une exception peut être une anarchie complète du projet ou l'absence d'un style commun.
Refactoring des pauses
En conclusion, je tiens à dire que la pause pour refactoring est une bonne approche. Le refactoring est une partie très importante du développement d'applications de qualité. Oui, nous n'écrivons pas tout de suite le code parfait, mais le laisser tel quel n'est pas bon non plus. Il arrive souvent que l'implémentation d'origine n'ait pas la capacité d'évoluer lorsque vous devez introduire de nouvelles fonctionnalités. Après tout, il est presque impossible de prévoir tous les changements possibles dans les futures versions du projet. De plus, aucune architecture ne garantit une couverture à 100% de tous les cas. Par conséquent, il est important d'apporter des modifications au code existant afin de l'adapter aux nouvelles fonctionnalités.