A tutti i programmatori che...

Perdonami ma no, col cavolo. L'avere termini stretti non è una scusa per fare quel che ho riportato sopra, cioè ignorare quasi sistematicamente la gestione degli errori, specialmente in procedure critiche come per esempio quelle che leggono/scrivono sul database (cosa che accade nei nostri applicativi, no non fare commenti ti prego, bastano già le mie bestemmie...), o per chiamare le variabili in quel modo e scrivere il codice di m***a, buttandolo la come viene e chi s'è visto s'è visto. Perché non è che si perde tempo a chiamare una variabile strNomeCliente invece di s1.

Soprattutto non va fatto se stai lavorando con altre persone e sai che al tuo programma ci dovranno metter mano anche i tuoi colleghi.

Anche perché questo modo di lavorare si traduce in casini una volta che il programma è in produzione o dai clienti. Ed il tempo che hai risparmiato prima per stare nei termini lo perdi dopo a fare debug per cercare degli errori che ormai sono annidati in vagonate di codice scritto a muzzo. E più il codice è scritto male, più tempo si perde a correggerlo, tempo in cui magari il cliente non può lavorare perché quel bug che stai cercando è talmente grave da impedire l'uso corretto della tua applicazione (già successo, più di una volta). E magari il tuo programma è quello su cui il tuo cliente basa tutto il suo lavoro, ed è il nostro caso.

Inoltre le buone pratiche dello sviluppo del software contemplerebbero una cosina chiamata "analisi", da farsi prima di mettersi giù a scrivere il codice. E se l'analisi è fatta bene, si riesce a stimare una quantità di tempo sufficiente a scrivere il programma come le buone regole della programmazione suggeriscono.



Proprio perché non banale, chi scrive quel codice dovrebbe documentarlo. Almeno almeno commentarlo, per spiegare al povero tapino che dovrà fargli la manutenzione con che logica è stato scritto e di cosa eventualmente tener conto quando si fanno delle modifiche.

Si dice che a risparmiare il centesimo prima si rischia di perdere i milioni dopo. Questo vale anche - e soprattutto - nello sviluppo del software.

da quel poco che ho capito, magari sbaglio, fai il lavoro di un mio collega che scrive procedure su un database. Anche lui commenta poco solo per il fatto che poi le mani sui sorgenti le mette solo lui.
In un software house ciò non sarebbe consentito in quanto lavori in team e li c'è qualcuno che fornisce le direttive.
A me ad esempio capita sovente di usare generatori di parser ed è ovvio che non ti spiego il codice prodotto in automatico dal generator per il semplice fatto che impiegherei una miriade di tempo e non avrebbe alcun senso. Sarebbe come commentare le pagine generate dinamicamente dal PHP per un server web. So che non intendevi questo. Io ad esempio mi occupo principalmente di programmazione multi-thread realtime, ed al massimo scrivo a grandi linee cosa fa il codice da me prodotto ma se poi uno non ha conoscenze di programmazione concorrente e relative problematiche puoi scrivere tutti i commenti che vuoi che non la capirà mai, ci sono "fatti" che sono difficilmente commentabili e richiedono la preparazione del programmatore.
Se sviluppi su TCP/IP anche qui esistono tutta una serie di problematiche che anche descrivendo il codice non emergono, devi averle studiate. Dico questo perchè a volte si vedono programmi complessi dati in mano al primo che capita, non dico a te personalmente, sia chiaro, senza sapere che si devono avere le conoscenze prima di poter modificare e/o capire il codice.
Il mio intervento aveva questo significato: dipende dal tipo di software che sviluppi e se lavori in gruppo o meno.



p.s.
comunque certe implementazioni tipo gli alberi RB si studiano a scuola in quanto il codice è, per così dire, uno standard e non avrebbe senso commentarlo.

La ditta dove lavoro produce software gestionali. Il software è stato sviluppato a suo tempo in Visual Basic 6 (come avrai potuto capire dallo spezzone di codice che ho pubblicato), è tutt'oggi lo stesso che viene continuamente mantenuto ed aggiornato, e lavora su base dati MS Access (bleah...) o MySQL, a scelta.

Come vedi non è niente di trascendentale o per cui siano necessarie particolari competenze tecniche specifiche per lavorare nel codice, a parte quelle necessarie per fare il mestiere del programmatore, of course.

Quindi il comportamento del mio capo nello scrivere il codice (si, è lui che ha dato vita a quei mostri) è ancor meno giustificato. Aggiungici poi che lui segue la filosofia del "ma tanto cosa potrà mai andar male?" quando scrive il codice (da li le gestioni degli errori bellamente ignorate e tante altre "belle" cosette), ed infine attaccaci la ancora il fatto che anche per fare delle cose semplici fa dei panegirici di codice, che al confronto la burocrazia italiana in quanto a macchinosità e complessità è una favoletta per bambini. Questo perché non è in grado di pensare in modo ottimizzato al codice che deve scrivere. È un confusionario da far spavento.

Un esempio: uno dei report del programma ha bisogno di un valore in entrata per farsi una qualche masturbazione mentale, non ricordo di preciso cosa. Il valore è un banale intero a 16 bit. Ora, un programmatore coscienzioso, cosa farebbe? Per esempio, prenderebbe il report (che nel nostro caso altro non è che una classe di ActiveReport, che è il tool che utilizziamo per la reportistica) e ci aggiungerebbe una bella proprietà da settare con il valore quando istanzi l'oggetto del tuo report. Oppure se proprio vuoi farla sporca, dato che siamo in VB6 ed il che sostanzialmente significa anarchia totale permessa quando si scrive il codice, cacci il valore in una variabile globale e te lo leggi col tuo fottuto report quando questo viene inizializzato.

Il mio capo no. Lui il valore lo scrive nel registro di Windows prima di lanciare il report, e poi il report se lo va a leggere da li quando gli serve. Quando ho visto quella roba non ci volevo credere, al che gli ho chiesto il perché di cotale stronzata (non ho usato il termine "stronzata" ma ero molto tentato...). La sua risposta è stata: "eh così risparmio spazio in RAM".

Capito? Lui per risparmiare i 2 fottuti byte in memoria di un intero a 16 bit, va a masturbare il registro di Windows. E 'sta filosofia del cazzo l'ha usata anche in altri punti del programma. Ah, e tanto per capirci, il solo eseguibile del programma pesa la bellezza di 40 MB. Ha l'EXE che pesa 40 MB a furia di codice scritto male nonché copiaincollato dappertutto, e poi si preoccupa di risparmiare 2 byte in memoria. Credo di non dover aggiungere altro.

Altre cagate che ha fatto/fa le ho menzionate nei post precedenti di questo thread, e sono solo una parte.

Capisci ora perché ci sono giorni che vorrei arrivare in ufficio con una mazza chiodata e perché sto diventando così inflessibile nei confronti di chi non lavora come si deve?

posso capire che nel tuo caso è per una questione di chiarezza, passi. Io ad esempio critico il mio collega in quanto lavora su un database, db2 per l'esattezza, assolutamente (non normalizzato) nemmeno alla prima forma normale, e dove non si usano chiavi primarie, secondarie etc.. in quanto i programmatori originari hanno implementato tali controlli attraverso il codice.
Questi si che sono errori molto gravi in quanto vanno ad incidere direttamente sulle prestazioni del database in generale e tali problematiche sono ampiamente dimostrabili e documentate.
La bellezza del codice purtroppo è un male incurabile.

Perché il nostro è normalizzato... certo, vaaaaaaaaaaai tra

Tabelle che contengono i record di più di un tipo di entità, distinte da un campo che generalmente si chiama "TIPO", che se è 1 il record appartiene ad un'entità, se è 2 ad un'altra, se è 3 ad un'altra ancora, e via dicendo... col risultato che un campo che magari si chiama "NOME_CLIENTE" (sparo a caso) per i record del tipo 1 contiene il nome del cliente, per i record del tipo 2 il nome del di lui cane, per i record del tipo 3 la marca della sua macchina, eccetera.

Ho visto campi chiamati per esempio "TOTALE" contenere l'ID di un record correlato di un'altra tabella, col risultato che ogni volta che vai a lavorarci devi sempre ricordarti che quello non è veramente un totale ma l'ID di una relazione. Non parliamo poi dei campi dove vengono concatenati più dati (per esempio un campo INDIRIZZO unico dove si mette il nome del cliente, la sua via, il CAP, la città, lo stato, separati da un carattere separatore...), dati doppiati tra le tabelle a destra e a sinistra "perché così è più semplice leggerli da codice senza dover fare ogni volta le JOIN" (parole del mio capo), eccetera.

E di tutta questa confusione non esiste una documentazione che sia una. Mi è capitato diverse volte di chiedere al capo di darmi una mano per sveltire un po' la ricerca dei bug, perché lui è quello che ha scritto quella merda ed in teoria dovrebbe conoscerla molto meglio di me. La sua risposta: "Eh non mi ricordo, è una cosa di X anni fa, segui il codice...". E li cosa gli vorresti dire se non un "sei un coglione"?

Credimi, dove lavoro io dal punto di vista tecnico è un incubo. Io non sono una gran cima di programmatore eh, c'è gente molto più brava di me, lo ammetto. Ma perlomeno cerco di lavorare con un minimo di criterio e disciplina, evitando di fare certe puttanate. Ed ogni volta che devo mettere le mani a quel codice od a quel database mi saltano fuori i nervi dalla pelle.

Ti capisco...

Ogni programmatore a maggior ragione chi lavora in un team dovrebbe seguire SEMPRE le buone regole fondamentali che tu all'inizio ai menzionato, indipendentemente dal fatto che il software che si sta sviluppando sia semplice o complesso.

Da quello che ci racconti personalmente posso solo dedurre che il personaggio in questione (il tuo capo ) farebbe meglio a prendersi un gregge di pecore e fare il pastore.
Mi spiace che tu sia costretto a dover lavorare con un personaggio simile e per di più non poterlo prendere a calci in culo.
Troppo facile scrivere codice alla caxxo di cane e poi quando ci sono problemi mandare gli altri a sistemare i casini... che ci vada lui!

Toglimi una curiosità... come ha fatto sto tipo a diventare capo di una ditta che produce software

Beh in ditta ormai non lo si vede più, se non per qualche aperitivo. Per il resto è in giro principalmente a farsi i hazzi suoi o in vacanza. Di fatto ora come ora è come se facesse il pastore con un gregge di pecore, peccato che il software che la ditta vende l'ha fatto lui, quindi quello ci dobbiamo smazzare.



Ti dirò (forse l'ho anche già detto), come persona non è cattivo, anzi. È proprio dal punto di vista tecnico/lavorativo che non ci siamo. E del come concepisce l'informatica, con la sua filosofia del "tanto cosa vuoi che vada male?", peccato che nell'informatica di robe che possono andare male ce ne sono a milioni, e vanno gestite. E grazie a questa sua filosofia la ditta, per "merito" di una delle sue ultime pensate con cui si è alzato (storto direi) la mattina, ha rischiato di veder finita la sua colonna vertebrale (aka: l'infrastruttura che eroga il servizio ai clienti) completamente in mano al cloud di Google. Perché tanto "è Google, cosa vuoi che vada storto?". Per fortuna sono riuscito a smontare 'sta sua idea del cacchio. È una storia un po' lunga, ma se vuoi la racconto



E quel che vien da dire anche a me, d'altra parte lui mi può rispondere "guarda che io ti pago per fare la manutenzione ai programmi della ditta, ti ho assunto come programmatore proprio per questo". E non avrebbe nemmeno tutti i torti. Quindi, zitti, testa bassa, naso turato e debuggare/aggiornare/mantenere/smandruppare. E bestemmiare. Tanto, molto a lungo e molto forte.



Semplice, la ditta è sua. Siccome è più o meno capace di mettere insieme 4 costrutti in VB6 (ma mettere insieme 4 costrutti non significa "programmare") ha pensato bene una decina d'anni fa di metter su ditta insieme ad un altro socio, di arrabattare insieme il software (no, non posso chiamare quello che ha fatto "sviluppare") e di venderlo. And that's it.

Oggi c'è stato un nuovo primato nella ditta dove lavoro. Il programma non compila perché una routine è troppo grande. Ed in effetti la Bibbia potrebbe essere pure più corta di quel papiro

Programmazione strutturata, funzioni, metodi e classi, questi sconosciuti...

Resto basito, e capisco perché da ragazzo mi dissero che la laurea in filosofia avrebbe potuto darmi sbocchi lavorativi nel mondo della programmazione

Un filosofo sicuramente saprebbe scrivere il codice in modo molto più pulito, disciplinato ed ordinato di quanto abbia fatto il mio capo.

Ne ho visti di programmi scritti di merda, ma mai m'era capitato che il compiler di Visual Basic 6 si rifiutasse di generare l'eseguibile perché c'è una routine troppo lunga. Mai.

E se c'è una routine troppo lunga, significa che c'è qualcosa di seriamente sbagliato. E qui la cosa seriamente sbagliata è tutto quello schifo di applicativo, dal primo all'ultimo byte. Database e file di configurazione inclusi.

Mima, a questo punto te lo voglio dire: il tuo capo...




È QUIIII !!!!!!!!!!!!!!

Il mio capo non sa nemmeno dell'esistenza di questo forum. Lo so per certo.

Ritenta, sarai più fortunato

Quel ragazzo songhe io

Ciao Mima. Hai mai pensato a metterti in proprio scrivendo ex novo un programma simile a quello del tuo capo?

Dove vivo io il mercato dell'informatica è talmente saturo che chi esce dalla scuola la prima cosa che conosce è la disoccupazione. E non sono nella posizione di poter rischiare di perdere guadagno mettendomi in proprio. Già adesso il mio stipendio è al limite minimo della mia categoria, a 31 anni vivo ancora con i miei perché se no non riuscirei a mettere da parte nemmeno un centesimo per il mio futuro, col salario che ho se ne andrebbe tutto in affitto, tasse, assicurazioni e spese varie.



Lavoriamo in un ambito statale pieno di leggi, leggine, regole, regolette, casini e via dicendo, che definire "palloso" è un eufemismo. Mi viene l'orticaria solo a pensare di mettermi in proprio in quest'ambito, senza contare che ci vuole una montagna di autorizzazioni per operare nel settore in cui lavoriamo ed oltre a noi ci sono altre 2 o 3 grosse ditte che ci lavorano solo nella mia zona.

Preferisco guardarmi in giro, ed alla prima buona occasione di impiego levare le tende. Che è quel che sto facendo infatti. Pertanto il lavoro ce l'ho, quindi non ho questa grande urgenza e posso permettermi di scegliere un buon posto.

come non detto. Speravo che da voi la situazione fosse migliore che in italia, per l'attività imprenditoriale.

Di persè la situazione impreditoriale è migliore, è proprio l'ambito (statale) in cui lavora il software che sviluppiamo ad essere di una pallosità mortale. Perlomeno per me. Quando me ne andrò da dove sono ora, spero di non averci mai più a che fare.

Poi il fatto che in genere la situazione imprenditoriale sia migliore (ma sta decadendo piuttosto rapidamente pure da noi) non toglie che in Ticino il settore informatico sia saturo da almeno 10 anni, mettersi in proprio oggi se non si hanno già delle basi solide (conoscenze, base di clientela, una buona riserva di denaro da investire, eccetera) è solo una perdita di soldi. Cosa che io non posso permettermi.

mah, ci vogliono idee nuove, il mercato è pieno di persone che fanno le stesse cose, che sfruttano cose inventate da altri e pochi sanno innovare, nessuno vuole perdere tempo nella ricerca.
E pensare che nel caso dell'informatica gli strumenti sono alla portata di tutti, un PC, un ambiente di sviluppo a piacere e ovviamente: studiare e studiare per inventare qualcosa di nuovo.

Mancano un sacco di cose nel mondo dell'informatica, avanti