Comment puis-je convaincre mon patron que la norme ANSI C est inadéquate pour notre nouveau projet? [fermé]

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 plusieurs étudiants en informatique au cours de cette période.

Notre patron a obtenu son diplôme il y a environ 30 ans (pour ne pas être considéré comme une infraction; j'ai également plus de la moitié de ce temps sur le dos) et a demandé que nous développions cette application dans ANSI C. La raison en est qu'il est le seul sera tout le temps, et par conséquent, 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 moment, mais cela me ralentissait vraiment pour m'assurer que toutes les opérations de pointeur étaient sécurisées et que toutes les chaînes avaient la bonne taille. De plus, le nombre de lignes de code liées au problème en question ne représentait qu'une petite fraction de notre base de code. Après quelques jours, j'ai tout abandonné et j'ai recommencé à utiliser C #. Notre patron a déjà vu le programme en cours et il aime son fonctionnement, mais il ne sait pas qu'il est écrit dans une autre langue.

La semaine prochaine, nous nous retrouverons tous les deux pour examiner le code source, afin qu'il "sache le maintenir". J'ai un peu peur et j'aimerais que vous me disiez quels arguments je pourrais utiliser pour étayer ma décision.

Lâche vôtre,

Notez que la commande "Faites-le comme ceci pour que je puisse le conserver" est en fait une très bonne exigence. La plupart des programmes sont beaucoup plus longs à gérer qu'à écrire. Conserver une solution dans une technologie connue est généralement une bonne idée.

Imaginez si un nouvel ordinateur s’est vu demander, en deux jours, d’écrire une application C # à Haskell et de dire: "Hé, ça marche et je suis parti, au revoir", vous laissant la maintenance.

Imaginez si un nouvel ordinateur qui avait demandé l’écriture d’une application ANSI C l’avait écrit dans Visual Basic 6 en deux jours et l’avait laissée. Vous devez maintenant le conserver et Windows 7 commence à se plaindre dès que le support d'installation est inséré .

C'est peut-être une bonne occasion de dire - comme le fait remarquer Heinzi dans les commentaires - qu'il s'agit "d'un prototype rapide écrit en C # ressemblant beaucoup à C - devons-nous le préparer pour la production ou le réimplémenter comme vous le faites en ANSI C demandé ", et ensuite prendre la discussion maintenant. Avoir la source réelle à voir est bien mieux que "Hé, ne devrions-nous pas écrire notre prochaine application en Haskell car c'est plus rapide".

En d'autres termes, vous avez maintenant l'occasion de démontrer qu'une nouvelle plate-forme pourrait être envisagée. Indiquez que vous avez écrit un prototype avant l'examen du code - cela aidera à dissiper l'impression que vous essayez de faufiler C # sous le radar. Je suggérerais que vous démontriez également que tout le code existant écrit en ANSI C peut être utilisé à partir de C #. Personnellement, je pense qu'on vous dira que la cible reste ANSI C pour rester sur une seule plate-forme.

Dans ce cas, votre patron semble être votre client, et sa principale exigence est de pouvoir gérer l'application lorsque vous passez à autre chose. Cela semble tout à fait raisonnable.

Le choix consiste donc à faire ce qu’il demande, ou à démontrer que vous pouvez terminer le développement ET lui apprendre à gérer une application C # dans les délais et à un coût inférieur. Si vous ne pouvez pas faire cela, 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 et la plupart (sinon la totalité) de notre code est écrit en C. Si vous devez obtenir des mesures un appareil (je suppose un débitmètre ou un thermocouple ou similaire ici) et l'afficher en temps quasi réel, C 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é et il est généralement basé sur Windows).

Bien sûr, vous pouvez utiliser une autre langue pour faire l'interface graphique. Mais vous pourriez vous épargner des efforts en utilisant simplement un package de tendances préexistant (il existe de bonnes solutions opensource disponibles).

Pour résumer, je dirais que l’interfaçage sous-jacent avec la partie matérielle C est un bon choix.

Oh cher. Ceci est une application en temps réel? Contrôler les équipements en temps réel? Collecter des données en temps réel? Utiliser une langue avec un ramasse-miettes? Oh cher.

Bien que je convienne que vous pouvez probablement créer l'application dans une langue plus moderne en moins de temps, ce n'est probablement pas le critère principal. La facilité de votre programmation est probablement beaucoup moins importante que les autres critères, tels que ceux définis par votre patron, le temps de réponse et le comportement déterministe.

J'aurais suggéré de faire un prototype en C # ou en Python, juste pour tester les fonctionnalités principales et l'interface utilisateur. ALORS testez-le à fond, en mesurant les latences et les temps de réponse réels, lorsque l'application reçoit beaucoup de données, pendant plusieurs jours de fonctionnement continu. Les chances sont, l'application pourrait être trop lente ou prendre du retard à des moments aléatoires, lorsque VM ou le ramasseur de mémoire démarre.

Je vous suggère de présenter ce que vous avez fait en tant que PROTOTYPE.

Coder 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 des décennies).

Eh bien, la première chose à faire est d'aller voir votre patron et de vous faire avouer. 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 ce soit la majeure partie du temps alloué à la réalisation du projet, vous devez faire face au fait que vous pourriez bientôt rechercher 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, vous devez le convaincre de plusieurs autres choses (1) que c # est adéquat, (2) il peut facilement apprendre à maintenir c #, (3). ) que vous ne vouliez pas l'écrire en C. En supposant que vous ayez toujours un travail et un rôle à jouer dans 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 tout mis au rebut pour recommencer à utiliser C #.

a mandaté que nous développions cette application dans ANSI C. La raison en est qu’il est le seul à être présent dans l’ensemble du temps et qu’il doit donc pouvoir comprendre ce que nous faisons.

C'est une exigence assez raisonnable.

Il a également décidé que nous ne devrions utiliser aucun type de données abstrait;

Cela n'a pas de sens. Maintenant, il commence à sentir un peu suspect, car il s'agit d'une exigence de conception de programme et non d'une exigence linguistique. Si le code doit être facile à gérer, la mise en œuvre de fichiers ADT ou l’utilisation d’appareils déjà testés et bien testés doit constituer 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 aussi de la programmation en général. Un programmeur expérimenté expérimenté, quelle que soit sa langue, ne ferait jamais une telle affirmation. (La seule exception à laquelle je peux penser est si la plus grande partie du code est destinée à être exécutée sur un système embarqué assez petit, et donc que toute la mémoire de travail nécessaire pour le code devait être pré-allouée. L'idée que le même code l’UI au niveau de l’écran s’oppose fortement à ce qu’il en soit ainsi).

J'imagine que votre patron n'a jamais participé à des projets de logiciels critiques à grande échelle, mais il a probablement été impliqué dans divers projets de faible qualité.

Cela n’a donc rien à voir avec le langage de programmation C. Vous pouvez aussi écrire facilement des programmes aussi vicieux 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 pour la conception de programmes, car il contient beaucoup plus de mots-clés liés à OO que C. Mais à part ça, il ne vous dit pas comment écrire vos programmes. Si vous croyez que tout ce qui est écrit en C est affreux par défaut et que tout ce qui est écrit en C # est le paradis par défaut, je parie que vous écrivez actuellement des programmes C # plutôt affreux sans vous en rendre compte.

Ce que je suggérerais, c'est que vous élaboriez un programme abstrait, indépendant du langage, mais détaillé avant toute autre chose. Utilisez l'approche normale, orientée objet. Quels objets sont présents et comment communiquent-ils entre eux, quelles sont les dépendances nécessaires, etc. Lorsque le programme a été suffisamment réfléchi et mis au point sur papier, cela ne devrait pas avoir beaucoup d'importance pour vous ni pour votre patron. langue que vous avez choisi pour l'implémenter.

Le premier problème que vous devez aborder est un problème émotionnel et irrationnel. Le secteur des technologies de l’information évolue constamment et, même s’il ya de la place pour tout, le refus de s’améliorer ou d’accepter le changement pose problème.

Pourquoi votre patron s'accroche-t-il à ANSI C? Si c'est la seule langue qu'il connaisse, alors peut-être qu'il est temps de changer, mais un argument rationnel peut être insuffisant. Votre patron se sentira-t-il sous-estimé ou peut-être renvoyé s'il est forcé 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 pourrez apporter seront gaspillés. En tant que subordonné, vous n'êtes peut-être pas celui qui peut avoir cette discussion avec lui. Peut-être abordez-vous ce sujet avec l’un des autres responsables, s’il en existe.

Pensez aussi à cela de votre point de vue. Pourquoi voulez-vous utiliser C #? A quel point est-ce le désir d'utiliser quelque chose de nouveau et de cool? Soit honnête avec toi. Si vous le reconnaissez, cela vous aidera à argumenter plus efficacement.

Le deuxième problème est celui du risque et du coût. Les logiciels d’écriture coûtent cher et le choix de la langue est un facteur important à cet égard. Considérer:

1. Combien de temps faudra-t-il pour écrire en C # versus C? Avec une orientation plus facile des objets et un meilleur ramassage des ordures, C # peut être plus facile. Toutefois, si l'application utilise de nombreux appels d'API non gérés, C peut être plus facile.
2. Si vous utilisez C #, devez-vous acheter des outils supplémentaires? On dirait que vous utilisez 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.?
3. Est-il facile de maintenir? Si vous trouvez un bogue, à quelle vitesse peut-il être corrigé? C # peut réduire l'orientation de cet objet. La collecte automatique des déchets permet également d'éviter la plupart des problèmes de fuite de mémoire et de pointeur.
4. Est-il facile de soutenir? Si vous avez du personnel de soutien, ils sauront peut-être comment lire un vidage mémoire mais savent-ils comment utiliser windbg avec SOS? Une version appropriée du framework .Net est-elle déjà installée sur les machines cibles?
5. Pensez à la dotation en personnel. Combien de personnes connaissent C versus C #? Si l'un de 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 de cesser de discuter des mérites techniques des langues. Les mérites techniques sont des choses que seuls votre patron et vous-même comprenez. Si vous commencez à parler d’impact sur les entreprises, vous attirez un groupe de personnes beaucoup plus large et vous présentez un argument bien plus convaincant.

Peut-être que C est un meilleur choix. C # n'est pas automatiquement meilleur pour toutes les situations. Peut-être que vous réalisez ce projet en C mais que vous faites une démonstration de concept C # pour le prochain. Rappelez-vous que vous pouvez perdre la bataille tout en continuant de gagner la guerre.

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 commettre d'erreur. ANSI C n'est pas la première chose que les gens apprennent aujourd'hui.

Maintenant, tous les étudiants en informatique vont me tuer.

Vous avez complètement échoué à nous convaincre que la norme ANSI C était inadéquate. C est un excellent langage qui semble adapté au type de tâches que vous avez décrit. Avec la brève description de la tâche (sauf l’exigence linguistique), je recommanderais également C (ou peut-être aller).

Je pense que le problème est que vous programmiez en C avec votre esprit pensant 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 votre façon de penser en fonction de la langue du jour.

Le problème n’est pas votre patron ni le langage C, le problème est d’ouvrir votre esprit à différentes façons de penser. Changer de langage de programmation vous sera bénéfique.

Tout d'abord, vous devez dire à votre patron que c'est dans une autre langue, maintenant. Il sera (à juste titre) fâché si vous ramenez quelque chose intentionnellement contre les exigences sans préavis.

Maintenant, la meilleure façon d’expliquer ces choses au patron / aux responsables est de les exprimer en termes de temps et d’argent. Estimez combien de temps un tel projet prendrait en ANSI C, puis combien de temps faudrait-il pour un niveau supérieur tel que C #. Notez que j'ai dit plus haut niveau, pas moderne. Cela peut aussi aider à aplanir les choses. Je veux dire, vous ne vous attaqueriez pas à peindre une pièce avec juste un pinceau, vous utiliseriez des rouleaux et d'autres éléments qui permettent à chaque trait (ligne de code) de couvrir davantage de zones du projet. De plus, si vous ou l'un des membres de votre équipe ne connaissez pas C, ou si vous êtes à l'aise pour faire un grand projet en C, cela gâche encore plus le problème du temps, car ils devront se mettre à jour.

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 faire en sorte que votre patron le fasse moins

L'aversion des superviseurs vis-à-vis des TDA a été abordée ailleurs, de même que l'apparente méconnaissance apparente du développeur des coûts de GC, je vais donc me concentrer sur les "fils".

Plutôt que de penser en termes de threads .NET (ou JVM, si endoctrinés), vous voudrez peut-être utiliser plusieurs processus, en utilisant un mécanisme de communication inter-processus (IPC) pour communiquer entre eux. Par exemple, les messages Windows, la mémoire partagée, la mémoire tampon de fichiers mappée en mémoire, le canal nommé, etc. Dédiez les petits processus à l’interaction avec un périphérique ou à un aspect de celui-ci et vérifiez l’IPC pour communiquer les mises à jour et les demandes d’accusé de réception, et disposez d’un processus un peu plus long pour gérer l’interface graphique et communiquer avec les «moniteurs» d’équipement en utilisant l’IPC sélectionné.