Quelle est votre opinion sur la programmation la plus controversée?

C'est certainement subjectif, mais j'aimerais essayer d'éviter qu'il devienne argumentatif. Je pense que cela pourrait être une question intéressante si les gens la traitent de manière appropriée.

L'idée de cette question est venue du fil de commentaires de ma réponse au "Quelles sont les cinq choses que vous détestez à propos de votre langue préférée?" question . J'ai soutenu que les classes en C # devraient être scellées par défaut - je ne mettrai pas mon raisonnement dans la question, mais je pourrais écrire une explication plus complète en réponse à cette question. J'ai été surpris par la chaleur de la discussion dans les commentaires (25 commentaires actuellement).

Alors, quelles opinions litigieuses avez - vous ? Je préfère éviter le genre de choses qui finissent par être assez religieuses avec relativement peu de base (par exemple, le positionnement d'un appareil orthopédique), mais des exemples peuvent inclure des choses comme "les tests unitaires ne sont pas vraiment très utiles" ou "les champs publics sont vraiment corrects". L'important (pour moi, en tout cas) est que vous avez des raisons derrière vos opinions.

Veuillez présenter votre opinion et votre raisonnement - j'encourage les gens à voter pour des opinions bien argumentées et intéressantes, que vous soyez ou non d'accord avec elles.

Les programmeurs qui ne codent pas pendant leur temps libre pour s'amuser ne deviendront jamais aussi bons que ceux qui le font.

Je pense que même les personnes les plus intelligentes et les plus talentueuses ne deviendront jamais de véritables programmeurs à moins de les traiter comme plus qu'un travail. Cela signifie qu'ils font de petits projets à côté, ou tout simplement jouer avec beaucoup de langues et d'idées différentes dans leur temps libre.

(Remarque: je ne dis pas que les bons programmeurs ne font rien d'autre que de programmer, mais ils font plus que programmer de 9 à 5)

La seule «meilleure pratique» que vous devriez utiliser tout le temps est «Utilisez votre cerveau».

Trop de gens sautent sur trop de fourgons et essaient d'imposer des méthodes, des modèles, des cadres, etc. à des choses qui ne les justifient pas. Ce n'est pas parce que quelque chose est nouveau ou parce qu'une personne respectée a une opinion que ça va à tout le monde :)

EDIT: Juste pour clarifier - je ne pense pas que les gens devraient ignorer les meilleures pratiques, les opinions valorisées, etc. fais, et QUELS avantages / inconvénients cela apporte-t-il?

"Googler", ça va!

Oui, je sais que cela choque certaines personnes que leurs années de mémorisation intense et / ou de piles glorieuses de livres de programmation commencent à tomber au bord d'une ressource à laquelle tout le monde peut accéder en quelques secondes, mais vous ne devriez pas le reprocher aux gens qui l'utilisent.

Trop souvent, j'entends googler des réponses à des problèmes résultant de critiques, et c'est vraiment insensé. Tout d'abord, il faut admettre que tout le monde a besoin de matériel de référence. Vous ne savez pas tout et vous devrez rechercher les choses. En concédant cela, est-ce vraiment important d'où vous avez obtenu l'information? Est-il important que vous le cherchiez dans un livre, que vous le cherchiez sur Google ou que vous l'entendiez d'une grenouille parlante que vous avez hallucinée? Non. Une bonne réponse est une bonne réponse.

Ce qui est important, c'est que vous compreniez le matériel, l'utilisiez comme le moyen de mettre fin à une solution de programmation réussie et que le client / votre employeur soit satisfait des résultats.

(bien que si vous obtenez des réponses de grenouilles hallucinantes, vous devriez probablement obtenir de l'aide tout de même)

La plupart des commentaires dans le code sont en fait une forme pernicieuse de duplication de code.

Nous passons la plupart de notre temps à maintenir le code écrit par d'autres (ou nous-mêmes) et les commentaires pauvres, incorrects, obsolètes et trompeurs doivent figurer en haut de la liste des artefacts les plus ennuyeux du code.

Je pense que finalement beaucoup de gens les effacent, en particulier ces monstruosités de bac à fleurs.

Il vaut mieux se concentrer sur la lisibilité du code, la refactorisation si nécessaire et la minimisation des idiomes et des excentricités.

D'un autre côté, de nombreux cours enseignent que les commentaires sont très presque plus importants que le code lui-même, ce qui conduit à la ligne suivante ajoute un style de commentaire factureTotal .

XML est très surfait

Je pense que trop de gens sautent dans le train XML avant d'utiliser leur cerveau ... XML pour le Web est génial, car il est conçu pour cela. Sinon, je pense que certaines définitions de problèmes et pensées de conception devraient devancer toute décision de les utiliser.

Mes 5 cents

Tous les programmeurs ne sont pas créés égaux

Très souvent, les gestionnaires pensent que DeveloperA == DeveloperB simplement parce qu'ils ont le même niveau d'expérience, etc. En réalité, les performances d'un développeur peuvent être 10x voire 100x celles d'un autre.

Il est politiquement risqué d'en parler, mais j'ai parfois envie de souligner que, même si plusieurs membres de l'équipe peuvent sembler de compétence égale, ce n'est pas toujours le cas. J'ai même vu des cas où les développeurs principaux étaient `` au-delà de tout espoir '' et les développeurs juniors ont fait tout le travail réel - je me suis toutefois assuré qu'ils obtiennent le crédit. :)

Je n'arrive pas à comprendre pourquoi les gens pensent que Java est absolument le meilleur "premier" langage de programmation à enseigner dans les universités.

D'une part, je crois que le premier langage de programmation devrait être tel qu'il souligne la nécessité d'apprendre le flux de contrôle et les variables, pas les objets et la syntaxe

D'autre part, je pense que les gens qui n'ont pas d'expérience dans le débogage des fuites de mémoire en C / C ++ ne peuvent pas pleinement apprécier ce que Java apporte à la table.

De plus, la progression naturelle devrait être de "comment puis-je faire ceci" à "comment puis-je trouver la bibliothèque qui fait cela" et non l'inverse.

Si vous ne connaissez qu'une seule langue, quelle que soit votre connaissance, vous n'êtes pas un excellent programmeur.

Il semble y avoir une attitude qui dit qu'une fois que vous êtes vraiment bon en C # ou en Java ou dans tout autre langage que vous avez commencé à apprendre, c'est tout ce dont vous avez besoin. Je ne le crois pas - chaque langue que j'ai jamais apprise m'a appris quelque chose de nouveau sur la programmation que j'ai pu réintroduire dans mon travail avec toutes les autres. Je pense que quiconque se restreint à une seule langue ne sera jamais aussi bon qu'il pourrait l'être.

Cela m'indique également un certain manque de rigueur et de volonté d'expérimenter qui ne correspond pas nécessairement aux qualités que je m'attendrais à trouver chez un très bon programmeur.

Performance ne importe.

Les instructions d'impression sont un moyen valide de déboguer le code

Je pense qu'il est tout à fait correct de déboguer votre code en le salissant System.out.println(ou tout autre document imprimé qui fonctionne pour votre langue). Souvent, cela peut être plus rapide que le débogage, et vous pouvez comparer les sorties imprimées avec d'autres exécutions de l'application.

Assurez-vous simplement de supprimer les instructions d'impression lorsque vous passez en production (ou mieux, transformez-les en instructions de journalisation)

Votre travail consiste à vous mettre au chômage.

Lorsque vous écrivez un logiciel pour votre employeur, tout logiciel que vous créez doit être écrit de telle manière qu'il puisse être récupéré par n'importe quel développeur et compris avec un minimum d'effort. Il est bien conçu, rédigé de manière claire et cohérente, formaté proprement, documenté là où il doit être, construit quotidiennement comme prévu, archivé dans le référentiel et correctement versionné.

Si vous êtes frappé par un bus, mis à pied, licencié ou quittez le travail, votre employeur devrait être en mesure de vous remplacer à tout moment, et le gars suivant pourrait entrer dans votre rôle, prendre votre code et être debout et en cours d'exécution dans les hauts d'une semaine. S'il ne peut pas faire cela, alors vous avez lamentablement échoué.

Fait intéressant, j'ai constaté que cet objectif m'a rendu plus précieux pour mes employeurs. Plus je m'efforce d'être jetable, plus je deviens précieux pour eux.

1) La farce Business Apps :

Je pense que tout ce qui concerne les frameworks "Enterprise" est de la fumée et des miroirs. J2EE, .NET, la majorité des frameworks Apache et la plupart des abstractions pour gérer de telles choses créent beaucoup plus de complexité qu'ils n'en résolvent.

Prenez n'importe quel ORM Java ou .NET normal, ou n'importe quel framework MVC supposé moderne pour l'un ou l'autre qui fait de la «magie» pour résoudre des tâches fastidieuses et simples. Vous finissez par écrire d'énormes quantités de laid XML XML qui sont difficiles à valider et à écrire rapidement. Vous avez des API massives où la moitié d'entre elles consistent simplement à intégrer le travail des autres API, des interfaces impossibles à recycler et des classes abstraites qui ne sont nécessaires que pour surmonter l'inflexibilité de Java et C #. Nous n'avons tout simplement pas besoin de la plupart de cela.

Que diriez-vous de tous les différents serveurs d'applications avec leur propre syntaxe de descripteur reproché, la base de données trop complexe et les produits de collecticiel?

Le point n'est pas cette complexité == mauvaise, c'est cette complexité inutile == mauvaise. J'ai travaillé dans des installations d'entreprise massives où certaines d'entre elles étaient nécessaires, mais même dans la plupart des cas, quelques scripts maison et une simple interface Web suffisent pour résoudre la plupart des cas d'utilisation.

J'essaierais de remplacer toutes ces applications d'entreprise par des cadres Web simples, des bases de données open source et des constructions de programmation triviales.

2) Les n années d'expérience requises:

À moins que vous n'ayez besoin d'un consultant ou d'un technicien pour gérer un problème spécifique lié à une application, une API ou un framework, alors vous n'avez pas vraiment besoin de quelqu'un avec 5 ans d'expérience dans cette application. Ce dont vous avez besoin, c'est d'un développeur / administrateur qui peut lire la documentation, qui possède des connaissances de domaine dans tout ce que vous faites et qui peut apprendre rapidement. Si vous avez besoin de développer dans une sorte de langage, un développeur décent le prendra en moins de 2 mois. Si vous avez besoin d'un administrateur pour le serveur Web X, en deux jours, il devrait avoir lu les pages de manuel et les groupes de discussion et être à jour. Rien de moins et cette personne ne vaut pas son salaire.

3) Le cursus commun "informatique":

La majorité des diplômes en informatique et en génie logiciel sont des taureaux. Si votre premier langage de programmation est Java ou C #, alors vous faites quelque chose de mal. Si vous n'obtenez pas plusieurs cours d'algèbre et de mathématiques, c'est faux. Si vous ne vous plongez pas dans la programmation fonctionnelle, elle est incomplète. Si vous ne pouvez pas appliquer des invariants de boucle à une boucle triviale pour, vous ne valez pas votre sel en tant que supposé informaticien. Si vous sortez avec une expérience dans les langages x et y et l'orientation des objets, c'est plein de s ***. Un véritable informaticien voit un langage en termes de concepts et de syntaxes qu'il utilise, et voit les méthodologies de programmation comme une parmi d'autres, et a une si bonne compréhension des philosophies sous-jacentes des deux que le choix de nouveaux langages, méthodes de conception ou langages de spécification devrait être trivial.

Les Getters et Setters sont très surutilisés

J'ai vu des millions de personnes affirmer que les champs publics sont mauvais, alors ils les rendent privés et fournissent des getters et des setters pour chacun d'eux. Je crois que cela est presque identique à rendre les champs publics, peut-être un peu différent si vous utilisez des threads (mais ce n'est généralement pas le cas) ou si vos accesseurs ont une logique métier / présentation (quelque chose 'd'étrange' au moins).

Je ne suis pas en faveur des domaines publics, mais contre la création d'un getter / setter (ou d'une propriété) pour chacun d'entre eux, puis de prétendre que faire cela est de l' encapsulation ou de la dissimulation d'informations ... ha!

MISE À JOUR:

Cette réponse a soulevé une certaine controverse dans ses commentaires, je vais donc essayer de la clarifier un peu (je laisserai l'original intact car c'est ce que beaucoup de gens ont voté).

Tout d'abord: toute personne qui utilise les champs publics mérite une peine de prison

Maintenant, créer des champs privés puis utiliser l'IDE pour générer automatiquement des getters et des setters pour chacun d'eux est presque aussi mauvais que d'utiliser des champs publics.

Beaucoup de gens pensent:

private fields + public accessors == encapsulation

Je dis que la génération (automatique ou non) d'une paire getter / setter pour vos champs va effectivement à l'encontre de la soi-disant encapsulation que vous essayez de réaliser.

Enfin, permettez-moi de citer Oncle Bob dans ce sujet (extrait du chapitre 6 de "Clean Code"):

Il y a une raison pour laquelle nous gardons nos variables privées. Nous ne voulons pas que quelqu'un d'autre dépende d'eux. Nous voulons la liberté de changer leur type ou leur mise en œuvre sur un coup de tête ou une impulsion. Pourquoi, alors, tant de programmeurs ajoutent-ils automatiquement des getters et des setters à leurs objets, exposant leurs champs privés comme s'ils étaient publics?

Les diagrammes UML sont très surévalués

Bien sûr, il existe des diagrammes utiles, par exemple un diagramme de classes pour le modèle composite , mais de nombreux diagrammes UML n'ont absolument aucune valeur.

Opinion: SQL est du code. Traitez-le comme tel

Autrement dit, tout comme votre langage C #, Java ou tout autre langage objet / procédure préféré, développez un style de mise en forme qui est lisible et maintenable.

Je déteste quand je vois du code SQL au format libre bâclé. Si vous criez lorsque vous voyez les deux styles d'accolades sur une page, pourquoi ou pourquoi ne criez-vous pas lorsque vous voyez du SQL formaté gratuit ou du SQL qui obscurcit ou obscurcit la condition JOIN?

La lisibilité est l'aspect le plus important de votre code.

Encore plus que l'exactitude. S'il est lisible, il est facile à corriger. C'est aussi facile à optimiser, facile à changer, facile à comprendre. Et j'espère que d'autres développeurs pourront également en tirer des leçons.

Si vous êtes développeur, vous devriez pouvoir écrire du code

J'ai fait pas mal d'entretiens l'an dernier, et pour ma part, j'étais censé tester la façon dont les gens pensaient et comment ils mettaient en œuvre des algorithmes simples à modérés sur un tableau blanc. J'avais d'abord commencé avec des questions comme:

Étant donné que Pi peut être estimé en utilisant la fonction 4 * (1 - 1/3 + 1/5 - 1/7 + ...) avec plus de termes donnant une plus grande précision, écrivez une fonction qui calcule Pi avec une précision de 5 décimales .

C'est un problème qui devrait vous faire réfléchir, mais ne devrait pas être hors de portée d'un développeur expérimenté (il peut être répondu dans environ 10 lignes de C #). Cependant, beaucoup de nos candidats (prétendument présélectionnés par l'agence) n'ont même pas pu commencer à y répondre, ni même expliquer comment ils pourraient s'y prendre pour y répondre. Donc, après un certain temps, j'ai commencé à poser des questions plus simples comme:

Étant donné que l'aire d'un cercle est donnée par Pi fois le rayon au carré, écrivez une fonction pour calculer l'aire d'un cercle.

Étonnamment, plus de la moitié des candidats ne pouvaient pas écrire cette fonction dans toute langue (je peux lire les langues les plus populaires, je les laisse donc utiliser la langue de leur choix, y compris le pseudo-code). Nous avions des "développeurs C #" qui ne pouvaient pas écrire cette fonction en C #.

J'ai été surpris par cela. J'avais toujours pensé que les développeurs devraient pouvoir écrire du code. Il semble que, de nos jours, il s'agit d'une opinion controversée. C'est certainement parmi les candidats aux entrevues!

Éditer:

Il y a beaucoup de discussions dans les commentaires pour savoir si la première question est bonne ou mauvaise, et si vous devez poser des questions aussi complexes que cela dans une interview. Je ne vais pas m'attarder là-dessus (c'est une toute nouvelle question) à part pour dire que vous manquez largement le but du message .

Oui, j'ai dit que les gens ne pouvaient pas faire de progrès avec cela, mais la deuxième question est triviale et beaucoup de gens ne pouvaient pas faire de progrès non plus! Quiconque s'appelle développeur doit pouvoir écrire la réponse à la seconde en quelques secondes sans même y penser. Et beaucoup ne le peuvent pas.

L'utilisation de la notation hongroise devrait être punie de mort.

Cela devrait être assez controversé;)

Les modèles de conception nuisent plus à une bonne conception qu’ils ne l’aident.

La conception de logiciels de l'OMI, en particulier une bonne conception de logiciels, est beaucoup trop variée pour être capturée de manière significative dans les modèles, en particulier dans le petit nombre de modèles dont les gens peuvent réellement se souvenir - et ils sont beaucoup trop abstraits pour que les gens se souviennent vraiment de plus d'une poignée. Ils n'aident donc pas beaucoup.

Et d'un autre côté, beaucoup trop de gens deviennent amoureux du concept et essaient d'appliquer des modèles partout - généralement, dans le code résultant, vous ne pouvez pas trouver la conception réelle entre tous les singletons et les usines abstraites (complètement dénués de sens).

Moins de code vaut mieux que plus!

Si les utilisateurs disent «c'est tout?» Et que votre travail reste invisible, c'est bien fait. La gloire peut être trouvée ailleurs.

PHP craint ;-)

La preuve est dans le pudding.

Les tests unitaires ne vous aideront pas à écrire du bon code

La seule raison d'avoir des tests unitaires est de s'assurer que le code qui fonctionne déjà ne se casse pas. Écrire des tests en premier ou écrire du code dans les tests est ridicule. Si vous écrivez aux tests avant le code, vous ne saurez même pas quels sont les cas marginaux. Vous pourriez avoir du code qui réussit les tests mais échoue toujours dans des circonstances imprévues.

De plus, les bons développeurs maintiendront une faible cohésion, ce qui rendra l'ajout de nouveau code peu susceptible de causer des problèmes avec les choses existantes.

En fait, je vais généraliser encore plus,

La plupart des «meilleures pratiques» en génie logiciel sont là pour empêcher les mauvais programmeurs de faire trop de dégâts .

Ils sont là pour tenir les mauvais développeurs et les empêcher de faire des erreurs stupides. Bien sûr, puisque la plupart des développeurs sont mauvais, c'est une bonne chose, mais les bons développeurs devraient obtenir un laissez-passer.

Écrivez de petites méthodes. Il semble que les programmeurs aiment écrire des méthodes loooong où ils font plusieurs choses différentes.

Je pense qu'une méthode devrait être créée partout où vous pouvez en nommer une.

C'est ok d'écrire du code poubelle de temps en temps

Parfois, un morceau de code poubelle rapide et sale est tout ce qui est nécessaire pour accomplir une tâche particulière. Patterns, ORM, SRP, peu importe ... Lancez une console ou une application Web, écrivez du sql en ligne (vous vous sentez bien) et éliminez l'exigence.

Code == Conception

Je ne suis pas fan des diagrammes UML sophistiqués et de la documentation de code sans fin. Dans un langage de haut niveau, votre code doit être lisible et compréhensible tel quel. La documentation et les diagrammes complexes ne sont pas vraiment plus conviviaux.

Voici un article sur le thème du code en tant que conception .

Le développement de logiciels n'est qu'un travail

Ne vous méprenez pas, j'aime beaucoup le développement de logiciels. J'ai écrit un blog ces dernières années sur le sujet. J'ai passé assez de temps ici pour avoir> 5000 points de réputation. Et je travaille dans une start-up qui fait généralement 60 heures par semaine pour beaucoup moins d'argent que je pourrais obtenir en tant qu'entrepreneur parce que l'équipe est fantastique et le travail est intéressant.

Mais dans le grand schéma des choses, c'est juste un travail.

Il se classe en importance en dessous de beaucoup de choses comme la famille, ma petite amie, les amis, le bonheur, etc.

Je pense que parfois beaucoup de développeurs oublient que le développement est juste quelque chose qui nous permet d'avoir les choses les plus importantes dans la vie (et de les avoir en faisant quelque chose que nous apprécions) plutôt que d'être le but final en soi.

Je pense aussi qu'il n'y a rien de mal à avoir des binaires dans le contrôle de source .. s'il y a une bonne raison à cela. Si j'ai un assemblage dont je n'ai pas la source et que je ne suis pas nécessairement au même endroit sur chaque machine de développement, je le collerai généralement dans un répertoire "binaires" et le référencerai dans un projet en utilisant un chemin relatif .

Beaucoup de gens semblent penser que je devrais être brûlé sur le bûcher pour avoir même mentionné «contrôle de source» et «binaire» dans la même phrase. Je connais même des endroits qui ont des règles strictes disant que vous ne pouvez pas les ajouter.

Chaque développeur doit être familier avec l'architecture de base des ordinateurs modernes. Cela s'applique également aux développeurs qui ciblent une machine virtuelle (peut-être plus encore, car on leur a dit à maintes reprises qu'ils n'avaient pas besoin de s'inquiéter de la gestion de la mémoire, etc.)

Les architectes / concepteurs de logiciels sont surévalués

En tant que développeur, je déteste l'idée des architectes logiciels. Ce sont essentiellement des gens qui ne codent plus à plein temps, lisent des magazines et des articles, puis vous expliquent comment concevoir des logiciels. Seules les personnes qui écrivent des logiciels à plein temps pour gagner leur vie devraient le faire. Peu m'importe si vous étiez le meilleur codeur du monde il y a 5 ans avant de devenir architecte, votre avis m'est inutile.

Comment est-ce controversé?

Modifier (pour clarifier): Je pense que la plupart des architectes logiciels sont d'excellents analystes commerciaux (parler avec les clients, rédiger des exigences, des tests, etc.), je pense simplement qu'ils n'ont pas leur place dans la conception de logiciels, de haut niveau ou autrement.

Il n'y a pas d'approche unique pour le développement

Je suis surpris que ce soit une opinion controversée, car cela me semble être du bon sens. Cependant, il existe de nombreuses entrées sur des blogs populaires faisant la promotion de l'approche du développement "taille unique", donc je pense que je suis peut-être en minorité.

Les choses que j'ai vues être présentées comme l' approche correcte pour tout projet - avant que toute information ne soit connue à ce sujet - sont des choses comme l'utilisation de Test Driven Development (TDD), Domain Driven Design (DDD), Object-Relational Mapping (ORM) , Agile (majuscule A), Orientation Objet (OO), etc. etc. englobant tout, des méthodologies aux architectures en passant par les composants. Le tout avec de beaux acronymes commercialisables, bien sûr.

Les gens semblent même aller jusqu'à mettre des badges sur leurs blogs tels que "I'm Test Driven" ou similaire, comme si leur stricte adhésion à une approche unique quels que soient les détails du projet était vraiment une bonne chose .

Ça ne l'est pas.

Le choix des méthodologies, architectures et composants appropriés, etc., doit être fait au cas par cas et dépend non seulement du type de projet sur lequel vous travaillez et de ses exigences uniques, mais également de la taille et des capacités de l'équipe avec laquelle vous travaillez.