Cinq tendances effrayantes du design moderne

L'habitude est une force terrible. Il vous fait résister au changement, il empêche le développement. Mais en informatique, nous aimons être à la pointe de la technologie, nous aimons les défis, nous aimons mettre en œuvre ce qui se répandra dans d'autres domaines en quelques années seulement.

Nous sommes prêts pour le nouveau et n'attendrons peut-être pas l'avenir, et nous devrons nous y adapter. On peut aller de l'avant, pour savoir seulement dans quelle direction.

Egor Bugaenko sait ce qui doit être fait maintenant pour rester un programmeur recherché dans 5 à 10 ans. Ses idées, comme toujours, peuvent sembler controversées. Vous n'avez pas besoin d'être inconditionnellement d'accord avec eux, mais de penser, par exemple, au projet pour animaux de compagnie ne fera pas de mal à nouveau. Et le fait que le programmeur ait besoin de l'anglais, il ne peut guère y avoir d'opinions différentes. Mais sur les points restants, il sera intéressant de connaître l'opinion de la communauté dans les commentaires.



Vient ensuite la version texte du rapport d'Egor sur AppsConf , mais il se réfère non seulement et pas tellement au développement mobile, mais à l'industrie dans son ensemble. Egor Bugaenko, fondateur de Zerocracy, développeur de Cactoos, Takes Framework, JCabi et d'autres projets open source. Il a écrit une série de livres intitulée Elegant Objects, a un blog provocateur et donne des reportages stimulants comme celui-ci.



Je vais commencer par une histoire sur la façon dont il n'y a pas si longtemps, j'ai décidé de commencer à développer des logiciels pour les appareils mobiles et je suis rapidement entré en collision que je ne savais pas comment le faire. Par conséquent, j'ai décidé de demander l'aide de quelqu'un qui me dirait comment créer une application sous une forme entièrement emballée. Autrement dit, créez une application qui sera disponible sur l'Apple Store.

Je me demandais comment assembler l'application dans un seul paquet, c'est-à-dire non seulement dessiner quelques boutons sur l'écran, mais créer une application entière . Évidemment, le code, par exemple, sur Swift et le produit sur le téléphone mobile, sont deux choses complètement différentes: la première est très petite, et la seconde est très grande et comprend de telles questions:

• Tests unitaires
• analyse statique;
• Intégration continue
• gestion des dépendances;
• Livraison continue;
• Environnement de mise en scène;
• Processus d'approbation d'application sur Apple Store
• processus d'assemblage des défauts de production, etc.

La disposition des boutons à l'écran est facile à lire sur Internet. J'avais besoin d'un spécialiste, un expert qui m'aiderait à assembler l'ensemble du pipeline. Pour moi, en tant que programmeur, c'est plus important que d'organiser les boutons à l'écran.

J'ai trouvé un tel spécialiste, mais il m'a dit: «Pourquoi pensez-vous à cela? Dessinez d'abord l'application. Qu'est-ce que l'intégration continue? Attendez avec les tests unitaires - faites-le fonctionner. Qu'est-ce qu'un pipeline de livraison? Pourquoi TestFlight - utilisez un simulateur. "

Certes, il est un bon programmeur, mais dans sa tête, à mon avis, tout est à l'envers . Il pense que le code est important et que le reste de l'emballage est secondaire. À mon avis, c'est un gros problème, et je veux en parler.

Pour une raison quelconque, de nombreux développeurs pensent que le code lui-même est important, et l'assemblage est ce que fait l' ingénieur DevOps ou quelqu'un d'autre. Habituellement, lorsque vous venez en équipe, c'est déjà fait et configuré. Vous vous retrouvez dans un projet où vous écrivez du code, sans savoir comment tout finit en production. Je crois que le fait que les programmeurs ne voient pas le cycle d'assemblage complet, ne savent pas comment cela fonctionne, est un problème.

Déployer d'abord, puis coder

J'écris des livres sur la programmation, et je sais par moi-même qu'un livre fonctionnera bien si vous le concevez magnifiquement en premier . Autrement dit, je conçois le livre avant d'écrire. Je fais d'abord un makefile qui, directement depuis la ligne de commande, recueille l'intégralité du livre à partir de fichiers sur LaTeX, prépare des textes, des images, des couvertures. Je passe beaucoup de temps et je fais en sorte qu'avec une seule commande, je rassemble le livre entier dans un fichier PDF. Je porte une grande attention à l'apparence, aux retraits, aux blocs de texte et à la distance entre eux, à la numérotation des pages. Quand j'aime tout cela, je vois que tout est magnifiquement assemblé et que tout dans ce produit est entier, même si une seule page est écrite jusqu'à présent, c'est seulement alors que je commence à écrire un livre, et alors seulement ça me fait plaisir.

Le plus souvent, les programmeurs font le contraire: ils écrivent, s'exécutent sur le simulateur, vérifient le travail. Je pense qu'il est plus correct de déployer d'abord, puis de coder .

Je vais donner un autre exemple. Un développeur novice s'est porté volontaire pour réaliser un projet open source avec nous. Il a choisi Flutter, a fait la première itération, a commencé, a dit que tout était cool et cool et a proposé de regarder. Nous demandons: «Comment essayer quelque chose? Voici l'iPhone - où pousser? " Ce qu'il a commencé à expliquer, où aller, quoi télécharger, a été un long processus.

Cela nous a semblé inconfortable et, à la fin, il a convenu que l'application devait vraiment être téléchargée sur TestFlight. Après un certain temps, il a montré l'application sur TestFlight. J'ai poussé les boutons et j'ai remarqué quelques défauts. Je ne travaillais pas avec Flutter et je ne voulais pas vraiment, mais je voulais corriger rapidement ce que j'avais remarqué. J'ai demandé comment procéder, où et comment envoyer une pull request. J'ouvre le dépôt, fichier readme: "Ceci est une application sympa ... cliquez sur télécharger ...".

Les instructions étaient compliquées et incompréhensibles, j'ai de nouveau demandé comment déployer tout cela sur mon ordinateur. Je voulais juste modifier le code de quelqu'un d'autre avec un simple clic de quelques boutons sur mon ordinateur, démarrer le simulateur et envoyer une demande de pull. Ce type est allé décrire tout cela et n'est jamais revenu.

Cette situation illustre que ses qualités de programmeur sont bonnes - il a pu exécuter l'application. Mais ses qualités, en tant que personne qui voit l'ensemble du projet, laissent beaucoup à désirer. En conséquence, le projet m'a perdu non seulement en tant que contributeur, mais aussi de nombreux autres. Ce programmeur n'a pas reçu de retour des autres, il a travaillé comme un solitaire.

À mon avis, être seul est mal en ce moment. Le marché évolue vers des équipes plus peuplées: il y aura plus de personnes, elles vont et viennent plus souvent.

La dynamique des ressources humaines évolue vers un roulement plus élevé, donc chaque personne qui revient au projet a besoin de le voir dans son intégralité - pas seulement le code qui s'exécute sur les simulateurs.

Un débutant devrait entrer dans un environnement qui lui est convivial du point de vue de l'assemblage - il doit ouvrir un fichier Lisez-moi et comprendre en quelques minutes comment faire tout démarrer sur le simulateur. Sur quoi cliquer pour vérifier si tout est construit à partir de la ligne de commande - pas à partir d'IDE complexes qui doivent être configurés pendant plusieurs heures. Il devrait être possible d'écrire make / build / etc sur la ligne de commande. Après cela, tout est collecté et imprime une ligne verte - tout est prêt - puis tirez la demande. C'est la première pensée que je veux partager aujourd'hui.

Bien sûr, vous direz que vous ne travaillez pas seul, ni en tant que seul fondateur de projets, ni en tant que CTO. Vous travaillez en équipe et vous ne pouvez pas simplement dire que vous allez maintenant vous occuper du déploiement, TestFlight, et vous devez comprendre d'urgence CI. Ce n'est pas votre tâche, vous n'aurez pas le temps, etc.

Par conséquent, je vous recommande de faire vos propres projets pour animaux de compagnie - des projets que vous faites pour votre propre plaisir - pour tout comprendre dans son intégralité.

Seuls 20 à 30% des programmeurs ont leur propre application publiée, et tout le monde devrait l'avoir. Si vous vous considérez et que vous voulez être un programmeur recherché, je vous recommande de créer votre application mobile et de passer par tout le cycle de son entrée sur le marché: contrôles sur l'Apple Store, CI, packaging et tout le reste. Rendez-le open source pour que les gens puissent contribuer et vous montrer comment ils échouent.

Voyez comment vous travaillez avec le marché, essayez de comprendre quel type de programmeurs vous êtes. Je pense qu'un programmeur qui n'a pas de projets pour animaux de compagnie est mauvais.

Soit il ne s'intéresse pas à sa profession, soit il s'en fiche, soit il ne le peut pas, soit il a peur. C'est une peur de voir tout le cycle. Nous avons peur de considérer le projet comme un produit prêt pour le client. Et le client pour nous dans de nombreux cas est un autre développeur, comme dans mon exemple, j'étais un développeur client sur Flutter.

La deuxième crainte, à mon avis, est l'argent.

Combien de code écrirez-vous pour 100 $?

Je travaille avec beaucoup de programmeurs sur la plateforme Zerocracy et j'ai remarqué qu'ils ont très souvent peur de l'argent. Ils ont l'habitude de payer à la fin du mois, et ils sont assez douloureux lorsqu'ils sont évalués en argent. Beaucoup ne peuvent pas répondre à la question simple: "Savez-vous combien vous pouvez faire du code pour 100 $?"

Vous savez sûrement combien vous voulez gagner par mois. Imaginez combien coûte un mois complet de votre vie: un appartement, une voiture, des paiements réguliers, le degré habituel de confort et de divertissement.

Les développeurs à temps plein et à rémunération fixe manquent de temps.

Je pense que nous travaillerons de plus en plus dans des équipes temporairement constituées, où les gens viennent quand ils sont nécessaires, et vont plus loin après. L'ère des développeurs assis au même endroit est en train de disparaître parce que l'entreprise les a embauchés il y a de nombreuses années, ils adorent cette entreprise, et donc ils sont avec elle - peu importe la technologie utilisée par l'entreprise.

Je connais des exemples de tels projets qui ont été écrits en C ++ pendant de nombreuses années, puis j'ai réalisé qu'ils avaient besoin d'écrire en Java. Et les mêmes personnes, dans le même bureau, pour le même échange d'argent investisseur, se recyclent pendant six mois et commencent à trembler et à rouler à Java. Il s'agit d'une approche du passé. À mon avis, à l'avenir, de telles approches cesseront d'exister, car elles n'auront aucun sens.

Le marché devient mondial , l'accès à distance au marché du travail devient de plus en plus facile. Une entreprise basée à Moscou sera sans intérêt et non rentable pour recycler des gens, par exemple, d'iOS à Android ou de C ++ à Java. Il est plus facile d'embaucher de nouveaux spécialistes qui viendront en tant que pigistes, termineront la tâche et partiront.

Je pense que ce format de projets sera populaire: les projets temporaires, où les pigistes se rencontrent, travaillent sur leurs tâches - un expert en cela, un autre expert en cela, et partent.

De la part des programmeurs, ce nouveau temps attend:

• La capacité de comprendre combien vous valez. C'est-à-dire, donnez une estimation de la valeur de votre heure de travail, de la valeur que vous allez en créer.
• Capacité à travailler dans des conditions temporaires.
• Compétences pour vous vendre, bien présenter. Un développeur indépendant sur le marché mondial doit avoir un «avantage commercial» et un prix.

Beaucoup de gens ont peur de créer des curriculum vitae, peur de se vendre. Comme je l'ai dit, je pense que le résumé devrait certainement inclure l'élément de projet pour animaux de compagnie.

Ses propres projets seront le premier indicateur de valeur sur le marché , et non pas là où vous développez des logiciels dont vous avez hérité pendant 5 années consécutives. Vous créez un projet Pet à partir de zéro, et peu importe de quoi il s'agit, à quel point il est compliqué ou combien de téléchargements il a sur l'Apple Store. Que ce soit 0 likes et 2 téléchargements, mais c'est un projet intégral que vous avez créé vous-même.

Pour moi, en tant qu'employeur, ces personnes ont plus de valeur que celles qui sont au bureau depuis de nombreuses années et qui ont un curriculum vitae avec un ou deux employeurs. C’est difficile pour moi de comprendre quoi faire avec cette personne, comment l’évaluer. Je sais qu'il veut que je le prenne pendant tout le mois et que je sois ami avec lui quel que soit le résultat. Pour moi, ce format est désormais inacceptable, pour un grand nombre d'employeurs à l'avenir, il sera également inconfortable.

Par conséquent, la recommandation est de compter l'argent, d'essayer de travailler sur des contrats . Cela ne conviendra peut-être pas tout à fait à vos employeurs, mais essayez d'être à plein temps et assis au bureau tout en recherchant des micro-projets pour un emploi à temps partiel. Pas pour l'argent, mais pour comprendre si le marché a besoin de vous en tant que pigiste ou non, si vous en avez besoin en tant qu'expert ou non. Ou vous n'avez besoin que de votre patron, qui a peur de vous perdre, car vous seul savez comment fonctionne le code du projet.

Cherchez des alternatives, voyez, essayez, vendez . Au début, vous ne serez pas acheté, il y aura des problèmes - beaucoup de problèmes! Mais en résolvant ces problèmes, vous deviendrez un programmeur plus recherché à un niveau supérieur.

Malheureusement, non seulement les programmeurs eux-mêmes ne peuvent pas déterminer le prix du travail, mais aussi les clients. Parfois, ils suggèrent que j'exécute certaines tâches en tant qu'expert. Et souvent, le client qui m'offre un emploi ne comprend pas comment m'évaluer. Plus souvent qu'autrement, les gens veulent juste moins cher, comme 50 $, pas 100 $, par heure. Je comprends qu'une personne avec cette approche ne comprend toujours pas combien j'écrirai en temps réel pendant cette heure. Ensuite, je suis d'accord et multiplie simplement le nombre d'heures par 2. En conséquence, j'obtiens autant que je voulais à l'origine.

Je connais ma valeur réelle et ma vitesse. Les clients ne sont pas prêts pour des montants de 100 à 500 $ par heure, pour eux, 20, c'est déjà beaucoup, car ils sont habitués au format d'emploi à temps plein au fil du temps. C'est-à-dire lorsqu'une personne reçoit de l'argent pour le temps qu'elle consacre prétendument au développement.

Je ne sais pas pour vous, mais je ne peux pas rester assis pendant 8 heures à écrire du code. Je suis sûr que chacun de vous confirmera que sur 8 heures de travail que vous êtes au bureau ou à l'ordinateur, vous écrivez en fait beaucoup moins de code. Et ils paient pour ces 8 heures, et le client pense que c'est 8 heures de travail. C'est un système de double tromperie: ils sont contents d'être trompés, et nous les trompons. Par conséquent, j'utilise le facteur de multiplication. Je vais travailler pendant au moins 20 ans, mais ensuite je ferai 3 semaines ce que je peux vraiment faire en 2 heures.

Apprenez à vos clients et apprenez à compter l'argent vous-même.

Les bons programmeurs écrivent du code, le meilleur - tickets

Les clients et les programmeurs sont habitués à la communication informelle.

La communication informelle sous forme de chats, appels téléphoniques, rassemblements, e-mail est une forme de communication qui détruit le projet et ne fait qu'empirer le client et le programmeur.

La communication informelle reste dans l'air, elle n'est pas consignée dans la documentation, n'est pas surveillée, puis il est difficile d'y revenir et rend le projet difficile à maintenir. Lorsqu'une équipe change, et comme je l'ai déjà dit, l'équipe doit changer et changera plus intensément, il devient très important de comprendre les communications passées du projet.

Si je viens à un projet en développement, je veux comprendre ce qui a été fait au cours de la dernière année, non seulement sous forme de code, mais aussi avoir une sorte d'explication pour ce code: pourquoi un tel cadre ou algorithme a été choisi, qui a déjà exprimé son opinion sur cet algorithme et je n'étais pas d'accord. Je veux voir tout cela, et ne pas chercher dans le bureau ou discuter pour quelqu'un qui va tout m'expliquer. J'ai besoin de pouvoir lire ceci directement dans le référentiel ou le système de tickets.

Malheureusement, le plus souvent, les programmeurs suivent l'exemple des clients. Bien sûr, dans l'intérêt du client d'avoir la possibilité d'une communication informelle avec le développeur. Et nous nous trouvons assez faibles et suivons leur exemple, écoutons au téléphone ce qui doit être fait, répondons, écoutons, répondons ... et ensuite nous allons le faire.

Ensuite, 2-3 semaines passent et nous ne nous souvenons plus de ce sur quoi nous nous sommes mis d'accord. Le client dit qu'il ne voulait pas cela, nous essayons de prouver que c'est ce qu'il a demandé, nous recherchons une mention dans le chat - la capture des puces commence.

Je pense que la raison en est la peur des systèmes de billetterie. De nombreux programmeurs avec lesquels nous travaillons (c'est sûr que cela vous concerne également) ne savent pas comment, n'aiment pas, ne veulent pas formuler des tâches sous la forme d'un ticket - clair et concis.

Il est plus facile pour les gens de dire: "Parlons!" Nous organiserons un rassemblement, nous asseoirons ensemble et déciderons de tout. Dans 3 heures, nous nous comprendrons, puis je vais coder. Je me souviendrai de ce que nous avons convenu et je programmerai tout. » N'oublie rien, retrouve-toi. Et donc nous allons en quelque sorte s'étendre de rallye en rallye.

C'est faux. En tant que programmeurs, nous devons convertir toute communication informelle en tickets. Nous avons parlé avec le client (client, propriétaire du produit, un autre programmeur), découvert ce qui doit être changé - nous convertissons toute communication en ticket limité par le cadre de notre système (Jira, GitHub, etc.), où nous écrivons: ce qui ne fonctionne pas, comment vous devez le réparer, pourquoi vous devez le réparer, quelle motivation, puis nous travaillons sur ce ticket.

L'incapacité d'un programmeur à structurer le travail en tickets peut indiquer ses faibles qualifications. Je pense qu'il existe deux types de développement:

• Développement continu - programmation de 9h à 17h: je suis arrivé, j'ai allumé l'ordinateur, puis j'ai fait quelque chose, là, le midi, j'ai aussi codé, la fin de la journée - enfin, demain je vais continuer. Autrement dit, nous programmons alors qu'il y a de l'énergie, du temps et de la force.
• Le développement incrémental est différent: il y a la tâche numéro 13, je vais le faire jusqu'à la fin, puis voir quelle tâche est la prochaine. Dans ce formulaire, la tâche (ticket) sera toujours terminée. Mais s'il n'y a pas de ticket, il n'y a pas de tâche documentée formulée, le projet ne bouge pas - le code n'est pas écrit et la demande de pull n'apparaît pas.

Je me retrouve souvent à travailler dans le premier scénario. J'aime programmer, le matin j'allume l'ordinateur - et je pars. Ensuite, je freine - arrêtez-vous, divisons-le en tâches, déterminons vers quelle tâche nous allons passer.

Dans la seconde version, chaque ticket se termine par une pull request: voici le problème, sa description, discussion dans le domaine de ce problème, un changement de code. Pull request envoyé, vérifié, accepté - ticket fermé, vous pouvez passer à la suivante.

Habituellement, les gens travaillent dans les deux sens. Mais pour une raison quelconque, l'un des principaux problèmes auxquels nous sommes confrontés: les gens ne savent tout simplement pas comment diviser la tâche en plus petits.

Certaines personnes croient à tort que le développement incrémentiel signifie nécessairement une tâche de 2 semaines et que le ticket devrait se terminer par une demande de tirage de 5 000 lignes modifiées. Ce n'est pas un développement progressif. Incrémentiel est une tâche de 0,5 à 2 heures, et à la fin d'une demande d'extraction de 50 à 100 lignes de code. Continu, au contraire - vous travaillez longtemps (jours, semaines) et vous produisez peu.

Par conséquent, je dis que les bons programmeurs écrivent du code, mais les meilleurs écrivent des tickets. Écrire du code est plus facile qu'un bon ticket - c'est une bonne explication de la raison pour laquelle ce code doit être fait. Par conséquent, si vous souhaitez développer et élever votre niveau, concentrez-vous sur la capacité d'expliquer à un autre programmeur ce qui doit être fait, et la capacité d'écouter un client ou un client et de traduire ses pensées en tickets.

Je vais donner un exemple tiré de la vie. Récemment, nous avons eu un client qui, comme beaucoup d'autres, a voulu expliquer l'essence du projet par téléphone. Il s'est entretenu plusieurs fois au téléphone avec l'un de nos architectes. Après une semaine, j'ai constaté que, malgré la discussion en cours, peut-être même une sorte de code est en cours d'écriture, il n'y a qu'un seul ticket dans le système. Il s'agit d'une erreur d'un architecte qui a reçu un flux d'informations et ne l'a pas structuré. Ensuite, s'il y a des problèmes dans le projet, nous n'aurons rien à répondre au client insatisfait. Nous n'augmenterons pas les journaux des conversations téléphoniques.

Ce n’est qu’une erreur d’architecte. Le client n'a pas besoin de le savoir. Le client est une créature chaotique et indisciplinée qui comprend peu pendant le processus de développement. Il devrait être comme ça. Mais notre tâche est d'être plus discipliné , alors écrivez les billets, la structure.

Quel langage de programmation apprendre en premier? L'anglais!

Le problème suivant que je rencontre souvent et auquel je veux faire attention est la langue anglaise. De nombreux développeurs russophones ignorent la langue anglaise, la considèrent comme secondaire et ne veulent pas apprendre, ou il leur est difficile de donner. Dans le domaine informatique, il existe une communauté russophone avec laquelle il me semble que nous devons nous battre de toutes nos forces. Habr, en tant que pionnier de cette communauté, rend un mauvais service.

Bien sûr, la langue russe est notre langue maternelle, et il n'est pas nécessaire de la refuser. Mais dans le domaine des mêmes billets, code, conférences, livres que vous lisez, je pense que nous devrions passer au format anglais uniquement .

Comme je l'ai dit, le monde du développement devient mondial, il y aura de moins en moins de programmeurs de Moscou - il y aura juste des programmeurs, par exemple, sur Swift, et il y aura peu de gens qui se soucient de vous de Moscou. Les programmeurs se vendront dans le monde entier via Internet, plutôt que par le biais d'entretiens au bureau. D'une manière ou d'une autre, ce marché viendra, même après 5-10-15 ans, et vous pourriez être laissé de côté.

Vous pensez qu'il est plus facile de communiquer avec un compatriote en russe. Telegram-, , . — , . , , .

, . , .

, .

. , , .

. . , -, . , , , . — . . , , , .

. , , , . , .

— . Twitter, , Telegram- . , . .

, , , , . , , , , , — .

5-10 . 2 , , .

, . — . , , .

GitHub —

, open source , 10–15 open source, (NASA ).

, .

open source . , — . : , pull requests , , GitHub, .

open source- . open source-, , , .

, , . — open source, ? , , , — .

, — , . , , . open source- . open source community: , -, , pulll request, .

open source-, : , , — - . 2 300 followers GitHub — , 6 .

— , . -, , . , .

, . , . , , , , . — , 25 , , community .

, . , . , full-time, . , .

— , . , 20 Twitter 2 GitHub, . open source-, , . .

— .

2000 , 2019. 2029 . , , followers, , .

, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .

— . .