Kibest
Expert
Pas mal, tu nous feras une petite démo quand ça sera fini ?Je chipote beaucoup pour le moment, j'avais pensé à un truc dans l'espace.
C'est pas mal effectivement"Debug.log ();".
Pas mal, tu nous feras une petite démo quand ça sera fini ?Je chipote beaucoup pour le moment, j'avais pensé à un truc dans l'espace.
C'est pas mal effectivement"Debug.log ();".
Ouais.Pas mal, tu nous feras une petite démo quand ça sera fini ?
C'est pas mal effectivement
Le debug est vital en développement. Un trace.log est indispensable en production quand tu as des doutes sur les données... etcJe chipote beaucoup pour le moment, j'avais pensé à un truc dans l'espace.
Sinon en fait dans Unity, le truc génial c'est ce fameux "Debug.log ();".
Cette ligne toute bête affiche du texte dans la console.
Sauf que tu peux mettre genre n'importe quoi dedans comme variable, et surtout tu peux la mettre n'importe où dans ton code (et voir en fonction de si elle s'affiche ou pas voir où ça débloque)
Cette ligne m'a déjà sauvé beaucoup de temps.
Chouette résumé. Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).Le debug est vital en développement. Un trace.log est indispensable en production quand tu as des doutes sur les données... etc
Pour moi, et par expérience, les règles d'un "bon" développement sont à raisonner selon deux cas
- La maintenance d'un existant
- La création totale
Les deux semblent identiques (du code, et du code)... sûrement pas: avec l'existant il faut tenir compte de ce qu'il y a déjà, et ce même si c'est pourri. Donc, il est fondamental de bien comprendre ce qu'on doit faire, et surtout ce que fait l'existant.
Quand on crée de zéro, là il y a trois aspects fondamentaux à mettre en oeuvre:
- On part du plus simple pour enrichir. Inutile de se disperser de suite, cela ne peut qu'être chiant à contourner par la suite
- Ne mettre que les données indispensables au départ, puis enrichir les données au fil des besoins
- Toujours bien raisonner le format et/ou la structure des données qu'on traite. En faisant de mauvais choix, on peut vite regretter des choix de conception antérieurs.
A partir de là, il y a la structuration du code
- Prévoir un maximum de petits "services" vitaux de partout (par ex. mettre en place des méthodes de gestion des dates pour les réutiliser de partout). Personnellement je crée toujours une boite à outils (toolbox) qui me liste des dizaines de trucs plus ou moins évolués
- Construire l'application avec à l'esprit qu'on peut l'enrichir, donc en découpant les fonctionnalités en modules
- Se méfier énormément des méthodes trop longues: si le code devient trop verbeux, c'est qu'il y a soit de la mutualisation de code possible, soit que l'algorithme est devenu trop complexe/mal fait. Les cas où les règles sont bien trop complexes signifient qu'on les regarde mal. Il y a toujours des choses qu'on peut redécouper pour s'éviter de la redondance de code.
- Intégrer dès le départ des traces pour le suivi d'exécution. Par exemple, on peut démarrer un programme avec une option "/log" qui active partout des traces écrites comme du debug.log() ou toute autre fonction du même acabit. Le but? identifier si tout fonctionne bien!
- Toujours prévoir l'imprévisible! Si on a de la donnée venant du monde extérieur au programme (ie fichiers/base de données/entrées au clavier/etc ) elle peut toujours arriver vérolée ou non cohérente. Un exemple très concret: si l'on structure des adresses, les codes postaux français sont numériques... mais bien des pays ont des codes alphanumériques. Donc, si l'on ne contrôle pas, c'est droit dans le mur au premier code postal anglais!
- Toujours prévoir des clauses d'échappement sur les traitements itératifs. ça semble idiot, mais une boucle peut vite devenir infinie si la clause de sorte n'est jamais remplie. Cela peut donner une bonne série de bugs chiants à trouver... ou des jeux à la Bethesda où l'écran se fige sans raison valable.
- Commenter le code, et donner des noms de méthodes/variables explicites! Rien ne m'horripile plus que les $toto ou les tabBidule, ou les méthodes FaitPleinsDeTrucsInutilesEtPasclairs! c'est bien simple: 90% du temps perdu en correction de bugs est lors de la relecture du code pour comprendre ce que le crétin (accessoirement c'est souvent VOUS le crétin) a fait pour rendre le code tout sauf explicite.
Et en complément
- Ne pas hésiter à documenter un minimum les méthodes créées
- Suivre les modifications via Git ou un équivalent. un bon outil de suivi de version. C'est vital pour ne pas corriger à tort, voire faire des régressions. j'aime bien gitkraken pour cette fonction, mais il y en a d'autres
- Toujours disposer de x sauvegardes annexes (c'est logique, mais combien le font vraiment?)
- En entreprise, penser à voir s'il est possible de standardiser des librairies. Plus c'est centralisé à ce niveau, moins on a de boulot par la suite... mais ça, c'est du domaine du rêve, car cela requiert de la rigueur et du temps pour rédiger un wiki dédié. Donc c'est du "bonus".
- Toujours penser à faire des tests pas uniquement en unitaire avec les données qui conviennent bien, mais avant tout qu'avec des données réelles (du client), ou dans des conditions dégradées pour s'assurer que tous les cas (si possible) sont couverts.
Ouiche ça....Chouette résumé. Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
Dommage. Quand tu développes une appli, inconsciemment, tu as tendance à ne tester que ce dont tu penses que ça fonctionnera puisque tu as pensé à le coder.Ouiche ça....
Chose que je ne peux pas réellement faire. ..
Demander à quelqu'un de tester...
Pléonasme ! Bon courageboulot saisonnier en restaurztion et je fais des horaires de dingues
Bah déjà tu bosses dans un milieu très difficile, c'est courageux de ta part! Donc bonne chance, bon courage, et reviens quand tu en auras envieSalut !
Je viens un peu aux nouvelles, j'ai toujours pas pu le commencer, j'ai commencé le boulot saisonnier en restaurztion et je fais des horaires de dingues, le seul temps libre que j'ai c'est pour dodo..... j'ai pas oublié j'essais de le faire quand j'ai un moment.......
Merci de votre compréhension les gars !
J'avais raté cette demandé à l'époque (pas de temps)Chouette résumé. Peut-être pourrais-tu rajouter quelques réflexions sur un chapitre pas si indépendant que ça, celui des BDD ? Quant aux applications interactives, en dehors du débogage, ne jamais faire soi-même les tests et encore moins les valider : la façon qu'ont les utilisateurs de les appréhender est souvent étonnante (prévoir l'imprévisible, dis-tu !).
ça n'est pas aussi clair hélas. Cela dépend fondamentalement pas de l'esthétique, mais du système de localisation.Bien qu'à peu près totalement d'accord avec tes préconisations sur les GUI, je diverge sur ton parallèle avec le développement des jeux vidéos. En effet, ces derniers s'affranchissent totalement de ce qui est la base d'un développement d'application traditionnelle : le respect des normes de présentation requis par l'OS considéré. Tu en donnes d'ailleurs un aperçu en évoquant les raccourcis, mais cela s'applique aussi aux menus, à la gestion des fenêtres, etc. Dans ces domaines, on n'a pas à faire selon son goût ou ses envies, mais selon les requis de Microsoft, ou Apple (pour Unix, je crains qu'il y ait autant de normes que de versions...). Grâce au respect par chacun de ces normes, si tu tombes sur une version suédoise d'une appli, tu arriveras tout de même à la quitter proprement...
Et puis il y aussi le cas particulier du développement Web qui mériterait un chapitre à lui tout seul ! (oui oui, c'est dégueulasse de te surcharger comme ça...)
C'est pour ça que j'insiste sur la dichotomie de marché. Pour faire une application Apple, tu es tenu de respecter des livrets blancs, là où sous Windows c'est totalement n'importe quoi en terme d'implémentation. Et pourtant, Microsoft n'est en cause car ils offrent ces mêmes cahiers... sauf que Apple est plus psychorigide, et les utilisateurs bien plus exigeants. Chez Ms il y a tellement de produits concurrents que le choix se porte sur la quantité d'utilisateurs (office par exemple), de réputation du produit (Winzip en son temps), que par l'ergonomie générale. C'est tout le souci.Ce que je voulais dire avec l'exemple de l'appli en suédois ne faisait pas référence aux problématiques de localisation, mais aux "normes" de menus : l'option Quitter devrait toujours être la dernière du menu Fichier, lequel devrait toujours être le premier des menus.
Pour ce qui est du web, on ne peut qu'approuver ton triste constat. Ayant quelques années géré le site marchand interne d'un grand groupe, les galères venaient des demandes démoniaques de la direction qui pouvaient se résumer en : à chaque utilisateur son site personnalisé ! Par contre, une mauvaise manip m'a conduit à installer un fond de page de couleur différente suivant le site de prod ou de dév...