Alcune classi contro 20 classi? Una domanda su bloat [chiuso]

Question

Alcune classi contro 20 classi? Una domanda su bloat [chiuso]

#1 da (8 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (0 voti)

7

Nel valutare il lavoro di una società di outsourcing, ho scoperto che hanno una propensione a dividere il lavoro in quante più classi possibili, ognuna delle quali è testabile. In un certo senso questo sembra encomiabile, ma lo stanno portando all'estremo e nessuno sembra in grado di controllarli.

Recentemente ho trovato quello che avrebbe dovuto essere un semplice componente dell'interfaccia utente che avrei implementato come nella maggior parte delle 3 classi (uno per i dati, uno per il controller, uno per la visualizzazione), in realtà erano suddivisi in circa 20 classi (ad es. classe base e più classi derivate) e protocolli, richiedendo alla fine circa 70 file sorgenti (file Objective C .m e intestazioni .h) che includevano un test per ogni parte, anche il più piccolo pezzo. Il loro codice, nonostante l'elaborato codice di test, funziona a malapena e si interrompe costantemente.

Giustificano questo con un vago discorso su SOLID e / o sul problema della "massiccia classe".

Questo codice è già stato scritto. A nessuno è stato permesso di progettarlo. Posso criticare l'implementazione, ma non influenzare realmente il design.

Quindi quale è una buona strategia, oltre a cercare un impiego migliore, per trattare con Outsourcing Companies Gone Wild dove i loro numerosi ingegneri espandono i progetti semplici il più possibile e il più a lungo possibile in questo modo, rendendoli complicati e vasti?

unit-testing design solid outsourcing

posta Questio 10.03.2018 - 20:45

fonte

4 risposte

Leggi altre domande sui tag unit-testing design solid outsourcing

Perché il modello di builder è spesso implementato in questo modo? Come funziona un thread dormiente?

score 8 · Answer 1

Dato problema x come posso dire che 20 è sbagliato e 3 è giusto?

Ecco come:

In una buona giornata il mio cervello può contenere 7 cose alla volta. Questo è tutto. Non piu. A volte è solo 5.

Quindi 20 è troppo. Non importa cosa sia x.

Tuttavia, 4 astrazioni con 5 classi nascoste dietro ciascuna vanno bene. E sì Questo è ancora 20. Probabilmente di più.

Quello che sto dicendo è che i numeri contano, ma anche l'organizzazione. Se questi ragazzi stanno impazzendo con classi piccole ma non fanno nulla per organizzarle, stanno causando un vero problema. Non è solo che non sei abituato allo stile. È che ti chiedono di ricordare più di 7 cose contemporaneamente.

Questo è uno stile valido. Stai attenta a non venire semplicemente contro di essa. Sottolinea invece la necessità di astrazioni affidabili per migliorare la leggibilità. Se devi immergerti in un'astrazione per capirlo, non funziona.

Hanno deciso di rompere le cose così piccole. È su di loro mettere tutto insieme in un modo che abbia senso.

score 2 · Answer 2

Senza vedere il codice è difficile dire se stanno facendo un lavoro buono o cattivo.

Ma normalmente è una buona idea infrangere il codice in minuscole classi. Questa strategia è molto comune quando non sei sicuro della migliore organizzazione del codice: quali classi hai veramente bisogno, come saranno organizzate, la conoscenza del dominio non è ancora buona, ecc.

Forse puoi discutere qualcosa su questa linea per convincere il resto della squadra che alcune classi hanno più senso essere una sola classe ora. C'è un articolo a riguardo di Martin Fowler.

Their code, despite the elaborate testing code, barely works and is constantly breaking.

Questo non è necessariamente un problema dalla strategia delle classi minuscole. Forse il progetto ha bisogno di alcuni test di integrazione per vedere se tutte queste classi funzionano bene insieme.

score 2 · Answer 3

La risposta alla tua domanda non può essere binario si o no. Dipende. Dipende se queste 20 classi sono il risultato di un'esplosione di classe a causa di un cattivo design o perché sono ben pensate per il design strutturato. Ad esempio: durante il refactoring del vecchio codice, mi sono reso conto che applicando il pattern del bridge il numero di classi può essere trasformato da x * y = > x + y. Lo stesso può succedere se pensi a pattern decoratore .

Quindi, come ho detto, devi capire se questo 20 è dovuto a x * yo x + y.

score 0 · Answer 4

Succede che ho bisogno di più di tre classi per MVC - se il controller deve fare qualcosa che è davvero complesso, ed è meglio estrarre la complessità in una classe separata, piuttosto che rendere il controller sempre più grande. O se la vista ha una vista secondaria complessa, specialmente se la suddetta sottoview può essere riutilizzata altrove.

Detto questo, qualsiasi classe extra è una complessità extra. Quindi rimuovere una piccola quantità di complessità in una classe separata è in genere cattivo. Se tre classi sono diventate 20, a meno che ciò che il tuo controllore doveva fare fosse straordinariamente complesso, potrebbe essere successo qui.