Resistenza all'astrazione [chiuso]

Perché? Beh, pensa in questo modo: sei felice di questa situazione perché sei tu a metterla lì, quindi sai già cosa significa @ Link. Probabilmente i tuoi colleghi no. Questo è il punto dolente delle astrazioni.

Immagina di incontrare una nuova pagina che qualcun altro ha creato e tutto ciò che ha è @ Page_7 in alto. Ti dispiacerebbe che tante informazioni sulla creazione e il layout della pagina fossero state astratte (e sarei d'accordo) ma questo esempio estremo mostra quale sia il problema: per usare queste astrazioni devi sapere che sono in uso, e capire dove e quanto saranno utilizzati. Forse se ti sono imbattuto in @@ header @@ e non hai conosciuto gli strumenti utilizzati per trasformarlo in codice o persino dove trovare il codice raw, allora ti lagnerai anche tu.

Ho visto troppo codice che scompare in una scatola nera e spunta dall'altra parte senza modo di sapere cosa succede nel mezzo (che è dove solitamente va male).

Ora questo potrebbe non essere il caso del tuo team e vogliono solo vedere l'HTML grezzo. Se è così che la squadra vuole, è così che deve essere. Non puoi arbitrariamente fare qualcosa di diverso se non usano tali tecniche. Non solo non è un buon lavoro di squadra, ma introduce artefatti che non capiranno perché non li usano.

Perché sono sviluppatori di software intelligenti, esperti e professionali.

Separare i livelli di astrazione è una parte assolutamente cruciale per isolare qualsiasi problema. Uno dei primi passi nella creazione di una testcase per riprodurre un bug (sia esso fisicamente che virtualmente nella tua testa) consiste nel prendere l'applicazione a più livelli e nell'esaminarne uno uno alla volta.

Quindi, ad esempio:

• le informazioni sullo schermo sembrano corrette?
• fa il codice HTML utilizzato dal browser per renderlo corretto?
• le direttive Razor sembrano corrette?
• i dati nel database sembrano corretti?

Questo è il motivo per cui le domande su Stack Overflow che riguardano tutti MySQL, PHP e HTML allo stesso tempo rettificano davvero le mie capacità. L'OP dovrebbe restringere il problema al livello tecnologico one prima di postare: ciò potrebbe benissimo implicare la scoperta di cosa sia il "raw HTML" che viene inviato al browser per il rendering.

Non riesco a capire quale dolore devi sopportare cercando di capire, mantenere ed eseguire il debug di un'applicazione senza eseguire questo passaggio fondamentale. Dividi e conquista!

L'HTML è perfetto per le astrazioni ed è per questo che esistono molti sistemi di template. Il problema con il tuo esempio è forse che stai nascondendo troppe informazioni: target e class attributi sono implicitamente definiti, e @Link , come nome, è troppo generico. Se il link è un link rapido, chiamalo @QuickLink .

Se la tua squadra già utilizza Razor, sembra che i tuoi costi siano stati ritenuti accettabili dai tuoi colleghi, quindi dubito che siano strongmente contrari all'approccio in linea di principio.

Ho paura che tu debba fare più domande per capire il dolore che provano i tuoi colleghi. Chiedi loro come potrebbero riscrivere il tuo esempio e cosa farebbero per attenuare il problema di avere un codice duplicato. Non uso questa particolare tecnologia, ma quanto è difficile eseguire il debug? Quanto è difficile eseguire un test e vedere l'HTML generato?