Come affrontare un architetto di software che ritiene di essere al di sopra di un programmatore standard? [chiuso]

-2

Questo post sembrava appartenere da qualche parte tra SE Workplace e SE Programmers. Tuttavia, poiché si rivolge specificamente a un problema di programmazione, ho deciso di inserirlo qui.

Quali sono le responsabilità di un architetto? Sto chiedendo perché in ogni azienda per cui ho lavorato, i doveri dell'architetto erano sulla falsariga di:

  • Specifica l'interfaccia dei moduli funzionali.
  • Partecipare alle revisioni del codice.
  • Preparazione dei documenti delle specifiche che descrivono la funzionalità che deve essere implementata, inclusi, ma non limitati a, diagrammi di sequenza e simili.

Recentemente ho iniziato un nuovo lavoro. Qui, i compiti dell'architetto sono:

  • Descrivere un problema e l'implementazione proposta a ciascun membro del team separatamente, invece di documentarla una volta e poi lasciarci familiarizzare con essa.
  • Impegnarsi in sequenze di codifica di quasi due settimane della durata di 24 ore in cui distribuisce un sacco di codice che non è affatto documentato, anche se il codice fa ciò che deve fare.
  • Non ti preoccupare affatto della revisione del codice, sia essa sua o di altri.
  • Ignorare gli standard di codifica che abbiamo cercato di attuare come programmatori: test di unità, documentazione o formattazione.
  • Essere completamente all'oscuro delle regole che governano il linguaggio in cui scriviamo la nostra applicazione in (C ++), incluso ma non limitato alla gestione del ciclo di vita degli oggetti, o passando grandi strutture via copia.

Quando si confronta con queste cose, risponde che "Non potremmo scrivere le cose che scrive in un modo che dovrebbe essere scritto". Quando ho parlato con alcuni dei più senior staff qui, hanno semplicemente detto che "È come è sempre stato", e che ha semplicemente più margine di manovra con la gestione perché individualmente mantiene un sistema per la gestione dei test della nostra applicazione che è ovviamente vitale per l'azienda.

Ritengo che un simile comportamento non dovrebbe essere tollerabile, dal momento che riduce il numero di persone che sono in grado di mantenere il codice praticamente a zero, poiché solitamente scrive il codice più basilare per l'applicazione che è necessario utilizzare in seguito. Capisco che potrebbe essere abituato a lavorare da solo a causa delle sue precedenti esperienze, ma ripetendo le sue pratiche, crea praticamente un sistema che nessun altro può mantenere in seguito.

C'è qualcosa che può essere fatto nella mia situazione, a meno che non abbia passato le mie dimissioni e abbia cercato un'altra opportunità? Sono davvero frustrato per la situazione, poiché la vedo semplicemente come un abuso di potere.

    
posta Standard Programmer 12.06.2016 - 17:30
fonte

1 risposta

4

What are the responsibilities of an architect?

Varia da azienda a azienda. Alcuni fanno il design di alto livello per il sistema. Alcuni servono come traduttori da business a dev e viceversa. Alcuni programmatori mentori su come essere migliori programmatori. Alcuni scrivono tutto quel codice nodoso che nessun altro può fare. Alcuni siedono nei loro uffici navigando sul Web, raccogliendo stipendi.

Is there anything that can be done in my situation, short of handing in my resignation and looking for another opportunity?

Assolutamente.

Iniziamo con la prima opzione: dare all'architetto il beneficio del dubbio. È del tutto possibile che rendendo il codice di lavoro stiano fornendo molto più valore all'azienda rispetto alla documentazione. Sì, potrebbe essere più lento o più soggetto a errori da parte tua per mantenerlo, ma potresti essere ancora più lento o più incline agli errori nell'implementazione delle cose che hanno implementato.

Ho lavorato in luoghi in cui un programmatore di alto livello ha fatto l'azienda. Senza la loro capacità di fare cose che i concorrenti non potevano, la società avrebbe foldato. Se non lo fanno, non importa quanto sia mantenibile il codice: tutti i lavori non sono disponibili.

Ora, questo è il caso decisamente ottimista. Uno scenario forse più probabile è quello in cui un buon programmatore non ha tenuto il passo con i tempi. Non hanno sentito parlare dei test unitari. Non comprano nella discussione dei costi per la manutenibilità. Forse sono occupati. Forse sono testardi. Forse non erano così tanto per cominciare. Non importa.

Ciò che devi fare è mostrare il valore in queste cose. Se l'architetto afferma che non avresti potuto farlo bene - sfida questo chiedendo di fare uno dei prossimi moduli. Se l'architetto dice che sono necessarie grandi copie di struttura, mostra che non lo sono rifattorizzando il codice e accantonandolo. Se l'architetto afferma che il codice è ampiamente gestibile, prendi alcune metriche sul tempo medio di risoluzione e dimostra che non lo sono. Se l'architetto non ritiene che i test unitari siano utili, mostra come puoi ottenere codice più veloce e con meno difetti usandoli.

E ricorda che sei tutto lì per risolvere i problemi. Se l'architetto non vuole risolvere i problemi a modo tuo, allora chiedi quale alternativa hanno.

    
risposta data 12.06.2016 - 18:18
fonte

Leggi altre domande sui tag