Sviluppo software - L'industria e le tendenze generali / Cattive pratiche [duplicato]

4

Sono uno sviluppatore web e faccio parte di un piccolo team che lavora su un'abbondanza di progetti. Questa è la mia prima vera "vera" società dopo la laurea in informatica e ho circa 2 anni di esperienza in Asp, SQL ecc.

Cercherò di arrivare direttamente al punto qui. Prima di un paio di cose:

1) Non abbiamo MAI commentato il codice. "Il codice di commento è per i deboli" sono le parole esatte, e possiamo piuttosto usare quel tempo che avremmo speso per inserire commenti qua e là per sfornare altro codice.

2) Non facciamo documentazione. "We it IT guys" e non abbiamo bisogno di documentare, lo ricordiamo automaticamente .. (Non le mie parole)

3) NON ABBIAMO MAI avuto recensioni o riunioni di codice. Quindi chiunque può inviare qualcosa al repository SVN. Abbiamo un sacco di progetti, le probabilità che un altro sviluppatore vedrà il tuo codice altamente improbabile.

4) Non eseguiamo test unitari di alcun tipo. Abbiamo "tester" che non sono tester dedicati, dipartimento piuttosto ambiguo responsabile della gestione dei progetti, ecc. Conosce bene il sistema in modo che possano eseguire test front-end (in genere eseguiti rapidamente).

5) Abbiamo un "Se costruisce la nave con la mentalità". Mi viene il brivido ogni volta che qualcuno lo menziona. (Fondamentalmente non ci interessa la qualità del codice).

6) Scoraggiato dal chiedere aiuto agli sviluppatori senior, nessuna guida di mentore. Lavoriamo come macchine. Finché continui a sfornare codice, stai bene.

7) Alcuni rendono il codice dinamico al punto che nessuno può mantenerlo. No davvero .. Dynamic SQL all'interno di SQL dinamico all'interno ... 5000 query SQL linea. Si arriva letteralmente al punto in cui nessuno, tranne il "genio" che lo ha scritto, può o vuole mantenerlo. Certo, vuoi rendere il codice il più dinamico possibile, ma dovrebbe essere comunque mantenibile? O ho sbagliato qui?

8) Non ci sono specifiche. Ma quando ti viene chiesto di prevedere e fare una stima di quanto tempo ci vorrà per correggere un "bug" o fare qualcosa su un pezzo di codice che non hai mai visto prima, ci si aspetta di fare una stima "lì e poi " sul posto. 2 settimane, 1 giorno e 3 ore e mezza ... Bello ... Finalmente finisce per essere totalmente scorretto, tutti mancano le loro scadenze quindi l'affare è infelice.

Siamo così frettolosi da fare errori su carta, che ci affrettiamo, commettiamo codice cattivo non testato, facciamo le cose male e scaviamo un buco per la prossima povera anima che deve mantenerla.

es. Ho fatto un miglioramento in una coppia in cui ho aggiunto i diritti per una funzione utente. Un paio di mesi lungo la linea, in arrivo un altro miglioramento assegnato a qualcun altro. Ha visto che l'ho già fatto e ha costruito un'altra funzione che ha "attivato" il mio codice. Quindi avevamo 2 funzioni completamente identiche con una diversa formulazione. Il bug per risolverlo è venuto da me, e ho dovuto risolvere il codice.

Un altro scenario. Abbiamo avviato una ripetizione di un progetto in MVC. Invece di ricercare e prendere tempo per conoscere MVC, lo sviluppatore ha fatto il salto e ha iniziato a programmare con SESSIONI e controlli codificati ecc. Invece di utilizzare gli helper HTML. Le pagine di layout, BundleConfigs e tutte le altre parti essenziali e di base sono state trascurate. Perché non abbiamo fatto le cose correttamente?

La mia domanda:

Questo standard del settore è quello di affrettare le cose? Anche se ciò significa creare un numero maggiore di bug e problemi che in futuro richiederanno più tempo per risolverli? Invece di passare inizialmente un'ora o due in più e fare qualcosa in modo corretto, dobbiamo tornare a bug dopo bug, alla fine ci costa 10 ore di lavoro. (Certo, ci saranno sempre bug), ma sembra che i ragazzi ricevano lodi sono quelli che commettono codice orribile e creano mal di testa per tutti. Sembra che ci sia poco spazio per qualcuno che prende le cose un po 'più lentamente e appoggia una solida base.

Inoltre, è standard del settore non eseguire test, codice di commenti, creare documentazione ecc.?

Sono un po 'frustrato a questo punto, non so dove guardare ...

Gradirei qualsiasi commento o opinione.

Modifica

Credo che la mia domanda abbia avuto una risposta indiretta. Sono curioso riguardo all'industria generale e ad altre società? Tutte le aziende sono orientate in questo modo? C'è luce nel tunnel, se dici che vai a lavorare per un grande giocatore come Microsoft o Google? Qualche azienda là fuori si preoccupa ancora di test delle unità, revisioni del codice, altre revisioni delle prestazioni o pratiche di qualità del codice? Sembra che la risposta dagli altri articoli sia purtroppo no. Quindi, come voglio distinguere la mia domanda dalle altre domande esistenti, voglio sapere che aspetto ha l'erba dall'altra parte? Altre società?

    
posta fransHbrink 01.02.2015 - 18:56
fonte

2 risposte

5

Is this industry standard to rush things?

In una certa misura. Le aziende sono nel mondo degli affari per fare soldi e (quasi universalmente) gli uomini d'affari vogliono le cose più velocemente, anche a scapito di una qualità ondulata della mano.

Furthermore, is it industry standard not to do testing, comment code, create documentation etc.. ?

Nella mia attuale azienda, non abbiamo alcun dipartimento di controllo qualità. Di recente ne ho sentito parlare anche di altri che non lo fanno. Ci sono un numero di argomenti. Avere un dipartimento QA significa che gli sviluppatori hanno maggiori probabilità di trascurare la qualità dal momento che "non è il loro lavoro". Avere un dipartimento di QA è troppo costoso per il numero di bug che trovano. Le persone di QA dedicate sono in gran parte orribili, quindi perché preoccuparsi?

È decisamente discutibile se questa è una buona idea. Non è certamente standard.

"Commenting code is for the weak" are the exact words, and we can rather use that time we would've spend on inserting comments here and there on churning out more code.

Che tipo di commenti ti aspetti? Certamente alcuni commenti ben posizionati sono buoni, ma i commenti in stile javadoc sono sempre più rari. I commenti non saranno di aiuto se la tua classe / funzione / variabile ha un brutto nome. Se hai un buon nome, i commenti sono sforzi duplicati. Se hai dei brutti nomi, i commenti non fanno altro che perdere tempo speso meglio per correggere i tuoi nomi.

"We are IT guys" and we don't need to document stuff, we remember it automatically..

Anche se non sono d'accordo con la ragione, la documentazione è decisamente rara in molte industrie per una buona ragione. È costoso da creare. È invariabilmente non aggiornato o errato. E spesso devi duplicarlo per vari tipi di pubblico di destinazione.

We NEVER have code reviews and or meetings.

Quasi tutte le industrie avranno alcuni incontri. Le revisioni del codice sono meno comuni, ma forse non necessarie come si potrebbe immaginare. Ho lavorato in alcuni posti che richiedono recensioni di codice e probabilmente il 75% delle volte sono completamente inutili. Processo per motivi di processo. E questo è in posti che fanno bene le recensioni del codice. Se non hai l'abilità / pazienza / comunicazione per fare recensioni sul codice piuttosto che mettere a tacere cose inutili o fare a turno a criticarsi a vicenda ...

We have a "If it builds ship it mentality"

Impressionante. Questo è abbastanza comune in questi giorni poiché i check-in con gating e le suite di test automatizzate possono garantire che il codice di costruzione funzioni correttamente. ... anche se non sembra che tu abbia quel tipo di infrastruttura.

There are no specifications.

Purtroppo, anche comune. Se stai agendo bene, allora la tua specifica è il codice, che accumuli giorno per giorno e settimana per settimana lavorando a stretto contatto con i tuoi stakeholder. Più spesso, è una scusa per gli uomini d'affari non fare il loro lavoro.

Detto questo, il tuo argomento sulle stime è di pesce. Cosa ti fa pensare che le specifiche renderanno migliori le tue stime? Probabilmente cambieranno comunque ...

Quindi quello che descrivi sembra un ambiente disgustoso, non standard, disfunzionale, preso insieme - uno che si aspetta che le persone pompino un codice scadente senza una visione a lungo termine. Ma in isolamento, alcune delle cose con cui hai problemi non sono tanto i problemi se fatti bene, o non la causa della cattiveria che vedi. E anche questo tipo di visione del codice a breve termine può essere praticabile nelle aziende in cui il codice verrà gettato via e / o il time to market conta davvero (che è molto, molto meno di quanto pensino gli uomini d'affari).

    
risposta data 01.02.2015 - 20:24
fonte
0

Guardalo con gli occhi del business: o, questo modo di lavorare è sbagliato, vuol dire che prima o poi l'azienda non sarà in grado di trovare sviluppatori, o di assumerne abbastanza per sistemare tutto il codice non stampabile. Oppure, il codice genera ancora abbastanza soldi per la sopravvivenza dell'azienda. Pertanto, non c'è niente di sbagliato.

    
risposta data 01.02.2015 - 19:44
fonte