Hej ludzie, ponieważ zaczynam swoją karierę jako programista w fintechu, mam kilka wniosków na temat tego, czym kodowanie tutaj różni się od moich projektów na studiach/hackathonie.

Zwykle, kiedy pracujemy nad osobistymi projektami, są to małe prototypy naszych myśli. Ale ponieważ pracujemy nad projektami na dużą skalę, oprócz pisania logiki biznesowej / implementacji algorytmów struktury danych, istnieją inne obszary, w których nasz kod zacina się i rozwiązywanie tych problemów może być frustrujące.

Nawet jeśli ktoś jest dobry w kodowaniu, a algorytmy mające ogólne pojęcie o systemie, zapewnia płynniejsze działanie. Niektóre praktyki, w których można przeprowadzić burzę mózgów jako osoby odświeżające, to:

Rozwój oparty na testach

Takie podejście może pomóc w pisaniu czystego kodu, który jest obecnie koniecznością w branży. W scenariuszach, w których istnieje kompromis między O(N) + czysty kod a kodem algorytmicznym O(logN), ludzie mają tendencję do akceptowania kodu, który jest bardziej przejrzysty i czytelny.

• Jako nowicjusze mamy tendencję do refaktoryzacji naszego kodu po tym, jak widzimy nieudane przypadki testowe na przykład na Leetcode/CodeChef/IB lub jakiejkolwiek innej platformie kodowania, ale podczas pracy nad projektem zmiana kodu podczas napotykania błędów podczas kontroli jakości może prowadzić do niechlujnego i nieczytelnego kodu. Uprzednie przeprowadzenie dyskusji z kierownikami projektów, zdefiniowanie wszystkich przypadków brzegowych/testowych dla funkcji oraz zdefiniowanie różnych danych wejściowych/wyjściowych funkcji, które zamierzasz napisać, może pomóc w budowaniu lepszego zrozumienia i umiejętności współpracy między zespołami, zmniejszaniu liczby błędów i poprawiając czas dostarczania.
• Oczywiście nie wszędzie w branży piszemy UT ze względu na ich dodatkową złożoność i ścisłe terminy, ale nawet posiadanie wstępnego planu na papierze przed rozpoczęciem kodowania ostatecznie prowadzi do czystszego kodu z kilkoma błędami.
• Ponadto pisanie UT ochroni twoją funkcję przed uszkodzeniem z powodu nadchodzących zmian.

Kiedy dołączamy do nowej firmy, chcemy jak najszybciej zająć się kodowaniem i projektami, aby wywrzeć wpływ, i ignorować znaczenie spędzenia czasu na poznaniu frameworku używanego przez firmę i odświeżenia podstaw.

Poświęcenie dnia lub dwóch na stworzenie kompleksowej wiedzy o frameworku i jego metodach/praktykach wstrzykiwania zależności. Zwykle nie widzimy kolejności podczas wstrzykiwania modułów ani liczby modułów, które wstrzykujemy, i pomijamy drobne szczegóły, dlatego bardziej prawdopodobne jest, że napotkamy problemy, takie jak zależności cykliczne i problemy z diamentami. Rozwiązywanie tych problemów może być frustrujące w pierwszych dniach pracy z nowym frameworkiem.

Na przykład w Nest.js dobrą praktyką jest importowanie modułów zamiast usług, ponieważ zwiększy to prawdopodobieństwo napotkania błędów

Po przejrzeniu dzienników można przejść do modułu RootTestModule, aby dowiedzieć się, że wszystkie usługi są tam importowane w porządku, a zatem można się pomylić. Ten problem cyklicznej zależności można łatwo naprawić za pomocą forwardRef() , ale jeśli chcesz ćwiczyć czysty kod, spróbuj unikać takich praktyk kodowania.

PS — Nawaliłem kiedyś, pisząc AWS Lambda. Niepożądane iniekcje mogą prowadzić do długich czasów inicjalizacji, a tym samym zwiększać koszty i rozmiar serwera. Ten artykuł autorstwa amazon AWS dla lambdas to bardzo dobra lektura, aby wiedzieć, jak uniknąć wpadek związanych z wstrzykiwaniem zależności, co prowadzi do lepszej optymalizacji wydajności. Mimo że jest to specyficzne dla Lambdas, możesz się do tego odnieść, aby mieć duży obraz, aby zrozumieć znaczenie.

Obsługa błędów

Błędy z pamięci podręcznej mogą prowadzić do dużych błędów, które mogą być trudne do wykrycia podczas kontroli jakości.

Implementacja niestandardowego opakowania błędów w warstwie kontrolera może okazać się korzystna w dłuższej perspektywie. Możesz mieć kilka różnych opakowań dla różnych typów błędów, takich jak błędy sprawdzania poprawności, błędy serwera i błędy w operacjach sieciowych, których możemy potrzebować HTTPError, dla operacji bazodanowych DBErrors i tak dalej.

W JavaScript mamy wbudowaną klasę Error

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. Zawsze łap swoje błędy.
2. Unikaj zgłaszania błędów z części kodu, która działa asynchronicznie po zakończeniu żądania.

Ponieważ obecnie skalujemy nasze systemy, szukamy różnych platform/narzędzi do monitorowania naszego systemu i pomagam w tym, że mogę powiedzieć na pewno, że jest to zupełnie inna domena, którą można eksplorować. Możliwość skonfigurowania pulpitów nawigacyjnych i alertów monitorowania APM lub Infra pomogła mi lepiej zrozumieć architekturę.

PS — Nie podaję tutaj szczegółów, ponieważ pojawi się kilka interesujących artykułów o mojej podróży w tej domenie, bądźcie czujni!!

Baza danych

Nie tylko pisanie zapytań i podstawowa wiedza na temat DBMS ( relacyjnych i nierelacyjnych ), ale znajomość najlepszych praktyk jest koniecznością. Kilka punktów, o które należy zadbać podczas pisania kodu, może być -

• Przestrzeganie zasad bezpieczeństwa — dobrym pomysłem jest posiadanie danych umożliwiających identyfikację osób, które są objęte szyfrowaniem warstwy aplikacji. Jeśli nie, spróbuj unikać udostępniania poufnych danych otwartym punktom końcowym. Podążanie za architekturą 3-warstwową i zawsze wdrażanie warstwy DAO/bazy danych pomaga w elastyczności w przypadkach, w których chcesz przełączać się lub używać wielu baz danych.
• Monitorowanie wydajności zapytań — zawsze pisz indeksowane zapytania, pisanie zapytań w nieindeksowanych polach jest dużym NIE, jeśli chodzi o analizę i monitorowanie wydajności.
• Posiadanie podstawowych informacji na temat potencjalnych wymagań najwyższej warstwy, takich jak baza danych w pamięci . czyli Redis.

Kilka pytań, które warto zadać starszym programistom —

Jak udostępniamy klientom nasze usługi?

Jakie masz wszystkie potoki kodu i jakie praktyki wdrażania stosujemy?

Dlaczego ich używamy?

Jakie są inne dostępne alternatywy?

Pisanie kodu ogólnego

Postaraj się napisać swój kod tak ogólnie, jak to tylko możliwe. Dla prostego przykładu chcesz napisać kod, aby znaleźć odległość Hamminga między dwiema strunami.

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)
    );
}

Ale co, jeśli napiszemy to bardziej ogólnie, przekazując tutaj również funkcję komparatora? Prostym przypadkiem użycia może być sytuacja, w której ktoś chce w przyszłości znaleźć odległość Hamminga za pomocą łańcucha bez rozróżniania wielkości liter?

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)
    );
}

Mam nadzieję, że ten artykuł pomoże ci lepiej kodować, dotrzymywać terminów i zabijać w miejscu pracy.

Jest o wiele więcej do poznania, ale to jest to, co odkryłem w zeszłym roku. Ponieważ trochę zbadałem każdą z tych sekcji, postaram się napisać więcej o każdym z tych dogłębnych frameworków/narzędzi, których używamy, oraz ich zaletach i wadach. Więc bądźcie czujni ludzie.