Pause café n°13 : Ce que tout débutant en programmation devrait savoir ; 4 façons d'intégrer le Design Thinking dans votre processus de développement

Ce que tout débutant en programmation devrait savoir

Source : Stackoverflow En tant que développeur, vous entendrez de nombreuses théories différentes sur ce à quoi devrait ressembler le code. Certaines personnes pensent que moins une application contient de lignes de code, plus elle est facile à lire. Mais cela n’est que partiellement vrai. Je préfère évaluer la qualité du code en utilisant les critères suivants :

1. Le code doit être cohérent, informatif et bien documenté.
2. Le code doit utiliser des fonctionnalités stables et modernes.
3. Le code ne doit pas être inutilement complexe ou brisé.

Si vous décidez de réduire le nombre de lignes de code au détriment d’un des critères ci-dessus, cela deviendra un problème. Ne faites pas cela.

Lire le code de quelqu'un d'autre est difficile

En effet, le rapport entre le temps passé à lire et à écrire du code est supérieur à 10 pour 1. Mais on ne peut pas se passer de lire le code des autres. Vous devrez lire le code de quelqu'un d'autre. Et plus tôt vous améliorerez vos compétences, mieux ce sera. Essayez d'étudier le code d'autres personnes en utilisant les référentiels GitHub ouverts. Vous pouvez vous entraîner à tout moment : trouvez simplement un projet qui vous convient et approfondissez chaque ligne. Une autre façon d'améliorer votre capacité à lire le code des autres est de commencer à copier le style. Lorsque vous écrivez du code dans le style de quelqu'un d'autre, cela améliore non seulement vos compétences en lecture, mais vous rend également le code plus familier. Essaie.

Vous n’écrirez jamais de code « parfait »

J'ai été développeur solo pendant quatre ans avant de commencer à travailler en équipe. Pendant la majeure partie de ce temps, j'ai cru que tout programmeur expérimenté écrivait un code parfait. À mon avis, apprendre à écrire un code parfait n’est qu’une question de temps et d’efforts. Mais lorsque j’ai rejoint l’équipe, il est devenu évident que personne n’écrivait de code « parfait ». Il est vrai que le code finalement inclus dans le système était presque toujours « parfait ». Pourquoi est-ce arrivé? Tout est question d'analyse de code. Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants que l’on puisse embaucher. Mais chacun d'entre eux (moi y compris) aurait une véritable crise de panique si quelqu'un suggérait d'inclure du code non testé dans l'application. Même si vous pensez être le prochain Bill Gates, vous ferez des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manquants. Des choses que parfois votre cerveau ne capte tout simplement pas. Des choses qui ne peuvent être remarquées qu’avec un regard neuf. Efforcez-vous de travailler avec des personnes attentives aux détails et disposées à critiquer votre travail. Il sera difficile d’accepter les critiques au début, mais c’est le seul moyen fiable d’améliorer la qualité de votre code. Faites de votre mieux pour ne pas être sur la défensive lors de la révision du code et ne prenez jamais les critiques personnellement. Vous n'êtes pas votre code.

Vous ne devriez pas écrire de code 8 heures par jour

Personne ne peut vous dire exactement combien de temps ils passent par jour à écrire du code. Mais en réalité, peu de gens écrivent du code plus de 4 heures par jour. Les personnes qui ne sont pas d’accord avec cela font soit l’exception à la règle, soit travaillent pour des entreprises qui traitent mal leur personnel. La programmation est un travail intense et épuisant mentalement. Il est complètement faux de penser que quelqu’un écrira du code 8 heures par jour, 5 jours par semaine. Il y aura de rares occasions où vous devrez respecter un délai, mais quand je dis rarement, je veux dire presque jamais. Ne laissez pas le travail vous alourdir et vous obliger à faire des heures supplémentaires. Je ne suggère pas que vous travailliez seulement quatre heures par jour. Il est généralement préférable de consacrer les quatre heures restantes à des tâches telles que :

• apprendre de nouveaux outils, fonctions, applications ;
• discuter des processus de travail avec des collègues ;
• aider les collègues qui rencontrent des difficultés au travail;
• planification des tâches ;
• analyse de codes ;
• réunions/réunions d'affaires.

Je recommande également fortement de prendre des pauses régulières tout au long de la journée et de faire de l'exercice (au moins un peu). Les effets positifs de l’exercice sont prouvés depuis longtemps.

4 façons d'intégrer le Design Thinking dans votre processus de développement

Source Tech Beacon Pour créer un produit qui répond aux besoins de vos clients, vous devrez considérer ce qu'ils veulent. Si vous avez écrit une application avec une navigation confuse ou une interface de chargement inutilement longue, préparez-vous à un échec futur. En tant que programmeur, vous devrez peut-être approfondir la conception du produit sur lequel votre équipe travaille. Ce type de collaboration est très utile car chacun remarque des choses que l’autre ne remarque peut-être pas. Je vous propose 4 conseils sur la façon dont un développeur et un concepteur peuvent travailler ensemble.

1. Impliquez-vous dès le début

Ne présumez pas que la conception vient toujours en premier et que le développement vient en second. Cela est peut-être vrai, mais cela ne signifie pas que les développeurs ne devraient pas être impliqués dans le processus de conception. Le programmeur est capable de fournir des informations techniques importantes sur la manière dont le projet peut être mis en œuvre, tandis que les concepteurs comprennent mieux les désirs des utilisateurs. Il est préférable de déterminer le plus tôt possible quelle fonction est techniquement impossible ou ne répond pas aux besoins des utilisateurs. Si les concepteurs et les développeurs travaillent ensemble, les problèmes peuvent être découverts et résolus immédiatement plutôt qu'après l'approbation de la conception. De nombreuses entreprises adoptent une approche collaborative du développement de logiciels. Cela signifie que les membres de l'équipe ne sont pas seulement responsables de leur propre étape ou morceau de code, mais assument la responsabilité collective de tout, de la conception aux tests.

2. Apprenez le processus UX

Ceux qui ne sont pas familiers avec l’UX (expérience utilisateur) ne comprendront peut-être pas pourquoi les équipes changent encore et encore de conception pour des détails apparemment mineurs. Chaque étape du processus UX se déroule pour une seule raison : offrir la meilleure expérience possible à l'utilisateur. Il est donc important de prêter attention à la création d’un processus UX dès le début. Il peut inclure :

• rechercher le but du projet;
• créer un wireframe - une conception simple qui vous permet de déterminer les principales caractéristiques du produit ;
• ajouter des détails plus fins à la conception du projet, tels que l'interface utilisateur ;
• tests utilisateur des conceptions. C’est peut-être l’étape la plus importante du développement UX. Cela fournit des informations précieuses sur le produit avant que vous passiez du temps à le développer ;
• Itération : à l'aide de l'analyse des résultats des tests, itérez la conception pour améliorer l'expérience utilisateur.

Les équipes répètent les étapes de conception et de test plusieurs fois jusqu'à ce qu'il n'y ait plus de modifications, ou si le temps le permet. Cela signifie généralement que vous disposerez de plusieurs versions du design.

3. Suivez le développement de la conception

C'est très mauvais lorsque les concepteurs créent un projet sans consulter les développeurs. C'est contre-productif. Il est important pour DevOps de définir des règles afin que les développeurs aient accès aux plans de conception dans des formats facilement accessibles tels que PNG ou PDF. Une collaboration efficace entre développeurs et concepteurs est essentielle à la réussite de la mise en œuvre d’une application. Évitez à tout prix de remettre aveuglément un design fini. Il vaut mieux corriger une erreur au début plutôt qu’à la fin.

4. Convenez de l'étape à laquelle le projet vous sera présenté

Lorsqu'il est demandé aux développeurs de créer une version minimale viable d'un produit (MVP), ils doivent connaître dès le début les exigences de la version finale. Cela est nécessaire pour éviter les problèmes d'attentes injustifiées. Les concepteurs doivent montrer les deux versions de la conception au développeur : à la fois le MVP et la version finale. Cela aidera à mettre en œuvre le MVP, en tenant compte de ce que le client s'attend à voir dans la version finale. Lorsque les concepteurs et les développeurs travaillent ensemble, ils bénéficient de nombreux avantages. Chacun d’eux possède des connaissances qui peuvent être appliquées à l’expérience de l’autre. Les développeurs peuvent fournir des informations précieuses sur les fonctionnalités qui ne peuvent pas être implémentées dans la conception. D'autre part, la collaboration avec un programmeur évitera au concepteur de refaire le projet, ce qui fera ainsi gagner du temps à toute l'équipe.