Pour gagner un contrat, le code doit être compliqué ?
Joanna Carter
Membre, Modérateur
Bonsoir mes potes.
Je viens de répondre à une requête pour un développeur dont le proposer m'a demandé de lui envoyer quelques classes, etc, afin qu'il puisse évaluer mes compétences en coding
En réponse, il m'a dit qu'il a trouvé mon code "rudimentaire" ::)
Je ne sais pas comment on peut déterminer la complexité de code, si on ne peut pas voir l'entièreté d'un projet ; les code Objective-C que j'ai envoyé n'était que deux classes d'un projet qui contient, au moins 462 classes, protocoles, etc.
Il ne s'intéressait pas dans le C# mais là , j'ai un projet avec plus de 1 214 classes, interface, enums, events, etc ; et ça, ce n'était que les frameworks qui faisaient les fondations du projet principal.
Mais, moi, parmi tous ce code, tous les classes, etc sont, pour la plupart simples ; c'est comment elles sont connectées qui fait la complexité.
De mon avis, si on ne peut pas lire facilement le code, on a fait un grand bol de spaghetti 8--)
Qu'en pensez-vous ?
Réponses
Bonjour,
A mon avis plus les classes sont simple plus le developper est talentueux. Est ce qu'il dit n'a aucun fondement vu que le principal finalement c'est que la classe fasse le boulot qu'on lui a demander.
Le code compliqué ne sert pas à gagner un contrat, mais à le conserver longtemps longtemps... c'en est même une assurance contre le chômage pour certains ;-)
Des tas de choses très méchantes sur cet évaluateur.
Faire compliqué, c'est simple !
Faire simple, c'est compliqué !
Quand je vois ce qui est fait dans certaines grandes multinationales le code n'a pas vraiment besoin d'être ni beau ni long ni robuste.
J'ai parfois honte de ce que je suis obligeÌ de faire pour tenir des délais ou de voir ce que d'autres ont du faire dans des conditions similaires.
Réponds-lui ceci tu as tout à fait raison.
La complexité est rarement dans la classe et souvent plus dans l'architecture !
Est-ce qu'il s'agit de la personne qui a posté ici il y a quelques jours (qui cherche des collaborateurs) ?
En fait, tu aurais dus envoyer 3 niveaux de classes, avec une explication sur l'architecture de l'application :
- Quelques classes de briques primitives tout en bas de l'architecture
- Quelques classes de haut niveau de ton framework, basées sur les briques
- Quelques classes du projet utilisateur, exploitant le framework
Histoire de montrer que tu n'est pas qu'une simple codeuse produisant du code "rudimentaire".
Mon évaluation de l'évaluateur serait assez mauvaise ! Ne serait-ce pas un gars qui cherche à en avoir un max pour rien ? Bon après il n'y a pas lieu de fournir trop de truc tant qu'il n'y a pas de contrat signé !
T'as raison là . Comme plusieurs fois précédentes, c'était mon tarif qui lui a fait peur et il a dû chercher une excuse
Il y a fort fort longtemps, à mes débuts dans le code j'ai rencontré un indépendant qui évaluait son tarif en nombre de lignes de codes. A ce moment là je trouvais cela pertinent, facile à mettre en oe“uvre et à facturer. C'était bien avant la programmation orienté objet.
Aujourd'hui, plus mon code est cours, plus mon code est simple, plus je suis fier de moi. J'adore voir dans des outils comme GitHub les statistiques de code. Je ne suis jamais aussi fier de moi que quand j'ai supprimé des dizaines de lignes de code pour arrivé au même résultat.
Je me fixe comme règle qu'une fonction doit toujours être lu d'un seul trait à l'écran et que mes classes ne doivent pas excéder quelques pages. J'essaye systématiquement de réduire la longueur de mon code pour pouvoir le lire, le relire et donc le maintenir facilement.
Aujourd'hui si je devais évaluer un code je me pencherai beaucoup plus sur l'architecture que sur le code à proprement parlé.
Ceroce est tellement vrai
C'est difficile de faire un code qui plait à tout le monde mais je pense que tout le monde s'accorde à dire que plus il est simple mieux c'est.
On part d'un événement et on peut suivre jusqu'au résultat sans avoir à changer 15 fois de fichiers et de classes.
Je dis attention avec des principes comme le Single Responsability Principl qui peut multiplier le nombre d'objets si trop respecté. C'est un peu comme dans l'administration quand il faut passer par 15 guichets pour obtenir quelque chose.
C'est là que tu te rends compte du gros décalage qui existe entre les centres de formation (universités, école d'ingé) et la réalité du terrain... Faire au plus vite devant des demandes fonctionnelles qui ne tiennent pas la route...
ça paraà®t une bonne idée mais ce n'est pas toujours possible.
e.g. Observer Pattern
On a une classe/struct, qui est le modèle, et plusieurs vues qui doit être mis à jour à chaque changement dans le modèle. Du coup, on utiliserait NotificationCenter pour inscrire les vues aux notifications du modèle. Maintenant, on aurait l'envoie d'un notification que l'on ne puisse pas "suivre" directement.
Même, en utilisant les delegates, il faudrait appeler une méthode du delegate dans une classe/struct et, facultativement, le traiter dans une autre classe/struct. Mais, s'il y avait une hiérarchie de classes, ou, même, un type qui implémente un protocole, sur la côté recevante, on ne pourrait pas le suivre encore.
Moi, j'écris, entre autres choses, les frameworks et, là , on a déjà un répartition de fonctionnalités entre le framework et l'appli qui l'utilise ; par exemple, UITableView et son delegate ou dataSource.
Mais ce qui est important, c'est que l'on puisse lire et comprendre le code de chaque fichier comme code autonome ; si nécessaire, en ajoutant les commentaires.
Malheureusement, il y a les boà®tes qui ne veulent que la vitesse. Mais, là , ils ne pensent pas de l'avenir et ils créent une énorme "dette technique" de court-circuits dont ils parlent "on le refera plus tard" ::)
Il y a quelques ans, j'ai travailler comme consultante dans une boà®te dont le gérant de projet était un type qui utilisait Microsoft Project pour la gestion. Le problème était que, avec cet outil, le projet est considéré comme une ligne droite avec les phases de travail. Mais le bon développement prend souvent les boucles de : design, code, test, redesign, etc. Il m'a demandé, "combien de temps faut-il compter pour une phase" et il a été étonné quand je lui ai répondu, "pour la première boucle..." 8--)
Je parle souvent de la choix pour un projet - on a : la vitesse, la qualité, le coût ; on ne peux avoir que deux des trois :-*