NOTE: Apart from
(and even then it's questionable, I'm Scottish). These are machine translated in languages I don't read. If they're terrible please contact me.
You can see how this translation was done in this article.
Wednesday, 06 November 2024
//Less than a minute
Come sviluppatore freelance uno dei set di abilità è necessario imparare rapidamente è come lavorare su basi di codice esistenti in modo efficace. Sono stato fortunato ad aver costruito un mucchio di sistemi --graffi; questo è un JOY come sviluppatore esperto tuttavia non è sempre il caso.
I sistemi di legacy hanno sfide significative; specialmente quando gli sviluppatori/architetti chiave (se siete abbastanza fortunati da averli) sono andati avanti.
Ciò è spesso trascurato soprattutto nelle piccole imprese. In generale, sono necessari 4 tipi chiave di documentazione:
La documentazione è una delle cose che noi sviluppatori spesso odiamo fare (non è codice) ma è cruciale. Come puoi vedere I LOVE Markdown, con quelli come Mermaid e PlantUML puoi creare alcuni diagrammi e diagrammi di flusso davvero belli che possono essere inclusi nella tua documentazione.
Deve essere ATTUALE; gli sviluppatori spesso parlano di bit-rot; dove le dipendenze di un progetto diventano obsoleti / rischi di sicurezza downright. Questo vale anche per la documentazione; se non è corrente non è utile.
Ci sono diversi livelli di documentazione ma in generale ogni volta che si cambia il codice a cui si fa riferimento in un documento si dovrebbe aggiornare tale documento.
Questo è spesso una sfida, soprattutto se il sistema è stato intorno per un po '. È necessario sapere quale versione di Node /.NET ecc, quale versione del database, quale versione del framework ecc. Questo è spesso trascurato, ma è CRECIAL per alzarsi e funzionare rapidamente.
Ho spesso visto gli sviluppatori dire che questo non è rilevante in questi giorni di sistemi cloud e grandi applicazioni distribuite, ma non sono d'accordo; è necessario essere in grado di eseguire il sistema localmente per debug problemi in modo rapido ed efficace.
Response.Write
in Classic ASP sono finiti. Per un'applicazione anche modestamente complessa (soprattutto quella che non hai scritto) è fondamentale passare attraverso il codice. Per seguire una richiesta dal suo inizio attraverso il servizio di identificare ciò che potrebbe accadere, quali eccezioni non possono essere catturati ecc.LogInformation
per ogni richiesta. Potresti voler usare un Processore di Telemetria personalizzato per filtrare le richieste che non vuoi registrare.In OGNI progetto lavoro sul primo passo è ottenere il sistema (o gran parte di esso) in esecuzione localmente. Vedendo il codice, eseguendo il codice, debug il codice si può ottenere una sensazione per come funziona il sistema.
In ogni sistema questo è il tuo fonte della verità, non importa quello che dicono i documenti, ciò che gli altri vi dicono su come dovrebbe funzionare è come funziona.
Questo spesso impegnativo, è come trovare la strada in una nuova città senza roadmap. Fortunatamente nelle applicazioni si dispone di un punto di ingresso (un caricamento pagina / una chiamata front end API ecc.) Scegli un punto e inizia da lì.
Utilizzare qualsiasi cosa è necessario per interagire con esso, che si tratti di PostMan, Rider HttpClient o anche una pagina web. Aggancia il tuo debugger, fai la chiamata e seguila. Sciacquare e ripetere per ogni parte del sistema.
Generalmente lascia questo finche' non capisci il sistema. E' SEMPRE tentare di 'gettarlo via e ricominciare' tuttavia resistere a questa tentazione. Specialmente per un sistema funzionante FUNZIONA ricostruire / anche refactoring un sistema è un rischio enorme. Sì, è divertente ma per ogni riga di codice si cambia si rischia di introdurre nuovi bug snd emozionanti.
Come tutto il resto (soprattutto quando si contrae) è necessario giustificare il lavoro che si esegue su un sistema. Questa giustificazione deve essere focalizzata su uno dei seguenti elementi:
Questo è spesso trascurato, soprattutto dagli sviluppatori. Devi essere in grado di giustificare il lavoro che stai facendo su un sistema. Ciò è particolarmente vero in un ambiente contrattuale in cui si è pagati per l'ora. Alla fine, non e' il tuo codice e non i tuoi soldi. Il motivo per cui stai facendo un cambiamento è spesso più importante del cambiamento stesso.
Ho lavorato come appaltatore per oltre un decennio, non è facile; come appaltatore ogni ora del vostro tempo è un 'costo' per il cliente. È necessario aggiungere valore di spostamento al sistema rispetto al costo. Se non lo siete allora sarete rapidamente alla ricerca di un nuovo contratto.
Come sviluppatori, tendiamo ad essere uomini d'affari schifosi siamo concentrati sulla 'perfezione' ad ogni turno. In realtà, non c'è bisogno di fare un sistema "perfetto" (direi che non c'è una cosa del genere); basta fornire valore al cliente.
Su un impegno a più lungo termine questo include garantire nuovo codice è manutenibile ed efficiente dal punto di vista dei costi da eseguire. Nei sistemi legacy questo è MOLTO più duro. Spesso si deve guadare attraverso una palude, essendo ansioso che come si impara il sistema non si può offrire molto valore. I'm not making any changes
Pensi che... I'm just learning the system
.
Questo è un errore; si sta imparando il sistema per renderlo migliore. Stai imparando il sistema per renderlo più efficiente. Stai imparando il sistema per renderlo piu' maneggevole. Se un cliente non può accettare questo passaggio, allora è necessario essere molto attenti a come si comunica questo (o cercare un nuovo contratto).
Ancora una volta spesso trascurato, un sacco di tempo sei portato in come un appaltatore perché qualche persona chiave ha lasciato (non essere coinvolto nella politica di questo; non è la vostra preoccupazione). È necessario essere in grado di lavorare con le persone che sono lì per raggiungere gli obiettivi del progetto. In un contratto avrai generalmente i termini del tuo fidanzamento specificato (nel mio contratto attuale si tratta di'migliorare l'affidabilità e ridurre i costi di gestione'); concentrati su questo. Se non sei sicuro di cosa significhi allora chiedi.
Tenete a mente chi è il vostro contatto diretto; soprattutto nei primi due mesi. Tienili informati (probabilmente non avrai nuove funzionalità per vantarti di come ottieni filato su come funziona il sistema). In genere invio una e-mail di sintesi ogni settimana / due settimane al mio contatto diretto; questo è un buon modo per tenerli informati di ciò che stai facendo e quello che stai trovando.
Ricorda, questa è la persona che approverà la tua fattura; non ci dovrebbero essere sorprese al momento della fattura. Una volta che si inizia a controllare il codice regolarmente questo è meno di un problema; si ha un record di esattamente quello che hai fatto e l'impatto che ha avuto. Fino ad allora, dovete tenerli informati. Devono sapere cosa hai fatto e perche' dovrebbero pagarti.
Ancora una volta, torna al codice legacy; se si fa una modifica in generale è necessario implementarlo.Anche il meglio di noi farà di tanto in tanto questo casino, soprattutto nei sistemi legacy codice ci sarà qualcosa Non potevi saperlo. quando vi schierate. Questo torna alla registrazione - se si dispone di un server di staging avere la registrazione un LOT (ma mantenuto per un breve periodo) poi quando si implementa in QUESTO è possibile raccogliere ulteriori informazioni su ciò che non è riuscito.
Non importa quanto tu sia bravo, quanti test hai fatto sul posto siamo tutti umani. Questa è una parte fondamentale della regola "non dispiegare in un venerdì"; aspettatevi che un dispiegamento causi un nuovo problema su un sistema. Preparati a lavorare finche' non sara' risolto. Se non sai perché ha fallito, aggiungi altri test per riprodurre il problema e più logging per assicurarti di catturare problemi simili in futuro.
Specialmente per i sistemi di produzione il vostro sistema di staging potrebbe non essere 1:1 (soprattutto per quanto riguarda il carico), utensile come k6 può aiutare a simulare il carico (anche meglio localmente dove si può fare la corretta profilazione come accennato in precedenza).
Ancora una volta spesso trascurato nel fervore per CI / CD è il motivo di questi. Semplice, farai un casino. Avere un modo molto veloce ed efficiente per distribuire un sistema significa che quando lo si rompe si può anche risolvere più rapidamente. Se il vostro sistema di revisione del codice CI significa che ci vogliono 2 giorni per ottenere un PR fuso allora che è il più veloce si può ragionevolmente fi un sistema. Se il vostro sistema CD significa che si prende giù il sistema in esecuzione; abituarsi a LONG notti.
Un meccanismo efficiente per fissare e distribuire il codice è essenziale per un efficiente gasdotto di sviluppo. Se ci vuole più tempo per distribuire una correzione di quanto ci sia voluto per trovare e implementare quella correzione in codice, allora sei meno propenso a risolvere le cose.
Ho messo questo in virgolette in quanto questo è un problema; per le applicazioni legacy (soprattutto quando la rielaborazione su larga scala è fuori dai limiti) ci sono due approcci principali.
Questo è il processo di semplice correzione del codice esistente; ancora una volta assicurarsi di testare accuratamente e avere i processi in atto per ripristinare / rapidamente reimpiegare eventuali correzioni. Non mentirò che questo tipo di sviluppo è raramente divertente in quanto si sono ancora probabilmente guadare attraverso la palude della base di codice esistente. Tuttavia, è un male necessario in molti casi.
Come al solito dovresti assicurarti di avere UNA FORMA DI PROVA per eseguire il codice corrente; idealmente dovrebbe anche testare per il fallimento per il problema che stai cercando di risolvere PRIMA di fare la correzione . Essi IDYLL per questo è quello di avere un test di unità che si rivolge da vicino l'area di codice che è necessario risolvere, ma questo è spesso al di fuori della portata del lavoro per grandi sistemi distribuiti.
In genere uso un sistema di test in quest'ordine di preferenza:
Per consentire di aggiornare PARTS di un sistema è possibile identificare componenti che possono essere separati da un monolito esistente in un microservizio (per un certo valore di'micro'). Questo può essere un ottimo modo per iniziare a modernizzare un sistema senza il rischio di una rielaborazione completa. Esempi comuni potrebbero essere la suddivisione degli endpoint delle API in nuovi progetti che utilizzano elementi più aggiornati. Il terrore di DRY può tuttavia entrare in gioco qui. Una soluzione mal strutturata ha spesso un sacco di componenti 'helper' o'service' che dovrebbero essere davvero in progetti diversi (o anche in pacchetti Nuget per un riutilizzo più globale).
Coprirò ulteriormente questo approccio in un futuro articolo in quanto è un elemento chiave di come lavoro sui sistemi legacy e non ovvio per molti sviluppatori.
Ora che abbiamo tutto questo fuori dalla strada arriva il spinoso problema dei pagamenti. Ho una regola generale:
Qualsiasi problema di pagamento sto cercando di andare avanti
Se sono in ritardo di pagamento; dipende dal vostro contratto, ma a SENZA entro 30 giorni, ma generalmente più vicino a 7; questo è un cattivo segno. Se ci sono cinguettii sopra la fattura (nickle-and-dimeing) pensare se la società è in grado di pagare per i vostri servizi su base continuativa.
Non scherzare con questo; se hai fatto il tuo lavoro è necessario essere pagati in modo tempestivo. Non importa quanto ti piace; se un cattivo cliente PUO' sfruttarti lo faranno. Non ne vale mai la pena.
Siate onesti; caricate solo per il tempo effettivamente lavorato; assicuratevi che sia chiaro quello che avete fatto e perché l'avete fatto.
Ho guidato team di sviluppatori e sono stato uno sviluppatore; sono stato un appaltatore e sono stato un cliente. Ho visto tutti i lati di tutto questo e posso dirtelo; se non vieni pagato in tempo allora devi andare avanti. Sul flip-side se si dispone di un appaltatore (o un ETP) che non sta consegnando, allora è necessario affrontare questo rapidamente. Ognuno ha lotte personali, ma soprattutto in un ambiente contrattuale è necessario fornire valore o non caricare per il tempo quando non lo siete.
Per quanto riguarda il tasso; troverete il vostro livello; personalmente faccio pagare di più per i progetti in cui ho più responsabilità (o che non sembrano divertenti). Faccio pagare meno per i progetti dove sto imparando una nuova tecnologia o per le startup. Ho anche lavorato meno giorni, ma ho mantenuto il mio tasso costante. Ma non accettare un basso tasso di palla; sei un professionista e si dovrebbe essere pagati come tale.
Beh, e' cosi'. Oggi sono fuori dal lavoro e domani per il funerale di mia nonna e francamente ho un po' di panico che ho un enorme sistema di legacy da imparare, quindi ho pensato di vomitare i miei pensieri su come lavorare su questi sistemi è come & le sfide.