J'aimerais avoir quelques conseils concernant les bonnes pratiques concernant le développement, ou même pour toute autre chose, travail avec des données, requêtes SQL, ou autre., en dehors des classiques règles de nommage de variable, la feuille et le crayon gomme, etc. Eventuellement des outils, des patterns de développements (comme le pattern MVC) que je ne connaîtrais peut-être pas (je suis encore étudiant donc je considère connaître que très peu de chose en réalité, surtout dans un domaine comme l'informatique....)
Concernant ce que je sais il y a les tests unitaires (développement dirigé par les tests) qui ont l'avantage de pouvoir être fait sans framework particulier, un simple << printf("Fail Number X") >> suffit par exemple, l'utilisation d'outils de génération automatique d'applications comme Ant ou Maven en Java, outil de versioning comme Git... J'ai aussi vu (dans un cadre universitaire) la méthodologie UML UP avec diagramme de cas d'utilisation, description des cas d'utilisation , diagramme d'état transition, séquence système, de classe, entité-association, séquence, et composant. Maître mot, utiliser tous ces moyens pour comprendre le besoin de l'utilisateur et très vite corriger ce qui doit être corrigé pour de nouveau rencontrer l'utilisateur et confirmer les changements.
d'abord comprendre les besoins des utilisateurs. Il faut les interroger, se mettre à leur place, enquêter même qqfois.
Ensuite écrire tout ce qui est nécessaire avant de coder et réfléchir. Cela parait évident mais cela évite souvent de partir dans un mur.
Concernant les patterns, tu peux trouver sur internet des explications avec exemples, surtout en Java. Tu peux au début te limiter aux principaux patterns.
Pour les outils, cela dépend des technologies utilisées. Java ?
Oui comprendre le besoin est le plus important ! J'avais oublié de préciser ce point. En cours j'ai vu la méthode UML UP pour formaliser le besoin de l'utilisateur, j'ai édité mon premier poste.
Pour les pattern j'ai lu le cours de Java et il va me falloir approfondir, notamment sur le pattern modèle vue contrôleur car je trouve différentes explications à des endroits différents..
Autrement, je n'ai pas de préférence pour un langage particulier. Je pense qu'on peut avoir une bonne pratique dans un langage et adapter / utiliser cette bonne pratique à un autre langage
Je dois m'autoformer à l'utilisation de Maven en Java. Les tutoriels ne sont pas toujours très clairs..
De ce que j'ai appris du peu d'expérience que j'ai : investit toi et sois toi même. Ne repose pas sur tes acquis, chercher à approfondir tes connaissances, tes compétences. Il n'y a pas de réponses "juste" en informatique, dix codes différents peuvent faire la même chose. Certains codes sont plus performants que d'autres mais ça, tu l'améliores au fur et à mesure. Surtout n'est pas peur de poser des questions (sur le net ou même dans tes entreprises (stage, alternance, ...)), tu apprends mieux avec l'expérience des autres. Sois toi même, c'est à dire ne cherche pas à tout connaître du bout des doigts, ce n'est pas possible. Tu ne peux pas tout savoir, et n'ai pas peur de le dire. Lors d'un test, tu n'arrives pas à faire ci ou à faire ça, n'est pas peur de dire ce que tu as réussi et ce que tu n'as pas réussi et pourquoi.
Le dernier conseil que je puisse te donner c'est : pratique, pratique et pratique.
Chacun à sa propre façon de faire (et heureusement). Je code différemment que mes collègues, même si on utilise le même langage, on c'est chacun approprié le pattern MVP. On se retrouve facilement dans nos codes quand on doit mettre le nez dans le code d'un autre.
Le coup des commentaires dans le code, c'est valable (obligatoire) que pour les projets open-sources (et les cours ). Si tes membres (variables/méthodes) sont bien nommés et ton code un semblant propre, c'est facile pour un développeur nageant dans le même domaine que toi de s'y retrouver. Dans nos projets, nous avons très peu de commentaires et quand on en met c'est pour des morceaux de code pris sur le net ou des méthodes un peu complexe.
Si tu fais du mobile, évite d'utiliser au maximum des librairies, surtout si c'est juste pour utiliser une méthode. Essaye de limiter l'ajout de code externe, c'est mieux.
Si tu reçois une maquette que tu juges qu'un élément est complètement anti-UX, alors fais-le à ta façon. Pour mon cas, je reçois souvent des maquettes Android copiés d'iOS, je retrouve donc des éléments qui n'ont rien à voir avec Android ou pas du tout Material Design, je préviens le designer et je fais le nécessaire pour corriger et avoir un design pro Android.
Ne cherche pas non plus à apprendre 10 langages. Essaye de te focus sur ce que tu souhaites faire comme métier et investit toi dedans. N'essaye pas non plus de devenir le meilleur dedans, juste sait la base, tu apprendras le reste avec l'expérience.
Il est préférable d'avoir les variables et méthodes en camelCase (c'est mieux en anglais). Evite d'avoir des méthodes de plus de 30 lignes ou des class qui font 500 lignes.
Versionne tes projets avec Git. C'est toujours mieux pour s'y retrouver. Et aussi profite que l'open source existe. Il y a de magnifiques projets sur Github où tu peux apprendre énormément de choses, crois moi. N'ai pas peur de passer du temps dans des projets concernant ton domaine.
Fais une veille quotidienne : suis les bons comptes sur Twitter sur ton domaine. La veille est ultra importante en informatique
Dernières chose que j'ai en tête : tu es toujours plus compétent que quelqu'un, n'hésite pas d'aider ceux qui le demande (aider, pas faire le code à leur place), tu apprendras énormément de ça.
Voilà, si tu as besoin d'autre chose, n'hésite pas
Ah oui, j'essaye d'en apprendre tant que je peux... Pas forcément pour tout retenir mais pour avoir vu pas mal de chose, me dire que j'ai déjà vu un truc similaire et que peut-être que si on applique le même résonnement, ... ?
Malheureusement les plus expérimentés ne sont pas toujours disposés à partager :/
Ah si j'aime bien réfléchir sur des problèmes, même si je ne connais pas, réfléchir avec du monde, où chacun met sa petite pierre à l'édifice, c'est d'ailleurs ce qui me fait aimer l'informatique, et du fait qu'il n'y a pas une seuule solution, chacun peut avoir sa solution qui fonctionne, même s'il y a de meilleures solutions que d'autres mais au moins chacun a sa chance de travailler, c'est pas comme en mathématiques où si on se trompe une fois, ben on est mort haha, même si j'aime aussi les maths, mais je suis moins bon
Ah oui c'est important de pratiquer !
C'est reçu pour le conseil de développement mobile : limiter le code externe !
Justement, en parlant de maquette, j'ai un cours en favoris (d'ici) sur l'UX-design, qu'est-ce que c'est ? C'est un type d'ergonomie j'imagine ! Pour mobile uniquement ? Je n'ai pas encore pu le lire (j'ai pas mal de pages en favoris à lire enfaite, je liquide petit à petit en fonction de se qui s'ajoute en parallèle...)
Pour Git il faut que je prenne les automatismes mais ça va venir
Je ne suis pas sur Twitter mais quelles comptes/pages me conseilles-tu ?
Oui j'aime bien aider les gens, sans abus évidemment
Un autre conseil : évite d'avoir une liste de page favorites. J'avais le même soucis que toi, je sauvegardais chaque jour 4-5 pages dans ma liste et je ne les lisait jamais. Maintenant je prends le temps de lire les pages, si je ne peux pas, je les épingle sur Chrome comme ça je sais que je dois les lire en urgence et vu que je les vois tout le temps, ce n'est plus un soucis. Si tu ne lis pas les pages au jour le jour, ça peut très vite devenir obsolète et donc inutile. Tout de manière, en les mettant en favoris, il y a de fortes chances que tu ne les lises jamais.
UX : User Experience (expérience utilisateur). Par exemple une "bouteille" de ketchup il a était designé pour tenir sur son pied, mais on le met toujours sur son couvercle pour faciliter la sortie du ketchup : http://blogdummi.fr/wp-content/uploads/2015/03/Diff%C3%A9rence-entreproduit-et-exp%C3%A9rience-utilisateur.jpg L'UX c'est comment l'user réagit au produit, comment il en a l'habitude de se servir. Niveau Android, on a l'habitude d'avoir un titre dans la toolbar aligné à gauche et non centré (qui est plus iOS). Si tu changes cette habitude, ça ne va pas du tout.
Concernant Twitter, ça dépend de ton domaine. Tu veux faire quoi ? Du web front-end ? Backend ? De l'Android ? iOS ? Du logiciel ? Des jeux-vidéos ? Je me connais que en Android, donc je peux pas trop d'aider là dessus, c'est à toi de faire tes recherches
Je viens ajouter ma pierre à l'édifice bien que notre ami Joadar ait fait un bon tour d'horizon !
Les patterns sont en effet intéressants à connaitre, ils vont pouvoir t'aider à mettre en oeuvre un code structuré et maintenable, mais il faut bien prendre en compte qu'ils vont dépendre de la structure où tu vas travailler ou du projet. Par exemple, si tu travailles dans une startup, généralement on va utiliser des méthodes de développement agiles, qui dit agile, dit respect des principes YAGNI (https://en.wikipedia.org/wiki/You_aren't_gonna_need_it) et KISS(https://en.wikipedia.org/wiki/KISS_principle), on n'utilisera donc pas forcément de structures particulières, à part peut-être un modèle MVC. A contrario, dans une plus grosse entreprise, si le projet est conséquent, il vaut mieux connaitre ses patterns, pour éviter d'avoir une usigne à gaz ! => Que retirer de tout ça ? Que connaitre les quelques patterns les plus importants (MVC, Fluent inteface, Facade, Conteneur d'injecteur de dépendance, Adapter, Decorator...) suffisent et que par la suite tu vas être formé ou t'autoformer dans ton entreprise !
Pour la qualité du code (doc, commentaires et tests unitaires), encore une fois ça dépend du projet, je suis du même avis que Joadar, les commentaires dans du code propre (variables bien nommé, fonction propre (~30/50 lignes grand max)), ils sont inutiles au possible, ils alourdissent le code. Par contre, si tu travailles sur un outil plus critique (un serveur par exemple), il faut de la documentation sur les points cruciaux et surtout des tests unitaires pour t'assurer que tout fonctionne correctement et pas juste des cas de tests aux limites ! Après, un serveur d'intégration continue comme jenkins est intéressant !
Pour la gestion de versions, pour ma part, c'est simple : GIT. Il faut avoir quelques bases, savoir comment fonctionne une branche, comment merge et ceux en passant d'abord par de la ligne de commande (ce n'est que mon point de vue), ça vous force à savoir ce que vous faites.
Après, comme ça a été dit plus haut, pratiquer, pratiquer et pratiquer :D. On le voit partout mais : "C'est en forgeant qu'on devient forgeron". La veille est en effet importante, personnellement, je suis surtout les blogs et les bon compte twitter. Et, n'ai pas peur d'interroger les gens plus expérimentés, un mail à un blogueur c'est cool ! Quand, je reçois un mail, c'est toujours enrichissant, un exemple j'écris un article assez conséquent, c'est impressionnant le nombre coquilles/erreurs qu'on peut éventuellement faire et si on peut les corriger et en même temps vous aider, ça sera toujours avec plaisir !
Pour les compte/pages, ça va dépendre de la technologie, en voici quelques-uns :
Avant ces points là, je placerai SOLID. Qui est nécessaire pour ne pas créer des monstres incontrôlables. Notamment la partie SOL, les ID ayant tendance à conduire à la sur-ingénierie si suivis avec trop de zèle. En revanche, les trois premiers sont vitaux dans un projet qui évolue en permanence.
Woaaah, je connaissais les principes YAGNI et KISS en pratique mais pas les accronymes
J'ai noté les pattern cités : MVC, Fluent inteface, Facade, Conteneur d'injecteur de dépendance, Adapter, Decorator.
Je vais chercher des informations pour prendre connaissance de ce que je ne saispas et revoir ce que je connais déjà.
Qu'appelle-t-on serveur d'intégration continue ?
J'ai fait des recherche sur Wikipedia (https://fr.wikipedia.org/wiki/Int%C3%A9gration_continue) et c'est fort. Par contre ça doit demander des efforts pour la mise en place. C'est bien que je sache que de tels outils existent.
SOLID est toujours à rappeler (je ne connaissais que les 3 premiers niveaux, SOL) et j'ai pu revoir le principe de DRY qu'on avait vu en cours en découvrant la POO, sans nommer l'accronyme DRY cependant.
Merci beaucoup pour tes liens Lud00, Twitter, etc.
Je regarde tout ça dès que possible.
En réalité je n'ai pas de préférence, j'aime l'informatique et je veux juste apprendre pour le plaisir en réalité
En tout cas je vous remercie pour toutes vos réponses, c'est vraiment super sympa de voir des gens qui partagent comme ça !
Yep, merci Ksass`Peuk pour l'intervention, en effet SOLID est clairement à mettre en avant. Surtout les principes de single responsibility et l' open/close principle.
Comme tu t'es renseigné sur wikipedia, je te fais une explication plus pratique. Admettons, que tu es déjà un code versionné et un ensemble de tests unitaires créé. Tu réalises une nouvelle feature que tu vas push sur ta branche principale, le serveur d'intégration continue (comme jenkins ou travis), va alors pourvoir jouer l'ensemble des tests que tu as effectués avant.
Si les tests réussissent,le serveur va déployer en prod
Sinon, en fonction de ce que tu as configuré, tu peux recevoir un email ou encore directement un message sur IRC, qui t'indiquera gentillement, que tu as fait n'importe quoi lors de ton dernier commit :3
Un must have en somme ! Surtout que contrairement aux apparence, c'est assez simple à mettre en place ! Voilà, si quelqu'un a d'autres choses à ajouter n'hésiter pas !
Je fais un petit up pour demander si vous savez quels types d'informations qui doivent figurer dans le fichier README concernant un projet, pour Github ou Bitbucket par exemple ?
Salut, dans un projet open source, tu dois toujours préciser la licence. Si tu n'as pas mis de licence, alors ton projet est personnel.
Ensuite, dans un readme, si c'est pour une librairie, c'est toujours bien d'avoir un historique du pourquoi cette librairie, ainsi que les méthodes principales et des exemples pour voir comment ça fonctionne. La date, la technologie utilisée et même les softwares (moi j'aime bien ce petit détail) sont aussi importants. Le nom et des liens (Twitter, Github, ...) des contributeurs est toujours agréable.
Mettre les possibles évolutions du projet est chouette et aussi encourager (si c'est du open source) les personnes à contribuer
Merci beaucoup pour la réponse ! Bon ben le sujet est en résolu
C'est sympa ! Merci
Bonnes pratiques de développement
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
http://borntocode.fr/ - Twitter
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
http://borntocode.fr/ - Twitter