Vous direz quel est le problème au développeur mobile avant d'écrire sur le backend. L'essentiel est que l'API y soit pratique, compréhensible et flexible. Mais nous ne le pensons pas.
Chez AppsConf, nous pensons tous que nous devons parfois aller au-delà du développement mobile et pomper le chapeau de la lettre T dans le modèle en forme de T. Ici, par exemple, apprenez à connaître les langues du serveur un peu plus profondément que: "J'ai entendu dire que Ruby est mort." Et un peu plus large - c'est-à-dire, non seulement avec les plus populaires, mais aussi depuis les deuxièmes rangées et même souterraines.
Pour vous inspirer de l'idée du titre d'introduction, nous avons enregistré une interview de Nikita Sobolev. Ils allaient parler de langages de programmation, mais il s'est avéré que les programmeurs. Venez sous la coupe, si vous pensez qu'il vaut mieux être juste un bon développeur, et non un développeur Android ou iOS, et surtout si vous n'êtes pas d'accord avec cela. Vendredi est le moment de discuter.
- Comment aimez-vous l'idée de toute une série de rapports d'examen sur diverses technologies du backend au frontend lors de la conférence sur le développement mobile, que nous avons appelée Introduction?
Nikita Sobolev CTO chez wemake.services, auteur de la méthodologie du processus de développement logiciel répétable, organisateur d'ElixirLangMoscow, membre du comité du programme Moscow Python Conf ++ , conférencier fréquent lors de conférences informatiques et champion de la qualité du code .
À mon avis, c'est la meilleure piste sur une conférence mobile.
Je n'aime pas vraiment l'idée de spécialistes étroits. Je suis beaucoup plus proche de l'idée d'une personne en forme de T - c'est-à-dire une personne qui connaît bien une chose, mais avec un large horizon de compréhension des problèmes dans le domaine.
Malheureusement, il me semble que les développeurs mobiles dans ce sens sont seuls. Le problème est aggravé par le fait qu'ils sont très dépendants du fournisseur. En gros, Apple va fermer - ils partiront dans le froid.
Par conséquent, j'aime vraiment l'idée de la piste d'introduction et le fait que les invités à la conférence soient invités à regarder autour de soi, à découvrir ce que les autres ont, à apprendre de leur expérience et à s'améliorer en tant que spécialiste en termes de vues.
- Pour quelles autres conférences cette idée est-elle pertinente?Pour tant de gens. J'ai à portée de main un exemple Python. La dernière fois, nous avons invité Go, Elixir et Julia. Cette année, je veux inviter le front-end et le Haskellist (au
fait, l' appel à communications est déjà ouvert ). Étant donné que les développeurs Python sont également différents, beaucoup d'entre eux fonctionnent comme une pile complète, il est également utile pour eux d'obtenir des connaissances de l'extérieur.
- Pensez-vous que les développeurs mobiles sont devenus plus disposés à regarder autour, parce que c'est devenu nécessaire pour le développement professionnel, ou a-t-il toujours été le cas, juste la communauté a mûri?C'est difficile pour moi de juger avec précision, la dernière fois que j'ai écrit une application mobile en 2010. Mon langage principal était alors Java, j'ai pris Objective-C et j'ai écrit une application pour iOS. J'étais inspiré, pensais-je, maintenant je vais commencer à faire tout ça. Mais non: il n'y avait pas de gestion de mémoire, il n'y avait pas de bibliothèques, il n'y avait pas de gestion des dépendances, le système de build était dégoûtant. Depuis lors, je n'ai pas examiné attentivement ce domaine.
Et maintenant, je vois plusieurs tendances qui attirent naturellement les travailleurs mobiles vers une «programmation sérieuse».
Dans le passé, les langues étaient hautement spécialisées dans ce domaine. Objective-C était uniquement destiné au développement d'Apple. Et maintenant, par exemple, ils essaient de tirer Swift vers le serveur et de faire quelque chose dessus. Java pour le backend et pour Android étaient deux langages différents. Et maintenant, Kotlin est plus ou moins similaire pour les deux. JavaScript est apparu dans le monde du développement d'applications mobiles, et c'est une sorte de langage de serveur, et en même temps, un langage pour le frontend.
Il existe une seule infrastructure qui commence à intéresser les gens. Si auparavant (dans mon cas, c'était en 2010) le développement mobile était complètement déconnecté, maintenant tout est différent.
De plus, le rapprochement se fait des deux côtés. Une intégration plus étroite de la plate-forme donne aux utilisateurs la possibilité et la nécessité de suivre cette intégration.
- Mais si l'intégration elle-même revient au développeur mobile, pourquoi devrait-il comprendre les langues du backend?J'ai une réponse philosophique à cette question.
Si vous voulez être développeur Android, vous n'avez probablement pas besoin de comprendre le backend. Et si vous voulez être juste un développeur - bien sûr, c'est nécessaire.
Un développeur est quelqu'un qui résout les problèmes du monde réel avec du code. En conséquence, les décisions peuvent se produire partout, y compris dans une application mobile, sur un serveur, sur un frontend. Un bon développeur peut résoudre en principe tout problème du monde réel en utilisant des outils de développement.
Il est clair qu'il y a une entrée pour chacun de ces outils, l'accumulation de pratique, etc., mais la fixation rigide sur une technologie, à mon avis, est préjudiciable à l'individu qui s'y livre.
Au moins, la technologie devient obsolète. Les langues qui étaient populaires il y a 15 ans ne sont presque jamais utilisées. L'habileté de constamment développer et apprendre de nouvelles choses, en regardant les voisins, est d'une importance cruciale pour tout développeur. En particulier, il est important de comprendre le backend, car le backend est fondamental pour tout le développement, aujourd'hui tout communique en quelque sorte avec le serveur.
De plus, à coup sûr, les utilisateurs de mobilité sont mal à l'aise avec d'autres développeurs qui trouvent plus facile de trouver un langage commun. Le front-end et le back-end sont encore plus proches que n'importe quel développeur d'applications mobiles. Mon rapport contribuera dans une certaine mesure à résoudre le problème de la communication humaine, à intégrer.
La profondeur ou la surface que vous devez comprendre est une autre question. Surtout si nous parlons d'un développeur mobile qui, quoi qu'on en dise, a besoin de creuser profondément dans son domaine.
Je suis pour le fait que vous devez regarder activement autour et dans le passé. Il est important d'étudier l'histoire des logiciels et de la programmation. Si vous ne connaissez pas l'histoire, vous réinventerez beaucoup de choses que vous avez déjà inventées et abandonnées pour des raisons complètement objectives. Je dirige une
chaîne de télégrammes où je partage des liens vers des projets open source sympas sans être lié à la langue, j'essaie de mettre en avant des idées importantes.
- Un développeur d'applications mobiles a-t-il assez d'idées générales ou pas?Cela dépend tout d'abord de l'environnement. Si une personne a besoin d'influencer directement le backend dans son entreprise: pour définir des tâches plus correctes pour elle, pour participer au processus, peut-être pour gérer ces personnes, alors vous devrez le comprendre en profondeur.
Mais si vous êtes uniquement engagé dans le développement mobile, il suffit d'avoir une idée superficielle de ce qui s'y passe, des langues, des problèmes et des solutions populaires. Pour ces personnes,
mon rapport sur Saint AppsConf est également calculé. Naturellement, une présentation approfondie ne peut être donnée dans un seul rapport.
- De quoi d'autre un développeur a-t-il besoin pour être un développeur sympa?- La capacité de lire et de comprendre ce qui est lu.
- Capacité à écrire, à exprimer vos pensées par écrit.
- La capacité de parler afin d'exprimer ces pensées verbalement.
- Capacité d'écouter et d'entendre les autres.
- Comprendre le sujet. Le développeur doit comprendre ce qu'il fait, car il résout le problème de la vie de manière technique.
- Et bien sûr, comprenez la technique.
Ces compétences me semblent suffisantes. Tout le reste peut être déduit de ceux-ci ou rejeté.
- Vous pensez donc que vous devez comprendre le sujet?Limité, bien sûr, mais nécessaire. Par exemple, nous avons simultanément 3-4 projets, bien sûr, je ne les comprends pas tous parfaitement, mais je comprends les concepts de base avec lesquels je travaille. Comment ils sont interconnectés, comment ils affectent l'argent, où sont les dépenses, où sont les revenus, pourquoi tout cela est-il nécessaire pour les affaires.
Et je conseille également d'autres développeurs. Dans notre entreprise, nous établissons une documentation pour eux, comment fonctionne l'entreprise, quels problèmes nous résolvons, pourquoi cela ne peut pas être résolu par les mains. Il est parfois moins coûteux d'embaucher une personne pour qu'une fois, par exemple, elle passe par un répertoire de marchandises. Si nous automatisons le processus, vous devez comprendre pourquoi.
- Regardons un exemple. Si vous écrivez un service de livraison pour une boulangerie, vous devez comprendre comment fonctionne la livraison, mais vous n'avez pas à comprendre les types de petits pains que cette boulangerie cuit?Et dans certaines sortes de petits pains aussi. Parce que certains petits pains peuvent être stockés pendant une heure et environ deux jours. En conséquence, leur livraison sera différente.
- Dans votre rapport, vous vous engagez à prendre en compte plusieurs langues populaires à la fois, plusieurs langues des deuxièmes lignes et plusieurs langues du sous-sol. Quelles langues seront-elles?Je ne prendrai pas les langages que les participants à la conférence peuvent déjà connaître: Kotlin, Java, JavaScript. Cela n'a aucun sens d'en parler si la plupart des spectateurs les connaissent déjà. J'ai décidé de parler de langues que les gens sont assurés de ne pas connaître, car les applications mobiles ne leur écrivent pas du tout. Il y a beaucoup de choix.
J'adore les langages de programmation. Sans tâche spécifique. J'aime le langage de programmation comme idée. Certaines personnes ont pensé: «Il existe un tel ensemble de problèmes, ils peuvent être combinés et résolus en une seule fois. Faisons un langage pour cela. " Il résoudra une liste spécifique de problèmes. Et une autre langue résoudra d'autres problèmes, car généralement tous les problèmes ne peuvent pas être résolus en même temps.
J'aime vraiment voir quels problèmes chaque langue résout et pourquoi cela peut être nécessaire dans la pratique. Le langage lui-même devient pour moi un objet d'art intellectuel. Un grand nombre de personnes ont travaillé, pensé, conçu, optimisé. C'est très intéressant, donc je suis de nombreux langages de programmation.
Les langues que j'ai choisies pour le rapport ont plusieurs caractéristiques intéressantes. Premièrement, ils sont controversés. Aucun d'eux n'est une langue qui est finalement bonne dans tout dans la conscience de la communauté.
Tout le monde sait que Python est lent, mais c'est toujours le langage le plus populaire, il est utilisé partout. Je vais essayer d'expliquer pourquoi il est utilisé.
Et en parlant de Ruby, la première chose que les gens disent, c'est que Ruby est mort. En fait, les développeurs Ruby maintenant plus que dans n'importe quel autre langage se soucient de l'architecture et mettent en œuvre un grand nombre d'idées provenant d'autres langages - fonctionnels, orientés objet, et en font quelque chose de très intéressant.
Si nous parlons de Go, alors Go a un champ d'application très étroit, mais à la suite du battage médiatique, tout le monde a commencé à écrire dessus.
Chacune des langues que j'ai choisi de représenter pendant le discours a une sorte de conflit.
En tant que personnage dans une bonne histoire. Et l'essence du conflit est que certaines choses fonctionnent bien, d'autres non. Ce conflit sera à la tête du rapport.
- Pensez-vous que vous devez choisir votre langue pour chaque tâche, projet?C'est une bonne idée, mais cela ne fonctionne pas dans la pratique. Exactement là où nous avons commencé. Il y a des programmeurs Android, il y a des programmeurs Python qui, quand vous leur montrez le code Ruby, c'est la même chose, seulement de profil, ils disent: "Oh non, tout est incompréhensible, je ne veux pas comprendre".
Bien sûr, j'aimerais que les gens soient plus polyvalents et puissent choisir un instrument pour la tâche, mais il s'avère que les gens savent une chose et prennent toujours cet outil.
Le facteur d'embauche est également ajouté ici. Par exemple, dans notre entreprise, nous ne pouvions pas choisir entre TypeScript et Python. Mais, si j'ai besoin d'embaucher un développeur Elixir, je le chercherai toute ma vie. Je connais de tels développeurs, mais pas tellement, et pas pour que je puisse rapidement les attirer. Par conséquent, vous devez modérer vos ambitions et vous adapter au marché et aux clients, qui ont également une pile limitée en fonction du marché.
- Vous promettez un regard subjectif sur près de 10 langues complètement différentes. Les connaissez-vous tous, avez-vous écrit quelque chose sur chacun d'eux?Avec chacun de différentes manières, mais, bien sûr, je les ai tous essayés au moins dans une certaine mesure.
Par exemple, sur Rust j'écris en open source, et sur pony j'ai écrit 15 lignes de code, lu le tutoriel, admiré, et maintenant je veux montrer aux participants de la conférence. Pour qu'ils s'inspirent eux aussi de l'idée.
- Évidemment, dans un rapport, vous ne pourrez pas donner une image complète et une compréhension de chaque langue. Pourquoi les gens devraient-ils consulter votre rapport et ne pas le rechercher sur Google?La raison en est que quand une personne vivante vous le dit, c'est complètement différent. Dans une certaine mesure, un rapport est toujours un spectacle. Lorsque les gens viennent au spectacle, ils reçoivent non seulement du contenu, mais aussi des émotions. Lorsque vous utilisez Google, vous obtenez uniquement du contenu. Si cela vous intéresse, vous allez quand même le rechercher sur Google. Et le format du discours d'une personne vivante permet d'obtenir populairement et facilement des connaissances intéressantes.
- Quels seront les principaux éléments de votre «show»?Il y a beaucoup de langues, elles sont toutes cool, mais il n'y a rien sur quoi écrire.
Il existe de nombreuses langues populaires pour résoudre vos problèmes commerciaux: embauche, clients, bibliothèques. Mais ils sont tous devenus populaires pour une raison. En règle générale, la raison principale est qu'ils sont très simples. Ils sont basés sur des concepts simples, faciles à démarrer, mais difficiles à poursuivre.
Il existe des langages de niche, et des concepts complexes très intéressants apparaissent déjà sur lesquels vous pouvez construire quelque chose de grand et de fiable: Rust avec son excellent compilateur, Elixir avec sa machine virtuelle absolument perforante, Haskell avec son système de type, etc. Mais ils ne peuvent pas devenir populaires simplement en raison du seuil d'entrée élevé.
La plupart des développeurs qui veulent apprendre quelque chose utilisent des langues populaires et leur écrivent. Et la question de savoir pourquoi quelque chose d'autre pourrait être nécessaire ne se pose pas, car dans les projets avec lesquels ils travaillent, rien de plus compliqué n'est requis.
Il est très important pour le développeur de comprendre les limites de l'outil.
Pour comprendre la limitation, vous devez vous reposer contre votre front, combattre un problème, puis prendre du recul et le regarder à distance. Ce n'est que dans les rapports de personnes qui ont travaillé avec quelque chose pendant de nombreuses années que cela se manifeste. Et je connais bien ces gens, j'ai accumulé divers cas et je sais où me reposer. Et je peux résumer mon expérience et celle des autres.
- Ecrire «Hello world» sur Haskell est déjà un grand exploit, mais cela ne suffit-il pas?Oui, vous devez bouillir dans la communauté des fonctionnaires. Pour écouter quels problèmes ils résolvent, quels rapports ils font - afin que vous puissiez comprendre la section.
Par exemple, dans la communauté haskelliste, le problème d'entrée est très aigu. Ils ne peuvent toujours pas le résoudre et rendre leur langue plus conviviale pour les débutants. Historiquement, Haskell utilise une syntaxe complètement différente et des règles complètement différentes, juste pour écrire au moins quelque chose. Même un développeur expérimenté ne sera tout d'abord pas certain de ce qui se passe dans ce code.
Et ce n'est pas seulement dans la programmation fonctionnelle. Si vous commencez à vous familiariser avec les fonctionnalités d'Elixir, ce sera beaucoup plus facile. Elixir est très similaire en syntaxe à Ruby. Au début, vous ne verrez pas la différence, vous pouvez écrire de la même manière qu'en Ruby. Et c'est seulement alors qu'il devient clair qu'il s'agit d'un langage fonctionnel. Vous ne le remarquez pas jusqu'à un certain point, puis vous découvrez par vous-même des opportunités supplémentaires. Vous comprenez qu'en fait, il repose sur des principes complètement différents. Connaissant cette base, il devient facile de passer à un langage fonctionnel moins convivial.
L'ordre est important.
- En plus des langues populaires et des langues, comme vous le dites, de la deuxième série, qui est au moins en partie entendue, vous allez en introduire des totalement inconnues. Par exemple, quel est ce poney?Pony est un langage de programmation open-source, orienté objet, modèle acteur, à capacités sécurisées et hautes performances. Autrement dit, fortement typé, sûr de la mémoire, langage d'acteur. Il est très jeune et très intéressant.
Ses développeurs créent un langage dans lequel vous pouvez créer un très grand nombre d'acteurs, comme dans Elixir, mais ces acteurs sont garantis en sécurité de type. Les limites d'applicabilité de ce langage sont encore totalement incompréhensibles. Mais je dirais qu'il peut toucher Go, et je soutiens activement tout ce qui peut toucher Go.
- Si toutes les langues ont des lacunes et des limites, que faire? Que faire à ce sujet?Souffrir. Et continuez à rechercher l'excellence technique. C'est un rêve inaccessible pour tout ingénieur, mais le processus de recherche de cette excellence est un grand objectif.
Saint AppsConf après 10 jours. Le comité de programme a sélectionné 35 rapports et 12 réunions, parmi lesquels chaque développeur mobile trouvera des idées utiles pour résoudre les problèmes quotidiens et pour leur développement professionnel et personnel. Je te retrouve les 21 et 22 octobre à Saint-Pétersbourg!
Une question bonus pour ceux qui veulent partager leur expérience, mais pour une raison quelconque, ils ne sont pas encore devenus conférenciers. Vous parlez souvent, pourquoi en avez-vous besoin et qu'est-ce qui vous motive?J'ai trois objectifs:
- Amusez-vous, j'aime vraiment les conférences, c'est amusant et intéressant.
- Local - trouver des développeurs et des clients.
- Global - pour améliorer notre industrie . Je vois beaucoup de problèmes et je veux influencer positivement et réparer le mal.
Un orateur lors d'une conférence peut influencer une industrie par le biais d'un public. Lui de la tribune peut prouver son point de vue et motiver les gens à changer.