Ciao gente, mentre sto iniziando la mia carriera come sviluppatore di software in fintech, ci sono alcune realizzazioni su come la programmazione qui sia diversa dai miei progetti universitari / hackathon.

Di solito, quando lavoriamo su progetti personali, sono piccoli prototipi dei nostri pensieri. Ma mentre lavoriamo su progetti su larga scala oltre a scrivere logica aziendale / implementare algoritmi di struttura dati, ci sono altre aree in cui il nostro codice si blocca e può diventare frustrante risolvere questi problemi.

Anche se si è bravi a codificare e gli algoritmi, avere un'idea generale del sistema porta a un'esperienza più fluida. Alcune pratiche in cui si può fare brainstorming come matricole sono-

Sviluppo guidato dai test

Questo approccio può aiutarti a scrivere codice pulito che è un must del settore al giorno d'oggi. Negli scenari in cui esiste un compromesso tra O(N) + codice pulito v/s O(logN) codice algoritmico, generalmente, le persone tendono ad accettare codice più pulito e leggibile.

• Come matricole, tendiamo a rifattorizzare il nostro codice dopo aver visto casi di test falliti su Leetcode/CodeChef/IB o qualsiasi altra piattaforma di codifica, ad esempio, ma mentre lavoriamo su un progetto la modifica del codice mentre riscontriamo bug durante il QA può portare a codice disordinato e illeggibile. Avere discussioni end-to-end con i project manager in anticipo, definendo tutti i casi limite/test per la funzionalità e definendo vari input/output delle funzioni che stai per scrivere può aiutare a costruire una migliore comprensione e capacità di collaborazione tra team, riducendo bug e migliorare i tempi di consegna.
• Naturalmente, non scriviamo UT ovunque nel settore a causa della loro maggiore complessità e delle scadenze rigorose, ma anche avere un progetto approssimativo su carta prima di iniziare la codifica alla fine porta a un codice più pulito con pochi bug.
• Inoltre, scrivere UT salverà la tua funzionalità da guasti a causa di imminenti sviluppi.

Quando entriamo a far parte di una nuova azienda, vogliamo entrare nella codifica e nei progetti il ​​più rapidamente possibile per creare un impatto e ignorare l'importanza di dedicare un po 'di tempo a conoscere il framework che l'azienda sta utilizzando e rispolverare le basi.

Trascorrere un giorno o due alla creazione di una conoscenza end-to-end sul framework e sui metodi / pratiche di iniezione delle sue dipendenze. Generalmente non tendiamo a vedere l'ordine durante l'iniezione dei moduli o il numero di moduli che stiamo iniettando e perdiamo piccoli dettagli, diventando quindi più propensi a incorrere in problemi come dipendenze circolari e problemi con i diamanti. Questi possono essere frustranti da risolvere nei primi giorni di lavoro con il nuovo framework.

Ad esempio, in Nest.js è buona norma importare moduli invece di servizi poiché aumenterai le possibilità di incorrere in errori

Dopo aver esaminato i registri, si potrebbe andare al RootTestModule solo per scoprire che tutti i servizi vengono importati lì correttamente e quindi confondersi. Questo problema di dipendenza circolare può essere facilmente risolto utilizzando forwardRef() , ma se vuoi esercitarti con un codice pulito prova a evitare tali pratiche di codifica.

PS: ho fatto un gran casino mentre scrivevo AWS Lambda una volta. Le iniezioni indesiderate possono portare a tempi di inizializzazione elevati e quindi aumentare i costi e le dimensioni del server. Questo articolo di amazon AWS per lambda è un'ottima lettura per sapere come evitare incidenti di dependency injection che portano a migliori ottimizzazioni delle prestazioni. Anche se è particolare per Lambda, puoi fare riferimento a questo per avere un quadro generale per capirne l'importanza.

Gestione degli errori

Gli errori non memorizzati nella cache possono portare a grossi bug che possono essere difficili da rilevare anche durante il QA.

L'implementazione di un wrapper di errore personalizzato sul livello del controller può rivelarsi vantaggioso a lungo termine. Puoi avere diversi wrapper per diversi tipi di errori come errori di convalida, errori del server ed errori nelle operazioni di rete potremmo aver bisogno di HTTPError, per le operazioni di database DBErrors e così via.

In JavaScript, abbiamo una classe Error incorporata

Error {
  constructor(message) {
    this.message = message;
    this.name = "Error"; // (different names for different built-in error classes)
    this.stack = <call stack>; // non-standard, but most environments support it
  }
}

export class ServerError extends Error {
    serverMessage: ServerMessages;
    statusCode: number;
    context: Record<string, string>;

    constructor(
        errorCode: ServerMessages,
        message: string,
        statusCode = 500,
        context: Record<string, string> = {},
    ) {
        super(message);
        this.name = ServerError.name;
        this.serverMessage = errorCode;
        this.statusCode = statusCode;
        this.context = context;
    }
}

1. Cattura sempre i tuoi errori.
2. Evita di generare errori dalla parte di codice che funziona in modo asincrono dopo che la richiesta è stata completata.

Poiché attualmente stiamo ridimensionando i nostri sistemi, stiamo cercando diverse piattaforme/strumenti per monitorare il nostro sistema e sto aiutando con quell'unica cosa che posso dire con certezza è che questo è un intero altro dominio che si può esplorare. Avere l'opportunità di impostare dashboard e avvisi di monitoraggio APM o Infra mi ha aiutato a comprendere meglio l'architettura.

P S — Non fornisco dettagli qui poiché stanno arrivando alcuni articoli interessanti sul mio viaggio in questo dominio, rimanete sintonizzati!!

Banca dati

Non solo scrivere domande e conoscenze di base su DBMS ( relazionali e non relazionali ), ma conoscere le migliori pratiche è un must. Alcuni punti di cui occuparsi durante la scrittura del codice potrebbero essere:

• Seguire le pratiche di sicurezza: se disponi di dati PII con una crittografia a livello di applicazione attorno, è una buona idea. In caso contrario, prova a evitare di esporre dati sensibili agli endpoint aperti. Seguire l'architettura a 3 livelli e implementare sempre un livello DAO/Database aiuta la flessibilità nei casi in cui si desidera cambiare o utilizzare più DB.
• Monitoraggio delle prestazioni delle query: scrivere sempre query indicizzate scrivere query su campi non indicizzati è un grande NO quando si tratta di analisi e monitoraggio delle prestazioni.
• Avere informazioni di base sui potenziali requisiti di livello superiore come un database in memoria . cioè- Redis.

Alcune domande da porre ai tuoi sviluppatori senior:

Come offriamo i nostri servizi ai clienti?

Quali sono tutte le pipeline di codice che hai e quali pratiche di distribuzione utilizziamo?

Perché li stiamo usando?

Quali sono le altre alternative disponibili?

Scrivere codice generico

Prova a scrivere il tuo codice nel modo più generale possibile. Per un semplice esempio, vuoi scrivere codice per trovare la distanza di hamming tra due stringhe.

export function hammingDistanceBetweenTwoStrings(
    str1: string,
    str2: string,
    comparator: (arg0: string, arg1: string) => boolean,
): number {
    const minLengthAmongTwo =
        str1.length < str2.length ? str1.length : str2.length;

    let diffCharacters = 0;
    for (let i = 0; i < minLengthAmongTwo; i++) {
        const isDifferent = str1.charAt(i).localeCompare(str2.charAt(i)) !== 0;
        if (isDifferent) diffCharacters++;
    }

    return (
        diffCharacters +
        (str1.length - minLengthAmongTwo) +
        (str2.length - minLengthAmongTwo)
    );
}

Ma cosa succede se lo scriviamo in modo più generico passando anche qui una funzione di confronto? Un semplice caso d'uso può essere cosa succede se qualcuno vuole trovare la distanza di hamming con una stringa senza distinzione tra maiuscole e minuscole in futuro?

export function hammingDistanceBetweenTwoStrings(
    str1: string,
    str2: string,
    comparator: (arg0: string, arg1: string) => boolean,
): number {
    const minLengthAmongTwo =
        str1.length < str2.length ? str1.length: str2.length;

    let diffCharacters = 0;
    for (let i = 0; i < minLengthAmongTwo; i++) {
        const isDifferent = comparator(str1.charAt(i), str2.charAt(i));
        if (isDifferent) diffCharacters++;
    }

    return (
        diffCharacters +
        (str1.length - minLengthAmongTwo) +
        (str2.length - minLengthAmongTwo)
    );
}

Spero che questo articolo ti aiuti a programmare meglio, rispettare le scadenze e uccidere nel tuo spazio di lavoro.

C'è molto altro da sapere, ma questo è quello che ho scoperto nell'ultimo anno. Dopo aver esplorato un po' ciascuna di queste sezioni, cercherò di scrivere di più su ciascuno di questi framework/strumenti approfonditi che stiamo utilizzando e sui loro pro e contro. Quindi rimanete sintonizzati gente.