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

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?"

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.

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.

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.

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

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?

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?

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 ...

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).

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.

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.