Aujourd'hui, nous attirons votre attention sur la
traduction continue
de matériel sur les dangers de la programmation dite "fonctionnelle".
Le succès est le chemin, pas le but.
Admettons que nous, les programmeurs, sommes payés pour notre temps. Tout comme les constructeurs qui creusent des trous près de ma maison depuis deux ans maintenant (d'ailleurs, ils construisent un mur, c'est-à-dire une route).
Cherchons la formule de productivité du programmeur. Tous ceux qui ont travaillé dans une grande entreprise sérieuse connaissent une formule simple pour réussir:
= __ x __
▍Nombre de bugs corrigés
Le cerveau humain est très mal adapté pour travailler avec ce qu'on appelle «l'état d'application» en programmation. Nous pouvons, à un moment donné, stocker seulement environ cinq éléments dans notre mémoire à court terme. Un «état» dans la programmation est généralement des données stockées en mémoire. Dans la POO, il s'agit, par exemple, de champs ou de variables d'objet. Travailler avec un état mutable est très similaire à jongler. Peu de mes amis peuvent jongler avec trois balles, sans parler de cinq.
La POO fait bon usage de ces faiblesses. En POO, presque tout peut muter. Je remercie les forces supérieures pour le fait que les créateurs de OOP ont sérieusement pris en compte ce dont dépend la productivité des développeurs! Dans la POO, tous les états mutables sont également disponibles pour une utilisation dans différents emplacements de programmes par référence. Cela signifie que le programmeur doit non seulement penser à l'état mutable de l'objet avec lequel il travaille actuellement. Il doit se souvenir des états mutables d'un autre 10-50 objets avec lesquels cet objet interagit! C'est comme jongler avec 50 balles à la fois. Cet état de fait a également une valeur ajoutée. C'est un excellent exercice pour le cerveau.
Des erreurs? Oui - pendant le processus de jonglage, certaines balles tombent. Le programmeur peut manquer quelques petites choses concernant l'interaction de 50 objets. Mais qui, franchement, s'en soucie? Les erreurs de production doivent être signalées par les utilisateurs. C'est ainsi que fonctionnent les grandes organisations sérieuses. Ensuite, les messages d'erreur sont envoyés au journal JIRA (comme vous le comprenez, il s'agit d'un logiciel sérieux au niveau de l'entreprise). Même quelques années ne s'écouleront pas et les erreurs seront corrigées. Le problème est résolu!
Seigneur, comme j'aime mon application de banque mobile. Il est très fonctionnel, la banque valorise mon entreprise et s'occupe de mes données personnelles. Les erreurs ne sont que des possibilités (m'a-t-on dit)!
Les programmeurs dits "fonctionnels" ne comprennent pas pourquoi isoler l'état et le rendre immuable. Cela entraîne les tristes conséquences de réduire la complexité des programmes et, par conséquent, de réduire le nombre d'erreurs. S'il y a moins d'erreurs dans la base de code, cela signifie que les programmeurs devront résoudre moins de problèmes. Les sociétés de développement ne pourront pas facturer à leurs clients la correction de bogues. En utilisant des méthodes fonctionnelles, les programmeurs travaillant dans n'importe quelle grande entreprise sérieuse auront l'air mauvais aux yeux de leurs gestionnaires, et en même temps, ils nuiront grandement à leurs chances de carrière.
▍Nombre de lignes de code
Le programmeur a besoin de l'occasion de démontrer aux gestionnaires les résultats de son travail, les résultats de la progression vers l'objectif. Quelle est la manière la plus efficace d'exprimer les résultats d'un programmeur? C'est, bien sûr, le nombre de lignes de code qu'il a écrit! Si nous passions tous à la programmation fonctionnelle, nous bouleverserions grandement les managers et susciterions chez eux de sérieux soupçons quant à l'efficacité de notre travail. Une approche «déclarative» conduit à écrire du code plus concis. Son utilisation réduit considérablement le nombre de lignes de code dans les programmes. Je pense qu'il est tout à fait inacceptable qu'avec une approche déclarative, pour atteindre le même objectif, jusqu'à 3-5 fois moins de code soit nécessaire que lors de l'utilisation de la POO.
En d'autres termes, lors de la transition vers une programmation fonctionnelle, notre productivité s'effondrera littéralement aux yeux des dirigeants d'entreprise sérieux. Cela, à son tour, mettra nos emplois en danger. Par conséquent, il est dans notre intérêt de rester à l'écart de la programmation «fonctionnelle».
Le même conseil s'applique aux entrepreneurs qui facturent les clients en fonction des heures travaillées. Voici une formule de réussite simple pour eux:
__ = ____ = $$$$$$
Cette formule de réussite est bien sûr également directement applicable aux entrepreneurs sérieux qui sont payés pour le nombre de lignes de code:
if (1 == '1') { doStuff(); } else { // }
▍Le code de spaghetti est notre pain et notre beurre
Contrairement à la programmation fonctionnelle, la POO nous offre une approche cohérente pour écrire du code spaghetti. Ceci est extrêmement bénéfique pour la productivité des développeurs. Écrire un code spaghetti signifie passer plus d'heures à écrire le code. C'est un avantage direct pour tout programmeur orienté objet sérieux. Les spaghettis sont non seulement très savoureux. C'est également un concept extrêmement important pour ceux qui écrivent dans le style de la POO.
La POO est un vrai cadeau pour les entrepreneurs et les employés d'entreprises sérieuses.
Département de prévention des erreurs
Vous ne devriez pas avoir peur d'utiliser la POO. Je le répète - les erreurs ennuyeuses sont une bagatelle dont vous ne devriez pas vous inquiéter. Dans toute organisation sérieuse, il existe un service de prévention des erreurs (il est également appelé service d'assistance aux utilisateurs), dont la tâche principale est de protéger les développeurs de l'entreprise des clients en colère. En fin de compte - si le client ne peut pas utiliser correctement l'application - ce n'est que sa faute.
Les développeurs ne devraient pas être gênés par des choses qui ne sont pas pertinentes pour leur entreprise, telles que les rapports de bogues. Cela permet de garantir une situation dans laquelle les ressources de l'entreprise ne sont pas gaspillées. En conséquence, les développeurs ont la possibilité d'implémenter calmement de nouvelles fonctionnalités d'application et de concentrer toute leur attention sur la création d'abstractions orientées objet de la classe entreprise et sur l'application de modèles de conception complexes.
▍ Processus de rapport d'erreurs
Ce processus soigneusement conçu et bien planifié existe généralement pour protéger les ressources humaines des organisations. Dès que l'utilisateur rencontre une erreur, il recherche généralement le numéro de téléphone du service client. Ensuite, l'utilisateur est présenté avec un grand menu téléphonique interactif, qui comprend diverses options. Habituellement, il faut environ 2 à 5 minutes pour écouter les informations sur le menu et sélectionner l'option souhaitée. Cette étape vous permet de filtrer les clients les moins persistants.
Ensuite, le client est généralement informé que l'entreprise est confrontée à un «volume d'appels inhabituellement important» et que «le temps d'attente moyen est de 56 minutes». Dans le même temps, ils s'excusent généralement auprès du client pour le dérangement et parlent de la façon dont ils apprécient lui et son entreprise. À cette étape, la plupart des clients décident de ne pas signaler d'erreur. Afin de divertir ceux qui osent encore attendre, ils jouent généralement de la musique inspirante. De plus, on leur propose d'essayer une nouvelle merveilleuse application. Il s'agit de l'application avec laquelle le client a eu un problème.
Une fois la période d'attente de 56 minutes terminée, l'appel est redirigé vers un centre d'appels situé quelque part en Amérique du Nord. Les employés de ces centres d'appels suivent généralement une formation spéciale qui leur permet de parler avec un fort accent indien ou bulgare. L'employé du centre d'appels répond que l'application en question n'entre pas dans le cadre de sa responsabilité, mais il fera volontiers basculer le client vers un autre service.
Après une autre période d'attente, qui dure maintenant 42 minutes, un autre employé du centre d'appels avec des notes de bonheur dans la voix dit au client que l'erreur qu'il a rencontrée est en fait une caractéristique de l'application. Après cela, il est conseillé au client de se référer à la section d'aide de l'application. Si le client continue d'insister sur le fait qu'il a affaire à une erreur, il peut même créer une demande d'assistance. Le client peut même obtenir une réponse - quelque chose dans l'esprit de "La lecture a échoué".
J'espère que vous êtes maintenant convaincu que les erreurs ne sont pas de la préoccupation du programmeur. Les organisations prennent généralement des mesures sérieuses pour protéger les développeurs contre une perte de temps inutile.
Évitez les «erreurs de débutant» lors des entrevues
Si vous cherchez activement du travail - faites un effort pour supprimer toutes les absurdités «fonctionnelles» de votre CV. Sinon, personne ne vous prendra au sérieux. Personne dans le monde réel de l'entreprise ne passe du temps à étudier les jouets pour enfants comme la «composition des fonctions», la «pureté», les «monades» ou l '«immunité». Vous ne voulez guère être comme un étranger. Si vous commencez à parler de telles choses, cela mettra la personne qui vous interviewera mal à l'aise. Et si un représentant d'une entreprise employeur potentielle estime que vous êtes plus intelligent que lui - vos chances d'obtenir un emploi dans cette entreprise auront tendance à être nulles.
Les spécialistes RH, recrutant du personnel technique dans les grandes entreprises, suivent en outre une formation intensive obligatoire. Cela leur permet de distinguer en toute confiance entre les technologies sérieuses - telles que Java et JavaScript.
Assurez-vous que votre CV contient des références à ce qui démontre votre connaissance approfondie de la technologie qui est appréciée par les grandes entreprises. Incluez des mots et des expressions tels que «classe», «héritage», «modèles de conception», «injection de dépendance», «SOLIDE», «usine abstraite» et «singleton».
Lorsque vous êtes invité à résoudre le problème FizzBuzz, qui est souvent proposé lors des entretiens, sur un morceau de papier, vous vous souvenez de la recommandation suivante, à savoir que vous devez être préparé à l'avance pour résoudre ce problème. C'est votre chance de montrer vos connaissances approfondies dans les domaines de la programmation qui sont appréciés dans le monde de l'entreprise. Vous devriez commencer par un projet de solution complet qui implique l'utilisation de modèles de conception et d'autres techniques de POO. Un bon point de départ pour résoudre ce problème peut être
FizzBuzzEnterpriseEdition . De nombreux candidats font la même erreur que celle typique des débutants. Cette erreur réside dans le fait qu'ils s'appuient sur des technologies limitées comme les fonctions. Après cela, il n'y a rien d'étonnant à ce qu'après l'entretien, personne ne les appelle et ne leur écrive.
La programmation fonctionnelle ne peut probablement pas être utilisée pour développer des solutions logicielles sérieuses.
Après avoir considéré les arguments ci-dessus, sérieux et précis, n'importe qui peut maintenant clairement voir que rien de bon ne peut être attendu de l'utilisation de la programmation dite "fonctionnelle". Il est très clair que cette approche de programmation doit être évitée à tout prix.
Beaucoup de bruit a été soulevé autour de la programmation «fonctionnelle» au cours des deux dernières années. Mais la bonne chose est que ce passe-temps à court terme de la communauté des programmeurs est déjà en train de disparaître! Les grands acteurs du marché comme Facebook et Microsoft ont depuis longtemps compris les limites de la programmation fonctionnelle et la supériorité absolue des approches orientées objet pour organiser le code par-dessus. Ils orientent leurs efforts vers une nouvelle génération de langages orientés objet, en particulier - vers
ReasonML et
BosqueOOP . Ces langages portent la mutabilité de l'état de l'application à un tout nouveau niveau et, heureusement, ils ne prennent pas en charge les absurdités fonctionnelles inutiles comme les structures de données immuables.
Résumé: don des dieux
Ici, vous pouvez avoir une question sur les alternatives de la programmation dite "fonctionnelle". Ceci, bien sûr, est une programmation orientée objet. La POO nous est envoyée par le vrai dieu de la programmation. La POO est une force avec laquelle il faut compter. Il s'agit d'un outil capitalisé qui rend les programmeurs productifs. Grâce à la POO, vous et votre équipe serez toujours occupés par les affaires (et vous ne perdrez pas votre emploi).
Voici mon article dans lequel je parle en détail de la POO.
Qu'une force (orientée objet) soit avec vous. Et votre code. Je suis un avec force. Paix à tous.
Comme beaucoup d'entre vous l'ont probablement deviné, il s'agit de matériel satirique. Si vous êtes un programmeur débutant, ne prenez pas tout cela à cœur.
La programmation fonctionnelle est excellente. Passez un peu de temps à explorer ce paradigme de programmation et vous vous retrouverez devant plusieurs de vos coéquipiers.
J'espère que vous étiez aussi intéressé par la lecture que j'écrivais.
Chers lecteurs! Qu'est-ce qui vous déplaît le plus dans la POO?
