Domanda da ignorante... quanti metodi può contenere una classe?

[.Kurt]

vedi subito che "chiunque" significa "una dozzina di persone".

Significa solo che non hai mai visto un progetto fatto bene, o che gli spacciatori di acronimi ti hanno venduto robaccia. Visto che qui siamo nella sezione php te ne linko uno: http://symfony.com/
Un migliaio di contributori: https://github.com/symfony/symfony/graphs/contributors

O immagini di poter comprendere ogni singola riga di funzionamento di Windows 10 con tutti i suoi vari programmi di supporto, con 4 diagrammini?
(..)
Sarà... nessuno riesce a mettere mano a un progetto "serio", per il semplice fatto che è troppo grande.

Una parola: ortogonalità. Prendi symfony, che è un progetto medio/grande. Quanti di quei commit pensi che siano arrivati da persone che abbiano visto e compreso tutto il codice scritto finora? Proprio nessuno, neanche il fondatore. Perché non ha importanza (e non è proprio possibile e basta). Perché anche in quei milioni di righe di codice, se devi modificare qualcosa, sai già cosa devi andare a vedere. Quanto tempo pensi che ci voglia per lavorare o modificare uno di quei componenti senza averlo mai visto? 15 minuti.

ovvero che a nessuna frega niente di quanto è fico (a parte i fanboy), basta che funzioni?

Che dipende. Il "basta che funzioni" mi va bene se devo fare una cosa a cui so che ci lavorerò esclusivamente io e che utilizzerò solo io. Già se ci deve lavorare qualcun'altro, è bene farle bene le cose, per la sanità mentale di tutti quanti. Ancora di più se lo devi distribuire.

Perché, se io cliente, devo scegliere tra due sw entrambi funzionanti e che fanno le stesse cose, ma mentre uno è testato, documentato, con la metà del codice dell'altro, comprensibile, etc. e l'altro no, non ci metto molto a decidere quale scegliere.
Inoltre, è molto imbarazzante se il cliente, dopo neanche un mese, ti chiede una modifica e gli devi chiedere del tempo perché non hai idea di cosa faccia il tuo stesso codice.
Ancora peggio se una piccola modifica necessita la riscrittura di una buona parte dell'applicazione, lì c'è da piangere. E' esattamente in quel momento i venditori di acronimi scuoteranno tristemente la testa.

[zacca94]

Pattern ed antipattern un po' come fisica e metafisica?

Perdonami, difficilmente rispondo in maniera cruda a meno da non sentirmi preso di mira da commenti stupidamente sarcastici.

BOH ho notato che ostenti un bel pò superiorità ovunque spacciando verità assolute (o con commenti come questi).

Con te mi sembra di stare su un forum di Arch Linux, con la differenza che molto probabilmente in un luogo come quello saresti il primo ad essere continuamente perculato.

E alla fine MySQL andava a parare esattamente dove avevo intuito (anche se io ho citato un esempio in particolare) mentre lui criticava tutta una filosofia di pensiero di cui l'esempio faceva parte, che poi oltretutto non condivido, ma comprendo appieno il suo punto di vista. Quindi che volemo fa?

Anzi per non degenerare ed andare totalmente fuori ot. Io penso che il discorso di MySQL sia relativo:
- Ovvero gli standard sono importanti tanto quanto lo sono le persone che si impongono per essi, in quanto abbiamo ottenuto notevoli benefici grazie ad essi (ECMAScript docet). Quindi dare dell'hobbista a qualcuno potrebbe essere un pò denigratorio.

- In termini monetari probabilmente le risorse dovrebbero essere focalizzate in maniera differente. Ma su questo non mi dilungo.

[satifal]

Perdonami, difficilmente rispondo in maniera cruda a meno da non sentirmi preso di mira da commenti stupidamente sarcastici.

Se ti senti preso di mira da "commenti stupidamente sarcastici" il problema è esclusivamente tuo. Evidentemente hai, come si suol dire, la coda di paglia o poca autostima.
Dai su che la vita è bella.

[MySQL]

Significa solo che non hai mai visto un progetto fatto bene...
Una parola: ortogonalità. Prendi symfony, che è un progetto medio/grande. Quanti di quei commit pensi che siano arrivati da persone che abbiano visto e compreso tutto il codice scritto finora? Proprio nessuno, neanche il fondatore.

Guarda, sono tra i maintainer di un progetto più grande (forse il più grande), insieme a molte altre centinaia... ma...
"ortogonalità" significa...

Perché non ha importanza (e non è proprio possibile e basta). Perché anche in quei milioni di righe di codice, se devi modificare qualcosa, sai già cosa devi andare a vedere. Quanto tempo pensi che ci voglia per lavorare o modificare uno di quei componenti senza averlo mai visto? 15 minuti.

15 minuti? Guarda, mi basta così

Che dipende. Il "basta che funzioni"...

Come già spiegato ci sono tanti altri che la pensano in maniera diversa (dagli agili in giù). Se ritieni che chissà quale schemino ti consenta di capire (ed essere autorizzato a) come modificare lo scheduler (gli) Linux in un branch "vero"... in 15 minuti... OK... buona fortuna... cambi una virgola qui, e un server in Cina smette di funzionare (cit rimaneggiata).

Hai mai visto i mitici diagrammi di flusso? Ebbene, sarai d'accordo che non servono praticamente a nulla, se non per frazioni minime di algoritmi minuscoli (immagina il diagramma di flusso di Word...)
Ebbene UML e i superacronimi non fanno molto di più, aumentano forse di un ordine di grandezza il livello di comprensibilità (cioè passi da un foglio A4 a un foglio di plotter pieno di disegnini).
Oltre, purtroppo, non arrivano, perchè quando ti servirebbe uno schema grande come un campo da calcio non puoi farcela, qualsiasi cosa "spaccino" i vari "evangelisti".

Perché, se io cliente, devo scegliere tra due sw entrambi funzionanti e che fanno le stesse cose...

Ahem... direi che di clienti ne hai visti ben pochi, o pressochè nessuno in ambito industriale.
Perchè la risposta è "quello che costa meno".
Senza se e senza ma.
Provare, per credere.

Inoltre, è molto imbarazzante se il cliente, dopo neanche un mese, ti chiede una modifica e gli devi chiedere del tempo perché non hai idea di cosa faccia il tuo stesso codice.
Ancora peggio se una piccola modifica necessita la riscrittura di una buona parte dell'applicazione, lì c'è da piangere. E' esattamente in quel momento i venditori di acronimi scuoteranno tristemente la testa.

Certo, gli "spacciatori" gireranno con la Panda (aspettando di vendere un programma) mentre l'"agile" avrà l'autista o la Ferrari a seconda dei gusti.
Ho messo sopra un'intervistina che riassume molto bene la differenza tra "hobby" e "industria" informatica.

Ribadisco: ho come l'impressione che sei abituato ai progettini del sitarello del panettiere sotto casa o dell'(in)utiliy open source, dove se c'è un problema nessuno ti fa causa per i danni.

Non c'è nulla di male, in questo, intendiamoci.

Ma la minestra è diversa, molto diversa, quando i progetti costano centiania di migliaia di euro, e solo una frazione sono relative alle licenze, e devi fornire garanzie patrimoniali.
Quando poi si passa ai milioni (di euro) subentrano ottiche ancora diverse, ma in Italia essenzialmente non ci sono (se non per un pugno di aziende pubbliche e private, banche e assicurazioni).

Precisato tutto ciò siamo (hai dovuto riconoscere che...) giunti alla conclusione che neppure gli spacciatori di acronimi riescono a far comprendere come funziona un progetto complesso; ritenere di poterne modificare una porzione così... "a casaccio"... sperando che NON abbia ripercussioni più o meno complesse e più o meno sottili e difficili da individuare, significa avere ancora tanti tasti da premere.

Tra l'altro son curioso di sapere PERCHE' ci sono 1000 acronimi (che non significano assolutamente nulla, per chi ha le competenze per capirli) invece di 2. Se fossero così magici, perchè 1000?

[MySQL]

Ovvero gli standard sono importanti tanto quanto lo sono le persone che si impongono per essi, in quanto abbiamo ottenuto notevoli benefici grazie ad essi (ECMAScript docet).

Bhè direi che gli standard non esistono.
Che l'ingegneria del software è per il 90% fuffa (utile però per vendere i relativi corsi di certificazione o universitari)

Quindi dare dell'hobbista a qualcuno potrebbe essere un pò denigratorio.

Bhè diciamo che quasi sempre è un dato di fatto.
Il 99% (non il 100, intendiamoci) è della fascia hobbystica-panettiere-sotto-casa.
So dare due calci a un pallone, ma non mi ritengo un calciatore da serie A.

Con l'informatica la situazione è opposta: accendere un iphone e pensare di avere la scienza infusa. Magari...

Riassumendo: prima legge dell'informatica. Finchè funziona, lascialo stare.
Il tuo sito funziona ragionevolmente bene? Tienitelo stretto, perfezionalo, e vendilo a più clienti possibili, lascia perdere le "seghe" mentali se è procedurale o a oggetti, perchè troverai sempre il fico più fico che ti spiegherà che un programma a oggetti è merda, e bisogna farlo 100% funzionale (anche se è pressochè impossibile) e infine troverai il fico squared che ti dirà invece che lo devi scrivere in assembly.
Poi arriverà il Supremo che spiegherà come solo Java potrà salvarti

[Santino83_02]

perchè troverai sempre il fico più fico che ti spiegherà che un programma a oggetti è merda, e bisogna farlo 100% funzionale (anche se è pressochè impossibile) e infine troverai il fico squared che ti dirà invece che lo devi scrivere in assembly.
Poi arriverà il Supremo che spiegherà come solo Java potrà salvarti

sei rimasto indietro, se è in php, ogni settimana troverà qualcuno che gli dirà di farlo con l'ultimo framework uscito, per poi trovare quello che gli dirà di farlo in nodejs cambiando tutta l'app con qualche *js del caso

[.Kurt]

Hai mai visto i mitici diagrammi di flusso? (...) Ebbene UML e i superacronimi non fanno molto di più

Non ho mai accennato ne a diagrammi di flusso ne a UML. Mai fatto uso, tranne qualche volta a lezione.
Il mio punto è che avere un repo anarchico la cui unica regola per contribuire è "fate quello che vi pare" o "implementa la funzionalità come vuoi", è destinato a vita breve. Non sono umanamente mantenibili.

giunti alla conclusione che neppure gli spacciatori di acronimi riescono a far comprendere come funziona un progetto complesso
(...)
Se fossero così magici, perchè 1000?

Perché magici non sono. Se ci fosse un algoritmo sicuro per scrivere programmi perfetti, questa professione non esisterebbe. Esisterebbe un unico programmatore, il cui nome sarebbe "programmatore.exe". Visto che così non è, e Skynet ancora non ha preso il controllo, dovresti prendere tutti questi concetti esattamente come te li hanno proposti: delle linee guida da seguire o meno. Un motivo per doverli seguirli? Perché, come dicevo prima, un sw scadente che (benché funzioni e faccia esattamente quello che ti serve) nel caso di piccole modifiche che richiedano la riscrittura di codice in 12 pagine e 400 linee di codice ti costa tempo e denaro, oltre che a una crisi di nervi.