여러분, 저는 핀테크 분야에서 소프트웨어 개발자로 경력을 시작하면서 여기서 코딩이 제 대학/해커톤 프로젝트와 어떻게 다른지에 대해 몇 가지 깨닫게 되었습니다.

일반적으로 개인 프로젝트를 작업할 때 그것들은 우리 생각의 작은 원형입니다. 그러나 비즈니스 로직 작성/데이터 구조 알고리즘 구현과는 별도로 대규모 프로젝트에서 작업할 때 코드가 막히는 다른 영역이 있으며 이러한 문제를 해결하는 데 어려움을 겪을 수 있습니다.

코딩과 알고리즘에 능숙하더라도 시스템에 대한 전반적인 아이디어를 가지고 있으면 더 원활한 경험을 할 수 있습니다. 신입생으로서 브레인스토밍할 수 있는 몇 가지 관행은 다음과 같습니다.

테스트 주도 개발

이 접근 방식은 오늘날 업계에서 반드시 필요한 깨끗한 코드를 작성하는 데 도움이 될 수 있습니다. O(N) + 깨끗한 코드 v/s O(logN) 알고리즘 코드 사이에 트레이드 오프가 있는 시나리오에서 일반적으로 사람들은 더 깨끗하고 읽기 쉬운 코드를 받아들이는 경향이 있습니다.

• 신입생으로서 우리는 Leetcode/CodeChef/IB 또는 예를 들어 다른 코딩 플랫폼에서 실패한 테스트 사례를 본 후 코드를 리팩토링하는 경향이 있지만, QA 중에 버그가 발생하는 동안 코드를 변경하는 프로젝트에서 작업하는 동안 지저분하고 읽을 수 없는 코드로 이어질 수 있습니다. 기능에 대한 모든 에지/테스트 사례를 정의하고 작성하려는 기능의 다양한 입력/출력을 정의하기 전에 프로젝트 관리자와 엔드 투 엔드 토론을 하면 더 나은 이해와 팀 간 협업 기술을 구축하고 버그를 줄이는 데 도움이 될 수 있습니다. 배달 시간을 개선합니다.
• 물론 우리는 추가된 복잡성과 엄격한 기한 때문에 업계 어디에서나 UT를 작성하지는 않지만 코딩을 시작하기 전에 종이에 대략적인 청사진을 가지고 있어도 결국 버그가 거의 없는 더 깨끗한 코드로 이어집니다.
• 또한 UT를 작성하면 향후 개발로 인해 기능이 손상되지 않도록 보호할 수 있습니다.

새로운 회사에 합류할 때 우리는 영향을 미치기 위해 가능한 한 빨리 코딩과 프로젝트에 참여하고 회사에서 사용하고 있는 프레임워크에 대해 배우고 기본 사항을 닦는 데 시간을 보내는 것의 중요성을 무시합니다.

프레임워크 및 종속성 주입 방법/실무에 대한 엔드 투 엔드 지식을 만드는 데 하루나 이틀을 보냅니다. 우리는 일반적으로 모듈을 주입하는 동안 순서나 주입하는 모듈의 수를 보지 않고 작은 세부 사항을 놓치는 경향이 있으므로 순환 종속성 및 다이아몬드 문제와 같은 문제에 부딪힐 가능성이 높아집니다. 이러한 문제는 새 프레임워크로 작업하는 초기에 해결하기 어려울 수 있습니다.

예를 들어 Nest.js에서는 오류가 발생할 가능성이 높아지므로 서비스 대신 모듈을 가져오는 것이 좋습니다.

로그를 검토한 후 RootTestModule로 이동하여 모든 서비스를 제대로 가져왔으므로 혼란스러울 수 있습니다. 이 순환 종속성 문제는 forwardRef() 를 사용하여 쉽게 해결할 수 있지만 깨끗한 코드를 연습하려면 이러한 코딩 방법을 피하십시오.

추신 — AWS Lambda를 한 번 작성하는 동안 큰 시간을 망쳤습니다. 원치 않는 주입은 초기화 시간이 길어져 서버 비용과 크기를 증가시킬 수 있습니다. Amazon AWS for lambdas의 이 기사는 더 나은 성능 최적화로 이어지는 종속성 주입 사고를 피하는 방법을 알기에 매우 좋은 읽기 자료입니다. 람다에 특화되어 있지만 중요성을 이해하기 위해 큰 그림을 보기 위해 이것을 참조할 수 있습니다.

오류 처리

캐시되지 않은 오류는 QA 중에도 파악하기 어려운 큰 버그로 이어질 수 있습니다.

컨트롤러 계층에 사용자 지정 오류 래퍼를 구현하면 장기적으로 도움이 될 수 있습니다. 유효성 검사 오류, 서버 오류, HTTPError가 필요할 수 있는 네트워크 작업 오류, 데이터베이스 작업 DBErrors 등과 같은 다양한 유형의 오류에 대해 여러 가지 다른 래퍼를 사용할 수 있습니다.

JavaScript에는 내장 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. 항상 오류를 잡아라.
2. 요청이 완료된 후 비동기로 작동하는 코드 부분에서 오류가 발생하지 않도록 합니다.

현재 시스템을 확장하고 있기 때문에 시스템을 모니터링할 다양한 플랫폼/도구를 찾고 있으며 제가 확실히 말할 수 있는 한 가지는 이것이 탐색할 수 있는 완전히 다른 도메인이라는 것입니다. APM 또는 Infra 모니터링 대시보드 및 경고를 설정할 수 있는 기회를 얻은 덕분에 아키텍처를 더 잘 이해할 수 있었습니다.

P S —이 영역에서의 여정에 대한 몇 가지 흥미로운 기사가 ​​올라올 예정이므로 여기에 세부 정보를 제공하지 않습니다. 계속 지켜봐 주시기 바랍니다!!

데이터 베이스

DBMS( 관계형 및 비관계형 ) 에 대한 쿼리 작성 및 기본 지식 뿐만 아니라 모범 사례를 아는 것도 필수입니다. 코드를 작성하는 동안 주의해야 할 몇 가지 사항은 다음과 같습니다.

• 보안 관행 준수 — 주변에 응용 프로그램 계층 암호화가 있는 PII 데이터가 있는 경우 좋은 생각입니다. 그렇지 않은 경우 중요한 데이터가 개방형 엔드포인트에 노출되지 않도록 하십시오. 3계층 아키텍처를 따르고 항상 DAO/Database 계층 을 구현하면 여러 DB를 전환하거나 사용하려는 경우에 유연성을 제공합니다.
• 쿼리 성능 모니터링 — 성능 분석 및 모니터링과 관련하여 인덱싱되지 않은 필드에 쿼리를 작성하는 인덱싱된 쿼리를 항상 작성하는 것은 큰 NO입니다.
• 메모리 내 데이터베이스 와 같은 잠재적인 최상위 계층 요구 사항에 대한 기본 통찰력을 가집니다 . 즉- Redis.

선임 개발자에게 물어볼 몇 가지 질문 —

고객에게 서비스를 어떻게 호스팅하고 있습니까?

보유하고 있는 모든 코드 파이프라인은 무엇이며 어떤 배포 사례를 사용하고 있습니까?

왜 우리는 이것을 사용하고 있습니까?

사용 가능한 다른 대안은 무엇입니까?

일반 코드 작성

가능한 한 일반적으로 코드를 작성하십시오. 간단한 예로 두 문자열 사이의 해밍 거리를 찾는 코드를 작성하려고 합니다.

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

그러나 여기에도 비교 함수를 전달하여 더 일반적으로 작성하면 어떻게 될까요? 간단한 사용 사례는 누군가가 미래에 대소문자를 구분하지 않는 문자열로 해밍 거리를 찾고자 하는 경우가 될 수 있습니다.

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

이 기사가 더 나은 코딩, 기한 준수 및 작업 공간에서의 작업에 도움이 되기를 바랍니다.

알아야 할 것이 훨씬 더 많지만 이것이 제가 작년에 발견한 것입니다. 이러한 각 섹션을 조금씩 살펴보았기 때문에 우리가 사용하고 있는 각 심층 프레임워크/도구와 장단점에 대해 자세히 작성하려고 합니다. 그러니 계속 지켜봐주십시오.