Come "child proof" dovrei scrivere codice come programmatore solista? [duplicare]

Naviga le tue risposte
1

Nella nostra azienda c'erano una volta più programmatori, ora sono l'ultimo uomo in piedi. Ho ereditato tutto il codice e mantengo, riscrivo, estendo (, sistemo).

Mi imbatto sempre in questo comportamento che cerco di rendere la cosa ingannevole in modo che un collaboratore di dummie non possa rovinare il codice. Ma ci sono dei limiti a quello che posso fare. Non posso impedire che qualcuno abbia un riferimento a un oggetto. Persino le classi di sistema java / android ti danno un oggetto che non dovresti tenere ma utilizzarlo localmente e questo è tutto.

Nella nostra azienda molto è andato storto e io sono una specie di bambino bruciato, vedo possibilità come qualcuno potrebbe fare la cosa sbagliata e il codice continua a bloccarsi e mi viene chiesto "perché scrivi cose del genere" ...

In questo momento sono l'unico programmatore, ma in futuro forse ne avremo di più (di nuovo), ma in questo momento mi limito a trattenermi spendendo troppo tempo a cercare di capire come potrei scrivere le mie cose in modo tale che la minima quantità di errori può essere fatto con esso. Anche se sarei quello che ha dovuto commettere l'errore.

Come tutti quelli che faccio errori ofc. Quindi controllo i valori ecc. E scrivo i limiti nei java-doc per ricordare a me stesso quali valori posso passare, ecc. Quei semplici controlli non sono ciò di cui stiamo parlando. Sto parlando di ciò che spesso potrei scrivere un metodo in un modo semplice e buono ma una voce nella mia testa dice "oh no, e se QUALCUNO passasse un parametro sbagliato o facesse questo e quello con esso" e all'improvviso mi ritrovo a incapsulare la logica e rendere le cose più complicate solo per aggiungere una sorta di protezione contro ... i programmatori dummie con me sono l'unico possibile.

NON sto lavorando su alcuna API aperta o cose condivise. Non ci sarà (molto probabilmente) nessun controllo del codice, ecc. Io sono l'unico che usa il codice e rimarrà così per molto tempo.

Quindi, come faccio a smettere di fare questa codifica infallibile che mi costa troppo tempo e capacità intellettuali.

EDIT: ho letto l'altra domanda + risposte. Capisco l'intera 'programmazione difensiva' ma mi chiedo quando lo sto prendendo troppo lontano? E questo è più il mio problema.

    
posta NikkyD 01.09.2014 - 14:28
fonte

4 risposte

4

Come qualcuno che ha iniziato in Basic e C; Ho una politica:

If it can explode, make sure it explodes.

La paranoia con controllo degli errori e stili difensivi spesso crea un codice più lento e più difficile da eseguire il debug. (E può introdurre i propri bug) La realtà è che il codice deve essere documentato e che dovresti aspettarti che uno sviluppatore ragionevole lo usi. Se stai facendo null controlla dappertutto, allora c'è qualcosa di sbagliato nel design in generale.

Più cerchi di nascondere le cose più spesso ferisci te stesso o la tua squadra. Ritorna a morderti nel sedere.

    
risposta data 01.09.2014 - 21:50
fonte
3

Il modo migliore per rendere il codice a prova di bambino è quello di renderlo disaccoppiato in moduli, quindi ogni modulo può avere la sua API documentata e può essere progettato per fare bene 1 cosa.

Questo non impedirà a un bambino di prendere il modulo di rete e di inserirlo nello slot DVD, ma ti permetterà di spegnerli in seguito per non utilizzarlo come previsto, come dimostrato dalla documentazione.

Questo significa che devi dedicare più tempo alla progettazione di classi e moduli e ai limiti dell'interfaccia, ma è un tempo ben speso.

    
risposta data 01.09.2014 - 15:28
fonte
1

Ok, quindi quello che capisco tu stia cercando di capire (forse capisci), è che devi assicurarti che nessuno faccia male al tuo codice? (perché se incasinato il codice le cose si rompono). Forse la soluzione alla tua eccessiva preoccupazione non sta rendendo il tuo codice a prova di bambino, ma invece, aumentando la ridondanza, dovresti considerare l'utilizzo di subversion. Subersion fondamentalmente consente di salvare un progetto in un repository (repository), quindi quando si vogliono apportare modifiche al codice, si "dirama" il progetto, nel senso che tu (o qualsiasi altro programmatore) puoi apportare modifiche al codice in questo senza che questo abbia effetto sul "tronco" (copia principale), quindi se il codice non viene modificato, è solo nel ramo e non nella versione reale, ma se vengono apportati miglioramenti significativi al codice, è possibile unire il ramo con il baule significa che i cambiamenti avvengono nella copia di lavoro reale! Quindi, finché questi programmatori "dummie" stanno lavorando solo sul ramo, niente viene incasinato. Un'altra funzione interessante è che se viene incasinato nel bagagliaio, puoi tornare indietro nel tempo fino al momento in cui tali modifiche non sono state apportate. Subversion è davvero un salvavita, considera beanstalk come repository e TortoiseSVN come software di sovversione.

    
risposta data 01.09.2014 - 15:14
fonte
1

Mi piace la risposta di @misterbiscuit, anche se sono un ragazzo Java e ho poca esperienza con C (sembra che alcuni concetti siano intercambiabili oltre il linguaggio di programmazione).

Vorrei modificare:

  • Se scrivi software dal quale potrebbe dipendere la vita (mia) di qualcuno, ti incoraggio a controllare due volte e a triplicare ogni valore di fckn. Altrimenti, continua a leggere.
  • Convenzioni - se null è un parametro di input valido, è necessario controllarlo. Se, per convenzione, null non è consentito (ma per alcuni casi speciali), puoi presumere che non lo otterrai. Ci sono buoni libri disponibili che ogni sviluppatore dovrebbe aver letto ("Codice pulito", "Efficace Java")
  • Test delle unità: quando si modifica il codice legacy, tendo a scrivere test unitari per il comportamento corrente . Questo porta a molti test che sembrano sbagliati, in effetti è solo il comportamento del codice di produzione che mi ha fatto scrivere il test in quel modo (per renderlo verde). Potresti fare lo stesso trucco, ma in anticipo - scrivere test che documentano il comportamento corrente.
  • Documentazione - è necessario scrivere architettura e concetti in modo significativo. Nessuno legge un documento di 300 pagine prima di iniziare la codifica (tranne che si chiama "Java for Beginners"). Mi piacciono i concetti di arc42 , perché puoi documentare l'architettura in 3 pagine, se vuoi. e quindi aggiungere alcune regole comuni e il gioco è fatto. (Tuttavia, dipende da molti altri fattori su come sarà la documentazione)
risposta data 01.09.2014 - 23:05
fonte

Leggi altre domande sui tag

Come motivare i modificatori di accesso di classe mutevoli adattivi Perché il compilatore non si lamenta quando provo ad accedere a un valore di array inesistente?