L'erreur classique que font les développeurs.

[@LuccDev]

Je suis moyennement d'accord. Je suis d'accord avec le fait qu'il faut être pragmatique, et ne pas "coder pour coder", ou "over-engineer" son code. En revanche, je pense que parfois c'est strictement nécessaire de bien réfléchir à faire du code de qualité: quand on collabore beaucoup, quand le projet est assez complexe pour qu'on s'attarde sur faire la "bonne" structure, quand le projet à des contraintes strictes (sécurité, mémoire, temps réel...) Bref je pense que cette vidéo fonctionne pour les projets classiques où les boilerplates sont déjà là, mais c'est tout. Si les experts se prennent la tête à faire des outils style Rust (qui force certains paradigmes) ou TypeScript (qui "force" l'usage du typage dans un langage qui n'en a pas à la base), ou gofmt (qui force des règles de formatage du code) c'est clairement que le code est important.

[@Mortagus]

Je trouve que le sujet abordé est super important, même si la forme est un peu "rentre-dedans" ^^. Je suis développeur web depuis 10 maintenant, et je suis d'accord : le code n'est pas un but en soit. Seul le résultat final compte. Cela dit, une application à une vie, adopter des bonnes pratiques de programmation et réfléchir à la meilleur façon d'écrire son code peut avoir des impacts non négligeable sur la vie d'une application. Depuis quelque temps, je suis de plus en plus d'accord avec les préceptes mit en avant par les "software crafters". Adopter des bonnes méthodes de travail afin d'avoir une qualité de code optimal est super important non seulement pour limiter les coups de maintenance dans le futur, mais aussi pour prendre soin de la santé mental des développeurs qui s'occupent du projet. Je suis tout à fait d'accord que le syndrome du "le code est tellement pourri qu'on est obligé de repartir de zero" est une très mauvaise idée la plus part du temps, mais d'un autre côté, si on en arrive à de telle extrémités, c'est bien parce que des gens ont négliger leur travail. Loin de moi l'idée de pointer qui que ce soit du doigt, notre métier est très difficile à de multiple niveau. Mais quand même : le code est secondaire, mais s'il est négligé, c'est mal barré au bout d'un moment.

[@TechWithVince]

De mon experience c'est exactement l'inverse qui se passe à chaque fois. Les products managers veulent rusher les features, les dévelopers acceptent, initiallement on a un gain de temps mais sur le long terme ça devient impossible à maintenir Je comprends pas cette tendance à vouloir en faire un métier de singe...

[@Mortagus]

Je suis d'accord avec la remarque, mais je ne suis pas certain que ça soit tout à fait raccord avec le sujet de la vidéo

[@adriyyyy]

Clairement ! Mais coder sans comprendre le but final ou l'utilité de l'utilisateur final, ça fait faire du code beau et propre, mais inadapté au terrain et donc inutile ! On vient souvent me trouver pour des fonctionnalités qui ne sont même pas comprises du demandeur… Alors là, mon enquête commence histoire de bien comprendre le but pour écrire à la fois du code propre et utile !

[@mephisto--]

Hors-sujet malheureusement, un développeur full stack expérimenté ne s'amuse pas à se traiter lui-même de singe :')

[@delioskayzox9658]

Toujours les formats courts et concis c'est super merci pour ça :)

[@ParfaitementWeb]

Merci !

[@friendymulwala]

Je suis nouveau sur cette chaîne KZbin mais j’aime déjà !

[@Learnbynet]

Belle découvert ici ! une super chaine qui traite de la psychologie du développeur ! j'ador J'e m'abonne direct et merci

[@BdeB1000]

vraiment chouette tes vidéos, ça s'applique à tous les languages !

[@felixbertoni]

Le code n'est pas important ... MAIS ... C'est quand même une des bases du logiciel que vous développez. Entre qualité du code et fonctionnalités, il n'y a pas un qui est plus important que l'autre, mais un équilibre à trouver, parce que ces deux aspects d'un logiciel sont dépendants l'un de l'autre. Et cet équilibre peut changer au fil du temps. A noter que par "code", je parle pas seulement du code, mais de l'architecture du logiciel, de sa documentation technique etc. Fonctionnalités > code. C'est plutôt évident. Mieux vaut un logiciel qui marche qu'un logiciel qui marche pas. Donc, rien ne sert d'avoir un code magnifique si votre logiciel ne fonctionne pas ou n'apporte aucune valeur. C'est en particulier vrai dans les débuts d'un logiciel : on veut montrer les fonctionnalités pour avoir des utilisateurs (et ou des clients) rapidement, ou encore pour avoir un retour d'un client si c'est un logiciel sur commande. Code > fonctionnalités. C'est un peu moins évident. Un logiciel qui marche, c'est bien, mais un logiciel qui marche et évolue dans la durée, c'est mieux. La qualité du code peut affecter drastiquement les fonctionnalités. Par exemple, cette abstraction que vous avez pris le temps de faire, il y a quelques mois ou années, dans le coeur de votre application, et qui maintenant vous permet de rajouter une fonctionnalité, demandée par un client, presque sans effort, et sans compromettre le reste du logiciel. C'est vrai sur la durée d'un logiciel : on veut pouvoir modifier et maintenir le logiciel avec le moins d'effort possible. Là dessous, c'est le concept de dette technique : parfois, en gagnant du temps sur le court terme, on baisse la qualité générale du code (la "dette"), et on perds du temps sur le long terme en devant se "battre" avec du code de moins bonne qualité (les "intérets" de la "dette"). Par exemple, si vous avez une fonctionnalité majeure A, et que vous ajoutez une fonctionnalité mineure B, vous avez (on imagine) deux choix : ajouter directement B dans le code de A, c'est le plus rapide, ou prendre le temps de refactorer un peu votre code pour que A et B soient bien séparées. Si vous prenez la première option, alors chaque fois que vous allez modifier A (c'est une fonctionnalité majeure, donc ca risque d'arriver souvent), vous allez devoir aussi traîner le code de B comme un boulet. Ca peut être un détail, mais même si vous y passez 5 minute de plus à chaque fois, à une modification tous les deux jours, en un an vous avez perdu presque 15 heures. Le truc pervers avec la dette technique, c'est que c'est un cercle vicieux. Plus vous laissez s'accumuler des "défauts" dans le code, et plus résoudre les défauts sera coûteux. Donc vous serez "encouragé" à ne pas résoudre les défauts (parce que trop couteux sur le moment), et en ajouter de nouveaux. De la même manière, le refactoring est grandement aidé par les tests automatiques (qui permettent de vérifier qu'on a rien cassé en refactorant), mais les tests automatiques sont plus faciles à mettre en place avec une bonne architecture logicielle, architecture logicielle qui est améliorée par ... le refactoring. D'un autre côté, si on passe trop de temps à refactorer (et a tester et concevoir), on avance pas. Bon, comme je disais plus tôt, c'est un équilibre à trouver. Et en particulier, cet équilibre dépends beaucoup du domaine et de l'ampleur du logiciel développé. Si on développe un site web d'ampleur moyenne, avec des fonctionnalités relativement ciblées, on peu souvent se permettre d'avoir un code d'une qualité moyenne, parce que les techno modernes de dev web permettent une grande flexibilité et une grande robustesse sans effort (en sacrifiant un peu de perfs à l'execution, mais bon c'est pas un soucis). Et en général, c'est même bénéfique d'avoir un code "moyen", parce que les fonctionnalités dépendent pas trop du code. Si on développe une application à haute performance, qu'elle soit web ou non, et donc qu'on est amené à toucher un peu plus le "bas niveau", comme par exemple coder en C++ ou même en langage d'assemblage, ou alors faire des optimisations de base de donnée, on aura beaucoup plus envie d'avoir un code très lisible et parfaitement organisé, parce que le code sera beaucoup plus "complexe", par exemple, avec des effets de bords dans tous les sens, et moins prévisible, du fait des optimisation spécifiques qui sont faites.

[@sofiane90]

En tant qu'étudiant-chercheur en math appli, je ne suis pas d'accord. Je ne code pas uniquement pour obéir à un cahier des charges. Je code dans l'optique d'expérimenter, de découvrir, d'alimenter ma capacité d'abstraction, en toute liberté. L'abstraction ne coûte rien, très souvent, en revanche un manque d'abstraction peut coûter cher, ou réduire drastiquement le champ des possibilités, surtout s'il s'agit d'une librairie/api.

[@joelp5343]

Tellement d'accord avec ce qui est dit ! Surtout à 4 mn de la vidéo !

[@trabrouss]

C’est bien ce que dit mon mentors, le langage de code n’est qu’un outil. Et le plus important c’est de comprendre ce tu fais et savoir ce que tu veux faire. Le client également se fou pas mal du code le plus important pour lui ce que l’application règle son souci.

[@andersonbeauvais267]

J'aime beaucoup tes vidéos bon ton de voix ,un bonne mise en perspective de la carrière de développeur

[@MrMasquime]

Un des moyens d'écrire seulement le code nécessaire est d'essayer d'écrire les tests (automatisés) avant le code :)

[@soubinan]

Point de vue totalement partagé Je pense que je vais même encore plus loin Je ne code jamais une fonctionnalité si je peux l’implémenter sans coder 👨🏾‍💻 (News letter, authentificatition/authorisation, encryption… et j’ai pas fini …)

[@FabskoSD]

Totalement d’accord avec toi, si le monde était ainsi, nous aurions certainement des applications inédites et des idées originaux souvent abandonnées par cette complexité de devoir répondre à des normes de mise en forme alors que ce qui compte au final, qu’importe le chemin emprunter, le résultat compte ! Merci pour cette vidéo

[@andersonbeauvais267]

Oui je suis totalment D'ACCORD AVEC LUI seul le résultat final compte car elle permet de gagner des sous

[@nicovapp28]

Etre bon en dev, c'est savoir faire du bon code et pas du beau code. Faire un fonction alors qu'un autre existe et fait le même taf, je suis d'accord, c'est réinventé la roue. Mais prendre des librairie sur le net via npm ou composer pour faire cette fonction est à mon sens une connerie (je parle d'une simple fonction). Sur npm et composer cela embarque tellement de dépendance, du moins pour certain fonction basic, que finalement ont ce retrouve avec 1 mo de code alors que 10 ko ferais le taf. Le code source a un impact sur le résultat final si il a était bien pensé de base et surtout bien optimisé tous en restant lisible.

[@ghiscode5306]

C'est mon combat de tous les jours. Expliquer à des débutants que le code ne sert à rien tant qu'on a pas compris le problème à résoudre. Hélas certains ne pensent qu'au code et se prennent un mur. Cette vidéo je la partage avec des débutants... Ils comprendront peut être.

[@williammbollombassy1778]

Je suis débutant en code et ce n'est que maintenant que je viens de réaliser cela. Haha 😅

[@ghiscode5306]

@@williammbollombassy1778 ahahah bon courage pour ton apprentissage et surtout faut pas abandonner. Un développeur c'est quelqu'un qui résoud des problèmes. Donc pas de solution, pas de code. C'est également cette capacité qui va te différencier des autres. Quand je sais comment procéder et que je maîtrise pas la syntaxe je peux aisément lire la doc et développer la fonctionnalité. Bon code...

[@lionel449]

Je suis d accord et je vous encourage vraiment j ai une question est t il nécessaire d apprendre les frameworks par exemple php et symfony.

[@JirAWS]

D'accord avec le fond, mais pas d'accord avec la forme :D j'ai mis du temps à comprendre là où tu voulais en venir haha. Par contre clairement yes, besoin > code. Le code permet de créer une solution, mais une solution sans problématique à résoudre... "Tiens je t'ai dis que j'avais inventé une fourchette connectée qui me dit combien de fois je l'ai utilisée ?" -> 0 vente. :D

[@jonathanthomas7231]

"C'est pas du mauvais code, c'est juste du mauvais travail". 👍🏽👍🏽👍🏽😂😂😂

[@soushi8885]

Personnellement, je rends une fonctionnalité fonctionnelle et une foi terminée, je fais un petit "clean up" pour m'assurer de la qualité du code, mais je n'abuse pas non plus. C'est seulement si le besoin de refactorisation ou d'optimisation est explicite que là on se met à travailler sur le code pour le code sans forcément penser à livrer une fonctionnalité. J'imagine que c'est avant tout une question de communication au sein de l'équipe pour savoir quelles sont les priorités et besoins pour bien s'enligner sur le futur développement de l'application !

[@ChristopheLefevre]

A quel point je suis d'accord avec toi. Etant passé d'un département web à un département IT, je n'ai jamais réussi à comprendre la logique d'imaginer une application comme une base de données, l'obsession de découper une application en 3 couches, lorsque ça n'apporte rien à l'expérience utilisateur et la création de tables de relations inutiles parce que c'est la bonne pratique. Quand je voyais que le simple ajout d'un champ dans un formulaire pouvait nécessiter la modification de 3 applications, la création d'un projet, avec phase de validation, etc, et donc faire appel à toute une équipe, j'avais envie de pleurer .

[@felixbertoni]

Je vais essayer de vous apporter quelques éléments vis à vis des points que vous soulevez : - "imaginer une application comme une base de données". Le formalisme des bases de données relationnelles est facile à modéliser mathématiquement, étant donné qu'il s'appuie directement sur le modèle relationnel. Donc ça rends très simple certaines transformations et vérifications du modèle. - "Découper une application en 3 couches". Le principe est de séparer l'application en sous parties, et de les découpler par une abstraction entre chaque couche, pour rendre les modifications et la maintenance plus facile. C'est une assignation des responsabilités. En général on a les données (stockage), le traitement (code métier) et la présentation (interface utilisateur). Par exemple, si le traitement et la présentation sont bien découplées, on peut modifier complètement la présentation, et donc le style de l'application, sans se soucier de comment les données sont traitées. Ca permet aussi de proposer plusieurs interfaces différentes pour une même application. A noter que c'est pas la seule architecture possible pour un logiciel, mais elle a le mérite d'être extrêmement simple, et particulièrement naturelle pour le web client/serveur/base de données. - "création de tables de relations inutiles parce que c'est la bonne pratique" Parfois des tables de relation supplémentaires peuvent être nécessaires pour normaliser les bases de données, ou encore pour des optimisations. A noter une chose : ce qui est bon est parfois très mal implémenté ou mal utilisé. Rien ne sert de modéliser une application qui convertis des PNG en PDF en local comme une base de données. Une application en 3 couches avec une mauvaise abstraction entre les couches peut être contre productive. Des tables inutiles peuvent exister en cas de mauvaise conception de la base de données. Et souvent, quand il y a des problèmes au niveau architectural, c'est justement parce que les développeurs (ou plutôt les managers/product owners/...) ont voulu aller trop vite, et on négligé la conception et la qualité interne du logiciel.

[@b4st13n5]

L'utilisateur ne va pas regarder le code mais il va quand même hurler si la page web met 5 secondes a charger parce que le développeur ne sait pas coder un minimum de performance. Le code est pas important, les principes de programmations oui tout même.

[@DanielGohou]

comment ne plus se tromper sur l'identation

[@cyrilgallego2258]

J’adore tes vidéo!!! Merci!!!

[@ParfaitementWeb]

Avec plaisir et merci !

[@martinfeuillet2418]

Par contre le thème light depuis 15 ans t'es pas aveugle ?

[@ParfaitementWeb]

Haha. J'en ai fait une vidéo 😄 : kzbin.info/www/bejne/pYenk6huoc2kd6M

[@Shmolitz]

Je suis assez d'accord avec toi, L'important c'est le résultat ! A ce propos, que penses-tu du framework Django? Il est connu justement pour aller droit au but et d'avoir un résultat propre rapidement.

[@ParfaitementWeb]

Salut ! J'ai envie de répondre anecdotiquement, de façon humoristique, que le code (et donc le framework) n'est pas important ;) Plus sérieusement, choisir Django pour du Python, c'est la valeur sûre, y'a pas de crainte à avoir.

[@dutiona]

Le message est un peu flou. Il est vrai que le meilleur code est celui qui n'est jamais écrit, pour une raison simple, moins de code = moins de bug. Et le meilleur moyen d'améliorer les perfs est d'avoir une logique de code bien pensée plutôt que de faire de l'early optim (donc logique plutôt que du code). Mais c'est faux de dire que le code n'est pas important dans notre sociétés actuelle, avec les enjeux actuels. Je m'explique : nos machines sont infiniment plus puissantes aujourd'hui qu'elles ne l'étaient il y a 20-30 ans, pourtant nos programmes sont lents comme la mort, les pages internet sont lourdent, on a besoin d'une RAM de foux furieux pour faire tourner des trucs qui tournaient très bien à l'époque avec un P2 166Mz/ 64Mo de RAM. Pourquoi ? Parce-qu’une très grande partie du code poussée en prod par les applis "modernes" fournis des perfs catastrophiques. Et c'est toujours pour la même raison : il faut livrer, tan pis pour les perfs, on verra plus tard, on n'a pas le temps. He ben j'aimerai bien qu'on commence à quantifier l'impact sur le réchauffement climatique du code de merde. Ca serait vraiment intéressant. Je me souviens d'un talk Alexandrescu qui expliquait comment il avait réussi à optimiser de 1% les perfs de "facebook::string" en C++ et l'impact que ca a en vrai. 1% sur une feature core c'est des milions d'euros d'économies sur le cloud au vu du volume de données traitées. Au final, le code n'est pas forcément important au début, pour un prototype. Il le devient pour la mise en prod. Et ignorer ce fait c'est de l'amateurisme.

[@theworldismonde6588]

merci beaucoup vraiment bien !

[@ParfaitementWeb]

Ravi de lire tes encouragements. Merci !

[@ghostsngoblins6894]

Je dirais même que coder n"est pas un art, seul le résultat peut être une œuvre. 🍓

[@svenlee6262]

J'ai un bon exemple qui prouve que le code n'est pas important. Où je travaille on fait de la quantité au lieu de la qualité. On est toujours sur Java 7 avec Tomcat 6, le code est "enrichit" depuis 15 ans par des devs différents, il est devenu imbuvable, on a des classes de +20'000 lignes et +400 tables dans notre db (30% inutilisées). Mais on a un max de clients et on fait un max de blés....

[@betrouni_]

Bonjour quand tu dis que tu est gérant d'une agence de dev web tu veux dire que tu as des employés ? On a beaucoup de développeurs web sur youtube mais aucun contenu sur la gestion d'une entreprise dans le web ça pourrait être intéréssant Très bonne vidéo au passage

[@ParfaitementWeb]

Merci 😊 J'y pensais à ce type de contenu en me demandant s'il y avait une demande sur KZbin, je note !

[@antop60610]

@@ParfaitementWeb carrement.

[@graphiste]

Je m'abonne direct !

[@ParfaitementWeb]

Bienvenue !

[@Zarinoow]

J'ai les 3 cas (bon moi je suis dev java (pas js), mais bon, j'ai déjà eu les 3 cas de figure)

[@sparttan21]

Faire du code overkill alors que le besoin c'est 10% de ce qu'on a codé est typiquement le genre de truc que je trouve absurde. "Oui mais ça couvre plus de possibilité". Ouais bah on fera ça quand le besoin sera exprimé. Aujourd'hui on en a pas besoin inutile de coder une formule1 quand le besoin est un vélo.

[@jeanphi.g]

Le problème c'est la confusion trop souvent faite entre "code" et "algorithme" 🙄

[@Yrtiop]

Je suis absolument pas d'accord, si votre code fonctionne mais ressemble à rien vous (ou les autres devs qui passeront dessus) allez vous casser les dents dessus dès qu'il va falloir faire évoluer un truc. Bien évidement que le client s'en bat les couilles de votre code, sauf que quand 1 an plus tard vous allez perdre une journée pour le modifier alors que ça aurait pu prendre 1h avec un code mieux foutu vous allez être perdant. Et plus le projet est gros plus c'est important. Et puis l'optimisation ça peut être crucial dans certains cas, il m'est parfois arrivé de faire un bout de code à l'arrache qui tourne très bien en dev quand il y a peu de données mais qui va ramer à mort en prod. Et pour les librairies pareil ça dépend du contexte, parfois il est pas nécessaire d'utiliser un char d'assaut pour écraser un moustique, si on peut faire une fonction de 4 lignes plutôt qu'utiliser une librairie énorme pour faire la même chose autant faire ses 4 lignes de code.

[@lunique_rudd]

Là est probablement tout l'intérêt du paradigme fonctionnel : on se concentre sur la fonctionnalité, pas sur comment l'implanter.

[@baptistem4377]

Pour ce qui est de développer son propre truc alors qu'un package open source existe déjà : ouaip c'est mieux d'utiliser un truc déjà fait, quitte à être dépendant du fournisseur, cependant si ledit package est un enfer à utiliser, mieux vaut tenter de le recoder soi même je pense. Petit exemple personnel, on a passé littéralement deux jours à vouloir faire fonctionner une gem dans notre application rails, et à un moment on a dit "fuck it", on a développé un code qui faisait exactement ce que la gem promettait, le tout en... 2h. Je suis bien conscient que dans 99,9% des cas, utiliser un truc tout prêt, ne pas réinventer la roue, tout ça, c'est la base, mais je voulais juste rappeller ces 0.1% qui existent quand même et qui peuvent rendre fou x)

[@LivingDeadApocalypse]

alors d'abord l'erreur classique de confondre "programmeur" et "développeur"...

[@pierrekilgoretrout3143]

Chaque ligne de code est un bug potentiel, donc au moins il y a de lignes de code, au mieux

[@guepion]

mdr mon code c le bazar h24 je crois que j'ai été touché par la flemme

[@vieilatome2257]

Moi c'est juste parce-que mon code est à source ouverte et que j'ai vraiment peur de me taper la honte si quelqu'un le voit :P

[@noahsarcana]

Un code source est comme une bâtisse, plus c'est gros, plus faut des fondations solides

[@Adamy-69]

Il n’est d’autant pas important d’autant qu’il est tout le temps réécrit … évolution oblige : qui se sert aujourd’hui d’un logiciel qui a été écrit et compilé il y a 5 ans ?

[@latortura42]

Génial le code est pas important, comme ça on apelle un developpeur qui répare les conneries de l'ancien developpeur.

[@albertnowak7512]

Bons filmes.

[@daz74000]

Cela se voit que tu n as jamais étudié le génie logiciel. Le coût de la maintenance et de l évolution d un logiciel ou site est le plus important et est étroitement lié à la qualité du code