Quand la programmation «appropriée» n'a-t-elle plus d'importance?


49

Je construis un jeu Android pendant mon temps libre. Il utilise la bibliothèque libgdx, ce qui me permet de supporter une bonne partie des tâches lourdes.

Pendant que je développais, j'ai sélectionné négligemment des types de données pour certaines procédures. J'ai utilisé une table de hachage parce que je voulais quelque chose proche d'un tableau associatif. Valeurs clés lisibles par l'homme. Dans d'autres endroits pour réaliser des choses similaires, j'utilise un vecteur. Je sais que libgdx a des classes vector2 et vector3, mais je ne les ai jamais utilisées.

Lorsque je rencontre des problèmes étranges et que je cherche de l'aide auprès de Stack Overflow, je vois beaucoup de personnes qui ne font que répondre aux questions qui utilisent un type de données donné, lorsqu'un autre type est techniquement "approprié". C'est comme utiliser un ArrayList car il ne nécessite pas de limites définies par rapport à la redéfinition d'un int [] avec de nouvelles limites connues. Ou même quelque chose d'anodin comme celui-ci:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Je sais qu'il évalue item.length à chaque itération. Cependant, je sais aussi que les articles ne seront jamais plus de 15 à 20 articles. Alors, devrais-je me préoccuper si j'évalue items.length à chaque itération?

J'ai effectué des tests pour voir comment l'application fonctionne à l'aide de la méthode que je viens de décrire par rapport à la méthode appropriée, suivez le didacticiel et utilisez les types de données exacts proposés par la communauté. Les résultats: même chose. Moyenne 45 fps. J'ai ouvert chaque application sur le téléphone et l'onglet Galaxy. Aucune différence.

Je suppose donc que ma question est la suivante: existe-t-il un seuil à partir duquel il n’est plus important d’être approprié? Est-ce que ça va de dire - "tant que le travail est fait, je m'en fiche?"


4
C'est une question de grandeur. Essayez de créer des bases de données multi-terrabyte mises au service du monde réel avec des recherches et des agrégations dans des temps de réponse inférieurs à la seconde avec des milliers de demandes à la minute. Votre problème n'est pas assez grave. Bien que votre approche soit satisfaisante, si vous suivez cette voie, vous en arriverez inévitablement à une conclusion douloureuse qui prend du temps à atteindre.
Jimmy Hoffa

8
Si votre langue avait une vraie boucle FOR, ce problème d'évaluation multiple ne se poserait pas. Malheureusement, la syntaxe C l'exige, car ce n'est pas vraiment une boucle FOR; c'est une boucle WHILE portant une perruque et des lunettes à gros nez, et il est tenu d'accepter toute condition arbitraire (ou aucune condition) de terminaison de la boucle.
Mason Wheeler

2
Je vois votre modification, mais si vous essayez de démontrer que le fait d'être ivre et téméraire est acceptable dans tous les contextes, à l'exception de faire la fête un vendredi soir avec un conducteur désigné, vous êtes probablement en train d'aboyer du mauvais arbre.
Robert Harvey

17
Comment savez-vous qu'il "évalue" item.length à chaque itération? Les compilateurs sont très intelligents. Et même si elle va chercher à plusieurs reprises item.length, alors quoi? Je n'aimerais pas voir du code comme 'int itemsLength = items.length; for (; i <itemsLength; ...) 'sauf en cas de problème de performance mesuré.
Kevin Cline

6
Votre élément items.length n’a absolument rien à voir avec une "programmation appropriée". C'est une micro-optimisation, et les bons programmeurs savent qu'il vaut mieux ne pas perdre de temps sur ceux-ci jusqu'à ce qu'ils aient exécuté un profileur et sachent où se trouvent les véritables problèmes de performances. Les micro-optimisations et un bon style de programmation sont souvent des opposés, ce n'est pas la même chose.
Michael Borgwardt

Réponses:


65

Vous écrivez un programme pour résoudre un problème. Ce problème s’accompagne d’un ensemble spécifique d’exigences pour le résoudre. Si ces conditions sont remplies, le problème est résolu et l'objectif est atteint.

C'est ça.

Maintenant, la raison pour laquelle les meilleures pratiques ont été observées est que certaines exigences concernent la maintenabilité, la testabilité, les garanties de performance, etc. Par conséquent, vous avez ces gens embêtants comme moi qui exigent des choses comme un style de codage approprié. Il ne faut pas beaucoup plus d'effort pour croiser vos T et décaler vos I, et c'est un geste de respect envers ceux qui doivent lire votre code plus tard et comprendre ce qu'il fait.

Pour les systèmes de grande taille, ce type de contrainte et de discipline est essentiel, car vous devez jouer avec les autres pour que tout fonctionne correctement et réduire au minimum les dettes techniques afin que le projet ne s'écroule pas sous son propre poids.

À l'opposé, vous trouverez des utilitaires uniques que vous écrivez pour résoudre un problème spécifique actuellement, des utilitaires que vous n'utiliserez plus jamais. Dans ces cas, le style et les meilleures pratiques sont totalement hors de propos; vous piratez la chose ensemble, lancez-la et passez à la suivante.

Donc, comme avec beaucoup de choses dans le développement de logiciels, cela dépend.


1
J'ai tendance à être d'accord. Au travail, je ne pose pas de questions, c'est croisé et pointillé. Mais considérez que beaucoup de choses que je fais pour le travail sont une chose qui n'a vraiment pas besoin d'être entretenue. Passant tendance genre de choses. Des applications d'anniversaire, des choses qui vont et viennent. Tous convenables là-bas, mais ils n'ont vraiment pas besoin d'être.
Kai Qing

21
On peut faire valoir que le fait d’être discipliné à tout moment facilite la discipline lorsque vous devez le faire. Certaines personnes posent des questions sur le dépassement de pile sans avoir à appuyer sur la touche Maj, en affirmant qu'elles peuvent transmettre leurs idées de manière adéquate sans cela, et que la langue anglaise est de toute façon une chose fluide et évolutive. Je ne trouve rien de plus exaspérant, sauf peut-être les auteurs de virus qui pensent que mon temps processeur est gratuit.
Robert Harvey

2
@KaiQing Quelqu'un doit vous remettre une application héritée de 5mloc qui est née en pascal et qui est reportée depuis, car lors de votre première tentative d’ajout ou de modification d’une fonctionnalité de cette application, vous réaliseriez immédiatement pourquoi les meilleures pratiques existent et sont éclairées.
Jimmy Hoffa

5
@KaiQing, Angry Birds doit fonctionner sur plusieurs plates-formes. Si le jeu est suspendu pendant 2 secondes, x% du public va l'abandonner, ce qui signifie y moins d'argent pour les gens d'Angry Birds. Je vous parie que cela a été écrit très très attentivement. Peut-être que cela répond à votre question. Si le code est juste pour vous, qui se soucie de ce que vous faites? S'il y a de l'argent ou du temps d'autres personnes en jeu, alors il vaut mieux être très très prudent.
Charles E. Grant

2
@KaiQing Personne ne peut vous en indiquer le seuil, il varie d'un projet à l'autre et sur chaque projet au fil du temps. Nombre de variables qui affectent le seuil entre le système étant maintenable et non dépendant du système: LOC, base d’utilisateurs, base de développeurs, type d’application (cryptographie par rapport à des pilotes), robustesse des fonctionnalités, exigences en matière de redondance, criticité logicielle (serveur de messagerie vs Life Support Device vs. widget Widget), Plates-formes prises en charge, Pile de technologies, Quantité de données en cours de transaction ou d'analyse, Contraintes de vérification de l'historique et bien d'autres choses qui affectent la qualité du code
Jimmy Hoffa

18

Il y a une vieille citation sage: "Ne suivez pas les traces des hommes sages d'autrefois. Cherchez ce qu'ils cherchaient." Il y a des raisons pour toutes les règles du codage «correct». Savoir pourquoi ces règles existent est plus important que de savoir quelles sont ces règles.

Il existe une règle selon laquelle vous ne devez pas appliquer de test pouvant être recalculé à plusieurs reprises dans une boucle for, comme celle-ci. Dans les cas où la règle a été inventée pour remédier (lorsque la performance serait vraiment différente), cela a du sens. Dans ce cas, il n'y a qu'une seule bonne réponse. Dans votre exemple, on sait qu'il n'y a pas de différence de performances et qu'il ne peut y avoir plus d'une vingtaine d'itérations. Dans ce cas, il y a deux bonnes réponses, soit appliquer la règle de toute façon, car elle est simple et ne fera aucun mal et pourrait aider à créer de bonnes habitudes, ou d'ignorer la règle, car il n'y a pas de différence de performances à craindre.

Je préfère la première bonne réponse et vous semblez préférer la deuxième. Vous n'avez pas tort à ce sujet. Je pense que vous vous trompez dans votre idée de la programmation «appropriée». Il ne s'agit pas de suivre un ensemble de règles choisies au hasard qui ne vous aident pas et qui ne servent à rien. Si vous ne corrigez pas la boucle for dans l'exemple, vous suivez une très bonne règle contre l'optimisation prématurée.

La vraie programmation consiste à suivre de bonnes règles intelligentes.


Je ne dirais pas que je préfère la seconde. Quelqu'un a édité mon post pour supprimer la partie sur ma façon de rendre ce jeu Android presque entièrement saoul (juste pour le plaisir) et, par conséquent, je suis surpris de voir que mes choix saouls ne font aucune différence en termes de performances. J'ai remplacé certaines classes étranges par des classes appropriées à tester. Je conviens cependant que connaître les règles est plus important que de savoir quelles sont les règles ...
Kai Qing

De plus, mon idée de "bonne" programmation est l'aboutissement des opinions répétitives de la communauté du stackoverflow, ainsi que de la collection de programmeurs qui sont venus et sont partis dans l'entreprise pour laquelle je travaille. Certains avec des diplômes de CI, certains autodidactes. Il y a une opinion commune sur laquelle baser les choses et j'ai tendance à être d'accord avec ce que tout le monde dit collectivement avant de décider qu'une solution est bonne et une solution est fausse. Merci d'avoir participé.
Kai Qing

1
S'il me semblait que je vous reprochais d'avoir enfreint les règles, je l'ai mal formulé. Je ne m'opposerais à rien de ce dont vous avez parlé. J'essayais de souligner que "l'esprit de la loi" est plus important que la "lettre de la loi".
Michael Shaw

Hé, non, je ne pensais pas que vous me disiez. J'étais juste en train de communiquer. J'ai posé cette question pour une raison et je suis heureux que tant de personnes aient répondu sans voter, et cela a été clos
Kai Qing

10

La meilleure façon d’envisager cette question est de dégager des rendements décroissants: comparer l’avantage supplémentaire de l’élaboration du programme au coût de l’aménagement supplémentaire.

Les rendements décroissants s'installent lorsque le bénéfice marginal est inférieur au temps / effort marginal.

Pouvez-vous faire une analyse de rentabilisation pour items.lengthsortir de la forboucle? Économiquement, ce changement peut-il même justifier le temps passé à essayer de le justifier? Comme il n’ya aucune différence dans l’expérience utilisateur, vous n’obtiendrez jamais rien, même pour le temps passé à mesurer (à part une leçon utile à retenir). Les utilisateurs n’apprécieront pas plus le programme qu’ils ne le font, et plus de copies ne seront pas vendues à la suite de ce changement.

Cela n’est pas toujours facile à évaluer, car les analyses de rentabilisation sont remplies d’inconnues et de risques et risquent donc de faire l’objet de facteurs non pris en compte qui ne deviendront évidents que rétrospectivement. Les changements proposés peuvent être totalement non triviaux, de sorte qu'ils font une grande différence.

Une pensée de type «rendements décroissants» peut constituer une chasse aux excuses pour ne pas prendre certaines mesures et éviter de prendre des risques, ce qui, avec le recul, pourrait se révéler être une suite d’occasions manquées.

Mais parfois, il est évident de ne pas faire quelque chose. Si un développement semble nécessiter un miracle économique uniquement pour payer le coût du développement (rentabilité), c'est probablement une mauvaise idée.


Très bien écrit. Dans mon cas, le retour n'a jamais été planifié. Tout retour peut être accessoire, mais ne doit pas être écarté car je pense que certains des plus grands succès ont commencé comme des douves. En ce qui concerne le travail des clients, où l’argent est en jeu au lieu d’aggraver si l’application se bloque ou si quelque chose devient un inconvénient mineur, le seuil est plus épais. Si les repères semblent bons, mais que le code est réputé ne pas être le plus efficace, personne ne viendra jamais le vérifier avant son évolution et peut-être exigerait-il une migration de toute façon ... difficile à dire à ce sujet.
Kai Qing

En effet. Nous ne pouvons pas toujours faire une sorte de cas objectif. Tout le monde n'apprécie pas le programme de la même manière. Supposons que l’utilité principale du programme soit le plaisir de travailler dessus. Cela pourrait ne servir à personne et personne ne paiera pour les améliorations (même s'il y a des utilisateurs autres que le programmeur), mais c'est suffisant pour justifier une amélioration de quelque manière que ce soit.
Kaz

Deux mots utiles à ajouter à votre réponse très bien écrite - "Investissement spéculatif" - vous le faites parce que vous spéculez qu'il y aura un retour dans le futur.
mattnz

@mattnz - ce que vous dites est vrai, en ce sens que personne ne fait quelque chose sans retour, même si le retour est amusant. Presque tous mes projets personnels sont faits pour l'humour. Presque tous en font assez pour justifier leurs besoins. Aucun d'entre eux ne m'a permis de quitter.
Kai Qing

Exactement tout le monde. Nous devons donc d’abord déterminer ce que nous espérons tirer de l’écriture de ce programme ou continuer à le faire. Ce quelque chose pourrait être "passer le temps pour que ce soit amusant". Mais même dans ce cas, nous pouvons penser: est-ce que travailler sur telle chose dans tel programme est la meilleure façon de réaliser le plus amusant, ou mettons-nous le temps à autre chose.
Kaz

3

Quand vous ne devez pas vous soucier que votre code soit "correct"

  • Si vous parvenez à atteindre l'objectif commercial et à le maintenir dans le temps avec des frais généraux minimes. (les utilisateurs ne voient pas la source avant de vous payer)
  • MVP / POC - Si écrire un code correct signifie perdre du temps sur un concept avant de savoir comment en tirer profit (si vous passez des années et 45 millions de dollars à écrire votre application et que vous fermez votre boutique parce qu'elle n'avait pas de marché, personne ne bon était le code)
  • Dans une situation où la vie était en danger (par exemple, le prototype d'Iron Man 1 était un sale bidouillage, mais il l'avait sorti de la grotte, n'est-ce pas?)
  • ou si vous ne savez tout simplement pas comment écrire le code approprié (si quelque chose parvient à gagner sa vie en écrivant un code non approprié, dans le chômage d'aujourd'hui, mieux vaut écrire un mauvais code qu'être sans abri)
  • si vous savez simplement ce que vous faites ou pensez pouvoir vous en tirer en prétendant le faire

Quand écrire le code correct

  • Si cela aura un impact commercial significatif, par exemple, la performance aura un impact sur le chiffre d'affaires ou empêchera les ventes
  • Si le problème ne se pose pas, le maintien du code devient un problème commercial (coûts de maintenance élevés).
  • Si vous êtes un programmeur connu travaillant sur un grand projet open source
  • Idem pour une grande entreprise qui contribue au monde avec une bibliothèque interne
  • Si vous souhaitez montrer votre travail en tant que portfolio lors d'entretiens futurs

1
Malheureusement, il y en a une autre sur la liste qui ne tient pas à être une bonne personne et que beaucoup de gens sont bénis de ne pas savoir: lorsqu'un client vomit un ancien système sous vos soins et vous dit qu'il doit le faire en une semaine. Parfois, le temps et / ou le budget ne se prêtent pas à un codage correct et votre attention sur le projet est davantage une grâce qu'une transaction commerciale. Par exemple, si leur code utilise des méthodes largement obsolètes mais nécessite des correctifs (scénario dans le Web). Je ne peux pas tout réparer. Doit être sale.
Kai Qing

"Si le problème ne se pose pas, la maintenance du code devient un problème commercial (coûts de maintenance élevés)." Ce seuil est en réalité considérablement inférieur à ce que la plupart des développeurs inexpérimentés sont enclins à croire. Écrire un code solide se rembourse souvent en quelques heures, et non en plusieurs jours ou mois.
PeterAllenWebb

2

La performance est-elle votre principale préoccupation? Est-ce ce que vous essayez de maximiser?

Si c'est le cas, il y a une leçon fondamentale à apprendre, et si vous le faites, vous serez l'un des rares.

N'essayez pas de "penser" à ce que vous devriez faire pour accélérer les choses - c'est deviner. Si vous demandez "Devrais-je utiliser cette classe de contenants ou celle-là?" Ou "Devrais-je me mettre lengthà la place de la boucle?", Vous êtes comme un médecin qui voit un patient et tente de décider du traitement à donner sans réellement interroger ou examiner le patient.

C'est deviner. Tout le monde le fait, mais ça ne marche pas.

Au lieu de cela, laissez le programme lui-même vous dire quel est son problème. Voici un exemple détaillé.

Voyez-vous la différence?


Je dirais que ma seule préoccupation est que dans mes tests, je n’ai constaté aucune différence de performances entre l’utilisation incorrecte et correcte des types de données pour le scénario spécifié. Comme dans votre suggestion, j'ai surchargé la classe avec plus de données pour voir si c'était trop peu pour faire une différence. En fin de compte, les deux ont joué à égalité. Certes, je fais juste un jeu de type RPG de base. Ce n'est pas comme un logiciel bancaire ou quelque chose de complexe. Mais cela m’a amené à me demander s’il serait préférable que les entreprises ne soient pas aussi convenables tout le temps.
Kai Qing

Puisque la performance est votre préoccupation, vous devriez demander au programme ce que vous devriez regarder, sans vous demander si votre question préconçue fait une différence. S'il vous plaît cliquer sur ce lien, et faire ce qu'il dit. Cela vous indiquera ce à quoi le programme consacre beaucoup de temps et vous indiquera comment le rendre plus rapide.
Mike Dunlavey

Eh bien, la performance était ma base pour la procédure de questionnement, pas nécessairement une préoccupation. Je ne cherche pas à comparer les performances à proprement parler. Le simple fait d’observer que le code inefficace n’a aucune incidence sur les performances. L'efficacité du programme est clairement transparente pour l'utilisateur. Par conséquent, le souci d'un tel profilage n'est plus pertinent. Certes, je devais avoir une certaine préoccupation à comparer, mais c'était surtout de la curiosité. Et si le produit est fini et qu'il est sensiblement lent, alors oui, un profileur a du sens. Merci pour le lien
Kai Qing

2

Votre question est la suivante: "tant que le travail est fait, ça m'est égal?"

Ma réponse est "on ne sait jamais ce qu'il adviendra de votre code". J'ai été impliqué dans tellement de projets qui ont débuté sous le nom "hé, laissez-moi écrire cette chose rapide pour régler le problème d'un utilisateur". Écris-le, mets-le là-bas, n'y pense plus jamais.

Une fois, cette chose que j'ai écrite s'est transformée en "oh, maintenant tout le service de l'utilisateur veut utiliser ce code", ce qui avant que je puisse me retourner est devenu "toute la société utilise ce code et je dois maintenant prouver qu'il survivra à un audit et il y a une révision du code de 20 personnes prévue pour demain et un vice-président l'a déjà vendu à nos clients. "

Je réalise que vous "écrivez simplement un jeu Android pendant votre temps libre" mais vous ne savez jamais si ce jeu va décoller et devenir votre ticket pour la gloire et la fortune. Pire encore, ce jeu pourrait devenir votre ticket d’infamie, car il n'arrête pas de planter les téléphones des gens. Voulez-vous être la personne qui obtient une offre d'emploi parce que les enfants de quelqu'un ne peut pas arrêter de jouer au jeu sur son téléphone, ou voulez-vous être la personne qui se fait vilipender sur des babillards comme celui-ci?


1

La réponse est que cela n'a jamais d'importance et que c'est toujours important ...

Cela n’a jamais d’importance, car la programmation, appropriée ou non, est un moyen d’atteindre un objectif, pas un objectif en soi. Si cet objectif est atteint sans une "bonne" programmation, c'est bien (d'un point de vue commercial, il est souvent préférable que l'objectif puisse être atteint sans programmation).

C'est toujours important, car une bonne programmation est un outil qui vous aidera à atteindre vos objectifs. La façon appropriée de faire les choses est simplement de reconnaître que le faire autrement est plus douloureux à long terme que cela n'enregistre.

Ce qui répond à la question de savoir quand on peut l'ignorer - quand on est sûr qu'une autre solution sera plus facile à long terme (peut-être parce qu'il n'y aura pas de long terme).

Les outils uniques sont généralement conçus de la manière la plus rapide et la plus sale possible, avec peu ou pas de vérification d'erreur ou autre validation, pas de journalisation des exceptions, du code copier-coller avec des modifications mineures ou même aucune modification au lieu de fonctions génériques, etc. .

Faites attention: parfois, ces applications rapides et sales prennent leur propre vie, ce qui signifie que tous les raccourcis vous mordent ...


1
"jamais" et "toujours" s'annulent. Rendre votre réponse à la fois bonne et mauvaise.
Tulains Córdova

@ user1598390: leur annulation était le but. Annulez le dogme, et il ne vous reste plus que cela semble utile. Et vous vous tromperez et apprendrez de cela.
Jmoreno

Je veux dire que je suis d'accord avec vous mais je ne l'aurais pas porté à de tels extrêmes. Je ne pense pas que certains soient simplement crachés, échappant aux tests ou au débogage. Parce qu’il n’est ni optimisé ni parfaitement conçu, il n’en est pas moins un produit si les performances et la stabilité ne sont pas affectées par le shortcust. C’est finalement ce que je veux dire et pourquoi je me demande pourquoi tout le monde craint tant les exemples de codage qui ne sont pas haut de gamme. Cela arrive souvent sur stackoverflow.
Kai Qing

@KaiQing: Bien sûr, les tests et le débogage se produisent, mais ils sont généralement limités à ce qui existe pour le moment. Ainsi, par exemple, si le processus échoue avec un fichier au format UTF et aucun des fichiers sur lesquels vous travaillez réellement. faites, vous ne testez pas cela. L'optimisation doit être effectuée lorsqu'un problème de performance a été identifié. En ce qui concerne la raison pour laquelle une puanteur sur des exemples de codage non haut de gamme sur SO, je pense que cela dépend des objectifs du site. Il vise à être une ressource permanente, le code dans les réponses (et même les questions) est donc examiné comme s'il s'agissait d'un modèle que d'autres utiliseront.
Jmoreno

1

Ou même quelque chose d'anodin comme celui-ci:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Je sais qu'il évalue item.length à chaque itération. Cependant, je sais aussi que les articles ne seront jamais plus de 15 à 20 articles. Alors, devrais-je me préoccuper si j'évalue items.length à chaque itération?

En réalité, dans le code final, items.length ne sera pas évalué à chaque itération car le compilateur l'optimise. Et même si ce n'était pas le cas, length est un champ public dans l'objet tableau; y accéder ne coûte rien.

Donc, je suppose que ma question est la suivante: existe-t-il un seuil quand il ne faut plus> que ce soit approprié? Est-ce que ça va de dire - "tant que le travail est fait, je m'en fous?"

Cela dépend vraiment de ce que vous attendez de votre produit final. la différence entre un produit moyen et un excellent produit repose sur les détails. Une voiture comme Tata Nano et une voiture comme Mercedes S "font le travail" - ça vous emmène d'un endroit à un autre. La différence réside dans les détails: puissance du moteur, confort, sécurité et autres. Il en va de même pour tous les produits existants, y compris les logiciels. Par exemple, pourquoi quelqu'un paierait-il à Oracle, IBM ou Microsoft pour une base de données Oracle, DB2 ou MS SQL Server puisque MySQL et Postgre sont gratuits?

Si vous voulez faire attention aux détails et obtenir un produit de haute qualité, vous devriez vous intéresser à ce genre de choses (et à d’autres, évidemment).


Je ne pense cependant pas être d'accord avec cela. Dans mon post, je ne mentionne aucune différence de performance. Cela suggère qu'il n'y a pas de produit moyen ou excellent, mais un équilibre égal malgré les inconvénients d'un. Je suis d'accord avec votre déclaration, cependant, s'il y avait un projet spécifique d'une grande importance que nous utilisions tous comme comparaison. Mais, de manière abstraite, l’observation générale est que, dans ce projet anonyme, une classe résolument inefficace s’avérait tout aussi performante que la classe optimisée. Alors, est-il acceptable d'adopter une attitude détendue à cet égard ou de plaider pour la perfection à chaque fois?
Kai Qing

@ Kai Qing Une seule classe ne fait pas (ou ne devrait pas) faire une grande différence. Je l'ai dit: si vous vous attendez à ce que votre produit soit un produit de haute qualité, accordez une attention particulière aux détails (même si cela signifie une possible petite optimisation ou une conception soignée); D'autre part, si la seule chose que vous voulez, c'est un système fonctionnel, alors vous ne devriez probablement pas prêter beaucoup d'attention à de petits détails.
m3th0dman

Oui, vous avez raison, cela ne devrait pas faire de différence, même si sa conception est un peu soignée. Mais il peut faire une différence selon son objectif ou si, en général, son objectif s'est transformé avec le temps et est devenu quelque chose qu'il n'était pas destiné à être. Vu cela avant, mais je vais juste sur une tangente ici. Pour être juste, un produit peut être de haute qualité sans être plus que fonctionnel.
Kai Qing

1

Si vous programmez vous-même à la maison, vous pouvez peut-être couper quelques coins; et quand vous expérimentez et essayez des choses, cela est complètement justifié.

Attention cependant. Dans l'exemple que vous donnez, il n'est pas vraiment nécessaire de couper cet angle, vous devez être prudent. Cela pourrait créer une tendance et de mauvaises habitudes à la maison pourraient se glisser dans votre code au travail. Mieux vaut pratiquer et améliorer les bonnes habitudes à la maison et les laisser s'infiltrer dans votre code au travail. Cela vous aidera et aidera les autres.

Toute programmation que vous faites et toute réflexion que vous faites sur la programmation est un exercice. Faites-en la peine, sinon il reviendra et vous mordra.

Regardez du bon côté cependant. Vous avez posé une question à ce sujet, alors vous êtes peut-être déjà au courant de ce que je veux dire.


1
Oui, je suis au courant, mais le but de la question est principalement que, dans le contexte restreint et confiné, il ne semble pas y avoir de raison d'être aussi approprié. Au cours de toutes mes années de programmation, il n'y a pas eu beaucoup de retour en arrière pour nous mordre. Je doute que nous soyons si convenables. Je pense que c'est que les langues et les attentes changent comme les logiciels normaux. Certains moins que d'autres. Mais en fin de compte, l'inefficacité d'un projet ne peut se concrétiser que lorsque le projet est dans le passé et n'est plus essentielle. Cela rend difficile de justifier le mal de tête d'être si rigide.
Kai Qing

C'est un point juste. Les règles d'aujourd'hui peuvent être les restrictions de demain. Je n'aime pas qu'on me dise quoi faire, mais j'ai du respect pour ceux qui sont partis avant et qui ont appris à leurs dépens. Parfois, il peut être intéressant de savoir quelles règles sont utiles et quelles sont maintenant les dates de vente écoulées.
Daniel Hollinrake

1

Si un fabricant de meubles fabriquait un meuble où la qualité importait peu ou où la qualité risquait de passer inaperçue, devrait-il tout de même essayer de redresser ses coupes et de joindre correctement les meubles?

Beaucoup de gens voient le logiciel comme un savoir-faire. Ce que nous construisons ne doit pas seulement remplir une fonction, il doit être fiable, maintenable, robuste. Fabriquer de tels logiciels nécessite des compétences, et ces compétences proviennent de la pratique.

Ainsi, même si le choix d'une construction en boucle pour ce sur quoi vous travaillez aujourd'hui n'a pas d'importance, le fait de vous efforcer d'utiliser les constructions appropriées à tout moment fera de vous, avec le temps, un meilleur programmeur.


J'ai rencontré des cas de programmation où le code n'avait pas besoin d'être maintenable ni d'être exécuté en dehors des besoins. Comme des utilitaires de kiosque pour des salons ou des événements très spécifiques et non susceptibles d'être réutilisés. Dans le cas de mon propre jeu - je suis le seul à le maintenir, donc cet argument peut ne pas être le plus applicable. Je doute toujours du point de vue commun sur le "meilleur programmeur" car le strict respect des directives, la maintenabilité et l'utilisation correcte des types de données peuvent être suffisamment décourageants pour ne pas mener à terme le projet. Si le code fonctionne comme prévu, pourquoi le perfectionner?
Kai Qing

Même si le logiciel que vous construisez right_now n'a pas besoin d'être maintenu, l'écrire comme s'il renforçait vos compétences de codage. Lorsque vous devez enfin écrire du code maintenable, vous pourrez le faire plus facilement.
Bryan Oakley

Je dois écrire du code maintenable tout le temps. Dans certains cas, il n'est pas nécessaire que ce soit le cas. Cependant, j'ai beaucoup d'expérience et je sais généralement quand et où prendre des raccourcis. Le but de cet article était simplement de susciter une conversation sur le seuil de la juste et du négligé pour quelque raison que ce soit. Mon exemple ne fait que légèrement effleurer ce sujet, car celui-ci est généralement inoffensif dans une application plus petite. Cependant, si j'écrivais un logiciel de banque, je ne serais jamais aussi négligent.
Kai Qing
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.