Wie kann ich meinen Chef davon überzeugen, dass ANSI C für unser neues Projekt nicht geeignet ist? [geschlossen]

Vor einigen Monaten haben wir mit der Entwicklung einer App begonnen, mit der eigens entwickelte Testgeräte gesteuert und eine Reihe von Messungen aufgezeichnet werden können. Es sollte eine einfache Benutzeroberfläche haben und aufgrund der fortlaufenden Aufzeichnung, die stattfinden muss, wahrscheinlich Threads erfordern. Diese Anwendung wird einige Jahre lang verwendet und in diesem Zeitraum von einer Reihe von Informatikstudenten gepflegt.

Unser Chef hat vor ungefähr 30 Jahren seinen Abschluss gemacht (um nicht beleidigt zu sein; ich habe auch mehr als die Hälfte dieser Zeit auf meinem Rücken) und hat angeordnet, dass wir diese Anwendung in ANSI C entwickeln wird rund um die Uhr sein, und deshalb muss er verstehen können, was wir tun. Er entschied auch, dass wir keine abstrakten Datentypen verwenden sollten; Er gab uns sogar eine Liste mit den Namen der globalen Variablen (Seufzer), die wir verwenden sollen.

Ich habe diesen Ansatz tatsächlich eine Weile ausprobiert, aber er hat mich wirklich verlangsamt, um sicherzustellen, dass alle Zeigeroperationen sicher waren und alle Zeichenfolgen die richtige Größe hatten. Darüber hinaus war die Anzahl der Codezeilen, die sich tatsächlich auf das vorliegende Problem bezogen, nur ein kleiner Teil unserer Codebasis. Nach ein paar Tagen verschrottete ich die ganze Sache und begann erneut mit C #. Unser Chef hat das Programm bereits laufen sehen und es gefällt ihm, aber er weiß nicht, dass es in einer anderen Sprache geschrieben ist.

Nächste Woche werden wir uns treffen, um den Quellcode durchzugehen, damit er "weiß, wie man ihn pflegt". Ich habe ein bisschen Angst und würde gerne von euch hören, welche Argumente ich verwenden könnte, um meine Entscheidung zu unterstützen.

Feige deine,

Beachten Sie, dass "Bitte machen Sie das so, damit ich sicher bin, dass ich es beibehalten kann" eine sehr gute Voraussetzung ist - die meisten Programme verbringen viel mehr Zeit damit, als geschrieben zu werden, und eine Lösung in einer bekannten Technologie beizubehalten, ist normalerweise eine gute Idee.

Stellen Sie sich vor, ein neues Computerkind, das zum Schreiben einer C # -Anwendung aufgefordert wurde, schrieb diese in zwei Tagen in Haskell und sagte: "Hey, es funktioniert, und ich bin weg, tschüss."

Stellen Sie sich vor, ein neues Computerkind, das vor 15 Jahren zum Schreiben einer ANSI C-Anwendung aufgefordert wurde, hat sie in Visual Basic 6 in zwei Tagen geschrieben und verlassen. Jetzt müssen Sie es warten und Windows 7 fängt bereits beim Einlegen des Installationsmediums an, sich zu beschweren .

Dies könnte eine gute Gelegenheit sein zu sagen - wie Heinzi in den Kommentaren angedeutet hat -, dass "dies ein schneller Prototyp ist, der in C # geschrieben ist und sehr nach C aussieht - sollen wir ihn serienreif machen oder in ANSI C wie Sie neu implementieren fragte ", und nehmen Sie dann die Diskussion jetzt. Die Quelle zu sehen, ist viel besser als "Hey, sollten wir nicht unsere nächste Anwendung in Haskell schreiben, weil es schneller ist".

Mit anderen Worten - Sie haben jetzt die Möglichkeit zu demonstrieren, dass eine neue Plattform in Betracht gezogen werden könnte. Stellen Sie sicher, dass Sie vor der Codeüberprüfung einen Prototyp geschrieben haben. Auf diese Weise wird der Eindruck beseitigt, dass Sie versuchen, C # unter das Radar zu schleichen. Ich würde vorschlagen, dass Sie auch demonstrieren, dass der gesamte in ANSI C geschriebene Code in C # verwendet werden kann. Persönlich glaube ich, dass Ihnen mitgeteilt wird, dass das Ziel weiterhin ANSI C ist, auf einer einzigen Plattform zu bleiben.

Ihr Chef scheint in diesem Fall Ihr Kunde zu sein, und seine Hauptanforderung ist, dass er die Anwendung warten kann, wenn Sie fortfahren. Das scheint durchaus vernünftig.

Sie haben also die Wahl, das zu tun, was er verlangt, oder zu demonstrieren, dass Sie die Entwicklung abschließen UND ihm beibringen können, wie eine C # -Anwendung innerhalb der vorgegebenen Zeit und zu geringeren Kosten gewartet wird. Wenn Sie das nicht können, erfüllen Sie nicht die Anforderungen des Projekts.

Sie haben nicht viele Informationen angegeben, aber ich denke, C ist absolut die richtige Wahl - ich arbeite als Ingenieur in einer Industrieanlage und der größte Teil (wenn nicht der gesamte) unseres Codes ist in C geschrieben Ein Gerät (ich nehme hier einen Durchflussmesser oder ein Thermoelement oder ähnliches an) und dessen Anzeige in Echtzeit C ist eine ausgezeichnete Wahl.

Es ist schnell, portabel (ich habe noch nie in C # geschrieben, aber ich glaube nicht, dass es ohne eine bestimmte Version des installierten Frameworks funktioniert und normalerweise nur auf Windows basiert).

Sie könnten auf jeden Fall eine andere Sprache für die GUI verwenden. Sie können sich jedoch den Aufwand ersparen und ein bereits vorhandenes Trendpaket verwenden (es stehen einige gute Open Source-Pakete zur Verfügung).

Zusammenfassend würde ich sagen, dass für die zugrunde liegende Schnittstelle mit Hardware Teil C eine gute Wahl ist.

Ach je. Dies ist eine Echtzeitanwendung? Geräte in Echtzeit steuern? Daten in Echtzeit sammeln? Verwenden Sie eine Sprache mit einem Garbage Collector? Ach je.

Ich bin damit einverstanden, dass Sie die App wahrscheinlich in kürzerer Zeit in einer moderneren Sprache erstellen können, aber das ist wahrscheinlich nicht das Hauptkriterium. DIE EINFACHHEIT IHRER PROGRAMMIERUNG IST VIEL WICHTIGER ALS DIE ANDEREN KRITERIEN, wie die, die Ihr Chef festgelegt hat, UND die Reaktionszeit und das deterministische Verhalten.

Ich hätte vorgeschlagen, dass Sie einen Prototyp in C # oder Python erstellen, um die Hauptfunktionen und die Benutzeroberfläche zu testen. Dann probieren Sie es aus und messen Sie die tatsächlichen Latenzen und Reaktionszeiten, wenn die App über viele Tage hinweg mit vielen Daten überhäuft wird. Wahrscheinlich ist die App zu langsam oder fällt gelegentlich zurück, wenn VM oder der Garbage Collector aktiv werden.

Ich schlage vor, Sie präsentieren, was Sie als PROTOTYP getan haben.

Das Codieren in C ist nicht so schwer. Wenn Sie dem nicht gewachsen sind, sagen Sie es. Es gibt viele von uns für die Herausforderung. (Ich mache seit Jahrzehnten Echtzeit-C-Codierung.)

Nun, das erste, was Sie tun müssen, ist, zu Ihrem Chef zu gehen und sich zu stärken. Sie haben seine klare Bitte missachtet und tun dies schon seit Monaten. Ich weiß nicht, wie viel Zeit Sie dafür haben, aber wenn Sie davon ausgehen, dass die meiste Zeit für die Erledigung des Projekts aufgewendet wird, müssen Sie sich der Tatsache stellen, dass Sie möglicherweise bald nach einem neuen Job suchen.

Je früher Sie damit umgehen, desto besser.

Zweitens glaube ich nicht, dass Sie ihn davon überzeugen können, dass ANSI C unzureichend ist. Sie müssen ihn lediglich von mehreren anderen Dingen überzeugen (1), dass c # angemessen ist, (2), dass er leicht lernen kann, c # zu pflegen, (3) ), dass Sie nicht in der Lage waren, es in C zu schreiben. Unter der Annahme, dass Sie noch einen Job und eine Rolle bei diesem Projekt haben, würde ich mich auf 2 konzentrieren und die Ähnlichkeiten zwischen c und c # hervorheben.

Zitate als Antwort auf Kommentare ...

Vor ein paar Monaten begannen wir mit der Entwicklung einer [...] App. Nach ein paar Tagen verschrottete ich die ganze Sache und begann erneut mit C #.

hat uns beauftragt, diese Anwendung in ANSI C zu entwickeln. Das Grundprinzip ist, dass er der einzige ist, der die ganze Zeit über verfügbar ist, und daher muss er verstehen können, was wir tun.

Dies ist eine ziemlich vernünftige Voraussetzung.

Er entschied auch, dass wir keine abstrakten Datentypen verwenden sollten;

Das ergibt keinen Sinn. Jetzt fängt es an, ein bisschen verdächtig zu riechen, weil dies eine Programmdesignanforderung und keine Sprachanforderung ist. Wenn der Code einfach zu warten sein soll, sollte die Implementierung von ADTs oder die Verwendung von bereits getesteten eine Priorität sein.

Er gab uns sogar eine Liste mit den Namen der globalen Variablen (Seufzer), die wir verwenden sollen.

Ok, jetzt stinkt es. Jetzt können wir feststellen, dass Ihr Chef nicht nur über begrenzte Erfahrung mit verschiedenen Programmiersprachen verfügt, sondern auch mit der Programmierung im Allgemeinen. Ein erfahrener Programmierer, egal welcher Sprache, würde niemals eine solche Erklärung abgeben. (Die einzige Ausnahme, an die ich denken kann, ist, wenn der größte Teil des Codes auf einem relativ kleinen eingebetteten System ausgeführt werden soll und daher erwartet wurde, dass der gesamte für den Code erforderliche Arbeitsspeicher vorab zugewiesen wird. Die Idee, dass derselbe Code verwendet wird wird erwartet, dass eine Benutzeroberfläche auf Bildschirmebene vorliegt (spricht jedoch stark dagegen).

Ich vermute, Ihr Chef war noch nie an großen, unternehmenskritischen Softwareprojekten beteiligt, aber mit größerer Wahrscheinlichkeit schwebte er in verschiedenen minderwertigen Projekten herum.

Das hat also nichts mit der Programmiersprache C zu tun. Sie können ebenso schwierige Programme problemlos auch in C # schreiben. Es ist ein weit verbreiteter Fehler zu glauben, dass gutes Programmdesign von der Sprache abhängt. Das stimmt einfach nicht!

C # hat auf jeden Fall eine schönere, sauberere und weniger obskure Syntax als C. Es bietet reichlich Unterstützung für das Programmdesign, da es weit mehr OO-bezogene Schlüsselwörter als C enthält. Abgesehen davon sagt es Ihnen jedoch nicht, wie Sie Ihre Programme schreiben sollen. Wenn Sie glauben, dass alles, was in C geschrieben ist, standardmäßig furchtbar ist und alles, was in C # geschrieben ist, standardmäßig himmlisch ist, dann schreiben Sie wahrscheinlich gerade ziemlich furchtbare C # -Programme, ohne es zu merken.

Ich würde vorschlagen, dass Sie ein abstraktes, sprachunabhängiges, aber detailliertes Programmdesign erstellen, bevor Sie etwas anderes tun. Verwenden Sie den normalen, objektorientierten Ansatz. Welche Objekte gibt es und wie kommunizieren sie untereinander, welche Abhängigkeiten werden benötigt usw. usw. Wenn Sie das Programmdesign gründlich durchdacht und auf Papier gebracht haben, sollte es Ihnen und Ihrem Chef nicht viel ausmachen, welche Sprache, in der Sie es implementiert haben.

Das erste Problem, das Sie ansprechen müssen, ist ein emotionales, irrationales. Die IT-Branche befindet sich in ständigem Wandel und obwohl es Orte für alles gibt, ist es ein Problem, sich zu weigern, Verbesserungen vorzunehmen oder Veränderungen zu akzeptieren.

Warum klammert sich Ihr Chef an ANSI C? Wenn dies die einzige Sprache ist, die er oder sie kennt, ist es vielleicht Zeit für eine Änderung, aber ein rationales Argument kann unzureichend sein. Fühlt sich Ihr Chef unterbewertet oder möglicherweise entlassen, wenn er gezwungen wird, in einer unbekannten Sprache zu arbeiten? Betonen Sie die Erfahrung, die er hat, und andere Vorteile, die er mit sich bringt.

Wenn Sie dieses Problem nicht lösen, werden alle rationalen Argumente, die Sie vorbringen können, verschwendet. Als Untergebener sind Sie möglicherweise nicht derjenige, der diese Diskussion mit ihm führen kann. Sprechen Sie dieses Thema vielleicht bei einem der anderen Manager an, falls es welche gibt.

Betrachten Sie es auch aus Ihrer Sicht. Warum möchten Sie C # verwenden? Wie viel davon ist der Wunsch, etwas Neues und Cooles zu nutzen? Sei ehrlich zu dir selbst. Wenn Sie dies erkennen, können Sie effektiver argumentieren.

Das zweite Problem betrifft das Risiko und die Kosten. Das Schreiben von Software ist teuer und die Wahl der Sprache spielt dabei eine wichtige Rolle. Erwägen:

1. Wie lange wird es dauern, in C # gegen C zu schreiben? Mit einer einfacheren Objektorientierung und einer besseren Speicherbereinigung kann C # einfacher sein. Wenn die Anwendung jedoch viele nicht verwaltete API-Aufrufe verwendet, ist C möglicherweise einfacher.
2. Wenn Sie C # verwenden, müssen Sie zusätzliche Tools erwerben? Es hört sich so an, als ob Sie bereits Visual Studio verwenden. Benötigen Sie jedoch zusätzliche Tools für Lokalisierung, Codeüberprüfung und -analyse, Debugging usw.?
3. Wie einfach ist die Wartung? Wenn Sie einen Fehler finden, wie schnell kann er behoben werden? C # kann diese Objektorientierung reduzieren. Die automatische Speicherbereinigung vermeidet außerdem die meisten Probleme mit Speicherverlusten und Zeigern.
4. Wie einfach ist es zu unterstützen? Wenn Sie Support-Mitarbeiter haben, wissen diese möglicherweise, wie man einen Absturzspeicherauszug liest, aber wissen sie, wie man windbg mit SOS verwendet? Ist auf den Zielcomputern bereits eine entsprechende Version des .Net-Frameworks installiert?
5. Betrachten Sie die Besetzung. Wie viele Leute kennen C versus C #? Wenn einer oder beide von Ihnen die Organisation verlassen, wie einfach wäre es, Sie zu ersetzen? Sind C-Entwickler billiger oder teurer als C # -Entwickler?

Ich könnte weitermachen, aber es geht darum, nicht mehr nur über die technischen Vorzüge der Sprachen zu streiten. Technische Vorteile sind Dinge, die nur Sie und Ihr Chef verstehen. Wenn Sie anfangen, über geschäftliche Auswirkungen zu sprechen, ziehen Sie einen viel größeren Personenkreis an und liefern ein weitaus überzeugenderes Argument.

Vielleicht ist C die bessere Wahl. C # ist nicht automatisch besser für alle Situationen. Möglicherweise führen Sie dieses Projekt mit C durch, führen aber für das nächste einen C # Proof of Concept durch. Denken Sie daran, dass Sie den Kampf verlieren und trotzdem den Krieg gewinnen können.

Vielleicht ein weiteres Argument: Es ist wahrscheinlich sehr schwierig, Informatikstudenten zu finden, die genug Erfahrung haben, um C-Code fehlerfrei zu schreiben. ANSI C ist nicht das erste, was die Leute heute lernen.

Jetzt werden mich alle Informatikstudenten umbringen.

Sie haben uns nicht überzeugt, dass ANSI C unzureichend war. C ist eine ausgezeichnete Sprache, die für die von Ihnen beschriebenen Aufgaben geeignet zu sein scheint. Mit der kurzen Beschreibung der Aufgabe (außer der Sprachanforderung) würde ich auch C empfehlen (oder vielleicht gehen).

Ich denke, das Problem ist, dass Sie in C programmiert haben, während Ihr Verstand in C # gedacht hat. Ich habe ein ähnliches Problem, wenn ich von Perl zu C oder Java wechsle. Sie müssen lernen, sich an die Sprache anzupassen und müssen nicht lernen, aus Ihrer Denkweise in die Sprache des Tages zu übersetzen.

Das Problem ist nicht Ihr Chef oder die C-Sprache, das Problem ist, Ihren Geist für verschiedene Denkweisen zu öffnen. Das Ändern der Programmiersprache kommt Ihnen zugute.

Zuerst müssen Sie Ihrem Chef sagen, dass es jetzt in einer anderen Sprache ist. Er wird (verständlicherweise) wütend sein, wenn Sie ohne Vorankündigung etwas gezielt gegen die Anforderungen zurückbringen.

Der beste Weg, diese Dinge Chef / Manager zu erklären, ist es, Zeit und Geld zu sparen. Schätzen Sie, wie viel Zeit ein solches Projekt in ANSI C in Anspruch nehmen würde, und schätzen Sie dann, wie viel Zeit es in einem höheren Level wie C # in Anspruch nehmen würde. Beachten Sie, ich sagte höheres Niveau, nicht modern. Dies kann auch dazu beitragen, Dinge zu glätten. Ich meine, Sie würden einen Raum nicht mit nur einem winzigen Pinsel bemalen, Sie würden Walzen und andere Dinge verwenden, mit denen jeder Strich (Codezeile) mehr Fläche des Projekts abdeckt. Wenn Sie oder eines Ihrer Teammitglieder C nicht kennen oder ein umfangreiches Projekt in C erstellen möchten, wird dies die Zeitfrage noch mehr verschlingen, da sie sich auf den neuesten Stand bringen müssen.

Es hört sich auch so an, als würde Ihr Chef versuchen, Mikromanagement zu betreiben. Ich bin sicher, eine der anderen Antworten wird versuchen zu erklären, wie Sie Ihren Chef dazu bringen können, das weniger zu tun

Die Abneigung des Supervisors gegen ADTs wurde an anderer Stelle angesprochen, ebenso wie die Unkenntnis der Entwickler über die GC-Kosten, weshalb ich mich auf "Threads" konzentrieren werde.

Möglicherweise möchten Sie nicht in .NET (oder JVM, wenn dies so indoktriniert ist) -Threading denken, sondern mehrere Prozesse, die über einen IPC-Mechanismus (Inter-Process Communication) miteinander kommunizieren. ZB Windows Nachrichten, Shared Memory, Memory Mapped File Buffer, Named Pipe, was auch immer. Weisen Sie kleine Prozesse der Interaktion mit einem Gerät oder Aspekt des Geräts und der Überprüfung des IPC zu, um Aktualisierungen zu kommunizieren und Anforderungen zu bestätigen, und verwenden Sie einen etwas umfangreicheren Prozess, um die GUI zu warten und mit den Geräte- "Monitoren" zu kommunizieren, und zwar unter Verwendung des von Ihnen ausgewählten IPC.