Salut les gens, alors que je commence ma carrière en tant que développeur de logiciels dans la fintech, il y a quelques réalisations sur la façon dont le codage ici est différent de mes projets universitaires/hackathon.

Habituellement, lorsque nous travaillons sur des projets personnels, ce sont de petits prototypes de nos pensées. Mais comme nous travaillons sur des projets à grande échelle en dehors de l'écriture de la logique métier / de la mise en œuvre d'algorithmes de structure de données, il existe d'autres domaines où notre code reste bloqué et il peut être frustrant de résoudre ces problèmes.

Même si l'on est doué pour le codage et les algorithmes, avoir une idée globale du système conduit à une expérience plus fluide. Certaines pratiques où l'on peut faire un remue-méninges en tant que débutants sont-

Développement piloté par les tests

Cette approche peut vous aider à écrire du code propre, ce qui est aujourd'hui indispensable dans l'industrie. Dans les scénarios où il existe un compromis entre O(N) + code propre et code algorithmique O(logN), généralement, les gens ont tendance à accepter un code plus propre et lisible.

• En tant que débutants, nous avons tendance à refactoriser notre code après avoir vu des cas de test échoués sur Leetcode/CodeChef/IB ou toute autre plate-forme de codage par exemple, mais tout en travaillant sur un projet, changer de code tout en rencontrant des bogues pendant l'AQ peut conduire à un code désordonné et illisible. Avoir des discussions de bout en bout avec les chefs de projet au préalable pour définir tous les cas de test/de pointe pour la fonctionnalité et définir diverses entrées/sorties des fonctions que vous allez écrire peut aider à renforcer la compréhension et les compétences de collaboration entre les équipes, à réduire les bugs et améliorer votre délai de délivrabilité.
• Bien sûr, nous n'écrivons pas d'UT partout dans l'industrie en raison de leur complexité supplémentaire et de leurs délais stricts, mais même avoir un plan approximatif sur papier avant de commencer à coder conduit finalement à un code plus propre avec peu de bogues.
• De plus, écrire UT empêchera votre fonctionnalité de se casser en raison des développements à venir.

Lorsque nous rejoignons une nouvelle entreprise, nous voulons entrer dans le codage et les projets aussi rapidement que possible pour créer un impact et ignorer l'importance de passer du temps à apprendre le cadre que l'entreprise utilise et à approfondir les bases.

Passer un jour ou deux à créer une connaissance de bout en bout du framework et de ses méthodes/pratiques d'injection de dépendances. Nous n'avons généralement pas tendance à voir l'ordre lors de l'injection de modules ou le nombre de modules que nous injectons et manquons de petits détails, devenant ainsi plus susceptibles de rencontrer des problèmes tels que des dépendances circulaires et des problèmes de diamant. Ceux-ci peuvent être frustrants à résoudre dans les premiers jours de travail avec le nouveau framework.

Par exemple, dans Nest.js, il est recommandé d'importer des modules au lieu de services, car vous augmenterez vos chances de rencontrer des erreurs.

Après avoir parcouru les journaux, on peut aller au RootTestModule juste pour découvrir que tous les services y sont importés très bien et donc se confondre. Ce problème de dépendance circulaire peut facilement être résolu en utilisant forwardRef() , mais si vous voulez pratiquer un code propre, essayez d'éviter de telles pratiques de codage.

PS - J'ai beaucoup gâché en écrivant AWS Lambda une fois. Les injections indésirables peuvent entraîner des temps d'initialisation élevés et donc augmenter les coûts et la taille du serveur. Cet article d'Amazon AWS pour les lambdas est une très bonne lecture pour savoir comment éviter les accidents d'injection de dépendances qui conduisent à de meilleures optimisations de performances. Même si c'est particulier aux Lambdas, vous pouvez vous y référer pour avoir une vue d'ensemble et comprendre l'importance.

La gestion des erreurs

Les erreurs non mises en cache peuvent entraîner de gros bogues qui peuvent être difficiles à détecter lors de l'AQ également.

L'implémentation d'un wrapper d'erreurs personnalisé sur la couche contrôleur peut s'avérer bénéfique à long terme. Vous pouvez avoir plusieurs wrappers différents pour différents types d'erreurs telles que les erreurs de validation, les erreurs de serveur et les erreurs dans les opérations réseau, nous pouvons avoir besoin de HTTPError, pour les opérations de base de données DBErrors, etc.

En JavaScript, nous avons une classe Error intégrée

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. Attrapez toujours vos erreurs.
2. Évitez de générer des erreurs à partir de la partie de code qui fonctionne de manière asynchrone une fois la requête terminée.

Comme nous évoluons actuellement nos systèmes, nous recherchons différentes plates-formes/outils pour surveiller notre système et j'aide avec cette chose que je peux dire avec certitude, c'est qu'il s'agit d'un tout autre domaine que l'on peut explorer. L'opportunité de configurer des tableaux de bord et des alertes de surveillance APM ou Infra m'a aidé à mieux comprendre l'architecture.

P S — Ne pas fournir de détails ici car quelques articles intéressants sur mon parcours dans ce domaine sont à venir, restez à l'écoute !!

Base de données

Pas seulement écrire des requêtes et des connaissances de base sur le SGBD ( relationnel et non relationnel ), mais connaître les meilleures pratiques est indispensable. Quelques points à prendre en compte lors de l'écriture de code pourraient être -

• Suivre les pratiques de sécurité - Si vous avez des données PII ayant un cryptage de couche d'application autour d'elles, c'est une bonne idée. Sinon, essayez d'éviter d'exposer des données sensibles à des terminaux ouverts. Suivre l'architecture à 3 couches et toujours implémenter une couche DAO/base de données offre une flexibilité dans les cas où vous souhaitez basculer ou utiliser plusieurs bases de données.
• Surveillance des performances des requêtes - Toujours écrire des requêtes indexées écrire des requêtes sur des champs non indexés est un grand NON en matière d'analyse et de surveillance des performances.
• Avoir des informations de base sur les exigences potentielles de la couche supérieure, comme une base de données en mémoire . c'est-à-dire Redis.

Quelques questions à poser à vos développeurs seniors —

Comment hébergeons-nous nos services pour les clients ?

Quels sont tous les pipelines de code dont vous disposez et quelles pratiques de déploiement utilisons-nous ?

Pourquoi les utilisons-nous ?

Quelles sont les autres alternatives disponibles ?

Ecrire du code générique

Essayez d'écrire votre code aussi général que possible. Pour un exemple simple, vous voulez écrire du code pour trouver la distance de Hamming entre deux chaînes.

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

Mais que se passe-t-il si nous l'écrivons plus générique en passant une fonction de comparaison ici aussi ? Un cas d'utilisation simple peut être que se passe-t-il si quelqu'un veut trouver une distance de Hamming avec une chaîne insensible à la casse à l'avenir ?

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

J'espère que cet article vous aidera à mieux coder, à respecter vos délais et à tuer dans votre espace de travail.

Il y a beaucoup plus à savoir, mais c'est ce que j'ai découvert au cours de la dernière année. Comme j'ai exploré un peu chacune de ces sections, j'essaierai d'écrire plus sur chacun de ces cadres/outils approfondis que nous utilisons et leurs avantages et inconvénients. Alors restez à l'écoute les amis.