Compétences numériques utiles au-delà du dev pur ?

[Yo3258ann]

Salut,

Je bricole sur Unity depuis un moment (je m’amuse surtout avec des petits protos, côté gameplay et UI principalement), mais je me rends compte que je suis un peu à la ramasse sur des trucs périphériques, genre comment structurer proprement un projet si je devais bosser à plusieurs, ou même tout ce qui touche à la présentation en ligne, la sécurité des fichiers, etc.
Je me demandais si certains ici avaient bossé sur des projets où ces compétences-là ont vraiment compté, au-delà du code pur. Genre : gérer une com' simple, bosser en équipe, anticiper un minimum la partie "numérique responsable", ou éviter des erreurs de base sur la gestion des données.
Des retours d'expérience là-dessus ? Je me rends compte que bosser dans son coin c’est cool, mais parfois on zappe tout l’écosystème qui tourne autour.

Merci !

[boubouk50]

C'est souvent négligé, mais pour moi, tout ce qui touche à l'organisation de travail est aussi important que le code.
⇒ Un code bien pensé, bien agencé, bien structuré, bien hiérarchisé est un code facile à lire, à relire, à modifier, à réutiliser. Et c'est TRÈS important. Parce qu'un code en lui-même est un code, il fait ce pour quoi il est programmé. Mais professionnellement, tu ne vends pas du code, tu vends un produit. Et ce produit, il est qualitatif s'il est intelligemment conçu. Pourquoi ? Parce qu'un client va vouloir le modifier, l'améliorer, le développer. Et ça peut arriver quelques années après conception, et il faudra se replonger dans le code. Un code peu lisible est difficile à reprendre, un code figé est peu modifiable, peu expansible. Et c'est une réelle peine de devoir tout reprendre.
Aussi, parce que le jour où tu vas reprendre le code de quelqu'un d'autre qui n'aura pas fait bien les choses, tu vas avoir envie de l'éventrer pour aller chercher ses yeux par l'intérieur en tirant sur les nerfs optiques et les lui faire bouffer (tu comprends par ces mots, mon traumatisme de développeur qui reprend les projets d'autrui).
Aussi, parce que tu seras amené à développer pour ou avec d'autres développeurs et que vous devrez vous imposer une structure, une rigueur de travail pour que vos codes puissent s'intégrer correctement ensemble.
Enfin, parce qu'un développeur qui maîtrise tous les aspects périphériques ne pissera pas du code toute sa vie, il sera voué à décider des développements, à gérer des équipes, bref à superviser.
Donc : (outil de) Versionning / Design Pattern / Architecture / Nomenclature / Veille technologique

[Yo3258ann]

Merci beaucoup pour ton retour, super clair et bien senti (mention spéciale pour l’image des nerfs optiques ).
C’est exactement le genre de réalité que j’avais en tête, et ça fait du bien d’entendre que tout ce qui tourne autour du code "pur" est aussi fondamental. On a parfois l'impression que c’est du bonus, alors que c’est juste indispensable dès qu’on sort du cadre solo.
Dans cette optique, je suis tombé récemment sur une initiative intéressante qui va dans ce sens, autour du numérique responsable, de la structuration de projets et de la collaboration (bienvenum.org). C’est encore en construction sur certains aspects, mais je trouve que ça pose des bases utiles pour réfléchir au métier dans sa globalité.
Curieux d’avoir d’autres retours aussi, notamment sur les outils ou méthodes que vous avez testés (bons ou mauvais).

[boubouk50]

Ton site n'offre que des formations payantes non pas sur les compétences périphériques du métier de développeur, mais sur du marketing essentiellement. Donc d'un tout autre métier.