Salut Récemment, j'ai fait un rapport pour les étudiants sur les bosses qui peuvent être remplies en faisant du développement web moderne. Comment les différentes décisions que nous prenons au cours du processus de développement sont-elles liées, comment le choix de la technologie affecte la taille de l'équipe, comment la taille de l'équipe affecte les approches de test, comment les approches de test sont liées à la structure de toute l'entreprise ...

Il s'est avéré quelque chose comme une quête avec un choix distribué: à partir de quel langage de programmation choisir et à qui il vaut mieux embaucher une équipe qui fera le produit le plus utile jamais. Je vous suggère de lire ce post, de choisir vos options, de terminer la quête et de discuter de ce qui est devenu douloureux.

upd - a ajouté du texte au kat.

De l'idée au prototype

Supposons que mon ami Valera et moi avons décidé de faire une startup. Uber pour X , ou autre chose comme ça. Réunis dans un bar, discuté de cette idée, sujet sympa. Doit faire. Trois mois n'ont pas dormi, n'ont pas mangé, n'ont pas quitté la maison. Développé. Ils ont commencé et ont réalisé que personne n'en avait besoin.

Tristesse. Essayons encore. Cette fois, nous avons étudié le marché, examiné les besoins des utilisateurs, les problèmes. Nous avons fait une sorte de prototype complètement sur le genou, rapidement et gratuitement en deux soirées. Le prototype a décollé. Cool, continue.

Choisir la technologie

Nous pouvons maintenant prendre et créer une grande application à partir d'un prototype, le développer. Mais pour cela, nous devons adopter une approche plus sérieuse du choix des technologies que nous utiliserons.

La langue

En ordre. Quelle langue écrire? Vous pouvez prendre la fonction à la mode: Haskell, Erlang, Lisp (très à la mode chez les grands-pères de plus de 70 ans). Ou un autre tueur JS, qui est très cool, compilé dans JS, a toutes les fonctionnalités nécessaires. Mais très probablement, nous n'aurons personne à embaucher dans un an, car le prochain tueur JS ne décollera pas, et devra réapprendre ou réécrire le projet.

Tentez le numéro deux. Vous pouvez prendre quelque chose vérifié par le temps. Par exemple, PHP. C'est un bon langage, il est parfois à la mode de critiquer, il a ses inconvénients, mais il est facile de faire de la logique commerciale dessus, il est assez rapide, évolue bien, vous pouvez embaucher des gens à tout moment, n'importe où. Mais il n'est pas très productif. Par conséquent, nous avons besoin de beaucoup de fer ou d'écrire notre propre compilateur, comme l'ont fait Facebook ou VK.

Plus d'options? Vous pouvez prendre Perl, mais il n'y aura plus personne à embaucher hier. Plus?
Java Java est la norme. En tant que langage, ce n'est pas très, à mon avis subjectif, mais la JVM est une excellente machine virtuelle, tout va bien, cela fonctionne rapidement, mais elle a encore besoin de beaucoup de matériel. Et pendant que nous écrivions en Java un constructeur abstrait de l'usine de stratégie, au lieu de créer des fonctionnalités, les utilisateurs se sont tournés vers les concurrents.

D'accord, nous avons toujours Python. En principe, tout va bien. Mais nous exécutons l'application en Python, elle utilise un cœur de 56, sinon ... tout va bien. Ou vous pouvez prendre quelque chose de moderne: allez, Rust, autre chose. Mais ils sont trop bas, et nous ne faisons que des fonctionnalités depuis longtemps ... Nous devons encore choisir une langue. Que ce soit JS à la fin, descendez.

Base de données

Base. JS sans base de documents - de l'argent dans les égouts. Les bases de documents ont leurs avantages. Ils nous permettent de développer rapidement des prototypes, de ne pas se soucier du schéma, des données de saucisse dans les deux sens. Il y a de nombreux avantages, moins un: bouillie à partir des données. Lorsque nous avons dix, vingt ou quarante collections au lieu de trois, lorsque nous essayons d'en coller quelque chose de bon et de digeste sans l'absence de schémas, cela devient de plus en plus difficile à faire. Encore une fois, nous créons des fonctionnalités depuis longtemps.

Ok, prenons une base relationnelle. MySQL, PostgreSQL ou Oracle si vous avez assez d'argent. Avec les bases de données relationnelles, vous pouvez un jour venir travailler et vous retrouver en enfer à cause des transactions et des stockages. Cela ne se produit pas nécessairement avec notre projet. Mais si cela se produit, alors ces subtilités de la logique seront impossibles à tester. Et même si soudain nous atteignons la limite verticale de notre grand serveur d'or sur lequel nous hébergeons la base de données, il sera assez difficile de les séparer. Nous faisons des fonctionnalités depuis longtemps.

D'accord. Ils ont pris une certaine base, ORM a frappé devant pour faciliter le passage d'un SQL à un autre. Un jour (spoiler: jamais).

L'architecture

Quelle architecture choisir? Les gars sur Habré écrivent que les microservices sont cool. Oleg Bunin dit: "prenez des microservices".

Si vous commencez avec des microservices, avec une probabilité de quatre-vingt pour cent, les limites seront erronées car ils n'ont pas complètement pensé au modèle de domaine et ne savent pas où couper et où ne pas le faire. De plus, ils prennent tous des microservices, les déploient par lots sur tout leur cluster, et un mois plus tard, la question se pose: "Comment puis-je tester tout cela maintenant?" Les services fonctionnent déjà en production, mais nous ne les testons pas. En utilisant des méthodologies familières (pyramide de tests, tests d'intégration manuelle, tests de bout en bout), il est difficile de tester les microservices. Par conséquent, nous faisons des fonctionnalités depuis longtemps.

Ok, alors frappons un monolithe. C'est la bonne idée pour une startup. Vous pouvez vivre avec un grand monolithe pendant très longtemps et ne rencontrer aucun problème. Mais si nous décidons d'élargir considérablement l'équipe, nous devons être prudents. Le monolithe évolue normalement, tandis que les développeurs sont 20, 30, 50. De plus, la vitesse de livraison des fonctionnalités diminue de façon exponentielle, et nous perdons des utilisateurs.

Par où commencer le projet?

Tout doit être lancé quelque part. 2018, l'option la plus logique pour le faire dans le cloud. Ne l'exécutez pas dans le nuage - les garçons riront. Mais, tout d'abord, il existe la loi fédérale 152, qui limite considérablement le choix des fournisseurs de cloud pouvant être hébergés. Deuxièmement, il est très facile de valider accidentellement une clé privée sur votre compte sur Amazon sur Github, et quelqu'un viendra certainement dépenser tout votre argent. Et si cela ne se produit pas, à un moment donné, les tarifs du cloud vous feront exploser.

Vous pouvez louer un centre de données. Peut-être que ce n'est pas si économe en ressources au départ, mais à long terme, ce sera probablement moins cher que l'hébergement dans le cloud. Mais ici, nous avons besoin de personnes qui l'appuieront. D'après mon expérience, ceux qui l'aiment et savent le faire, n'aiment pas vraiment communiquer avec tout le monde, donc ils sont organisés dans le département. Et le département, c'est le séparatisme. Je veux dire, il sera plus facile d'échanger des expériences au sein de l'équipe des administrateurs, mais à l'avenir cela pourrait ne pas fonctionner très bien. Il y aura des questions avec la hiérarchisation des tâches des autres collègues, avec la synchronisation. D'autres spécialistes ne sauront pas ce qui se passe à l'intérieur du département qui prend en charge notre centre de données.
En général, le séparatisme ne nous convient pas. Logiquement, nous abordons la question du recrutement d'une équipe.

L'équipe

Développement

Disons que nous avons déterminé les langues, les bases de données et où héberger le projet. Il est temps de recruter une équipe. Vous pouvez prendre des gars très cool qui résoudront tous les problèmes: développeurs centuple, ninjas backend, vous comprenez. Peut-être que cela donnera un tour. Mais en fait, il est probable que les stars invitées:

• des mecs toxiques qui ne feront rien et créeront une mauvaise ambiance dans l'équipe,
• ou idéalistes construisant peu à peu une architecture irréprochable, plaçant l'ORM devant des bases que vous n'avez jamais à changer ...

En fin de compte ... oui, nous faisons des fonctionnalités depuis longtemps. Une autre option consiste à prendre des filles et des gars ordinaires qui écrivent simplement du code, font des fonctionnalités très bien. Mais si vous prenez beaucoup de développeurs peu expérimentés avec des antécédents différents, ils peuvent écrire du code dans un style différent, faire les choses différemment, et avec une taille suffisante de l'équipe, tout le monde sera à l'étroit, tout le monde aura des accolades frisées dans les quêtes de tir de l'autre. Ce n'est pas très efficace. Comment résoudre ce problème? Le patron peut lire tout le code. Je peux lire toutes les quêtes de tir, et mon amie et co-fondatrice, Valera, la relira pour la deuxième fois (au cas où, on ne sait jamais). Il est clair que cela ne se modifie pas et toutes les fonctionnalités se développent lentement.

Une option plus correcte consiste à définir un style de code pour l'entreprise. Pour de nombreuses langues, il existe déjà et vous pouvez simplement le suivre. Ou si quelqu'un le veut vraiment, vous pouvez en prendre un tout prêt et le remonter un peu, puis regarder les quêtes de tir et dire que l'accolade frisée n'est pas là, elle devrait être là selon le style de code. Vous ne pouvez pas contester un tel argument, mais en réalité ce n'est pas beaucoup mieux que la version précédente, de toute façon nous faisons lentement des fonctionnalités. L'option correcte pour toutes les langues modernes est de le vérifier automatiquement.

Ok Nous avons marqué les développeurs, le code fig. Mais nous avons commencé à publier des fonctionnalités en production, et nous devons en quelque sorte nous assurer que nous les roulons sans bugs, que rien ne tombe avec nous.

Assurance qualité

Nous pouvons dire que nous n'avons pas besoin de spécialistes en AQ. Beaucoup le font, cela fonctionne parfois. Mais tous les développeurs n'aiment pas écrire de tests. Ils peuvent être compris. Et il vaut mieux les motiver à écrire les tests, mais la réalité est cruelle: les tests unitaires ne détectent pas tous les bugs. Et si certains développeurs n'aiment pas écrire des tests et ont quand même commencé à les écrire, ce seront probablement des tests unitaires.

De plus, il existe encore des approches lorsque vous minimisez le temps moyen entre les pannes au lieu du temps moyen de récupération. Le temps moyen entre les échecs, c'est quand un spécialiste de l'assurance qualité dit: "nous ne publierons pas, j'ai un mauvais goût, il y aura des bugs, déployons dans deux semaines." Et le temps moyen de récupération est lorsque vous lancez quelque chose, vous voyez immédiatement sur les mesures que quelque chose est cassé, et après deux minutes, tout a été annulé, corrigé et tout va bien. Mais pour faire reculer le projet en deux minutes, vous devez tout couvrir avec des métriques normales, et ce n'est pas toujours trivial. Et si les métriques sont dans un état déplorable et que nous déployons une mauvaise version, nous pouvons le savoir après que tous les utilisateurs nous ont laissés aux concurrents.

Autre option: faire toujours un département QA. Vous vous souvenez: le département n'est pas très bon, c'est du séparatisme, ça ne nous convient pas. Le séparatisme peut être résolu avec l'aide d'équipes interfonctionnelles. Oui, ils résolvent le problème que notre administrateur est assis séparément, les testeurs sont séparés.

Mais ils créent d'autres problèmes. Étant donné que les développeurs, les testeurs et tous les autres membres des équipes interfonctionnelles commencent à communiquer davantage au sein de leurs équipes et à résoudre les problèmes précédents, ils communiquent moins avec leurs collègues dans leur fonction: d'autres backders et testeurs, ils commencent à réinventer la roue, font les mêmes choses en parallèle, l'isolement entre les équipes. Alêne pour le savon: il y a eu un séparatisme, il en est devenu un autre.

Comment résoudre ça? Communiquez avec des collègues dans des groupes de loisirs. Quelque part on l'appelle des guildes, quelque part c'est de la communauté. Si nous dimensionnons l'équipe avec des équipes interfonctionnelles afin qu'elles ne deviennent pas autonomes, nous organisons simplement un cercle de fans de backend, de langages fonctionnels, de sécurité ...

Résumé

En fait, tout n'est pas si mauvais. Vous pouvez trouver un moyen de sortir de toute situation, trouver une solution. Peut-être pas idéal, mais le plus approprié dans cette situation avec un minimum de problèmes. Un compromis est toujours possible.

Et pourtant - tout cela est intéressant. Il est intéressant de résoudre des problèmes que quelqu'un a déjà résolus; de nouveaux problèmes sont encore plus intéressants à résoudre. Il est intéressant de partager les connaissances.