Pour être strict ou pragmatique?

Je commence à réaliser que le développement de logiciels est (entre autres) un processus consistant à se poser constamment des questions. Questions concernant la qualité du code, la séparation des préoccupations, la minimisation des dépendances, ...

Mais la question principale est: jusqu'où pouvez-vous aller sans vous retrouver dans un hôpital psychiatrique?

Je postule pour un nouvel emploi. Hier, j'étais avec un éventuel futur employeur qui voulait tester mes capacités de programmation. L'un des exercices était: expliquer ce que fait ce code. J'ai parcouru le code de l'application (winforms sur vb.net) qu'ils développent (c'est une application administrative pour un hôpital). Cela m'a donné l'occasion de voir comment ils abordent les choses et c'était plutôt décevant.

Quelques exemples:

• J'ai vu quelque part: Appeler [insérer le nom du sous-programme ici] -> J'ai été frappé: n'est-ce pas quelque chose de VB6?
• Ils ont une couche de données distincte, utilisant ado.net, mais une méthode que j'ai dû examiner renvoie un ensemble de données à la couche appelante. Donc, datalayer séparé ou non, l'application est liée à ado.net (qui pourrait également ne jamais être un problème si elle ne passe jamais à une autre approche d'accès aux données).
• Cet ensemble de données est lu tel quel, il s'agit donc toujours d'une approche centrée sur les données (bien sûr, on peut discuter de la quantité de logique / comportement que vous pouvez mettre dans des classes comme "Patient" ou "LabAnalysisRequest".
• Je pense également avoir vu la construction d'une requête SQL par concaténation de chaînes.
• Ils utilisent des procédures stockées (ce qui, pour moi, signifie: dispersion de la logique)
• aucune mention des vues / contrôleurs: tout est axé sur la forme
• La chose la plus moche que j'ai vue était:

      Si TestEnvironment.IsTesting alors
         someVar = [une valeur codée en dur]
      autre
         someVar = [une valeur récupérée dynamiquement]
      fin si
      [reste de la fonction ici]
  

Tout est tellement différent de ce que j'ai appris à l'école: couche de domaine (agnostique de persistance), couche de persistance, couche de présentation, tests unitaires, ...

Je reformule donc ma question: à quel point doit-on être fondamental ou dogmatique? Dans quelle mesure un programmeur doit-il s'en tenir à ses principes ou simplement écrire du code qui fait le travail?

Je sais que cela ne répond pas directement à votre question, mais je pense toujours que cela vaut plus qu'un commentaire:

Lorsque vous faites un entretien d'embauche, vous les interviewez autant qu'ils vous interviewent . Brisez l'habitude de voir une entrevue comme quelque chose que vous rampez sur votre ventre en les suppliant de vous offrir quelque chose. Ils vous extraient, mais vous les extrayez également. S'ils ne vous aiment pas, ils ne vous embaucheront pas. Si vous ne les aimez pas, n'allez pas y travailler.

Oui, dans l'industrie, avec une base de code héritée de dix ans qui a été piratée au fil du temps par trois douzaines de développeurs avec des antécédents, des compétences et une passion différents, motivés par des délais serrés, un manque de ressources et des contraintes financières, le code ne sera jamais regardez de la façon dont vous (devriez) avoir appris qu'il devrait ressembler. Vous devrez faire quelques concessions. Mais combien, et où vous tracez la ligne, cela dépend entièrement de vous.
Bien sûr, les emplois sont plus difficiles à trouver moins de concessions que vous faites. Mais ils pourraient être plus agréables.

FWIW, je n'ai jusqu'à présent (> 10 ans dans l'industrie) jamais travaillé dans une grande entreprise avec de nombreux développeurs (~ 30 développeurs était le plus, une douzaine la norme), car il est beaucoup plus probable que vous changiez quelque chose dans un petit entreprise. Tant que je gagne assez d'argent pour ne pas affamer les enfants, je ne voudrais pas être une petite roue dentée dans une grande entreprise, où tout ce que j'ai à faire est de me synchroniser avec le reste des engrenages.
J'ai refusé des offres d'emploi après avoir vu les tests qu'ils voulaient que je réussisse. Je suis un développeur C ++, et il y a beaucoup de tests C ++ qui sont si mauvais que vos ongles d'orteil s'enroulent de dégoût, et je ne veux pas passer mon temps à lutter contre les moulins à vent parce qu'ils ont embauché des crétins qui ne peuvent pas écrire de code propre.
J'ai également quitté un emploi après quelques mois parce que leur philosophie de programmation (objectifs à court terme, peu importe l'année prochaine) ne correspondait pas à mes capacités (stabilité du code à long terme), même s'ils disaient différent dans l'interview.

N'écrivez jamais de code qui fait juste le travail. Cependant, soyez également disposé à examiner votre doctrine. Ce n'est pas parce que vous l'avez appris à l'école que c'est une pensée actuelle, ou même une pensée valide. Le cycle de vie de la conception de logiciels est devenu obsolète, car la programmation doit être plus réactive au monde des affaires. Parfois, les solutions logicielles mal connectées sont mal liées car les pièces ont été remplacées dans le temps imparti.

Voici une liste de problèmes que j'ai compilés qui détermineront dans quelle mesure vous vous adaptez au mode de vie de codage d'une entreprise.

1. Combien ils apprécient de réserver du temps pour refactoriser et mettre à jour leur base de code. La façon dont ils perçoivent la mise à jour de la base de code sera un facteur déterminant majeur de votre adéquation.
2. À quelle fréquence achètent-ils un tiers au lieu de coder en interne.
3. Que pensent-ils des logiciels open source? Réalisent-ils qu'ils ont la flexibilité de modifier le code? Le voient-ils de la même manière que l'achat d'un tiers.
4. Vous travaillerez sur une certaine couche d'abstraction. L'équipe avec laquelle vous vous connectez détermine-t-elle votre interface pour vous? Quelle couche / équipe / côté de l'interface a le plus de pouvoir dans la prise de décision.
5. Dans quelle mesure les superviseurs écoutent-ils les programmeurs lorsqu'ils prennent des décisions? Lorsqu'un programmeur lance un drapeau rouge, la supervision s'arrête-t-elle et examine-t-elle sa décision.
6. Considérez-vous les programmeurs expérimentés en gestion? Comment perçoivent-ils leur expérience? Leur expérience est-elle valable? Laissent-ils une expérience dépassée affecter la prise de décision?
7. Dans quelle mesure la base de code est-elle collante?
8. À quelle fréquence mettent-ils à jour leurs outils de programmation (IDE, etc.)

Les réponses à ces questions correspondent mieux à la façon dont vous apprécierez leur style de vie de programmation, que de voir si elles correspondent à votre dogme.

Le dogme sera inévitablement brisé (nous n'avons tout simplement pas le temps de mettre à jour X). Cependant, les priorités définiront à quel point vous vous heurtez à leur style et à leur prise de décision.

Je pense que vous devez peser cela dans le cadre de l'ensemble. Je me souviens que l'un de mes premiers emplois était un poste dans un groupe qui m'a dit qu'ils faisaient du C ++ orienté objet - ce que je venais de faire pendant plusieurs années à l'école.

Leur auto-évaluation était erronée - ils faisaient un C. quelque peu volumineux.Il était toujours très fonctionnel dans la nature et je devais aller me chercher un livre en C pour m'enseigner printf et getf et d'autres mécanismes C que je n'avais jamais appris. Le fait que personne dans l'équipe n'ait même réalisé à quel point C comme leur code montre à quel point ce "design C ++" était tombé. Mon objectif à l'époque était de faire du développement OO, donc c'était un peu rebutant.

Mais je suis content, au final, que je reste avec l'équipe. Ils étaient un groupe dynamique de gens très intelligents et je me suis mouillé les pieds avec beaucoup de problèmes difficiles, j'ai pu travailler tout le cycle de vie et les choses que j'ai apprises sur le domaine du problème (PKI) ont alimenté ma carrière depuis. Le travail que l'équipe faisait dans l'espace fonctionnel était incroyable et je pense toujours très affectueusement à ce produit et à cette expérience de travail. Mieux encore - je travaille toujours avec certaines de ces personnes aujourd'hui (plusieurs entreprises plus tard), elles sont toujours une inspiration et nous faisons toujours du bon travail.

Je ne pense pas que la mise en œuvre parfaite des meilleures pratiques d'un langage de codage soit la réussite ou l'échec d'une bonne expérience de travail ou d'une bonne équipe - le travail qui alimente une carrière est bien plus que cela, et si le produit est décent qualité, l'équipe a des conditions de travail décentes (comme le test Joel) et l'équipe est pleine de gens intelligents et qui font avancer les choses, alors la perfection de la mise en œuvre est secondaire. Éliminer des facteurs comme le bon travail, les bonnes personnes, les bonnes conditions de travail - et cela ne vaut pas la peine de rester - que le code soit ou non étrangement élaboré.

à quel point doit-on être fondamental ou dogmatique? Dans quelle mesure un programmeur doit-il s'en tenir à ses principes ou simplement écrire du code qui fait le travail?

La chose la plus importante à retenir ici est quel est votre but ?

Dans la plupart des entreprises, votre but dans la vie n'est pas d'écrire du code parfait. Votre but est de fournir de la valeur à l'utilisateur. Écrire un bon code est généralement le meilleur moyen de fournir un bon produit qui est également facile à entretenir, à dépanner et à développer.

Un bon code est un outil que vous devez appliquer lorsqu'il vous donne un bon retour sur investissement.

Quelques exemples:

1. Je passerais beaucoup de temps à concevoir et coder mes API, en particulier l'API de mon niveau métier. Beaucoup d'autres programmeurs vont les utiliser et cela permettra d'économiser beaucoup de temps et de problèmes s'ils sont correctement conçus
2. Je vais assouplir un peu les règles dans ma couche de présentation. Là, je serai plus enclin à sacrifier la "perfection" du code au profit de l'ajout de fonctionnalités

En bout de ligne, vous devez avoir des principes, mais vous devez également être suffisamment flexible pour briser ces principes lorsqu'ils causent plus de tort que de valeur.

J'ai travaillé pour un détaillant de commerce électronique pendant quelques années. Quand j'ai commencé là-bas, le code de leurs applications internes était entièrement écrit en VB pour MS Access, et c'était pour le moins horrible. J'avais une équipe de 3 développeurs, et au cours des prochaines années, nous avons remplacé cela par des applications VB.Net appropriées.

Mais comme mon budget d'embauche était extrêmement limité, je ne pouvais me permettre que des programmeurs débutants. Et, bien sûr, le code qu'ils ont produit n'était pas terrible. Mais cela a fonctionné, et l'entreprise a utilisé ces applications pour gagner de l'argent, tous les jours.

Et puis j'ai commencé à travailler avec mes gars. Un peu de formation en OOD, en conception de base de données, en MVC et en C #. Et au fil des ans, les choses se sont améliorées. Quand je suis parti après 4 ans, la base de code n'était toujours pas géniale, mais elle était 100 fois meilleure que lorsque j'ai commencé.

Une situation comme celle que vous décrivez est souvent la conséquence de devoir se contenter des ressources disponibles. Nous ne vivons pas dans un monde idéal. En même temps, c'est une excellente occasion de faire une différence.

BTW: certaines de ces applications sont toujours en cours d'utilisation, pratiquement inchangées par rapport à il y a environ 3 ans, et elles rapportent toujours de l'argent.

Je pense que s'en tenir à vos principes est très important. Vous devez toujours vous efforcer de produire le meilleur code possible dans les limites données. Cependant, si vous ajoutez "ne devrait jamais avoir à lire ou à modifier mauvais code" à votre liste de principes, vous aurez beaucoup de difficulté à trouver du travail. N'oubliez pas que 50% des programmeurs ont obtenu leur diplôme dans la moitié inférieure de leur classe. Même au sein d'une équipe composée d'un seul homme, "vous aujourd'hui" est mieux qualifié pour résoudre un problème que "vous le mois dernier". Être capable de travailler avec un code non idéal n'est qu'une partie du travail.

Beaucoup d'employeurs reconnaissent que, donc ils codent qu'ils vous donnent à lire peuvent être représentatifs du pire code dans leur base de code, plutôt que de leur meilleur. Si cela ne ressort pas clairement du contexte, vous devriez demander. Un collègue avec lequel j'interviewe parfois a une page de code qu'il a délibérément mal écrit juste pour l'utiliser comme question d'entrevue.

Dans 99% des cas, vous devez vous en tenir au «dogme» comme vous l'appelez. Le dogme est fait par des personnes expérimentées au fil des années de pratique, et ce qui semble pragmatique à un moment donné ne l'est pas souvent. Ceci est généralement plus pertinent que le fait que vous n'êtes pas assez bon pour gérer correctement ce problème.

Cependant, ne suivez pas le dogme aveuglément. Rappelez-vous quelles conclusions amènent les gens à suivre ce dogme. Parce que vous trouverez une infime partie des cas où cela ne devrait pas être suivi. Quoi qu'il en soit, ces cas seront très rares et vous devriez toujours en discuter avec d'autres programmeurs expérimentés avant de prendre une telle décision.

Soyez strict quand c'est important. Style d'accolade (ou autres conventions de codage)? Ça n'a pas d'importance. Utilisez celui que la boutique utilise. Rompre l'encapsulation (ou d'autres principes de programmation fondamentaux) sans raison valable? Pas si banal.

Stack Exchange utilise des tableaux pour la mise en page (comme le font de nombreux autres sites Web majeurs qui font de l' argent ). Est-ce que cela fait sortir la fumée des oreilles des puristes? Bien sûr. Mais le pragmatisme l'emporte sur la pureté, à chaque fois. Le produit d'expédition l'emporte sur son perfectionnement, à chaque fois.

La couche de domaine entier, la couche de persistance, la couche de présentation, le test unitaire est encore relativement nouvelle, d'un point de vue historique. Il existe des tonnes de logiciels qui utilisent toujours un modèle client / serveur et ne seront pas modifiés pour le dernier style architectural simplement parce qu'il est "meilleur".