In qualità di Junior Software Engineer dovrei dire che qualcosa è stato fatto male se mi sento così? [duplicare]

Chiedi a uno sviluppatore senior del tuo team. Non dirgli che pensi che sia sbagliato. Invece, digli che non capisci il codice e sei curioso di sapere perché è stato sviluppato così com'è. Chiedi loro di spiegarti il codice.

Chiedere una spiegazione del codice in modo non conflittuale da uno sviluppatore senior o qualcuno che ne conosca abbastanza sulla struttura e sui dettagli del codice è una buona idea.

Assicurati di chiedere informazioni (perché il codice è così com'è) che stai interrogando e prendi nota di quale sia la risposta. Se dopo la spiegazione viene fornita e non sei soddisfatto, approfondisci il problema e crea un caso e preparati a eseguirne il backup . Presentalo a chi ti ha aiutato per primo e chiedigli cosa pensano delle tue scoperte e lavora da lì.

A seconda della tua cultura del tuo posto di lavoro, potresti aspettare di avere l'opportunità di far passare qualcuno con te. Prenditi questo tempo per approfondire la questione se possibile. Generalmente uno sviluppatore junior non dovrebbe essere molto esperto e si presenteranno situazioni come questa.

In realtà, la risposta è "no". Parole come "buono" o "cattivo" sono usate solo dalla direzione. Per definire ciò che è "buono" devi diventare manageriale. Che questa sia o meno la tua preferenza è la tua preferenza.

Non sono io stesso un programmatore (beh, non in base alla descrizione del lavoro comunque), ma lavoro con / conosco molti programmatori. Conosco una donna, ad esempio, che è a basso livello di gestione per [inserire majeor telecom company] e l'uomo che è un ingegnere di progettazione senior per [inserire la maggior parte dei mezzi audiovisivi]. La donna continua a parlare di come sia "offensivo" e "irragionevole" per una persona del suo livello di carriera e ci si aspetta che l'esperienza apprenda nuove lingue. L'uomo ha iniziato a sviluppare ARM ma non vuole usare software "incompiuto" come Eclipse, quindi mi sta sempre facendo impazzire con gli strumenti a pagamento. Morale della storia - il codice cattivo esiste per tutti i tipi di motivi. Indicarlo non ti renderà amici.

Detto questo, se vuoi davvero farlo, l'altro consiglio presentato qui è davvero la strada da percorrere.

Oltre a ciò che dice @Bryan Oakley, sospetto che l'unica spiegazione per la mancanza di test unitari sia che il team non ha mai avuto il tempo di scriverli, questo è un dilemma comune, e rende anche estremamente difficile il refactoring .

Quindi, suggerirei che il corso più costruttivo che potresti fare è di fare volontariato per scrivere test unitari per il codice, forse come un modo per "comprenderlo meglio". Questo potrebbe risolvere uno dei principali odori che hai incontrato aprendo la porta per correggere gli altri.

Non aver paura di mettere in discussione qualcosa, ma non iniziare a puntare le dita. Per quanto ne sai, potresti riscontrare un caso grave di Esperto Principianti e le persone potrebbero essere appena diventate le loro vie. In tal caso, puoi sempre provare a illuminarli. Ma l'ego degli sviluppatori non è facile da gestire.

Anche questo potrebbe essere un codice legacy che è stato scritto prima del tempo degli attuali sviluppatori. Potrebbero essere altrettanto scontenti di quello che sei.

Informazioni sul modello di dominio anemico. Anch'io ero confuso dagli oggetti che vengono usati come strutture con getter / setter. Non mi piace particolarmente come viene utilizzato per TUTTO, specialmente nei progetti Java. Tuttavia, c'è un caso per questo design.

Un sistema può avere più computer che utilizzano più lingue. Gli oggetti possono essere utilizzati da javascript in un browser, un server C ++ app, un server di applicazioni Java, alcuni servizi web implementati in Python su una rete diversa, ecc.

Alcuni comportamenti sono diversi se si è sul server o sul client. Considera un metodo "salva". Se l'oggetto è in javascript, non può usare la stessa identica tecnica per ottenere quei dati nel database che il codice lato server farebbe. È possibile nascondere una chiamata di servizio nel metodo "salva" javascript. Ma non è male che il codice sia "consapevole" del livello in cui si trova e chiama esplicitamente il servizio.

Alcuni comportamenti non dovrebbero nemmeno esistere a seconda del livello in cui ti trovi. Considera un metodo "disegna". Questo sarebbe rilevante solo nel javascript lato client. Il comportamento dell'imballaggio con i dati può violare i principi della separazione. Il disegno dovrebbe essere fatto solo sui computer front-end. Sebbene tu possa dare all'oggetto diversi metodi su ogni livello, non sembra giusto.

Invece vai con il vecchio stile in stile C. Hai un oggetto simile a una struttura che passi tra i computer. (multi-lingua, diverse reti, lato server, lato client). I metodi in stile C sono "servizi" e potrebbero essere un servizio web. È possibile che si stia utilizzando un polimorfismo OOP pulito all'interno di ciascun livello, ma le app comunicano nella vecchia tecnica in stile C. (che non è sempre una brutta cosa).