Comment puis-je convaincre mon patron que l'ANSI C est inadéquat pour notre nouveau projet?
Il y a quelques mois, nous avons commencé à développer une application pour contrôler un équipement de test développé en interne et enregistrer un ensemble de mesures. Il devrait avoir une interface utilisateur simple et nécessiterait probablement des threads en raison de l'enregistrement continu qui doit avoir lieu. Cette application sera utilisée pendant quelques années et sera maintenue par un certain nombre d'étudiants en informatique pendant cette période.
Notre patron a obtenu son diplôme il y a une trentaine d'années (pour ne pas être considéré comme une infraction; j'ai aussi plus de la moitié de ce temps sur le dos) et a mandaté que nous développions cette application dans l'ANSI C. La raison en est qu'il est le seul à sera autour de tout le temps, et donc il doit être capable de comprendre ce que nous faisons. Il a également décidé que nous ne devrions utiliser aucun type de données abstrait; il nous a même donné une liste avec le nom des variables globales (soupir) qu'il veut que nous utilisions.
J'ai en fait essayé cette approche pendant un certain temps, mais cela me ralentissait vraiment pour m'assurer que toutes les opérations de pointeur étaient sûres et que toutes les chaînes avaient la bonne taille. De plus, le nombre de lignes de code qui étaient réellement liées au problème en cours n'était qu'une petite fraction de notre base de code. Après quelques jours, j'ai mis au rebut le tout et j'ai recommencé à utiliser C #. Notre patron a déjà vu le programme fonctionner et il aime la façon dont il fonctionne, mais il ne sait pas qu'il est écrit dans une autre langue.
La semaine prochaine, nous nous rencontrerons tous les deux pour revoir le code source, afin qu'il "sache comment le maintenir". J'ai un peu peur et j'aimerais avoir de vos commentaires quels arguments je pourrais utiliser pour appuyer ma décision.
Lâche vôtre,
Notez que le "Veuillez le faire comme ceci, donc je suis sûr I peut le maintenir" est en fait une très bonne exigence - la plupart des programmes passent beaucoup plus de temps à être maintenus que être écrit et conserver une solution dans une technologie connue est généralement une bonne idée.
Imaginez simplement qu'un nouveau gamin de l'informatique, lorsqu'on lui a demandé d'écrire une application C #, l'a écrite dans Haskell en deux jours et a dit "Hé, ça marche et je suis parti, bye" en vous laissant la maintenance.
Imaginez simplement si un nouvel enfant de l'informatique, lorsqu'on lui a demandé d'écrire une application ANSI C il y a 15 ans, l'avait écrite dans Visual Basic 6 en deux jours et l'avait laissée. Vous devez maintenant le maintenir et Windows 7 commence déjà à se plaindre lorsque le support d'installation est inséré.
Cela pourrait être une bonne occasion de dire - comme Heinzi l'a laissé entendre dans les commentaires - que "ceci est un prototype rapide écrit en C # qui ressemble beaucoup à C - devons-nous le préparer à la production, ou le réimplémenter en C ANSI comme vous demandé ", puis prenez la discussion maintenant. Avoir une source réelle à voir, c'est bien mieux que "Hé, ne devrions-nous pas écrire notre prochaine application en Haskell parce que c'est plus rapide".
En d'autres termes, vous avez maintenant la possibilité de démontrer qu'une nouvelle plateforme pourrait être envisagée. Apportez que vous avez écrit un prototype avant la révision du code - cela aidera à supprimer l'impression que vous essayez de glisser C # sous le radar. Je suggère que vous démontriez également que tout le code existant écrit en C ANSI peut être utilisé à partir de C #. Personnellement, je pense qu'on vous dira que la cible reste ANSI C pour rester sur une seule plateforme.
Votre patron semble être votre client dans ce cas, et sa principale exigence est qu'il soit en mesure de maintenir l'application lorsque vous passez. Cela semble tout à fait raisonnable.
Ainsi, le choix est de faire ce qu'il demande, ou de démontrer que vous pouvez terminer le développement ET lui apprendre à maintenir une application C # dans les délais et à moindre coût. Si vous ne pouvez pas le faire, vous ne répondez pas aux exigences du projet.
Vous n'avez pas donné beaucoup d'informations mais je pense que C est absolument le bon choix - je travaille en tant qu'ingénieur dans une usine industrielle et la plupart (sinon la totalité) de notre code est écrit en C. Si vous avez besoin d'obtenir des mesures de un appareil (je suppose un débitmètre ou un thermocouple ou similaire ici) et l'afficher en C presque en temps réel est un excellent choix.
C'est rapide, portable (je n'ai jamais écrit en C # mais je ne pense pas que cela fonctionne sans une version particulière du framework installée et il n'est généralement basé que sur Windows).
Vous pouvez certainement utiliser une autre langue pour faire l'interface graphique. Mais vous pourriez vous épargner l'effort et simplement utiliser un package de tendances préexistant (il existe de bons logiciels open source disponibles).
Pour résumer, je dirais que pour l'interface sous-jacente avec la partie matérielle C, c'est un bon choix.
Oh cher. Ceci est une application en temps réel? Vous contrôlez l'équipement en temps réel? Collecte de données en temps réel? Vous utilisez une langue avec un garbage collector? Oh cher.
Bien que je convienne que vous pouvez probablement faire l'application dans une langue plus moderne en moins de temps, ce n'est probablement pas le critère principal. FACILITÉ DE VOTRE PROGRAMMATION IS PROBABLEMENT MOINS IMPORTANT QUE LES AUTRES CRITÈRES, tels que ceux définis par votre patron, ET le temps de réponse, et le comportement déterministe.
J'aurais suggéré que vous fassiez un prototype en C # ou Python, juste pour tester les fonctionnalités principales et l'interface utilisateur. PUIS tester le diable hors de lui, mesurer les latences réelles et les temps de réponse, lorsque l'application est frappée avec beaucoup de données, sur plusieurs jours de fonctionnement continu. Il y a fort à parier que l'application pourrait finir par être trop lente ou prendre du retard à des moments aléatoires, lorsque VM ou le garbage collector intervient.
Je vous suggère de présenter ce que vous avez fait en tant que PROTOTYPE.
Le codage en C n'est pas si difficile. Si vous n'êtes pas à la hauteur, dites-le. Nous sommes nombreux à relever le défi. (Je fais du codage C en temps réel depuis maintenant des décennies).
Eh bien, la première chose à faire est d’aller voir votre patron et de vous en faire une idée. Vous avez ignoré sa demande claire, et pire encore depuis des mois. Je ne sais pas combien de temps vous avez consacré à cela, mais en supposant que c'est la plupart du temps alloué à la réalisation du projet, vous devez faire face au fait que vous pourriez bientôt chercher un nouvel emploi.
Le plus tôt vous vous en occuperez, mieux ce sera.
Deuxièmement, je ne pense pas que vous puissiez le convaincre que l'ANSI C est inadéquat, ce que vous devez faire est de le convaincre de plusieurs autres choses (1) que c # est adéquat, (2) il peut facilement apprendre à maintenir c #, (3 ) que vous étaient inadéquats pour l'écrire en C. En supposant que vous ayez encore un travail et un rôle à jouer avec ce projet, je me concentrerais sur 2, en soulignant les similitudes entre c et c #.
Citations en réponse aux commentaires ...
Il y a quelques mois, nous avons commencé à développer une application [...] Après quelques jours, j'ai mis au rebut le tout et j'ai recommencé à utiliser C #
a mandaté que nous développions cette application dans ANSI C. La raison est qu'il est le seul qui sera présent tout le temps, et qu'il doit donc être capable de comprendre ce que nous faisons.
Il s'agit d'une exigence assez raisonnable.
Il a également décidé que nous ne devrions utiliser aucun type de données abstrait;
Cela n'a aucun sens. Maintenant, cela commence à sentir un peu suspect, car c'est une exigence de conception de programme et non une exigence de langue. Si le code doit être facile à maintenir, à mettre en œuvre des ADT ou à utiliser des tests bien testés, ceux qui existent déjà devraient être une priorité.
il nous a même donné une liste avec le nom des variables globales (soupir) qu'il veut que nous utilisions.
Ok, alors maintenant ça pue. Nous pouvons maintenant dire que votre patron a une expérience limitée non seulement de divers langages de programmation, mais de la programmation en général. Un programmeur chevronné et expérimenté, quelle que soit sa langue, ne ferait jamais une telle déclaration. (La seule exception à laquelle je peux penser est si la plupart du code est destiné à fonctionner sur un système embarqué assez petit, et donc que tout la mémoire de travail nécessaire pour le code devait être pré-allouée L'idée que le même code devrait avoir une interface utilisateur au niveau de l'écran est fortement contre cela, cependant).
Je suppose que votre patron n'a jamais été impliqué dans des projets logiciels à grande échelle et critiques, mais il a plus probablement flotté dans divers projets de faible qualité.
Cela n'a donc rien à voir avec le langage de programmation C. Vous pouvez également facilement écrire des programmes tout aussi épineux en C #. C'est une erreur très courante de croire qu'une bonne conception de programme dépend de la langue. Ce n'est tout simplement pas vrai!
C # a certainement une syntaxe plus jolie, plus propre et moins obscure que C. Il a beaucoup de support de conception de programme, car il a beaucoup plus de mots-clés liés à OO que C. Mais à part cela, il ne vous dit pas comment = pour écrire vos programmes. Si vous pensez que tout ce qui est écrit en C est horrible par défaut et tout ce qui est écrit en C # est paradisiaque par défaut, je parie que vous écrivez actuellement des programmes C # plutôt horribles sans vous en rendre compte.
Ce que je suggérerais, c'est que vous fassiez une conception de programme abstraite, indépendante du langage, mais détaillée avant toute autre chose. Utilisez l'approche normale et orientée objet. Quels objets sont là et comment communiquent-ils entre eux, quelles sont les dépendances nécessaires, etc. etc. Lorsque vous avez suffisamment réfléchi à la conception du programme et l'avoir noté sur papier, cela ne devrait pas vous préoccuper ni langue dans laquelle vous avez choisi de l'implémenter.
Le premier problème que vous devez aborder est émotionnel et irrationnel. L'industrie informatique est en constante évolution et, bien qu'il y ait de la place pour tout, refuser d'améliorer ou d'embrasser le changement est un problème.
Pourquoi votre patron s'accroche-t-il à ANSI C? Si c'est la seule langue qu'il connaît, il est peut-être temps de changer, mais un argument rationnel peut être insuffisant. Votre patron se sentira-t-il sous-évalué ou peut-être renvoyé s'il est contraint de travailler dans une langue inconnue? Soulignez l'expérience qu'il a et les autres avantages qu'il apporte.
Si vous ne résolvez pas ce problème, tous les arguments rationnels que vous pouvez apporter seront gaspillés. En tant que subordonné, vous n'êtes peut-être pas celui qui peut avoir cette discussion avec lui. Peut-être aborder ce sujet avec l'un des autres gestionnaires, s'il y en a.
Considérez-le également de votre point de vue. Pourquoi voulez-vous utiliser C #? Dans quelle mesure est le désir d'utiliser quelque chose de nouveau et de cool? Soit honnête avec toi. Si vous le reconnaissez, cela vous aidera à discuter plus efficacement.
Le deuxième problème est celui du risque et du coût. L'écriture de logiciels coûte cher et le choix de la langue en est un facteur majeur. Considérer:
- Combien de temps faut-il pour écrire en C # contre C? Avec une orientation d'objet plus facile et une meilleure récupération de place, C # peut être plus facile. Cependant, si l'application utilise de nombreux appels d'API non gérés, C peut être plus facile.
- Si vous utilisez C #, devez-vous acheter des outils supplémentaires? Il semble que vous utilisiez déjà Visual Studio, mais avez-vous besoin d'outils supplémentaires pour la localisation, la révision et l'analyse de code, le débogage, etc.?
- Est-il facile à entretenir? Si vous trouvez un bug, à quelle vitesse peut-il être corrigé. C # peut réduire cette orientation d'objet. La collecte automatique des déchets évite également la plupart des problèmes de fuite de mémoire et de pointeur.
- Est-il facile à supporter? Si vous avez du personnel de support, ils savent peut-être lire un vidage sur incident, mais savent-ils comment utiliser windbg avec SOS? Les machines cibles ont-elles déjà une version appropriée du framework .Net installée?
- Pensez à la dotation. Combien de personnes connaissent C contre C #? Si l'un d'entre vous ou les deux quittaient l'organisation, serait-il facile de vous remplacer? Les développeurs C sont-ils moins chers ou plus chers que les développeurs C #?
Je pourrais continuer, mais le but est d'arrêter de discuter sur les mérites techniques des langues seules. Les mérites techniques sont des choses que vous seul et votre patron comprenez. Si vous commencez à parler de l'impact sur les entreprises, vous attirez un groupe de personnes beaucoup plus large et faites un argument beaucoup plus convaincant.
Peut-être que C est un meilleur choix. C # n'est pas automatiquement meilleur dans toutes les situations. Peut-être que vous faites ce projet en utilisant C mais faites une preuve de concept C # pour le prochain. N'oubliez pas que vous pouvez perdre la bataille mais toujours gagner la guerre aussi.
Vous n'avez absolument pas réussi à nous convaincre que l'ANSI C était inadéquat. C est un excellent langage qui semble adapté au type de tâches que vous avez décrites. Avec la brève description de la tâche (à l'exception des exigences linguistiques), je recommanderais également C (ou peut-être aller).
Je pense que le problème est que vous programmiez en C avec votre esprit en C #. J'ai un problème similaire lorsque je passe de Perl à C ou Java. Vous devez apprendre à vous adapter à la langue et non à traduire de votre façon de penser vers la langue du jour.
Le problème n'est pas votre patron ou le langage C, le problème est d'ouvrir votre esprit vers différentes façons de penser. Changer de langage de programmation vous sera bénéfique.
Peut-être un autre argument: il est probablement très difficile de trouver des étudiants en informatique qui ont suffisamment d'expérience pour écrire du code C sans faire d'erreurs. L'ANSI C n'est pas la première chose que les gens apprennent aujourd'hui.
Maintenant, tous les étudiants en informatique vont me tuer.
Tout d'abord, vous devez dire à votre patron que c'est dans une langue différente, maintenant. Il sera (naturellement) en colère si vous rapportez quelque chose à dessein contre les exigences sans préavis.
Maintenant, la meilleure façon d'expliquer ces choses aux patrons/managers est de le dire en termes de temps et d'argent. Estimez combien de temps un tel projet prendrait dans ANSI C, puis estimez combien de temps cela prendrait dans un niveau supérieur tel que C #. Notez que j'ai dit un niveau supérieur, pas moderne. Cela peut également aider à lisser les choses. Je veux dire, vous ne vous attaqueriez pas à peindre une pièce avec juste un minuscule pinceau, vous utiliseriez des rouleaux et d'autres choses qui font que chaque trait (ligne de code) couvre une plus grande partie du projet. De plus, si vous ou l'un des membres de votre équipe ne connaissez pas C, ou que vous êtes à l'aise pour faire un grand projet en C, cela ronge encore plus le problème de temps car ils devront se mettre au courant.
Il semble également que votre patron essaie de microgérer. Je suis sûr que l'une des autres réponses tentera d'expliquer comment amener votre patron à faire moins
L'aversion des superviseurs pour les ADT a été abordée ailleurs, tout comme la méconnaissance apparente du développeur concernant les coûts du GC, donc je vais me concentrer sur les "threads".
Peut-être plutôt que de penser en termes de threading .NET (ou JVM, si cela est si endoctriné), ce que vous voudrez peut-être, c'est plusieurs processus, en utilisant un mécanisme de communication inter-processus (IPC) pour communiquer entre eux. Par exemple: messages Windows, mémoire partagée, mémoire tampon de fichiers mappés en mémoire, canal nommé, etc. Consacrez de petits processus à interagir avec un périphérique ou un aspect du périphérique et à vérifier les IPC pour communiquer les mises à jour et accuser réception des demandes, et disposer d'un processus un peu plus large pour maintenir l'interface graphique et communiquer avec les moniteurs de l'équipement. "en utilisant ce que IPC vous sélectionnez.