Non riesco a programmare perché il codice che sto usando utilizza vecchi stili di codifica. È normale per i programmatori?

Ok, sarò sincero. È un brutto posto in cui lavorare ... Sono stato in queste situazioni e di solito finisce con l'essere inghiottito da questo codice. Dopo circa un anno ti ci abituerai e perderai la presa su come utilizzare le moderne alternative per ottenere lo stesso compito più facilmente, in modo più gestibile e anche più veloce in fase di esecuzione in la maggior parte dei casi.

Ho lasciato un posto di lavoro in quel modo, perché, dopo solo un mese, ho sentito di essere trascinato in un vecchio codice di scuola. Ho provato a provarlo, ma ho deciso di non farlo. Non potevo usare codice pulito e ho iniziato a perdere le abilità a causa della mancanza della pratica quotidiana. Qualsiasi approccio moderno doveva essere approvato da 3 livelli di sviluppatori, cosa che non accadde mai, perché l'idea era che le cose potessero rompersi quando si usano gli approcci moderni. E la natura fragile del codice che emerge quando non si usano approcci moderni è piuttosto spaventosa.

Non fraintendermi, ci sono casi in cui le persone sovrastimano le soluzioni e io sono tutto contrario. Ma essere trascinato nelle convenzioni e nello stile di codifica del '80 per un lungo periodo di tempo fermerà i tuoi progressi, e anche, penso, le opportunità di carriera.

Poi di nuovo, devi guadagnare denaro, quindi a volte devi fare ciò che non ti piace esattamente. Tieni d'occhio i sintomi di burnout e trasformando il codice in un compito banale in questi casi però.

Questo stile di codifica (se vuoi anche chiamarlo qualsiasi tipo di stile ) è cattivo stile di codifica.

Si possono scrivere brevi funzioni con nomi di variabili descrittive e controllo di flusso sensato nella maggior parte dei linguaggi moderni (Visual FoxPro è moderno, sì).

I problemi che stai avendo sono con una base di codice cattiva , niente di più, niente di meno.

Tali basi di codici esistono e sono molte - il fatto che tu abbia problemi con loro dimostra quanto possano essere cattivi (e che tu abbia un buon addestramento).

Quello che puoi provare e fare è migliorare le cose in cui puoi: rinominare le variabili, estrarre le caratteristiche comuni e dividere grandi funzioni in quelle più piccole, ecc ... Prendi una copia di Lavorare efficacemente con il codice legacy ...

Sono in un progetto C # con una struttura pessima, non lontano da ciò che descrivi. Combina solo 12 funzioni separate (ovvio copia-incolla) in una che prende un parametro singolo .

Questo non è davvero "vecchio stile", tranne che in quello (attuale) le buone pratiche di design non erano sempre così popolari. Questo è solo brutto codice. Il codice errato rallenta chiunque. Alla fine ci si abitua, ma è solo perché ci si abitua a particolari stranezze nel proprio sistema specifico. Dato un nuovo progetto, potresti trovare interi nuovi modi per scrivere codice errato. La cosa buona è che sai come identificare già questi odori di codice.

La cosa più importante che puoi fare è non propagare il problema . Non prendere queste cattive pratiche come una convention a meno che non sia la tua squadra. Mantieni pulito il nuovo codice in modo da non forzare un refactoring. Se è così male e hai tempo, considera un importante refactator ... ma in pratica raramente hai quel lusso.

Considera l'aggiunta di commenti mentre capisci le cose e cambia i piccoli pezzi e le parti come pratiche. A meno che tu non stia codificando da solo, devi risolvere questo problema con la tua squadra; se non ci sono convenzioni, dovresti prendere un po 'di tempo per inventarle, e magari impegnarti a migliorare lentamente la base di codice se la stai regolarmente mantenendo comunque.

Se trovi una funzione totalmente isolata con nomi di variabili cattive e la stai correggendo comunque, potresti anche rendere i nomi delle variabili qualcosa di utile, ridefinire i if. Non apportare modifiche alle funzionalità comuni a meno che non si proceda al refactoring di una grande porzione di esso.

• non hanno commenti - risolvilo man mano che lo impari
• non hanno funzioni (50, 100, 200, 300 o più righe eseguite in sequenza)

Questo probabilmente deriva da una precedente iterazione del codice. A questo punto, farei attenzione alle sottili differenze tra blocchi di codice apparentemente simili che sono diventati "caratteristiche". Ma a prescindere da quanto sia brutta un'idea di questo tipo di struttura, è piuttosto semplice da capire ... quindi non sono sicuro di dove avresti problemi.

• utilizza molte istruzioni if con molti percorsi - Non sono sicuro di cosa intendi qui
• ha variabili che non hanno senso (es .: cf_cfop, CF_Natop, lnom, r_procod) -

Vorrei sottolineare la cautela con il bit "variabili di ridenominazione". C'è una buona possibilità che tu non abbia ancora capito il gergo, e i nomi delle variabili avranno molto più senso dopo che sei stato lì per un po '. Per non dire che non ci possono essere nomi di variabili problematiche, ma i tuoi esempi sembrano avere una logica per loro, se tu sapessi quali sono gli acronimi comuni sul tuo sito. Questo ovviamente non è così importante se sei un team di 1.

• utilizza una lingua che non conosco (Visual FoxPro 8 del 2002) - Questo è il tuo problema, non il codice

Questo mi sembra un Opportunity .

È chiaro che puoi già vedere molti problemi nel modo in cui le cose sono fatte e gestite. Puoi lamentarti che è tutto spazzatura e che non puoi fare nulla, oppure puoi usare questa come un'opportunità d'oro per dimostrare davvero al tuo datore di lavoro il tuo valore.

Ora, non ti sarà d'aiuto se ti sposerai con il tuo datore di lavoro e gli dirai che tutto deve cambiare. Quindi il trucco è giocare un po ', chiedere un sacco di domande, e quando ti viene richiesto di scrivere il codice dovrai giocare secondo le loro regole con tutti i commenti, ecc., Poiché avrai bisogno di mantenere gli altri sviluppatori informati usando qualsiasi sistema che attualmente preferiscono, mentre allo stesso tempo puoi introdurre dei rifacimenti sensibili che non ti metteranno in pericolo. Puoi estrarre un paio di metodi e, se la tua lingua lo supporta, introdurre alcuni test unitari. Quando ti viene chiesto perché lo hai fatto in questo modo, o se ti viene detto che stai facendo qualcosa di "sbagliato", evita di diventare difensivo o polemico mentre fai una presentazione sonora della tua posizione per il tuo stile di codifica preferito. Ad esempio, puoi fare riferimento a libri come Codice pulito di Bob Martin o puoi fare riferimento ad altri libri, articoli o anche domande e risposte che hai trovato su Programmers.SE. Tutto ciò che puoi trovare utile per sostenere la tua posizione con fatti che potrebbero essere al di là della tua esperienza agli occhi delle persone con cui stai lavorando.

Riguardo ai commenti eccessivi, alcuni di questi possono essere chiariti se si aggiungessero alcuni nomi descrittivi per variabili e metodi, ma si potrebbe anche essere in grado di creare un caso per un buon sistema di controllo della versione, e usando ciò per mantenere la registrazione delle modifiche e delle date, ecc. e per l'uso di uno strumento per confrontare le diverse versioni dei file sorgente, se non si è già in possesso del VCS scelto.

Come ho detto, questa è un'opportunità per contribuire al miglioramento di un team di sviluppo che suona come se fosse perso per così dire. Hai l'opportunità di distinguerti come esperto e competente, e come qualcuno che può dare l'esempio. Queste sono tutte cose buone per aiutarti in seguito, mentre la tua carriera avanza.

Benvenuto nella giungla!

Sfortunatamente, spesso iniziare a lavorare in un'azienda significa iniziare ad affrontare questo tipo di situazioni, a meno che non lavori per un'azienda strutturata e ben organizzata, queste situazioni sono abbastanza comuni ...

Il mio consiglio è:

1. Iniziare l'apprendimento e acquisire familiarità con: linguaggio di programmazione utilizzato (Clipper / dBase) e ambiente (Visual FoxPro)

2. Leggi e analizza il codice base e inizia a commentarlo

3. organizzazione / refactoring del codice (affrontando il problema di troppe righe eseguite in sequenza)

Avere problemi con un codebase simile è normale, ma può diventare una grande sfida cercando di migliorare la qualità del codice e dare "il tuo tocco" al programma migliorando il codebase e magari rendendolo un programma migliore ...

Per rispondere alla tua domanda: Sì, le persone / aziende di tutto il mondo utilizzano un'infrastruttura che può essere costruita su un codice pessimo. Quando ci si integra in tali situazioni, può essere molto difficile da gestire.

La scorsa estate, ho lavorato come stagista sviluppando un'applicazione che verrà utilizzata dal team addetto al controllo qualità ad un reparto specifico. Il team addetto al controllo qualità utilizzava molti script standalone (VBScript, Perl, Bash) per eseguire test su database e simili, e volevano riunirli tutti in un'unica applicazione. Il problema con questo, tuttavia, è che questi script sono stati utilizzati in altre parti dell'azienda (quindi la funzionalità principale / i nomi delle variabili non potevano essere modificati) e il codice è stato "aggiunto a" per quasi 10 anni; un sacco di schifezze si erano accumulate.

Ecco cosa puoi fare al riguardo, però:

1. Chiedi aiuto: i tuoi colleghi colleghi che hanno dovuto esaminare questo codice hanno probabilmente familiarità con le sue idiosincrasie. Ciò che è ottuso e confuso per te va perfettamente bene per loro. Quindi chiedi aiuto!
2. Refactor quando possibile: se devi guardare / mantenere questo codice per un lungo periodo di tempo, rifattalo ogni volta che puoi. Anche se stai eseguendo una ricerca e sostituisci un nome di variabile, ogni piccolo aiuto è utile. Quella compagnia che ho internato per la scorsa estate ha avuto un problema simile nell'usare nomi di variabili scadenti. Ogni volta che potevo, eseguivo il loro codice attraverso un pettine a denti stretti, cambiando i nomi delle variabili, ottimizzando la logica (raggruppando varie funzioni in 1, ad esempio), ecc. Fai lo stesso ogni volta che ne hai l'opportunità!

Come ovunque, fintanto che le funzionalità esterne del codice funzionano correttamente, non importa come funzionino gli interni.

Ho intenzione di fare alcuni commenti che sono diversi da molti degli intervistati qui. Molti dei miei commenti potrebbero essere ovvi per te, ma devi comunque dirlo.

• Sii prudente nel cambiare codice che non capisci, finché non lo comprendi.
• Se lavori in un ambiente di squadra, con il codice su cui lavorano i tuoi compagni di squadra, discuti con loro delle modifiche prima di apportare le modifiche. A nessuno piace un "pistolero solitario" per entrare e cambiare il codice con cui tutti gli altri sono familiari. Questo non vuol dire che le tue modifiche non siano giustificate o la cosa "giusta" da fare.
• Ottieni adozione per le tue idee. Metti tutti d'accordo con le tue idee, quindi puoi utilizzare le competenze del tuo team per il refactoring, invece di caricarti di tutto il carico di lavoro.
• Acquisisci il buy-in di gestione. Potrebbero essere in grado di allocare fondi per te e riformulare il codice.
• Parla con il management in termini comprensivi dei vantaggi del ricalcolo del codice base. Un codice più gestibile significa meno tempo impiegato per risolvere bug, aggiungere funzionalità, ecc. Il che significa uno sviluppo economicamente vantaggioso. Tempo di restituzione più rapido ecc.

È facile aggiungere codice puro, suggerimenti per le migliori pratiche senza comprendere la politica del tuo ambiente. Le persone con cui lavori potrebbero non voler cambiare, o allocare il tempo per cambiare la tua base di codice, ma provare a vendere l'idea a tutti prima di saltare e cambiare tutto (che ha dei rischi intrinseci di per sé)

Spero che questo aiuti.

Una delle cose che sporge è il tuo commento modificato

Every change in old code must be keep commented in the code, plus meta information (date, programmer, task) related to that change (this became a mess, there are code with 3 used lines and 50 old lines commented). I'm thinking that is not only a code problem, but a management of software development problem.

Ho anche un progetto in cui ho ereditato una base di codice FoxPro precedente con molti dei problemi che descrivi. Una delle prime cose che ho presentato al progetto è stato un buon repository di codice sorgente. FoxPro può essere integrato con SourceSafe, ma quel prodotto è doloroso da usare.

Ho preso una copia dello href="http://paulmcnett.com/scX.php"> link strumento di Paul McNett e l'ho integrato nel mio ciclo di sviluppo. Fa un buon lavoro di estrazione del codice binario di FoxPro in un formato di testo che può quindi essere inserito in un repository sorgente, come Subversion, Mercurial o persino git. (Potresti trovare utile il progetto SubFox link .