Come posso convincere il mio capo che ANSI C è inadeguato per il nostro nuovo progetto? [chiuso]

Alcuni mesi fa, abbiamo iniziato a sviluppare un'app per controllare un'apparecchiatura di prova sviluppata internamente e registrare una serie di misurazioni. Dovrebbe avere un'interfaccia utente semplice e probabilmente richiederebbe discussioni a causa della registrazione continua che deve aver luogo. Questa applicazione verrà utilizzata per alcuni anni e sarà mantenuta da numerosi studenti di informatica durante questo periodo.

Il nostro capo si è laureato circa 30 anni fa (da non considerare come un'offesa; ho anche più della metà del tempo sulla schiena) e ha incaricato di sviluppare questa applicazione in ANSI C. La logica è che è l'unico che sarà in giro tutto il tempo, e quindi deve essere in grado di capire cosa stiamo facendo. Ha anche stabilito che non dovremmo usare tipi di dati astratti; ci ha persino fornito un elenco con il nome delle variabili globali (sospiro) che vuole che usiamo.

In realtà ho provato questo approccio per un po ', ma mi stava davvero rallentando per assicurarmi che tutte le operazioni del puntatore fossero sicure e che tutte le stringhe avessero la dimensione corretta. Inoltre, il numero di righe di codice effettivamente correlate al problema in questione era solo una piccola parte della nostra base di codice. Dopo alcuni giorni, ho demolito tutto e ho ricominciato a usare C #. Il nostro capo ha già visto il programma in esecuzione e gli piace il modo in cui funziona, ma non sa che è scritto in un'altra lingua.

La prossima settimana ci incontreremo per esaminare il codice sorgente, in modo che "sappia come mantenerlo". Ho un po 'paura, e vorrei sentire da voi ragazzi quali argomenti potrei usare per supportare la mia decisione.

Vigliacco tuo,

Si noti che il "Si prega di fare in questo modo, quindi sono sicuro che posso mantenerla" è in realtà un ottimo requisito - la maggior parte dei programmi di spendere molto più a lungo mantenute che essere scritto e mantenere una soluzione in una tecnologia nota di solito è una buona idea.

Immagina se un nuovo bambino del computer, quando gli viene chiesto di scrivere un'applicazione C #, lo scrisse in Haskell in due giorni e dicesse "Ehi, funziona e me ne vado, ciao" lasciandoti la manutenzione.

Immagina se qualche nuovo bambino del computer, quando gli è stato chiesto di scrivere un'applicazione ANSI C 15 anni fa, l'abbia scritta in Visual Basic 6 in due giorni e l'abbia lasciata. Ora devi mantenerlo e Windows 7 inizia a lamentarsi già quando viene inserito il supporto di installazione .

Questa potrebbe essere una buona opportunità per dire - come ha accennato Heinzi nei commenti - che "questo è un prototipo rapido scritto in C # che sembra somigliare molto a C - dovremmo renderlo pronto per la produzione o reimplementarlo in ANSI C come te chiesto ", quindi prendi la discussione ora. Avere una fonte reale da vedere, è molto meglio di "Ehi, non dovremmo scrivere la nostra prossima applicazione in Haskell perché è più veloce".

In altre parole: ora hai l'opportunità di dimostrare che una nuova piattaforma potrebbe essere presa in considerazione. Mostra che hai scritto un prototipo prima della revisione del codice: questo ti aiuterà a rimuovere l'impressione che stai cercando di intrufolarti in C # sotto il radar. Suggerirei anche di dimostrare che tutto il codice esistente scritto in ANSI C può essere utilizzato da C #. Personalmente credo che ti verrà detto che l'obiettivo rimane ANSI C per rimanere su un'unica piattaforma.

Il tuo capo sembrerebbe essere il tuo cliente in questo caso, e il suo requisito principale è che sia in grado di mantenere l'applicazione quando vai avanti. Questo sembra abbastanza ragionevole.

Quindi, la scelta è fare ciò che chiede, o dimostrare che è possibile completare lo sviluppo E insegnargli come mantenere un'applicazione C # entro i limiti di tempo e ad un costo inferiore. Se non puoi farlo, non stai soddisfacendo i requisiti del progetto.

Non hai fornito molte informazioni ma penso che C sia assolutamente la scelta giusta - lavoro come ingegnere in un impianto industriale e la maggior parte (se non tutto) del nostro codice è scritto in C. Se hai bisogno di ottenere misure da un dispositivo (suppongo che un misuratore di portata o una termocoppia o simile qui) e visualizzarlo in C quasi in tempo reale sia una scelta eccellente.

È veloce, portatile (non ho mai scritto in C # ma non credo che funzioni senza una particolare versione del framework installato e di solito è solo basato su Windows).

Certamente potresti usare un'altra lingua per fare la GUI. Ma potresti risparmiarti lo sforzo e semplicemente usare un pacchetto di tendenza preesistente (ce ne sono alcuni buoni open source disponibili).

Per riassumere direi che l'interfaccia sottostante con l'hardware parte C è una buona scelta.

Oh caro. Questa è un'applicazione in tempo reale? Controllo delle apparecchiature in tempo reale? Raccolta di dati in tempo reale? Usi una lingua con un garbage collector? Oh caro.

Anche se concordo sul fatto che probabilmente puoi eseguire l'app in un linguaggio più moderno in meno tempo, probabilmente non è questo il criterio principale. LA FACILITÀ DELLA PROGRAMMAZIONE È PROBABILMENTE MOLTO IMPORTANTE DEGLI ALTRI CRITERI, come quelli stabiliti dal proprio capo, E i tempi di risposta e il comportamento deterministico.

Ti avrei suggerito di fare un prototipo in C # o Python, solo per testare la funzionalità principale e l'interfaccia utente. POI testarlo, misurando latenze effettive e tempi di risposta, quando l'app viene colpita con molti dati, per molti giorni di funzionamento continuo. Le probabilità sono che l'app potrebbe finire per essere troppo lenta o rimanere indietro in momenti casuali, quando entra in gioco VM o il Garbage Collector.

Ti suggerisco di presentare ciò che hai fatto come PROTOTIPO.

La codifica in C non è così difficile. Se non sei all'altezza, dillo. Ci sono molti di noi pronti per la sfida. (Ho fatto la codifica C in tempo reale per, argh, decenni ormai).

Bene, la prima cosa da fare è andare dal tuo capo e confessarti. Hai ignorato la sua chiara richiesta e, peggio ancora, lo fai da mesi. Non so quanto tempo hai a disposizione, ma supponendo che sia il più delle volte assegnato per portare a termine il progetto, devi affrontare il fatto che potresti presto cercare un nuovo lavoro.

Prima lo affronti, meglio è.

In secondo luogo, non penso che tu possa convincerlo che ANSI C è inadeguato, quello che devi fare è convincerlo di molte altre cose (1) che c # è adeguato, (2) può facilmente imparare a mantenere c #, (3 ) che non eri disposto a scriverlo in C. Supponendo che tu abbia ancora un lavoro e una parte da svolgere con questo progetto, mi concentrerei su 2, sottolineando le somiglianze tra c e c #.

Citazioni in risposta ai commenti ...

Alcuni mesi fa, abbiamo iniziato a sviluppare un'app [...] Dopo alcuni giorni, ho demolito l'intera cosa e ho ricominciato da capo usando C #

ha incaricato di sviluppare questa applicazione in ANSI C. La logica è che è l'unico che sarà in giro per tutto il tempo, e quindi deve essere in grado di capire cosa stiamo facendo.

Questo è un requisito abbastanza ragionevole.

Ha anche stabilito che non dovremmo usare tipi di dati astratti;

Questo non ha senso. Ora sta iniziando a sembrare un po 'sospetto, perché questo è un requisito di progettazione del programma e non un requisito linguistico. Se il codice dovrebbe essere facile da mantenere, l'implementazione di ADT o l'uso di quelli ben testati, dovrebbero essere una priorità.

ci ha persino fornito un elenco con il nome delle variabili globali (sospiro) che vuole che usiamo.

Ok, quindi adesso puzza. Ora possiamo dire che il tuo capo ha un'esperienza limitata non solo da vari linguaggi di programmazione, ma dalla programmazione in generale. Un abile programmatore veterano, indipendentemente dalle preferenze linguistiche, non farebbe mai una simile affermazione. (L'unica eccezione che mi viene in mente è se la maggior parte del codice è progettata per essere eseguita su un sistema incorporato abbastanza piccolo, e quindi ci si aspettava che tutta la memoria di lavoro necessaria per il codice fosse pre-allocata. L'idea che lo stesso codice ci si aspetta che l'interfaccia utente a livello di schermo contesti fortemente che ciò avvenga, comunque).

Immagino che il tuo capo non sia mai stato coinvolto in progetti software mission-critical su larga scala, ma molto probabilmente ha fluttuato in vari progetti di bassa qualità.

Quindi questo non ha nulla a che fare con il linguaggio di programmazione C. Puoi anche scrivere facilmente programmi ugualmente difficili in C #. È un errore molto comune credere che una buona progettazione del programma dipenda dalla lingua. Questo semplicemente non è vero!

C # ha certamente una sintassi più bella, più pulita e meno oscura di C. Ha un sacco di supporto per la progettazione di programmi, dal momento che ha molte più parole chiave correlate a OO di C. Ma a parte questo, non ti dice come scrivere i tuoi programmi. Se ritieni che tutto ciò che è scritto in C sia terribile di default e tutto ciò che è scritto in C # sia il paradiso di default, scommetto che stai scrivendo programmi C # piuttosto terribili senza accorgertene.

Quello che vorrei suggerire è che tu prima di ogni altra cosa realizzi un progetto di programma astratto, indipendente dalla lingua, ma dettagliato. Utilizzare il normale approccio orientato agli oggetti. Quali oggetti ci sono e come comunicano tra loro, quali sono le dipendenze necessarie ecc. Ecc. Quando hai pensato abbastanza al progetto del programma e l'hai messo sulla carta, non dovrebbe importare molto a te né al tuo capo che lingua in cui hai scelto di implementarlo.

Il primo problema che devi affrontare è emotivo, irrazionale. Il settore IT è in costante cambiamento e, sebbene ci siano posti per tutto, rifiutare di migliorare o accettare il cambiamento è un problema.

Perché il tuo capo si aggrappa ad ANSI C? Se questa è l'unica lingua che conosce, allora forse è tempo di cambiare, ma un argomento razionale potrebbe essere insufficiente. Il tuo capo si sentirà sottovalutato o probabilmente licenziato se costretto a lavorare in una lingua sconosciuta? Sottolinea l'esperienza che ha e altri benefici che porta.

Se non risolvi questo problema, tutti gli argomenti razionali che puoi portare saranno sprecati. Come subordinato, potresti non essere quello che può avere questa discussione con lui. Forse affronta questo argomento con uno degli altri manager, se ce ne sono.

Consideralo anche dal tuo punto di vista. Perché vuoi usare C #? Quanto di tutto questo è il desiderio di usare qualcosa di nuovo e bello? Sii onesto con te stesso. Se lo riconosci, ti aiuterà a discutere in modo più efficace.

Il secondo problema riguarda i rischi e i costi. Scrivere software è costoso e la scelta della lingua è un fattore importante in questo. Tener conto di:

1. Quanto tempo ci vorrà per scrivere in C # contro C? Con un orientamento degli oggetti più semplice e una migliore raccolta dei rifiuti, C # potrebbe essere più semplice. Tuttavia, se l'applicazione utilizza molte chiamate API non gestite, C potrebbe essere più semplice.
2. Se usi C #, devi acquistare strumenti aggiuntivi? Sembra che tu abbia già utilizzato Visual Studio ma hai bisogno di strumenti aggiuntivi per la localizzazione, la revisione e l'analisi del codice, il debug e così via?
3. Quanto è facile da mantenere? Se trovi un bug, quanto velocemente può essere risolto. C # può ridurre questo orientamento dell'oggetto. La garbage collection automatica evita anche la maggior parte dei problemi di perdita di memoria e di puntatore.
4. Quanto è facile supportare? Se si dispone di personale di supporto, potrebbero sapere come leggere un dump di arresto anomalo ma sanno come utilizzare windbg con SOS? Le macchine target hanno già installato una versione appropriata del framework .Net?
5. Valuta il personale. Quante persone conoscono C contro C #? Se uno di voi o entrambi abbiate lasciato l'organizzazione, quanto sarebbe facile sostituirvi? Gli sviluppatori C sono più economici o più costosi degli sviluppatori C #?

Potrei continuare, ma il punto è smettere di discutere solo sui meriti tecnici delle lingue. I meriti tecnici sono cose che solo tu e il tuo capo capite. Se inizi a parlare dell'impatto sul business, attiri un gruppo di persone molto più ampio e fai una discussione molto più convincente.

Forse C è una scelta migliore. C # non è automaticamente migliore per tutte le situazioni. Forse fai questo progetto usando C ma fai una prova del concetto C # per il prossimo. Ricorda che puoi perdere la battaglia ma anche vincere la guerra.

Forse un altro argomento: probabilmente è molto difficile trovare studenti di informatica che abbiano abbastanza esperienza per scrivere codice C senza fare errori. ANSI C non è la prima cosa che la gente impara oggi.

Ora tutti gli studenti di informatica mi uccideranno.

Hai completamente fallito nel convincerci che ANSI C era inadeguato. C è un linguaggio eccellente che sembra adattato al tipo di compiti che hai descritto. Con la breve descrizione dell'attività (tranne i requisiti linguistici), consiglierei anche C (o forse andare).

Penso che il problema sia che stavi programmando in C con la tua mente pensando in C #. Ho un problema simile quando passo da Perl a C o Java. Devi imparare ad adattarti alla lingua e non imparare a tradurre dal tuo modo di pensare verso la lingua del giorno.

Il problema non è il tuo capo o il linguaggio C, il problema è aprire la tua mente verso diversi modi di pensare. Cambiare il linguaggio di programmazione è qualcosa che ti gioverà.

Prima di tutto, devi dire al tuo capo che ora è in una lingua diversa. Sarà (comprensibilmente) arrabbiato se riporti qualcosa di intenzionalmente contro i requisiti senza preavviso.

Ora, il modo migliore per spiegare queste cose al capo / manager è metterlo in termini di tempo e denaro. Stimare quanto tempo impiegherebbe un progetto del genere in ANSI C, quindi stimare quanto tempo occorrerebbe in qualcosa di livello superiore come C #. Nota ho detto di livello superiore, non moderno. Questo può aiutare anche a sistemare le cose. Voglio dire, non affronteresti la verniciatura di una stanza con solo un minuscolo pennello, useresti i rulli e altre cose che fanno sì che ogni tratto (riga di codice) copra più area del progetto. Inoltre, se tu o uno dei membri del tuo team non conoscete C, o vi sentite a vostro agio nella realizzazione di un grande progetto in C, ciò influisce ancor di più sul problema del tempo perché dovranno essere pronti.

Sembra anche che il tuo capo stia cercando di micromanage. Sono sicuro che una delle altre risposte proverà a spiegare come convincere il tuo capo a farlo meno

L'avversione del supervisore agli ADT è stata affrontata altrove, così come l'apparente inconsapevolezza dei devoti sui costi GC, quindi mi concentrerò sui "thread".

Forse piuttosto che pensare in termini di threading .NET (o JVM, se così indottrinato), ciò che potresti desiderare è più processi, usando un meccanismo di comunicazione tra processi (IPC) per comunicare tra loro. Ad esempio: messaggi di Windows, memoria condivisa, buffer di file mappato in memoria, named pipe, qualunque cosa. Dedica piccoli processi all'interazione con un dispositivo o aspetto del dispositivo e verifica l'IPC per comunicare gli aggiornamenti e riconoscere le richieste, e avere un processo un po 'più ampio per mantenere la GUI e comunicare con i "monitor" dell'apparecchiatura utilizzando qualsiasi IPC selezionato.