개발 고민 성찰 깨달음 일지들 TIL (매주 임의의 개발 주제)

[방법] 백엔드는 코어부터 개발하자(기초) - 240616#1

Basic Coding

백엔드 코어부터 개발하자


어떻게 하면 백엔드의 개발 생산성은 늘리면서

코드의 의존성은 크게 낮춘 코드를 짤 수 있을까?

#개발 #방법론 #백엔드




문제점 : 기존의 나의 코딩 방식

기존의 나의 코딩 방식은

기능1 을 하나 만들고 넘어가고

기능2 를 만들고 넘어가고

기능3을 만들고 넘어가고

.

.

.

언젠가는 완성!



대충 이런식으로 각각 하나의 기능/모듈을 완벽하게 만드는 것에 집중해 왔던 것이다.

웹 개발로 치면 버튼의 디자인부터 기능까지 한 번에 한 기능만 완벽하게 구현된 형태였다.

기능 하나에 모드 물리어 있다는 단점이 있었다.

이러다보니 개발 완성에 걸리는 시간이 상당히 늘어났고

기존에 짯던 코드를 잘 활용하지 못하는 문제점이 있었다.

image

나의 평가로 이는 마치 자동차를 만들어 오라고 하니까 자동차 외관부터 만드는 느낌? 이였다.

이렇게 되면 당연하게도 협업을 하는데 피드백을 받기까지 걸리는 시간이 길어지고 고객과의 소통까지 걸리는 시간이 지연되게 된다.




코어부터 개발하자

그러다 이희창님이 DDD 방법론을 보고 새로운 방법론을 고안하게 되었다.

코어부터 개발하자.

도메인 주도 설계(Domain-Driven Design, DDD)는 소프트웨어 개발 방법론 중 하나로, 복잡한 소프트웨어 시스템을 설계하고 개발할 때 도메인 지식을 기반으로 하는 접근 방식을 강조합니다. DDD는 도메인 전문가와 개발자가 협력하여 도메인 모델을 정교하게 설계하고, 이를 통해 소프트웨어를 구축하는 것을 목표로 합니다.
| from chat GPT



말이 어렵지만 현장의 개념을 Domain이라고 하고 그 기반으로 조금씩 개발해 나가는 방법론이다.

이 도메인이라는 부분은 곧 자동차의 엔진과 같은 부분이다. 사실상 고객이 원하는 일을 처리하는 하나의 함수이다.

이 부분을 매우 좋게 만드는 것 부터 시작하자는 것이다.



매우 좋다는 것은 다양한 입력을 받을 수 있고 반복해서 수정이 크게 필요하지 않으며 반복해서 사용할 코드 엔진을 처음에 잘 만들어 놓자는 것이다.

기존의 방식은 하나의 기능에만 너무 집중한 나머지 많은 문제점을 갖고 있었다고 확신한다.

내가 기존에 개발하던 방식은 결과가 정말 느리게 나왔고 최종 결과물도 사용자가 원했던 것과 다를 가능성이 매우 높았다.

하지만 오른쪽과 같이 일단 돌아가도록하는 핵심 엔진을 만들고 돌아만 가게 해서 출력물이 이쁘지 않더라도 일단 된다면 끝인 모델이다.

향후의 개발 과제들을 이런식으로 진행해보자

6개의 좋아요

DDD에 관심이 있으시다면 Clean-Arhitecture 를 찾아보시는건 어떨까요!!

2개의 좋아요

CleanCode

책 : Clean Code, 읽기 좋은 코드가 좋은 코드다 / 강의 : 클린코드 - 박재호

깨끗한 코드

  • 소프트웨어 반감기 : 소프트웨어는 어쨋든 바뀌게 된다 → 이걸 어떻게 내재화 하고 저항성을 올릴지가 관건이다

  • 한 번 나쁜 코드가 작성되면 막기가 힘들다

  • 코딩은 정원 가까기에 가깝다. 자주 바뀌고 문제가 생기면 이를 격리 후 조치해야 하기 때문이다

  • 리팩터링은 밖으로 들어나는 결과는 유지 한 채 내부 구조만 바꾸는 것이다(기능 추가가 아니다)

※ 가독성의 기본 정리 : 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화

항상 일관성 : 모든 변수, 함수, RestAPI까지 일관성을 유지해야 한다 → 다르다면 왜 다른 지를 고민하게 된다.

특정 목적을 달성하는 방법은 하나만 제공


[ 깃 커밋 ]

Write a caption

깃 커밋을 하는 과정에서 위와같이 앞에 동사 원형을 붙인 상태로 시작해야 한다.

  1. 기능 하나에 하나의 커밋으로 하는게 가장 좋다.

|100%xauto

위의 이미지에는 기능 3가지를 묶어서 하나의 커밋으로 때린 것을 볼 수 있다. 이런식으로 작성하면 안된다.

|100%xauto

위의 이미지는 프론트엔드의 기능을 구현한 것으로 묶어 두었기 때문에 좋은 커밋이다.

  1. srp를 지키기위해 why를 적어라

[ 이름(변수, 함수) ]

변수 : 변수를 덜 사용하고 최대한 가볍게 만들어 가독성을 높인다

  • 보편적 단어
function getImages() {}

보다는

인터넷에서 가져오는 것이라면 fetchImages() 가 더 의미있는 이름

var tmp

var retval

도 동일하게 보편적이라서 사용을 지양한다

RestAPI 명명법

GET -> 보통 읽기

POST -> 보통 쓰기

PUT -> 보통 업데이트

DELETE -> 보통 삭제
  • 단위를 포함하는 값들
function timeout(delay) {} // X
function timeout(delaySecs) {} // O
function timeout(delayMs) {} // O

function fileSizeLimitCheck(size) // X
function fileSizeLimitCheck(sizeMb) // O
function fileSizeLimitCheck(sizeKb) // O
  • 다른 중요한 속성 포함하기

변수의 의미를 제대로 이해하는 것이 중요하다면 그 의미를 드러내는 정보를 변수의 이름에 포함시켜야 한다.

// 평문인 비밀번호
const password = .. // X
const plainTextPassword = .. // O

// url encode 된 data
const data = .. // X
const dataUrlEnc = .. // O
  • 추가 실천 방안
  1. 상한/하한 : min, max 접두

  2. 경계를 포함 : first, last 접두

  3. 경계의 시작만 포함하고 끝은 포함하지 않을 때 : begin, end

  4. 불리언의 경우 : is, has

  5. get으로 시작되는 메소드는 내부 멤버를 반환한다고 관행적으로 생각함


[ 미학 ]

눈을 편하게 해주는 규칙들 → 비슷하거나 비슷하게 묶거나

  • 레이아웃을 동일하게 맞추어라

  • 비슷한 코드는(ex. 호출 url 만 다른 데이터 호출) 서로 비슷해 보이게 만들기

  • 서로 연관된 코드는 하나의 블록으로 묶기

서로 연관된 코드를 블록으로 묶기

Class Sever {
  // 핸들러
  viewComment()
  createComment()
  updateComment()
  replyComment()

  // 질의 / 응답 유틸리티
  commentOK()
  commentNotFound()

  // 데이터베이스 헬퍼
  openDatabase()
  closeDatabase()
}

[ 주석 ]

주석 없이도 이해하도록 명명을 잘하는게 가장 좋지만 그게 아니라면 주석 달기

  • 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말라. → 읽기 쉬운 코드 만들기
  • 나쁜 이름에 주석을 달지 마라 - 대신 이름을 고쳐라
  • 주석으로 안 좋은 코드인 이유를 설명해라
    • (오히려 잘못된 코드일수록 주석을 달아야하는데 숨기고 싶은 마음에 주석을 작성 안하는 것은 오히려 더 안 좋은 코드로 만드는 것인 것 같다.)
  • 큰 덩어리에 요약 주석 을 달아라
    • 클래스와 주석 위에는 가급적 주석을 달아놓자
# 고객이 자신을 위해서 구입한 항목을 모두 찾는다.
for customer_id in all_customers:
  for sale in all_sales[customer_id].sales:
    if sale.recipient == customer_id:
    ...

def GenerateUserReport():
  # 이 사용자를 위한 lock을 얻는다
  ...
  # 데이터베이스에서 사용자의 정보를 읽는다
  ...
  # 정보를 파일에 작성한다
  ... 
  # 사용자를 위한 lock을 되돌려 넣는다.
  • 주석의 의미 부여하기 → 사실상 완벽한 코드가 아니면 달 일이 많다
TODO: 아직 하지 않은 일
FIXME: 오동작을 일으킨다고 알려진 코드
HACK: 아름답지 않은 해결책
XXX: 위험! 여기 큰 문제가 있다
TextMate ESC

|100%xauto

이와같이 주석을 달면 Visual Studio의 작업 목록에서 내용을 볼 수 있다.

  • 좀 더 명확한 표현 사용하기

|100%xauto

  • 코너케이스를 설명해주는 입/출력 예를 작성해 두어라
/*
ex 2022.08.20.
*/

export function momentL(value: string | Date) {
  return moment(value).locale('ko').format('L');
}

이렇게 해야 왜 format을 썼는지 알 수 있다.

5개의 좋아요

[독서] 도대체 어떻게 IT 지식을 학습하는 것일까? - 소프트 스킬

How to Learn

IT 기술은 어떻게 습득하는 것일까?


매번 궁금해 왔던 질문이다.

IT 기술이 그토록 많은데 나의 학습 스킬은 좋지 못해서 매번 학습에 오랜시간이 걸린다…

나만의 학습방법이 있으면 좋겠다

#개발자 #봉순이 #개발자봉순이 #주니어개발자 #주니어개발자봉순이 #소프트스킬 #IT #학습법

문제점 : IT로 놀줄 모른다

어느날 항상 다른 개발자 분들이 읽어보라고 하는 소프트 스킬을 처음 열어보았다.

나 역시도 반신반의하는 마음으로 읽어본 책에는 정말 내가 지금까지 겪던 문제점이 그대로 적혀 있었다.

소프트 스킬 책에서 이야기 하는 IT 지식을 빨리 습득하는 방법 그것은

무언가를 배울 때는 직접 해보는게 가장 좋다. 빨리 행동에 옮길 수록 내 것이 된다.

다른 사람에게 알려줄 수 있는 수준이면 된다.

무언가를 배울 때 일단 해 보는 것이 매우 중요하다는 교훈을 건내준다.

10단계 학습법

이 책에서는 10단계에 거치어서 학습하기를 권한다.

1-6 단계는 학습을 위한 준비 단계

7-8 단계는 가지고 놀면서 학습하는 단계

9-10 단계는 고도화 하는 단계이다.

1-6단계 : 무엇을 어떻게 얻을 것인가

  • 1단계 : 블로그, gpt, 기사 등을 이용해서 시야를 넓혀 전체적인 주제를 바라보기. 범위가 어느 정도 되는지 큰 그림을 보는 일에 주력하자

  • 2단계 : 어떤 영역에 집중해서 어느 정도 범위까지 배울지 미리 정하기.

⇒ 쉽게 쉽게 내가 할 수 있는 범위를 정하는 작업. 어렵거나 버겁다고 느끼면 굳이 안 해도 된다. 즐거운 부분만 찾아 읽는 책과 비슷하다.

  • 3단계 : 성취하려는 가장 간단한 목표 정하기

⇒ 개발자니까 최소한 무엇을 만들어 내겠다 정도로 충분하다

  • 4단계 : 선택한 주제에 대해 최대한 다양한 자료를 찾아보아라. 최대한 많이 모아와라. 다양한 자료를 모으는 데 집중하라. (책, 블로그, 동영상, 전문가, 팟캐스트, 소스 코드, 프로젝트, 온라인 콘텐츠)

⇒ 나라면 메인을 책 하나 두고 나머지를 서브로 붙이는 형태로 필요한 부분을 빠르게 학습할 것이다.

  • 5단계 : 자신만의 학습 순서를 찾아라.

⇒ 책을 기반으로 어떻게 학습할지 계획해라

  • 6단계 : 자료를 선별하라. 감당할 만한 수준까지 자료의 양을 줄여라

⇒ 책의 내용에서 특정 부분에 대해 추가적으로 이해를 도울 수 있는 자료를 그때 그때 꺼내서 쓰면 된다

7-10단계 : 반복해서 실행하라

  • 7단계 : 아주 간단하게 결과를 빠르게 낼 수 있도록 해라.
    • => 어짜피 또 반복해서 코드를 봐야하기 때문에 굳이 어렵게 하지 말고 목표를 달성할 수준으로 처리하자

  • 8단계 : 7단계에서 만든 것을 리팩토링하며 계속해서 새로운 것을 만들어라

  • 9단계 : 기능을 계속 추가하며 고도화해라

  • 10단계 : 자신이 배운 것을 가르쳐라. 블로그나 발표 유튜브 등으로 내용을 전달해라.

Last : 지식의 빈틈 찾기

10단계까지 마치더라도 우리의 지식에는 구멍이 많이 뚫려 있다. 이런 구멍을 채울 수 있어야 한다.

주로 평소 유난히 시간이 오래 걸리는 부분이나 반복적으로 자주 하는 작업

또는 반복 작업 에 빈틈이 있다.

무시할 수도 있지만 일단 채우고 가는게 다 빠르게 목표에 달성하는 방법이다.

5개의 좋아요