Azure Native Qumulo Maintenant disponible dans l'UE, au Royaume-Uni et au Canada - En savoir plus

5 pratiques d'ingénierie étonnantes qui mènent à une excellente interface utilisateur chez Qumulo

Rédigé par:

Avant de venir à Qumulo, j'étais devenu un ingénieur logiciel travaillant sur l'interface utilisateur dans d'autres sociétés, et j'ai abandonné les bonnes pratiques d'ingénierie. Je me suis senti comme Code Monkey pendant une grande partie de ma carrière, travailler dur pour respecter les échéances et construire, ne laissant aucun temps pour une bonne ingénierie.

Cela a changé à Qumulo. Nous travaillons sur un produit profondément technique, et la qualité est soutenue par de bonnes pratiques d'ingénierie. Et bien que suivre ces pratiques puisse sembler lent lorsque nous le faisons, à long terme, elles nous aident vraiment à aller vite.

5 meilleures pratiques d'ingénierie 

Vous trouverez ci-dessous 5 meilleures pratiques d'ingénierie que nous suivons et qui responsabilisent tous ceux qui travaillent chez Qumulo.

1. Nous travaillons ensemble en équipe

Qumulo est ma première expérience où les équipes fonctionnent vraiment en équipe. Parce que nous travaillons dans une organisation plate sans gestionnaires, nos équipes travaillent ensemble en exigeant un consensus dans les décisions. Les membres de l'équipe peuvent également décider de la manière dont ils souhaitent travailler les uns avec les autres grâce à des accords de travail; Cela comprend les heures de travail, comment l'équipe suit le travail et comment les conflits sont résolus.

Pour l'interface utilisateur et l'expérience utilisateur, après avoir appris à travers des expériences et des itérations, nous avons introduit des sprints de conception pour aider à créer des maquettes pour la conception et le flux de notre interface utilisateur. Concevoir ensemble nous permet de comprendre comment nous sommes arrivés à une décision parce que tout le monde était impliqué, donc nous continuons à prendre de bonnes décisions à l'avenir et ne finissons pas par partager le contexte et remettre en question les décisions après coup.

2. Nous possédons la base de code

Lorsque je trouve un problème dans notre code, je suis habilité à trouver un moyen de le résoudre car nous, en tant qu'ingénieurs, possédons cette base de code. En conséquence, nous nettoyons après nous-mêmes et corrigeons les petits bogues que nous trouvons, et nous nous efforçons de résoudre les problèmes plus importants - je peux améliorer les outils pour aider à faire le travail que je dois faire.

Comparez cela avec une grande société de logiciels dans laquelle je travaillais: une fois que j'ai trouvé un simple bogue à 1 ligne en travaillant sur une tâche, j'ai décidé d'incorporer le correctif dans mon changement (aujourd'hui, je ferais bien sûr un correctif séparé). Un PM est venu une semaine plus tard pour me demander pourquoi j'avais corrigé un bogue qui n'était «pas approuvé» à corriger, et que j'allais avoir des ennuis et que je ferais mieux d'annuler ce changement. Je suis content d'avoir quitté CETTE entreprise!

3. Nous travaillons en binôme

Ce n'est pas seulement de la programmation, mais comprend également la conception et l'investigation. Nous utilisons notre temps de préparation quotidien pour organiser des paires et pour que les paires restent responsables.

Travailler par paires nous permet de bénéficier de différentes perspectives tout en travaillant sur un problème, la solution finale est donc plus complète. Semblable au travail d'équipe que j'ai décrit ci-dessus, travailler en binôme nous aide également à partager le contexte, ce qui empêche une personne d'être un goulot d'étranglement et prend en charge notre politique de vacances illimitée. Je sais que mon équipe sait déjà tout ce que je sais.

4. Nous pensons et travaillons par petites touches

Nos modifications de code sont dans des correctifs, et nous souhaitons que chaque correctif de code fasse une chose et ne contienne qu’un seul concept - par exemple, un correctif pour le changement de variable et un correctif pour un correctif. Un refactor volumineux se décompose parfois en dizaines de patchs où chaque patch exprime une très petite modification, mais la pile de patchs se transforme en un refactor important. Nos systèmes de contrôle de version et de révision de code nous aident à travailler avec de petits correctifs. Cela signifie que nous examinons de petits correctifs dans tous les contextes, ce qui nous permet de comprendre rapidement les correctifs.

5. Nous sommes obsédés par les tests

Les tests aident à vérifier que notre code fonctionne correctement. Ils s'assurent que notre refactor a été fait correctement, et ils nous gardent en sécurité lorsque les changements de code ont des conséquences imprévues.

Cette année, nous avons effectué quelques mises à niveau majeures de notre base de code d'interface utilisateur: nous avons activé TypeScript, et nos tests nous ont donné l'assurance que notre migration n'entraînait pas de problèmes prévus dans notre code existant. Nous avons également mis à niveau React et avons pu vérifier que la mise à niveau vers la dernière version de React 15 fonctionnait bien, et les tests échoués ont confirmé que nous devions faire plus d'efforts pour effacer les changements avant la mise à niveau de React 16.

Ces pratiques me permettent d'être un membre habilité de mon équipe et de Qumulo. Je suis encouragé à écrire du bon code avec des tests, à créer un framework et des outils pour m'aider à faire du bon travail, et à prendre le temps de partager et de travailler avec mes coéquipiers. Ces pratiques sont devenues une partie de mon métier en tant qu'ingénieur, et c'est très excitant de travailler dans un endroit où je suis encouragé à bien faire mon travail - pas ma production. J'ai l'impression d'apprendre et de grandir tout le temps chez Qumulo, et j'adore le sentiment qu'avec chaque jour, je deviens un meilleur ingénieur.

 

Articles Similaires

Remonter en haut