Bug-prevent vs vs clean code

1

Se mi trovo di fronte alla decisione di scrivere un codice pulito, bello, ma mi piacerebbe aprire un nuovo percorso che i bug potrebbero prendere per apparire, dovrei prenderlo? (Purché non sia disposto a dedicare il tempo a trovare un modo che soddisfi entrambi).

Per elaborare: sto scrivendo un gioco Pong come pratica, e potrei scrivere la stessa identica riga di codice in due istruzioni if-else o includerla come un'altra istruzione. Quest'ultimo approccio è sicuramente più elegante, ma significa che qualsiasi oggetto di gioco non contato lo attiverà. Non dovrebbero.

Ora, dato che questo è un gioco Pong, gli unici oggetti di gioco sono le due racchette (o qualunque cosa siano chiamate), la palla e le pareti visibili che la palla può rimbalzare (cioè quelle orizzontali) o le pareti invisibili che servono da grilletti per attraversare per segnare un punto (cioè muri verticali). Quindi, l'aggiunta di un'altra istruzione non dovrebbe essere catastrofica in questo caso.

Ma in altri casi simili che incontrerei in futuro, lavorando ad altri progetti? Dovrei trascurare di scrivere codice pulito a favore della praticità o no? O dovrei forse includere un errore che verrebbe stampato sulla console nel caso in cui venga disattivato, per identificarmi e rendere più facile il debug? O dovrei davvero prendermi il tempo per scrivere codice che sia al contempo pulito e che prevenga l'errore?

Voglio risposte dal punto di vista sia di uno sviluppatore solista che di un membro di una squadra. Non deve riguardare lo sviluppo del gioco, ma piuttosto la programmazione in generale.

Qual è la pratica migliore?

    
posta Demetre Saghliani 06.06.2018 - 19:02
fonte

3 risposte

13

Il codice Clean Code vs. Bug-Free è una falsa dicotomia. Se introduci un bug nel tentativo di renderlo "più pulito" (o renderlo più fragile "aprendo un nuovo percorso" per i bug), allora non è molto più pulito, è solo diverso (e probabilmente peggio).

"L'eleganza" è una questione di gusti. Ad alcune persone piacciono le espressioni lambda; è il loro ultimo martello d'oro che fa sembrare tutto un chiodo. Ma le espressioni lambda sono come tutto il resto; hanno un "punto debole" per il loro uso.

Salvare un paio di linee di codice mentre si rischiano nuovi bug non è un compromesso efficace. Invece di pensare in termini di semplice eleganza, prova a pensare "più robusto".

Qualsiasi refactoring dovrebbe essere preceduto da una serie di test unitari che "dimostreranno" che il tuo codice funziona ancora dopo essere stato refactored.

    
risposta data 06.06.2018 - 19:14
fonte
1

Dipende dalla natura dell'applicazione che stai sviluppando e anche da altri parametri, ovvero scadenza del progetto, squadra vs solone, manutenibilità ed estendibilità.

Permettetemi di darvi un'analogia, dovreste fare un software ATC per aeroplani in cui un semplice bug può rompere il sistema di comunicazione e portare a conseguenze molto negative. D'altra parte, se vuoi creare un'applicazione per lo streaming da video e un bug può perdere alcuni dei frame, le conseguenze non sono poi così negative.

Infine, ricorda sempre che un codice pulito dovrebbe essere pulito a causa del suo aspetto non dovuto alla sua natura di facile prevenzione e identificazione dei bug. Personalmente ho la tendenza verso la codifica pulita.

    
risposta data 06.06.2018 - 19:40
fonte
1

Consentitemi di porre la vostra domanda in modo estremo usando un'analogia.

Dovresti occuparti di una sala operatoria pulita o quella in cui gli strumenti funzionano correttamente? Puoi cospargere di cloro, togliere tutti quei brutti cateteri e fili: la sala operatoria sarà abbastanza pulita, ma gli strumenti difettosi renderanno infelici sia il chirurgo che il paziente.

L'avevo preso in un'altra prospettiva. Il codice pulito appartiene alla forma del codice, mentre il comportamento privo di bug è direttamente correlato alla soluzione del problema.

As Clean Architecture: una guida di artigiano alla struttura e al design del software, prima edizione di Robert C. Martin dice (nota che equipara anche design e architettura):

"The goal of software architecture is to minimize the human resources required to build and maintain the required system."

Posso solo aggiungere che è quasi impossibile prevedere con il 100% di accuratezza in che modo il sistema verrà sviluppato nel tempo, quali nuovi casi saranno prevalenti. Ma se l'architettura è ben pensata, gli sviluppatori comprendono il dominio, quindi l'evoluzione del sistema sarà fluida, fornendo sia un'architettura pulita, che un codice e riducendo al minimo i bug. Naturalmente, la praticità è in bilico tra le previsioni di sviluppo del sistema previste (a lungo termine) e le esigenze aziendali acute (a breve termine).

Credo che la risposta sia: prenditi cura dell'architettura e di entrambe le cose che stai cercando di contrapporre.

    
risposta data 06.06.2018 - 19:41
fonte

Leggi altre domande sui tag