Eh bien, ou commencez à le faire correctement.
Si on me demandait de signaler un problème spécifique qui a tué la plupart des produits logiciels, j'appellerais certainement l'envie des développeurs de prévoir un avenir lointain. Cela peut s'exprimer de plusieurs manières, mais le schéma général est à peu près le suivant:
"Nous devons implémenter la solution {X}, malgré le fait qu'il existe une solution beaucoup plus simple et plus adaptée pour nous {Y}, car lorsque {Z} se produira à l'avenir, alors {X} fonctionnera beaucoup mieux que {Y}" .De plus, il n'y a pas et ne peut pas être une information exacte sur la probabilité de survenue de l'événement {Z}.
Voici quelques exemples:
- Nous devons utiliser kubernetes et docker! Oui, un seul serveur fait face à la charge actuelle et il est facile à configurer et à maintenir, mais lorsque nous avons besoin d'une douzaine de serveurs, il sera plus facile de les déployer avec kubernetes et docker.
- Nous avons besoin d'une architecture de traitement de données distribuée! Oui, jusqu'à présent, un PC moyen s'occupe de tout, mais lorsque nous avons une solution de qualité industrielle et que les clients exigent un temps de disponibilité de cinq neuf en SLA, nous serons prêts pour cela.
- Nous devons embaucher une équipe de développement et créer un site Web à partir de zéro, malgré le fait qu'il serait beaucoup plus rapide de déployer quelque chose basé sur wordpress, car lorsque nous avons 100 fois plus de clients qu'aujourd'hui, alors wordpress ne sera pas si pratique.
- Nous devons utiliser l'héritage au lieu de la composition, car après 5 ans, la base de code augmentera de sorte que sans elle, il n'y aura aucun moyen.
- Nous devons écrire ce code en C ++, malgré le fait qu'en Python il sera plusieurs fois plus rapide, car après des années, il traitera des téraoctets de données et Python ne pourra peut-être pas y faire face.
Récemment, j'ai écrit
un article sur les problèmes imaginaires - ceux dont les gens s'amusent avec la solution, car les résoudre est plus intéressant que les vrais. Cela comprend également ces tentatives de prévoir l'avenir. Vous pouvez même en dire plus - c'est le problème imaginaire préféré de la plupart des petites entreprises en démarrage.
Mais ne rassemblons pas tout: essayer de se préparer pour l'avenir peut être utile si vous abordez cela avec sagesse. Mais peu de gens arrivent avec sagesse - les gens ont des fantasmes, des peurs, des émotions et d'autres sentiments humains.
Atteindre le succès est plus difficile que de vivre avec le succès déjà atteint
Chaque personne a parfois fantasmé sur la façon dont tout serait s'il était quelqu'un d'autre. Quelqu'un riche, célèbre, fort, doté de pouvoir. Y penser est assez intéressant, et cela arrive d'une manière ou d'une autre, involontairement. Vous avez donc vu une photo sur la couverture du magazine - et vous avez pensé, que ferais-je à la place de cette célébrité? Oh, alors je dépenserais l'argent pour ça, et si je le faisais alors. Et aussi ça. Et si vous pouviez encore voler et posséder des super pouvoirs! Oui, ce serait génial!
Les développeurs de logiciels sont aussi des personnes et se prêtent également aux fantasmes. Cela signifie donc que Facebook a construit sa plate-forme sur telle ou telle technologie et qu'il évolue jusqu'à un milliard d'utilisateurs ... Eh bien, nous ne sommes pas pires, et les technologies sont disponibles, faisons tout bien aussi, avec un carnet de commandes d'un milliard d'utilisateurs (bien qu'il y en ait jusqu'à présent une centaine). Mais la magie de Facebook n'était pas dans la technologie de mise à l'échelle d'un milliard d'utilisateurs. Elle a pu donner aux gens le bon produit au bon moment et au bon endroit. Le logiciel, capable d'évoluer jusqu'à un milliard d'utilisateurs, était une partie secondaire et moins importante de l'entreprise. Elle n'a été créée que lorsqu'elle est devenue nécessaire et uniquement lorsqu'elle a été nécessaire.
La médaille a deux faces:
a) Réaliser la croissance est plus difficile que de maintenir l'échelle.
b) La plupart des programmeurs exceptionnellement qualifiés et talentueux travaillent sur des produits qui nécessitent une bonne évolutivité.
Le point
"a" est facile à reconnaître. Pensez par vous-même - de toutes les sociétés de logiciels jamais créées, seulement 0,05% seulement ont probablement atteint le niveau de millions d'utilisateurs et de milliards de bénéfices. Le reste s'est écrasé plus tôt ou a reçu moins.
Ainsi, la plupart des fantasmes sur les fonctionnalités nécessaires à l'avenir pour les logiciels se résument généralement à essayer de résoudre les problèmes de ces 0,05% des entreprises. «Ici, nous avons une équipe de 1000 développeurs, 10 millions d'utilisateurs et une douzaine de grandes entreprises clientes avec leurs exigences complexes, et nous aurons alors besoin de ...» Non, vous n'en avez pas besoin. Avec une probabilité de 99,95%.
Mais dire NON à de telles idées tentantes est difficile - car cela détruit la foi en ces fractions d'un pourcentage de probabilité de succès. Nous devons cesser de nous présenter en tant que propriétaire de la nouvelle Amazonie et revenir aux problèmes d'aujourd'hui. Et aujourd'hui, vous avez 50 utilisateurs, dont 30 membres de la famille et des amis. Oui, la prise de conscience de l'état actuel des choses peut démotiver.
Le point
"b" n'aide pas non plus à faire face à l'obsession. Il est clair que les meilleurs programmeurs travaillent dans les meilleures entreprises. Soit parce qu'ils ont été créés grâce à leur talent, soit parce que les meilleures entreprises sont en mesure d'embaucher les meilleurs programmeurs. Le principe de Pareto fonctionne ici contre nous: il est préférable pour les programmeurs d'écrire des livres, de faire des présentations et de concevoir de meilleurs systèmes. Chacun de nous a entendu ces histoires fascinantes sur les clusters tolérants aux pannes répartis sur des milliers de nœuds, traitant des pétaoctets de données à l'aide d'un logiciel optimisé pour des performances incroyables. Mais la plupart d'entre nous n'ont pas besoin de réfléchir à la façon de construire un tel cluster dans notre entreprise ici et maintenant. Il n'est tout simplement pas nécessaire.
Alors, fermer les yeux et représenter votre entreprise dans 5 ans, c'est important - cela n'aidera-t-il pas? Faut-il vraiment arrêter de penser à l'avenir?
Bien sûr que non. Penser à l'avenir, c'est bien. Et concevoir un logiciel avec une base pour l'avenir est également utile, mais vous devez le faire correctement.
Concevoir de manière flexible, implémenter imparfaitement
Mieux vaut faire moins, mais bon. Très peu de produits satisfont réellement les besoins de leurs clients. Pour que vous fassiez
A et 90% de vos utilisateurs avaient besoin exactement de
A - ce ne sera jamais le cas. 90% de vos utilisateurs potentiels ont besoin d'une sorte de
B , et votre
A est juste l'alternative la plus proche de
B , et personne ne vend ni ne vend
B lui-même, donc certains acheteurs seront satisfaits d'une mésange à la main.
Qu'est-ce qui est bon dans ce scénario? Une fois que vous obtenez les acheteurs, vous pouvez toujours essayer de comprendre ce dont ils avaient vraiment besoin et éventuellement le réaliser. Eh bien, ou une alternative légèrement meilleure à cela. La base d'utilisateurs vous aide à étudier le marché, à y trouver des niches et à les remplir. Dès que vous tâtonnez pour ce créneau, commencez à y travailler - votre croissance commence ici.
Et cette approche est vraiment productive. Vous implémentez quelque chose de petit, mais cela fonctionne bien, donnez-le aux utilisateurs - puis écoutez ce qu'ils pensent de votre produit. Vous ne devinez plus, ne résolvez pas les problèmes imaginaires, n'ajoutez pas de complexité inutile. Vous vous adaptez, ajoutez quelque chose, supprimez quelque chose. Et cela crée votre produit unique.
Et de cette façon - plus votre base de code était petite à l'origine, plus il est facile de l'adapter à quelque chose de nouveau.
«Je déteste le code et j'aimerais en voir le moins possible dans notre produit» - Jack Diederich
Si vous avez fait fonctionner quelque chose parfaitement, vous l'avez mal fait. Vous avez dû faire de trop gros sacrifices en cours de route. Peut-être que c'était une perte de temps ou d'argent, peut-être que vous avez abandonné la flexibilité, peut-être autre chose. L'idéal n'est pas atteint gratuitement.
Un logiciel idéal n'est pas plus viable. Il est possible de le créer dans un délai raisonnable et à un prix raisonnable. Il fait assez souvent tout ou presque tout ce qui est nécessaire. Elle, étant imparfaite, laisse par définition place à son développement et à sa liberté de manœuvre.
Conception d'architecture logicielle optimiste - l'avenir peut se réveiller agréablement
Il est important de se rappeler que le monde qui vous entoure n'est pas statique. Les problèmes qui se présentent à vous après quelques années peuvent être facilement résolus à l'aide des technologies disponibles après quelques années. Beaucoup de gens conçoivent quelque chose, non seulement en ne tenant pas compte des opportunités futures, mais en s'appuyant généralement uniquement sur des outils qui ont déjà des décennies. Ils se limitent même pas aujourd'hui, mais hier.
Permettez-moi de vous parler d'un exemple spécifique: la conception de systèmes distribués dans l'espoir d'être prêt à toute croissance. L'une des craintes courantes menant à la création de tels systèmes est la crainte qu'à un moment donné, votre serveur ne soit pas en mesure de servir tous vos utilisateurs. Et ça arrive vraiment. Parfois. Mais pas dans les petites entreprises, pas dans les startups. De plus, la plupart des gens qui écrivent des logiciels en 2018, pour une raison quelconque, sont sûrs que cela fonctionnera sur des serveurs créés en 2005. Les ordinateurs s'améliorent chaque année et de bons serveurs peuvent être loués moins cher.
Permettez-moi de décrire un tel "vrai" serveur initial:
- Deux Xeons E5-2680v4 (28 cœurs et 56 threads, claquant de 2,4 GHz à 3,3 GHz)
- 512 gigaoctets de RAM DDR4-2400
- 2 SSD NVMe de 1,2 To chacun (~ 3 Go / s en lecture et ~ 1,5 Go / s en écriture chacun).
Oui, je parie que la moitié des systèmes distribués dans le monde fonctionneront complètement sur ce serveur, avec tous ses composants et dépendances, servant normalement toute leur base d'utilisateurs existante. Et c'est loin d'être le serveur le plus cool à ce jour. Cela peut être pris pour un prix de 800 à 1300 dollars par mois (selon où l'obtenir). Vous pouvez en louer une douzaine pour le salaire d'un ingénieur qualifié à Londres.
Ce qui est quand même bien sur ce serveur, c'est que le prix de sa location en 2 ans baissera de 2 fois.
Les ordinateurs évoluent, évoluent de façon très linéaire et prévisible et continueront d'évoluer comme prévu, quelque part jusqu'à la fin des années 2020. Il est difficile de deviner plus loin, mais il est peu probable que l'humanité propose quelque chose de nouveau. Et les gens se souviennent encore du fer du début du siècle et ont peur qu'il ne leur suffise pas de répondre à quelques milliers de demandes par jour.
Mais nous parlons de fer. Et pensez à tous les logiciels qui apparaissent et se développent autour. Peu de gens pensaient sérieusement à la commande vocale il y a 20 ans. Et regardez le monde d'aujourd'hui - "OK Google", "Bonjour, Alexa", "à quoi ressemble la météo maintenant, Siri?" Quiconque a commencé à écrire un frontend vocal au cours de la 2016e année - vient de réussir au 2018e.
Que commencer à écrire en 2018? Ah, si je le savais :) C'est quelque chose qui est déjà apparu à l'horizon, mais qui n'est pas encore devenu assez grand pour éclipser le soleil. Regardez autour de vous, vous remarquez peut-être quelque chose comme ça?
Les progrès du logiciel sont incroyables. Totalement inaperçus, avec l'avènement de WASM, les navigateurs sont devenus des machines virtuelles universelles. Après 2 ans, vous pouvez créer une application polyvalente, complexe et hautes performances en la compilant pour exactement une plate-forme: l'assemblage Web. Et ça va commencer partout.
Mais les gens vivent toujours quelque part en 2012. Ils utilisent Babel, bien que 99% des utilisateurs disposent d'au moins un navigateur prenant en charge ES6.
De nouveaux langages de programmation apparaissent en permanence. Et certains d'entre eux sont plutôt bons. Ce n'est qu'au cours des 8 dernières années que nous avons obtenu Go, Rust, Scale et D - tous ont trouvé leur créneau. Au cours des 2 prochaines années, je m'attends à voir comment Julia contribuera à la programmation scientifique. Et c'est exactement ce qui m'inquiète personnellement et ce que je suis. La quantité totale de technologie et de connaissances est incroyable.
Mais je m'égare ...
Inspirer l'avenir est relativement facile. Mais franchement, en plus de la progression linéaire de la croissance de la productivité, il est difficile d'imaginer ce qui se passera dans 2 ou 5 ans. Certaines idées flottent dans l'air, les équipes travaillent sur divers projets logiciels et matériels, mais qu'est-ce qui «tirera» de cela?
Néanmoins, si vous voulez préparer votre logiciel pour l'avenir, vous devez d'abord comprendre le présent. Ce qui est bien dans le présent, c'est qu'il existe déjà, il est observable, mesurable. Et ça tient encore un moment. Rendre votre logiciel au moins pertinent aujourd'hui est une bonne idée. Vous ne serez pas prêt pour les réalités de 2020 en utilisant les approches de 2000. Mais un logiciel écrit avec des approches pertinentes pour 2018 peut très bien fonctionner pour lui-même en 2020.
Alors ne vous privez pas du plaisir de développer un logiciel avec une base pour l'avenir. Faites-le plus correctement. Considérez non seulement le développement de votre futur produit, mais aussi le développement de son écosystème environnant. Tout ce qui peut être conçu de manière flexible doit être conçu de manière flexible. Cela vous donnera l'occasion de manoeuvrer au moment où vous saurez dans quelle direction cette manœuvre doit être effectuée. Et cela vous évitera de passer du temps à vous préparer à quelque chose qui ne se produira jamais.