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


64

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,


220
"Oh non, ce n'est pas la version finale, c'est juste une version C # que nous avons rapidement écrite en quelques jours à des fins de prototypage et de test, pour nous assurer de comprendre les exigences et d'ajuster l'interface utilisateur. La mise en œuvre de cette norme dans ANSI C va prendre une autre semaine X, parce que, vous le savez, nous devons travailler autour de ne pas avoir toutes les structures de données de fantaisie. ... Eh bien, oui, maintenant que vous le dites, la version C # ne le font déjà tout le programme final devrait, mais vous avez dit vous en avez besoin en ANSI C. ... OK, si vous insistez, restons avec cette version ... "
Heinzi le

8
@Heinzi: J'ai eu la même expérience: écrire un prototype de bibliothèque C # en 2 jours et le réécrire pendant plusieurs semaines en C. Heureusement, après ce projet, on m'a offert la chance d'être transféré dans une autre choix de langue raisonnable.
dan04

49
Variables globales et threads? Vous avez des problèmes, mon ami, quel que soit le langage de programmation que vous utilisez.
Nemanja Trifunovic

16
L'argument dont vous avez vraiment besoin est la raison pour laquelle vous devriez garder votre travail.
epo

11
Votre hypothèse est incorrecte - ANSI C convient à presque tous les projets. C'est pourquoi il est toujours populaire après toutes ces années. Que ce soit optimal ou non est une question différente.
Mark Ransom

Réponses:


108

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.


26
+1: pour avoir souligné l'exigence "faites-le comme ça, donc je suis sûr de pouvoir le maintenir". C # est certes beaucoup plus facile / plus rapide que le développement de C (en général), mais C a changé au cours des 30 dernières années de moins que C # a changé au cours des 15 dernières années. Donc, pour un produit qui doit être maintenu pendant de nombreuses années, C pourrait être mieux adapté. Vous devez faire des compromis entre toutes les exigences: complexité du projet (C # est probablement un meilleur choix), maintenance à long terme (C semble être plus stable), qui va effectuer la maintenance, etc.
Giorgio

4
@Ramhound Je ne parle pas de support VB6, mais de support de l' environnement de développement Visual Basic 6 . Lors de l'insertion du support d'installation, ma copie de Windows 7 m'avait explicitement notifié que ce n'était pas une bonne idée.

12
Bons points, mais que se passerait-il si le patron avait demandé que ce soit écrit en COBOL? Ou 6502 assemblée? À quel moment pouvez-vous dire à votre patron: "Ce langage est obsolète à cette fin, et une fois que vous serez parti, il ne restera plus personne qui comprend ce genre de choses"?
Ant

6
@ Alex: La cohérence est belle, c'est vrai. Mais écririez-vous un nouveau système Web en C si tous les autres logiciels (non Web) écrits par votre ministère étaient écrits en C? Je pense qu'il faut trouver un équilibre entre le choix des technologies appropriées pour le système que vous écrivez et les compétences existantes de l'équipe. Choisir une langue sans délibération parce que c'est ce que vous utilisez toujours peut être préjudiciable.
Ant

8
@ant, le payeur choisit la musique. (et nous sommes un magasin COBOL - pas de problème pour le supporter)

35

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.


21
Le PO a explicitement ignoré les exigences sans notification ni discussion. Si le patron était un client commercial, il pourrait refuser le paiement et éventuellement intenter une action en justice pour les frais exposés en raison du temps perdu. Inverser les rôles, et si vous commandiez par exemple un costume sur mesure et que vous trouviez que le tailleur n'aimait pas travailler avec le vêtement que vous avez spécifié si silencieusement, il a préféré remplacer celui qui lui plaisait par son choix de couleur? Le problème du PO, à présent, est qu'on ne peut lui faire confiance avec des projets sans une supervision étroite, un manque manifeste de compétences relationnelles et un manque de respect pour la direction.
epo

1
@ epo Je crois comprendre votre assertion selon laquelle le patron ne peut pas faire confiance au PO car ils n'ont pas fait ce qui était demandé. Cependant, s'il est un gestionnaire raisonnable, cela ne devrait pas arriver. Si le développeur approchait le manager avec une meilleure solution que celle envisagée à l'origine, j'espère que le manager sera ouvert à cette solution. Si je peux modifier légèrement votre exemple, c'est comme si le tailleur fabriquait un costume dans la couleur / le motif souhaité avec un type de tissu plus récent, plus résistant, plus résistant et moins cher que celui demandé, même si l'acheteur a demandé un type. de tissu qu'ils connaissaient.
Taylor Price

Cela étant dit, je conviens également que, dans ce cas, la maintenance est une exigence importante. Le PO est maintenant obligé de prouver au responsable qu'il a résolu le reste des besoins de manière à ce que le responsable puisse rapidement et efficacement apprendre à gérer.
Taylor Price

26

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.


7
Le portage du code C # de Windows vers Linux (avec Mono) a été plus efficace que celui obtenu avec le code C ++.
dan04

8
@ dan04: Quels problèmes avez-vous rencontré avec C ++? Je pensais que C ++ serait assez portable. De plus, C ++ n’est pas un C. J’ai toujours trouvé que l’utilisation de C avec la bibliothèque GNU C était assez portable, par exemple entre GNU Linux et cygwin.
Giorgio

4
@ dan04 C! = C ++.

2
@Giorgio: Une grande partie de celle-ci était composée de chaînes. Nous avons dû éliminer toute la TCHARmerde spécifique à Windows (que nous n'utilisions pas systématiquement) et nous avons adopté une norme d'équipe consistant à utiliser UTF-8 en même temps que la transition Linux. Malheureusement, cela nécessitait de ré-implémenter une grande partie de la bibliothèque standard sous Windows, boost::nowidequi n’existait pas à ce moment-là.
dan04

3
@ dan04: Comme dit, C n'est certainement pas aussi expressif que C # (ou C ++ d'ailleurs), mais j'utilise la bibliothèque GNU C ( gnu.org/software/libc ) depuis 1997 et c'est vraiment stable et portable. Pour C ++, je regarderais Qt (ou boost et les librairies standard) car elles sont assez portables. Dans la mesure du possible, j'éviterais tout ce qui concerne Windows: AFAIK, Microsoft n'a jamais eu pour objectif de produire des logiciels portables, car le verrouillage du client fait partie de sa stratégie marketing.
Giorgio

24

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).


3
Permet de formuler le premier bit différemment. 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? FONCTIONNER DANS UN ENVIRONNEMENT FILETÉ NON RÉALTIME? Oh cher. Vous devrez toujours échantillonner lorsque vous franchirez les limites d'un appareil. Le «temps réel» est un argument de paille et une exigence mal définie. C # va bien.
Gusdor

Vous n'avez évidemment pas entendu parler du travail de Joe Duffy . Il travaille sur la programmation système en C # depuis au moins 2013 . Le compilateur Roslyn peut compiler en code natif (c'est ainsi que fonctionne UWP) et la récupération de place ne pose pas de problème si vous faites attention à ce que vous faites.
RubberDuck

14

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 #.


Nulle part n'a-t-il mentionné qu'il construisait une version C # depuis des mois?
Anonyme

1
@Anonymous - Peu importe qu'il s'agisse de jours ou de mois, il N'A PAS encore suivi les instructions de son responsable. L'auteur n'avait manifestement pas les compétences nécessaires pour développer l'application selon ANSI C.
Ramhound

1
@Ramhound - Je ne conteste pas qu'il n'a pas suivi les instructions de son manager, je dis simplement que jmoerno se débrouillait comme s'il avait passé des mois à faire des siennes. En outre, s’il assemblait le projet en quelques jours pour servir de prototype fonctionnel sur lequel la version C plus stable spécifiée pouvait être basée, cela aurait alors tout son sens. Cela fait partie de la phase de planification.
Anonyme le

@ jmoreno - Toutes mes excuses, j'ai dû mal interpréter la question.
Anonyme

2
@ jmoreno - bien sûr. J'ai posté mon dernier commentaire après avoir vu la citation que vous avez ajoutée. Des excuses encore une fois.
Anonyme le

12

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.


1
+1 pour "Vous pouvez également écrire des programmes tout aussi épineux en C #."
Javier

11

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.


5
Je ne suis pas d'accord avec l'hypothèse implicite selon laquelle C # est par défaut un meilleur choix que ANSI C. Par exemple, si vous souhaitez rester indépendant de la plate-forme, C # est probablement un mauvais choix.

@ ThorbjørnRavnAndersen Je suis d'accord. S'il vous plaît voir le dernier paragraphe. Je mentionne également des cas tels que l'appel de code non géré. Je suppose que l'indépendance de la plate-forme aurait exclu C # du PO. C'est peut-être une hypothèse incorrecte.
Akton

1
L'indépendance de la plate-forme n'était qu'une des raisons possibles. Une formulation telle que "s'accrocher à ANSI C" indique, à mon avis, un parti pris.

@akton - Depuis quand ne pouvez-vous pas appeler du code non managé à partir de C #. Bien sûr, cela nécessite un wrapper et cela introduit des problèmes de support supplémentaires mais c'est possible. En outre, vous pouvez prendre en charge le C # sur plusieurs plates-formes si vous le souhaitez. Mono est pris en charge sur toutes les grandes plates-formes de bureau (OS X, Windows et Linux). Adoptée comme .NET Framework basé sur Microsoft Windows, la base de fonctionnalités de Mono ne lui correspond pas exactement (ce qui est déjà le cas avec WPF) et vous ne pourrez bien sûr pas développer d'applications Metro qui s'exécutent sous Linux. Bien sûr, il est peu probable que cela se fasse dans ce cas.
Ramhound le

@Ramhound Je n'ai pas dit que vous ne pouvez pas appeler du code non managé à partir de C #, mais que beaucoup de choses peuvent être pénibles. De même, vous pouvez faire du développement multi-plateformes en C # mais le C est presque universel, comme l'a dit Thorbjorn.
Akton

7

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.


ANSI C était en fait l'une des premières choses que j'ai apprises à l'université. J'ai commencé en 2004. Donc, au cours des 10 dernières années, il était encore enseigné. J'ai passé de nombreuses nuits en retard connecté via SSH à un environnement Unix en essayant de compiler mon code.
Ramhound

1
C'est drôle, je n'ai pas appris l'ANSI C avant ma dernière année à l'université. La première langue enseignée était le Pascal, pour que je sois protégé ...
tehnyit

Diplômé récent ici; nous avons été exposés à la fois au C et au C ++, mais le C était dans un contexte intégré et minime. Les deux étaient dans ma dernière année - purement C # et Java avant.
Ross

2
C simplement être difficile à programmer correctement est probablement le meilleur point contre l'utilisation de C.
Paul Nathan le

7

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.


4
Merci d'avoir répondu à votre première question sur les programmeurs Stack Exchange. Cependant, vous voudrez peut-être que vos réponses futures soient un peu moins personnelles en n'utilisant pas des expressions telles que "vous avez complètement échoué", "le problème est d'ouvrir votre esprit". Veuillez consulter la FAQ programmers.stackexchange.com/faq#etiquette . Je pense que vous pouvez faire une bonne description de votre argument avec un langage neutre.
DeveloperDon

2

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'abordabilité semble un argument possible. Bien que le patron (en tant que client, selon la suggestion de @ MatthewFlynn) affirme qu'il ne peut pas se permettre que le programme ne soit pas écrit en C, OP peut affirmer que le patron ne sera pas non plus en mesure de supporter les coûts de mise en œuvre et de maintenance associés au programme. écrit en C. Dans les deux cas, des compromis sont nécessaires pour que les choses se passent.
Rwong

1

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é.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.