e_rho.log

[TS] 0. 개요

Wed, 08 Jun 2022 07:56:30 GMT

이번 세번째 프로젝트에서 타입스크립트를 써보기로 했기에,, 공부를,, 해야한다..

JS vs TS

너무나도 역동적인 당신.. 자바스크립트.. 의 한계를 극복하고자 도입된 타입스크립트! 자바스크립트가 실행 단계에 가서야 확인할 수 있었던 타입에러를 코드단에서 확인하고 잡을 수 있다는 장점이 있다고 한다.

우리가 타입스크립트를 사용했다면, 자바스크립트로 변환하는 컴파일 과정이 필요하다.

JS 사용

(1)
let a;

a = 1000;
a = 'string';

(2)
const sum = (a, b) => {
    return a + b
}
sum(1, "5") // 12

TS 사용

(1)
let a : number;

a = 1000;
a = 'string';
// Type 'string' is not assignable to type 'number'.ts(2322)

(2) 
const sum = (a :number, b:number) => {
    return a + b
}
sum(1,5) // 6

TS의 Type

타입스크립트는 결국 변수에 "타입"을 정의하겠다는 것인데, 이는 타입표기(Type Annotation)을 사용해서 나타낼 수 있다.

기본 자료형

object와 reference 형태가 아닌 실제 값을 저장하는 자료형이다.

string, boolean, number, null, undefined, symbol

사용 방법

let 변수명 : type = value;

// null과 undefined는 type 과 value에 모두 null 또는 undefined를 작성
// null == undefined (true)
// null === undefined (false)

참조 자료형

객체, 배열, 함수 등과 같은 object 형식의 타입이다. 참조 즉 reference 방식을 사용한다는 것은 곳 메모리에 값을 저장하고, 메모리 주소를 참조하여 연산을 수행한다고 보면 된다.

object, array, function

let arr: number[] = [1, 2, 3]
let arr: Array = [1, 2, 3] // 제네릭을 사용한 표기법

추가 자료형

타입스크립트에서 추가로 제공하는 타입이 있다.

tuple, enum, any, void, never

튜플

길이와 각 요소의 타입이 정해진 배열을 저장하는 타입이다. tuple은 이전에 파이썬을 하면서 배운 적이 있는데, 중복이 안되고 [] 보다는 ()을 사용했던 그 개념과는 약간 다른 것 같다.

let arr: [string, number] = ["Hi", 6]

따라서 만약에 number인 요소에 .concat()을 시도하려고 했다거나, 정의되지 않은 인덱스 값을 호출하려고 하면 에러가 난다는 것이다.

enum

enum은 특정 값(상수)들의 집합을 저장하는 타입이다. 인덱싱이 가능하고, 인덱스를 변경하기까지 할 수 있다!

enum Hey {Hi=1, Hello=2, Cheers=3};

let greeting: Hey = Hey.Hi; 
let greeting: Hey = Hey[1];

흠 개인적으로 enum은 Class랑 비슷한 느낌이 들었다. enum을 사용하면 코드가 단순해지고, 인스턴스 생성과 상속을 방지한다고 되어있다. 이 친구에 대해 좀더 궁금해졌다.

any

any는 말 그대로 정말 그 어떤 타입이 와도 된다. 컴파일 중 타입 검사를 하지 않는다는 것을 의미한다.

void

텅 비었다는 void. 함수에서 반환 값이 없을 때 사용하며, any의 반대라고도 볼 수 있다. 변수의 undefined, null과 비슷하지만 void는 변수에 사용할 수 없다.

never

발생할 수 없는 타입으로, 항상 오류를 발생시키거나 절대 반환하지 않는 반환 타입이다. 함수에서 return이 곧 종료를 의미했던 것을 생각해본다면, 반환되지 않는다는건 함수가 종료되지 않음을 의미한다. 예시로 무한 루프를 도는 함수에 never type을 작성할 수 있다는 것이다.

오류에 당황하지 않기

Wed, 08 Jun 2022 07:15:57 GMT

prettier 는 저번 프로젝트때 써봤는데, eslint는 이번이 처음이었다. eslint는 오류가 있을 때 빨간 줄을 죽죽 그어주는, 마치 한글이나 워드의 맞춤법 오류기같은 존재로 대강 생각하고있었다.

그.런.데 서버 구축을 위해 필요한 npm 패키지들을 깔고 나니 갑자기 모든 파일의 모든 줄에서 빨간색 줄이 팍! 떠버렸다.

eslint랑 prettier가 서로 충돌이 난 것 같긴 했는데 애초에 설정 파일을 팀원한테서 받아온 것이다보니.. 나는 진정 아무것도 모르겠는 것..

구글링으로 다른 분의 velog를 읽어보니 eslint가 npm과 얽히면 뭔가 문제가 생기는 듯 했다.

아래 velog에서 제시해주신 방법대로 해보니 일단은 엄청난 빨간색 줄을 멈출 수 있었다.

멈춰!! ✋ 참고한 해결 방법!

그런데도 나의 오류창은 여기서 멈추지 않았다.

자세히 보니 string 을 감싸는 quote, 즉 따옴표에 뭔가 문제가 있었다. 아무래도 "" double과 '' single이 어디선가 충돌이 나는 것 같았다. 왜냐하면 더블도 싱글도 모두 에러가 났거덩 🤔

그래서 prettier 와 eslint 파일을 뜯어보기로 했다. 그랬더니 어머나 prettier 는 singlequote: true 로 되어있었고, eslint는 quote: ['warn', 'double'] 로 되어있는게 아닌가.

prettier는 single로 바꿔주는데, eslint는 double이 옳고 singel이 그른 것이라 하니 문제가 생긴 것이다.

우리 팀은 prettier를 전역으로 쓰고, eslint는 프론트팀과 백엔드팀이 각각 지정해서 쓰고 있기에 전역인 prettier에 따라,, eslint를 바꿔주었더니 완전 해결 완료다!!

[Node.js] 3. 서비스로 모듈 간 연결하기 (번역)

Tue, 07 Jun 2022 08:00:16 GMT

Structure & Coding Practices

🗨 Use services to communicate between modules

MVC 구조를 갖는 어플리케이션에서는 앱 내의 기술적인 역할들(ex. service, schema...)을 기준으로 경계가 나누어졌었다. 즉, 로직이 다른 것에 대해서는 딱히 구분선이 명확하지 않은 것이다. 이전에도 언급했다시피, 나는 각 모듈이 도메인의 한 부분을 담당하는 형태의 모듈화된 구조를 굉장히 선호한다.

예를들어, (유저,품목,주문으로 이루어진 예시 어플리케이션에서) 인증 라우터와 계정 라우터를 위한 핸들러를 가지고있는 유저 모듈을 생각해보자. 또, 주문과 관련된 모든 것을 처리하는 주문 모듈도 가지고 있을 것 같다. 그런데 유저가 주문을 하는 동안 주소를 업데이트하는 그런 경우도 생길 수 있지 않겠는가?

이 로직은 언급한 두 모듈이 사용되는데, 우리는 이걸 정확히 어디서 처리를 해야하는가에 대한 난제에 직면하게 된다. 우리는 배달 모듈에 사용자의 상세 정보를 업데이트하는 데이터베이스 쿼리를 짤 수 있겠지만 이는 곧 우리가 유저와 관련된 로직을 유저모듈 밖에 두게 된다는 것을 의미하고, 만들어둔 경계를 흐트러트리는 셈이다.

이 사태를 피하기 위해서 유저와 관련된 로직들을 유저 모듈의 서비스에서 실행하는 것이 가장 좋다. 그 다음 배달(딜리버리) 모듈에서 함수를 부르면 된다. 경계를 유지하고 필요한 곳에 로직을 위치시키는 방법을 쓰자는 것이다. 배달(딜리버리) 모듈은 유저 정보가 업데이트 되었는지는 모르고, 단지 추상화(abstraction)에 의존한다.

// 👎 Don't break the boundaries of the domain modules
const placeOrderHandler = (req, res) => {
  const { products, updateShippingAddress } = req.body

  if (updateShippingAddress) {
    // Update the user's default shipping address
    const { user } = res.locals.user
    const { shippingAddress } = req.body
    knex('users').where('id' '=', user.id).update({ shippingAddress })
  }
}

// 👍 Communicate using services
const placeOrderHandler = (req, res) => {
  const { products, updateShippingAddress } = req.body

  if (updateShippingAddress) {
    // Update the user's default shipping address
    const { user } = res.locals.user
    const { shippingAddress } = req.body
    userService.updateShippingAddress(user.id, shippingAddress)
  }
}

만약 메인 application 밖으로 서비스를 추출해야한다면, 배달(딜리버리) 모듈은 그 어떤 변화도 없이 같은 기능을 호출해올 수 있다. 같은 방식으로, 유저 서비스에도 배달 모듈에 변화를 주지 않고도 같은 일을 할 수 있다.

Monolith VS. Microservice Architecture

Tue, 07 Jun 2022 06:36:05 GMT

노드를 이용한 앱 구조에 대해 다룬 글을 읽었는데, 만들 application이 Monolitic한지, Microservice 기반인지를 생각하는 것이 중요하다는 글이 있었다.

그래서 두 architecture에 어떤 차이가 있는지 지금부터 살펴보도록 하겠다.

Monolith vs. Microservice

참고문헌 References

1. Microservices vs Monolithic Architecture (text) 2. MONOLITH VS MICROSERVICES ARCHITECTURE (youtube)

🗨 Monolith

monolith는 한글로 돌기둥이다.

즉, app이 하나의 단위(single unit)로 돌아가면 monolith이다.

대체로 database, client-side(HTML, JS 등 유저 인터페이스), server-side(HTTP 요청응답, 도메인별 로직, 등등)으로 구성되며 시스템을 변경하려면 개발자가 업데이트된 버전의 server-side app을 빌드하고 배포해야한다.

이런 시스템은 작은 팀에서 cost-effectively, 직관적으로 사용할 수 있다. 초기 단계에서 손쉽게 개발이 가능함을 의미하기도 한다.

그러나 단점도 존재한다! 모든 레이어가 너무 타이트하게(촘촘히) 연결되어있고, 재사용성이 낮다.

🗨 Microservice

독립적인 모듈 단위로 코드가 나눠져있다.

보통 IT 대기업들이 선호하고 지향하는 방향이라고 하니 보통 장점 위주로 나와있는 것 같다. monolith와 대비되는 특징들(어쩌면 장점)을 살펴보자.

이러한 아키텍쳐에서는 코드들이 독립적이기에 개발자들이 서로 다른 기술 스택을 사용해도 된다. 즉 전체 코드베이스를 이해하지 않아도 개발이 가능하다는 것이다! 하드웨어와 데이터베이스가 달라도 가능하다. AWS와 같은 클라우드 기술이 이러한 방식을 이끌어 나갈 것이라고 한다.

monolith보다는 큰 규모의 프로젝트에 유용하게 사용될 수 있다. 계속해서 프로젝트를 스케일업 해나갈 때, 클린 코드를 사용하고 싶을 때, 장기적인 수완을 생각했을 때 이러한 접근이 가능하다. 또, 외주(아웃소싱)를 맡기는 프로젝트에도 찰떡같이 쓰일 수 있다.

물론 microservice 아키텍쳐에도 단점은 있다. (그러니까 monolith를 쓰는데도 있겠지?) 기능이 모듈화 되어야한다. 또 서로 다른 기술 스택은 자동화에서 어려움을 겪을 수 있다. 데이터를 전송하는 과정에서 추가적인 computing power가 필요하다.

monolith에 비해 초기 단계가 쉬운 건 아니지만, 테스트와 코드 업데이트가 용이하다. 또, 기업(enterprise) 수준에서는 monolith보다 더 경제적인 솔루션이 될 수 있다.

[Node.js] 2. 핸들러, 서비스, 레포지토리 구조로 만들기 (번역)

Tue, 07 Jun 2022 01:06:58 GMT

이 블로그 글은 제시된 원문을 직접 번역한 것입니다. (오역이 있을 수 있으니 꼭 원문을 참고하시길 바라요!)

This article will give you a translated version of Original Article.

Structure & coding Practices

🗨 Start with a modular monolith
:: 모듈화된 monolith(architecture)로 시작하기

새로운 app을 만들기 전에 반드시 app이 monolith인지 microservice 기반인지를 생각해보는 것이 가장 중요할 것이다. (monolith architecture vs. microservice architecture 정리한 글 링크)

최근 대부분의 개발자와 아키텍터들은 microservice achitecture를 선택하고있다. 서비스를 확장하기에도 좋고, (코드) 독립성을 가질 수 있으며 큰 규모의 프로젝트를 진행시키면서 나오는 조직적인 어려움을 해결하기 때문이다.

Microservice는 하나의 어플리케이션을 작은 서비스들로 쪼개고 서로 다른 것끼리 communication하는 패턴으로, 널리 쓰이고 있다. 가장 간단한 예시는 사용자(user), 물품(product), 주문(order)에 대한 컴포넌트를 가지고 있는 시스템을 들 수 있다. 각각의 독립체(컴포넌트)사이의 경계가 잘 정의된 이커머스가 종종 언급되는 예시이다. (항상 그런 것은 아니다!)

개발하고 있는 도메인에 따라서 그 경계는 아주 모호할 수도 있다. 이런 모호함으로 어떤 서비스에서 어떤 운영 방식이 도입되어야하는지 구별하기 어려워진다. 서비스를 분리하는 것은 많은 이점을 제공하지만, 분배 시스템의 문제를 가져온다. 그래서 나(필자)는 항상 모듈로 된 monolith로 시작해서 어플리케이션의 진화를 가능케 하라고 조언하는 편이다.

나는 monolith 구조가 저평가되고 있다는 마이너한 의견을 지지한다(ㅋㅋ). monolith는 개발자로하여금 더 빨리 움직이게 하고, 특정한 모듈 하나에 초점을 맞추면서 반-독립(고립)된 상태에서 일할 수 있게 한다. 모든게 같은 레포지토리에 있기때문에 이리저리 옮겨다니기에도 편하고, 만약 모듈성(modularity)을 잘 유지한다면, monolith에서 서비스를 추출해내는건 그리 어렵지 않을 것이다.

각 모듈이 잠재적으로 분리된 서비스라고 생각하고, 그 모듈들 사이를 연결(communication)할 약속(contracts)에 의존해보라.

🗨 Split the implementation in layers
:: 층으로 나누기

대부분의 Node 서비스 디자인에서 가장 큰 결함은 핸들러 기능에서 너무 많은 것을 한다는 것이다. 이것은 MVC 구조를 사용하는 app에서 컨트롤러 클래스가 경험하는 문제이다. 전송(transport), 데이터 액세스, 및 비즈니스 로직을 단일 기능으로 처리함으로써 긴밀하게 결합된 기능들을 만들어낼 수 있다.

유효성 검사(validation), 비즈니스 로직, 요청 객체(request object)에서 값을 직접적으로 사용하는 데이터베이스 호출을 볼 일은 잘 없긴 하다. 아래 예시는 매우 간단한 예시다!

// 👎 Avoid creating handlers with too many responsibilities
// unless the scope of the application is small
const handler = async (req, res) => {
  const { name, email } = req.body

  if (!isValidName(name)) {
    return res.status(httpStatus.BAD_REQUEST).send()
  }

  if (!isValidEmail(email)) {
    return res.status(httpStatus.BAD_REQUEST).send()
  }

  await queryBuilder('user').insert({ name, email })]

  if (!isPromotionalPeriod()) {
    const promotionalCode = await queryBuilder
      .select('name', 'valid_until', 'percentage', 'target')
      .from('promotional_codes')
      .where({ target: 'new_joiners' })

    transport.sendMail({
      // ...
    })
  }

  return res.status(httpStatus.CREATED).send(user)
}

위의 예시는 많은 유지보수를 요구하지 않는 작은 app에서는 수용가능한 접근법이다. 그러나 이런 결정으로 인해 더 큰 규모의 확대가 어려워진다.

핸들러들은 더 길고, 읽기 어려워지고, 테스트하기 어려워진다. 기능이 한 가지에 집중해야하는 것은 아주 흔한 이해이지만, 이 경우, 핸들러 기능은 너무 많은 일을 하고 있다. 핸들러에서 validation, business logic, data fetching을 처리해서는 안된다.

대신에, 핸들러 기능은 전송(HTTP) 층에 초점을 맞춰야 한다. 데이터 불러오기(fetching)와 외부 연결(communication)에 관한 모든 것은 그 자체의 기능이나 모듈에서 추출되어야 한다.

// 👍 Handlers should only handle the HTTP logic
const handler = async (req, res) => {
  const { name, email } = req.body

  if (!isValidName(name)) {
    return res.status(httpStatus.BAD_REQUEST).send()
  }

  if (!isValidEmail(email)) {
    return res.status(httpStatus.BAD_REQUEST).send()
  }

  try {
    const user = userService.register(name, email)
    return res.status(httpStatus.CREATED).send(user)
  } catch (err) {
    return res.status(httpStatus.INTERNAL_SERVER_ERROR).send()
  }
}

위에서 언급한 데이터 불러오기와 외부적인 연결을 처리하는 모듈은 "서비스"라고 불린다. 이 배경에 어떤 역사적인 이유가 있는지는 확실치 않지만, 우리가 말한 뜻을 모두가 이해하기 위해서 용어를 자세히 들여다보자.

이러한 로직을 "서비스"로 묶음으로써 우리는 층으로 움직이는 시스템(layer-driven system)을 구축하게 된다. 핸들러는 전송에 관련된 것을 처리하고, 우리의 서비스는 HTTP 요청에 응답하는 것인지, 이벤트로 부터 발생된 메시지인지 알지 못한 채 도메인과 데이터에 접근하는 로직을 다룬다.

이렇게 하는 이유는 app 내에서 쓰임이 다른 것끼리 구분하고, 경계선을 그으려고 하는 것이다.조금 덜 복잡한 app의 경우 이 단계만으로도 큰 개선이 될 것이다.

그러나 서비스가 계속해서 유저, 프로모션 코드, 이메일과 관련된 로직을 처리한다는 것을 깨닫게 될 것이다. 우리가 이미 전송 로직과 다른 것들 사이에 경계를 두었음에도 불구하고 역할(책임; responsibilities)의 측면에서는 서비스가 아직도 너무 많은 일을 하고있다.

// user-service.js
export async function register(name, email) {
  const user = await queryBuilder('user').insert({ name, email })]  // 아래와 차이점

  if (!isPromotionalPeriod()) {
    const promotionalCode = await promotionService.getNewJoinerCode()
    await emailService.sendNewJoinerPromotionEmail(promotionalCode)
  }

  return user
}

유저와 직접 관련되지 않은 로직을 따로 추출함으로써 이 서비스를 스스로 모든 것을 다하는것 대신 대표자(delegate)로 만들 수 있다. 하지만 말할 수 있는 것은, 서비스의 역할이 아직도 너무 방대하다.

넓게 통용되는 패턴은 데이터 접근 로직을 "레포지토리(repository)"로 빼는 것이다.

// user-service.js
export async function register(name, email) {
  const user = await userRepository.insert(name, email)  // 위와 차이점

  if (!isPromotionalPeriod()) {
    const promotionalCode = await promotionService.getNewJoinerCode()
    await emailService.sendNewJoinerPromotionEmail(promotionalCode)
  }

  return user
}

데이터 접근을 레포지토리로 요약함으로써 서비스는 오직 비즈니스 로직을 위한 것이 된다. 게다가 테스트와 가독성이 높아진다. 가장 중요한건, 비즈니스와 데이터 사이를 기능적으로 구분할 수 있게 된 것이다.

이제 app의 로직이 전송, 도메인, 그리고 데이터 접근 층으로 나눠졌다. 각각을 바꿀 때 다른 것을 조금 바꾸거나 혹은 전혀 바꾸지 않아도 된다.만약 app이 Kafka 메세지를 소화시킬 필요가 있다면 우리는 다른 수송 층을 추가하고, 도메인과 데이터는 재사용하면 된다.

REST에서 gPRC 또는 messaging으로 옮겨가는건 정말 잘 일어나지 않는 일이다. 데이터 베이스를 바꾸는 경우는 더 희박하다. 그러나 그러한 가능성들을 인정함으로써 우리는 확장성, 가독성, 테스트가능성을 매우 향상시킬 수 있다.

아직 이러한 구조는 Node에서 유명하지는 않다. 모든 app이 이런 구조가 도움이 되는 것은 아니기 때문이다. 내가 주는 충고는 복잡성이 커지면 층을 추가하라는 것이다. 처음에는 핸들러만 가지고 시작해보다가 구조를 추가하는 위의 단계를 따라가보라.

My comment 이전에도 3계층으로 나누는걸 했었던 것 같은데... 이전에는 db(schema, models로 구성), routers, service, (필요시 middlewares)로 구성했었다.

schema는 데이터 베이스에 저장되는 필드 값의 속성을 지정해줄 수 있었다.
router에서는 HTTP 요청과 응답이 이루어지는 층이었다.
service는 라우터와 연결되어 에러메시지가 작성되고 여러가지 기본적인 로직들이 작성되는 곳이었다.
model은 데이터베이스에 접근해서 직접 query가 일어나는 곳이었다. 아마도 위 글에서 읽었던 handler-service-repository가 router-service-model 인걸까..? 이건 여쭤봐야겠당

[Node.js] 1. 모듈로 앱 구조 짜기 (번역)

Mon, 06 Jun 2022 16:40:51 GMT

이 블로그 글은 제시된 원문을 직접 번역한 것입니다. (오역이 있을 수 있으니 꼭 원문을 참고하시길 바라요!)

This article will give you a translated version of Original Article.

서론

자바스크립트의 가장 큰 이점은 바로 브라우저와 서버에서 모두 동작한다는 것이다. 엔지니어로서 하나의 언어를 마스터할 필요가 있다. 그러면 우리는 갈고 닦은 기술을 다양하게 적용해볼 수 있을 것이다. 필자 또한 이런 이유로 2015년 노드에 입문했다. Node는 프론트엔드와 백엔드 어플리케이션 사이에서 라이브러리, 로직, 타입을 재사용할 수 있다. 풀스택 개발자의 전형적인 예시가 될 수 있는 것이다! Node 생태계는 처음 구축된 당시의 무거운 프레임워크에서 탈피하여 자유로움과 유연함에 초점을 맞추고 있다. 엄격한 코딩 기준이나 어플리케이션 구조를 따지지 않아도 된다! 대신.. 유연함엔 대가가 따르긴 한다. JS를 처음 접했다면 Node 앱을 작성하는데 있어서 규칙과 원리를 찾기 어려울 것이다. OOP(객체지향프로그래밍)를 다뤄봤던 개발자들은 이전에 사용했던 언어에서 빠르게 관습들을 차용해올 수는 있다.

필자가 Node app을 개발하며 세웠던 몇 가지 규칙들을 간략히 보여주려고 한다.

Structure & Coding Practices

앱 구조를 짜는 것은 전략적이고 전술적인 결정을 합친 것이다. 개발자들은 폴더 정렬, 층, 그 사이의 연결(communication)뿐만 아니라 낮은 수준의 디테일까지 생각해야한다. 하나라도 무시하면 디자인에 흠이 발생하게 된다.

Structure the applicaion in modules

모듈로 앱 구조 짜기

백엔드 개발에서 가장 유명한 구조 디자인 패턴(structural design pattern)은 MVC이다. MVC는 대부분의 상황에 적용할 수 있고, 사용하기로 했다면 일이 잘못되는 일은 없다. MVC가 중점으로 다루고자 하는 것은 app의 기술적인 책임감들을 중점으로 구조화하는 것이다. HTTP 요청과 응답을 다루는 컨트롤러(controllers), 데이터베이스에서 데이터를 가져오는 모델(models), 응답을 시각화하는 뷰(views)로 구성된다.

이러한 접근법의 이점은 아직 크지 않다. 요즘에 대부분의 Node app은 JSON으로 통신해서 view 층이 필요하지 않은 REST한 서비스이다. 모델과 ORM을 사용하는 것도 항상 바람직한 것은 아니다. 데이터의 일부를 가지고있는 마이크로 서비스에 접근하는데 복잡한 도구들이 필요하지는 않기 때문이다. 그리고 컨트롤러 층은 종종 개발자들이 모든 종류의 로직을 컨트롤러에 쏟아내면서 복잡함 그 자체가 되기도 한다.

걱정을 나누는건 기술적 책임(역할)을 나누는 것과는 다른 얘기다.

MVC 구조의 장점은 MVC를 사용하는 각각의 app이 같은 방식으로 구성되어있다는 점이다. 하지만 나는 이것을 '결점'으로 보았다. app의 구조는 이것이 무엇을 하는 건지 보여줄 수 있어야하고, 도메인에 대한 정보를 제공해야한다. 컨트롤러로 가득찬 폴더를 열어보는 것은 서비스 내의 로직이 어떻게 구분되는 것인지 그 어떤 맥락도 제공하지 않는다. 모델의 긴 목록으로도 모델 간의 관계를 나타내지는 않는다.

노드 앱을 더 잘짜는 방식은 도메인의 한 부분을 대표하는 모듈들(modules)에 있다. 각각은 핸들러, 모델, 테스트, 비즈니스 로직을 포함한 구분된 폴더이다. 이러한 구조는 서비스가 하는 일을 한 눈에 들여다보기 편하게 하고 개발자로서 각 모듈의 모든 것에 대해 자신감을 갖게 한다. 놓친 것이 없는지 확인하기 위해 코드단에서 깊게 파볼 일이 없게 되는 것이다!

// 👎 Don't structure by technical responsibilities
├── src
|   ├── controllers
|   |   ├── user.js
|   |   ├── catalog.js
|   |   ├── order.js
|   ├── models
|   |   ├── user.js
|   |   ├── product.js
|   |   ├── order.js
|   ├── utils
|   |   ├── order.js
|   ├── tests
|   |   ├── user.test.js
|   |   ├── product.test.js

// 👍 Structure by domain modules
├── src
|   ├── user
|   |   ├── user-handlers.js
|   |   ├── user-service.js
|   |   ├── user-queries.js
|   |   ├── user-handlers.test.js
|   |   ├── index.js
|   ├── order
|   |   ├── order-handlers.js
|   |   ├── order-service.js
|   |   ├── order-queries.js
|   |   ├── order-handlers.test.js
|   |   ├── calculate-shipping.js
|   |   ├── calculate-shipping.test.js
|   |   ├── index.js
|   ├── catalog
|   |   ├── catalog-handlers.js
|   |   ├── product-queries.js
|   |   ├── catalog-handlers.test.js
|   |   ├── index.js

모듈 구조에 대해서는 따라야 할 특정한 패턴은 없다. 도메인 파트에 따라서 다른 내용들이 있을 수 있다. 예를 들어 핸들러, 모델 수가 다를 수도 있고, 비즈니스 로직의 크기가 다를 수 있다.

금융업계와 의학계에서 운영되는 app은 다른 방식으로 구조를 짜야한다. 도메인이 작동하는 방식의 차이점이 코드단에서 보여야한다. 즉, 우리의 소프트웨어가 해결하고자하는 실제 문제에 따라서 다르게 구조를 짜야할 필요가 있다. 모든 비즈니스 도메인은 다른 어려움에 직면하므로 우리는 어플리케이션을 모두 같게 디자인해서는 안된다.

My comment 실제로 나는 controller, model 등을 따로 구분해서 그 안에 user, function1, function2가 계속 반복된 형태의 스트럭쳐를 사용했었다. 그냥 파일을 여는 것 자체가 좀 귀찮..고 어려웠는데 이렇게 모듈로 만들면 관리가 편할 것 같다!

개발문서에 대하여

Tue, 05 Apr 2022 01:22:28 GMT

개발에 대해서 배우고 있는데, 자신에 대한 기준이 엄격하기 때문인지 구현이 두렵다. 또한, 나는 기획하고 프로젝트를 총괄하며 원활히 진행되도록 일조하는 일을 좋아하고 잘한다고 생각하기때문에 이 단계부터 알아가보려고 한다.

우선 프로젝트 순서를 이해하고, 내가 담당하여 작성할 개발문서에 대해 이해해보는 시간을 갖기로 했다. 이하의 내용들은 내 생각과 더불어 인터넷 세상의 많은 경험들을 참고하여 작성했다.

기획단계에서 필요한 프로젝트 문서

기획문서

기획문서는 프로젝트 시작 "전" 단계에서 정의해야할 내용을 작성한다.

개발 범위 및 전체 일정

어떤 프로젝트를 진행하건 프로젝트의 최종 목표가 무엇인지, 워크 플로우와 일정은 어떻게 되는지 수립하는 것은 프로젝트가 잘 굴러가도록 하는 요소 중 하나라고 생각한다. 많은 사람들이 협업하여 일하는 만큼 자신이 지금 어떤 트랙에서 어딜향해 달려가고 있는지를 잘 아는 것이 중요하다는 것이다.

시스템 구성도

개발, QA 관련 인스턴스 테스트 DB 정보 등을 식별하는 것으로, 이를 통해 추가 장비나 예산을 정할 수 있다고 한다.

이해관계자

커뮤니케이션할 담당자(책임자..)를 지정한다.

R&R 정의

업무분장은 프로젝트 진행에서 정말 중요하다. 앞서 말했듯, 내가 무엇을, 네가 무엇을, 우리가 무엇을 하고있는지 아는게 중요하기 때문이다.

시스템 흐름도

기획자와 개발자 간 원활한 소통을 위해 PPT 한 장에 전체적인 흐름을 정의한다.

화면 정의서

기획자와 개발자가 같은 도면을 생각하고 일할 수 있도록 돕기에 확정된 상태여야 한다. 이를 기반으로 DB 설계와 프로세스를 정의할 수 있기 때문이다.

프로세스 정의서

화면에서 데이터가 어떻게 처리되는지, 어떤 이벤트가 발생하는지 식별한다. 화면 이외의 CRUD 과정에서 어떤 데이터가 처리되는지도 정의해야 한다.

용어사전

DB 테이블 명과 칼럼 명을 생성해야한다. - 클래스명, 변수명도 함께 결정되기 때문이다.

공통 코드 정의

필요한 공통코드 정보를 API에서 제공하고 공통 화면에서 AJAX를 통해 가져다 쓰게 정의하여 사용하는 등 개발 소스를 관리한다.

Code convention

네이밍 규칙 및 변수 생성 등은 사전에 정의하고 공유해야한다.

기술 문서 작성 5단계

1. 문서 기획

PM과 함께 테크니컬 라이터는 문서 작성 범위, 문서 이해관계자, 프로세스, 문서 작성 도구, 파일 형식, 문서 일정을 정의한다. 문서는 개발 Phase나 산출국가에 따라 언어나 콘텐츠가 다양해질 수 있기에 작성 범위를 정의하는 것이 중요하다. 위에서 언급한 개발 이해관계자에는 책임자라고 적어뒀지만, 문서에 관련해서는 초안 작성자, 테크니컬 라이터, 문서 검토자, 피어리뷰 진행자, 문서 최종 승인자, 문서 배포자 등 다양한 역할이 존재할 수 있다. 또한 여기서의 프로세스는 프로젝트 특성에 따른 문서 작성의 프로세스를 의미한다. 문서 작성 도구는 회사의 규모나 조직 문화에 따라 달라질텐데, 이는 한 회사 내에서도 부서별로 사용하는 문서 도구가 구글 닥스인지, 노션인지, 마크다운인지에 따라서 다르기때문에 하나로 정하는 협의 과정이 필요한 것이다. 파일 형식 역시도 export할 것을 고려하여 pdf, html 5 등을 정해야한다. 만일 web으로 제공하면 보안 사항도 함께 정의해야 한다. 문서 일정은 문서 작성도 하나의 프로젝트이기에 문서 자체가 어떤 디벨롭 과정을 거쳐야하는지 그 일정이 수립되어야 효율적으로 작업할 수 있기에 정해야한다.

2. 목차 구조화

초안 작성자와 테크니컬 라이터는 회의를 통해 문서의 목차를 함께 구성한다. 시작이 반이라는 말이 이때 쓰이는데, 목차만 잘 구성해도 문서 작업의 절반이 끝난 것과 다름 없다.

문서를 구조화할 때 레퍼런스 문서를 분석하고, 독자의 평의성을 고려해야하는 등 고려할 점이 많다.

카카오엔터프라이즈의 테크니컬라이팅 팀에서는 자체 용어 정리, 템플릿, 기술 문서 규칙, 목차 구성 방법 및 요청을 서로 공유하고 있다.

3. 문서 작성

본격적으로 문서를 작성하는 방법은 초안 작성과 리라이팅이다. 문서 작성은 개발 세부 단계마다 작성될 필요가 있다. 만일 개발을 모두 완료한 뒤 문서를 작성하면, 개발과 관련된 다양한 이유(이슈 대응, 긴급 프로젝트 투입 등)로 쉽게 부실한 문서가 되기 때문이다.

초안 작성

카카오엔터프라이즈의 글에 의하면 ISO/IEC 표준에 따르면~~(글 작성에도 ISO표준이 있는지 몰랐다.)~~ 문서 한 페이지의 초안을 작성하는 데 1시간이 소요된다. 하지만 우리는 시간을 글쓰는데 투자하지 않는 경향이 있다. 개발도 하면서 문서도 작성하려고 한다면, 문서 작성 일정을 지키지 않는게 계속해서 쉬워질 것이다. 우리는 이러한 딜레이 현상을 최대한 지양하고, 다음 단계인 리뷰 단계에 할애할 충분한 시간을 보장하여 문서의 품질을 높이는 것이 중요하다.

리라이팅

테크니컬 라이터는 개발자가 생략한 "개발자라면 알 것"이라 생각한 내용을 보완 및 수정하여 회사 외부의 초급 개발자들도 쉽게 따라 할 수 있도록 상세히 작성한다. 또한 테크니컬 라이팅은 명확성, 간결성, 정확성, 일관성이라는 4대 원칙이 있다. 테크니컬 라이터는 작성된 초안을 원칙에 입각하여 가독성과 사용성이 높은 문서로 만들어낸다. 이때 기술적인 내용을 정확히 알아야 초안을 수정할 수 있기 때문에 초안 작성자에게 관련 교육을 요청하고, QnA를 주고받는 작업이 진행된다. ISO 표준에 따르면 수정/편집은 각각 0.5시간과 ~2.5시간이 소요된다고 한다.

4. 리뷰

리뷰 단계에서는 기술적인 측면과 스타일적인 측면에서 문서를 점검한다. 기술적인 리뷰는 초안 작성자와 다른 개발자가 함께 진행하여 문서의 기술적인 내용에 오류가 없는지에 초점을 맞춰 진행한다. 스타일적인 리뷰는 피어 리뷰라고도 하는데, 동료 테크니컬 라이터와 문서의 표현, 용어, 스타일 가이드, 맞춤법 등을 리뷰하는 과정이다.

만일 수정 보완 사항이 발견되면, 다시 "작성" 단계로 돌아간다.

ISO 표준에 따르면 페이지 당 내용 리뷰는 30분, 단순 교정 작업은 약 15분이 소요된다.

5. 배포

요즘에는 웹으로 문서를 배포하는 것이 추세이다. 누구나 쉽게 URL로 문서에 접근할 수 있기 때문이다. 만일 접근에 제한이 필요한 경우 PDF 포맷이나 Google Docs를 이용하여 권한을 제한하기도 한다. 테크니컬라이팅 딤에서는 문서 배포 이후의 문서 데이터베이스, 버전 관리도 진행한다.

예시 포맷

제목 목차 목차 별 페이지 제공 문서 정보 문서명, 작성일, 버전 저작권

🔻 How

친절한 설명

README를 읽어보기.

Markdown 문법으로 작성 보다 간편한 마크업 페이지 구성을 위해 Markdown 으로 작성한다. Typora라는 에디터는 렌더링된 화면(프리뷰)을 보여주기 때문에 효율적으로 문서를 작성할 수 있다.
표와 이미지를 잘 사용하기 카카오 개발자 문서 페이지에 들어가보면 친절한 설명과 다수의 표와 이미지를 볼 수 있다. 사람을 글을 읽기 귀찮아한다. 적어도 나는 그렇다. 따라서 긴 정보는 표와 이미지를 이용해서 압축하는 것이 좋다.

Reference

개발자 관점에서 필요한 프로젝트 문서 카카오엔터프라이즈-기술문서작성 5단계 Kakao Developers 문서

Python :: 모듈과 패키지

Thu, 03 Mar 2022 03:10:10 GMT

🔻 모듈

🌊 필요성

코드의 길이가 길어질 때, 다른 사람이 만들어놓은 함수나 변수를 활용할 수 있도록 하는 것이 바로 모듈!

🌊 모듈이 뭔데?
특정 목적을 가진 함수, 자료의 모임

🌊 모듈 사용법
import 하기
```
import module_name
```
사용법 확인하기
- 함수의 인자와 결과값을 알아야겠지!
ex. random.randrange(start,stop[, step]) → Return a randomly selected element from range(start, stop, step) : 범위(시작, 끝)에서 무작위로 선택된 요소를 반환
- ** 사용법** .(dot)을 이용한 뒤 모듈 속 함수/변수를 사용할 수 있다.
  🌊 모듈 만들기
- .py 파일에서 만들 수 있음!
- 파일 내에서 함수와 변수를 만들고나면, py파일명.함수명(또는 .변수명)으로 사용할 수 있다!
  🌊 모듈 활용하기
  사용 전에는 import로 부르는 것을 잊지 말자! 아래에는 대표적인 모듈과 모듈 내 대표적인 변수 및 함수를 간단히 정리했다.
  ◼ math 모듈
- math.pi 와 math.e 를 사용해서 파이값과 자연상수 값을 받을 수 있다.
- math.log(b, a) : log a b 표현할 수 있다!
  ◼ random 모듈
- random.randrange(a,b) : a 이상 b 미만의 숫자 중 하나 반환
  ◼ time 모듈
- time.ctime() : 현재 시간을 알려주는 함수

🔻 패키지

➰ 패키지가 뭐고 ?

모듈을 폴더(디렉토리)로 구분하여 관리하는 것
슬래시(/)를 이용하여 디렉토리를 구분하고, 각 디렉토리 안에 .py(모듈)을 저장하여 계층적인 관리가 가능하게 함
➰ 패키지 사용법
예를 들어, user 디렉토리(패키지) 속 info 라는 모듈에 personal이라는 함수가 있는 경우

[1]
```
import user.info
print(info.personal(3, 4))
```
[2]
```
from user.info import personal
print(personal(3, 4))
```
두 가지 방식으로 아용할 수 있다. 2번의 경우, 함수/변수 사용시 dot을 사용하지 않아도 된다!

🔻 urllib (url 라이브러리)

`urllib.request.urlopen`

urllib 패키지 내의 request 모듈에 포함된 urlopen 함수
해당 url의 html 파일을 가져오는 함수!
.read()와 .decode() 메서드를 이용해서 결과를 문자열로 반환하고, 반환한 문자열을 특정 인코딩 방식으로 해독할 수 있다!

flex를 공부해보자

Thu, 20 Jan 2022 17:33:45 GMT

다른 조에서는 배운 것 같은데, 나는 아니니 혼자 공부해보는 수 밖에! 참고 사이트는 다음과 같다.

Naver D2
1분코딩

🔻flex에 대한 진실

flex와 grid는 함께 언급되는 친구인 것 같다. flex보다 grid를 이용하는 경우가 많고 심지어는 이보다는 float을 아직 많이 사용한다고 한다. 그렇지만 flex의 편리함은 최강이라고 한다.
flex item은 가로 방향으로 배치되고, 자신의 width만큼만 차지한다. height은 컨테이너의 높이만큼 늘어난다(알아서 늘어난다는 뜻!, of course, height 조정도 가능)

🔻flex 구성

◼ flexbox 만드는 방법

flex 사용의 시작은 flex를 적용하는 것!

정렬하고자 하는 요소의 부모요소에 display:flex 속성을 선언 → 그러면 flex container가 되고, 자식들은 flex item이 됨!
```
.flex_container {
  display: flex;
}
```
inline-flex도 있는데 이건 컨테이너가 주변 요소와 어떻게 어우러질지 결정하는 값! 아무래도 item width만큼 container가 크기가 조정된다는걸까..? 내 추측이다.

◼ item과 container

flex container: 부모 요소
flex item: 자식 요소 (복수)

큰 컨테이너 박스 안에 flex item이 배치되어 있다고 보면 된다! 컨테이너의 가로 축은 main axis, 세로 축은 cross axis이다.

부모요소와 자식 요소의 속성이 다르다!

(부모) flex container 속성: flex-direction, flex-wrap, justify-content, align-items, align-content
(자식) flex item 속성: flex, flex-grow, flew-shrink, flex-basis, order

◼ flex main axis

flex-derection 속성으로 주축 방향이 결정되고, 이 방향에 따라 flex item이 정렬된다.
속성값으로 row(default) 또는 column이 있다.

🔻flex 속성

◼ flex container 속성

1. flex-direction 배치방향 설정

.container {
    flex-direction: row; 
}

row: 왼쪽에서부터 층층
row-reverse: 오른쪽에서부터 층층
column: 위에서 아래 방향으로 층층
column-reverse: 아래에서 위로 층층 쌓인다!
2. flex-wrap 줄넘김 처리 설정
컨테이너에 여유 공간이 없을 때, 아이템 줄바꿈을 어떻게 할 지 결정하는 속성
```
.container {
  flex-wrap: nowrap;
}
```
nowrap: 기본값, 여유 없는거 무시하고 밖으로 삐져나감
wrap: item이 아랫줄로 이동
wrap-reverse: item이 윗줄로 이동

3. flex-flow : direction과 wrap을 한번에 지정

.container {
    flex-flow: row wrap;
}

4. justify-content

여기서 justify란 메인 축을 따라 정렬(이동)하는 것! 반대로 메인 축의 수직으로 정렬(이동)하는 것은 align이다.

.container {
    justify-content: flex-start;

flex-start: 기본값, 아이템을 시작점으로 정렬
- flex-direction이 row이면 왼쪽, column이면 위
flex-end: 아이템을 끝점으로 정렬
- flex-direction이 row이면 오른쪽, column이면 아래
center: 아이템을 가운데로 정렬
space-between: 아이템들의 사이에 균일한 간격을 생성
space-around: 아이템들의 둘레에 균일한 간격 생성
space-evenly: 아이템 사이와 양 끝에 균일한 간격 생성
- IE와 Edge는 지원되지 않음!

5. align-items

.container {
    align-items: stretch;
}

stretch: 아이템들이 수직축 방향으로 끝까지 늘어남
flex-start: 아이템들을 시작점으로 정렬
- flex-direction이 row면 위, column이면 왼쪽
flex-end: 아이템을 끝으로 정렬
- flex-direction이 row면 아래, column이면 오른쪽
center: 아이템을 가운데로 정렬
baseline: 아이템을 텍스트 베이스라인 기준으로 정렬

6. align-content 여러 행 정렬

flex-wrap이 wrap 으로 설정된 상태에서, 아이템 행이 2줄 이상 되었을 때 수직축 방향 정렬을 결정
```
.container {
  flex-wrap: wrap;
  align-content: stretch;
}
```
stretch : 아이템들이 수직축 방향으로 늘어남
flex-start: 아이템을 시작점으로 정렬 (내용물만큼만 height 설정)
flex-end: 아이템을 끝점으로 정렬 (row인 경우 아래)
center: 가운데정렬
space-between : 두 줄로 내려갔을 때 사이 너비 동일하게
space-around : 각 줄의 around 너비가 동일
space-evenly : 밖과 안이 너비 동일 (MS 계열 브라우저에서 실행x)

◼ flex item 속성

1. flex-basis 아이템 기본 크기 설정

flex-direction이 row면 너비, column이면 높이

flex-basis: 100px 하면 100px 넘는 아이템은 그대로 넘는 수준에서 유지됨
width 쓰면 100px보다 큰 아이템도 100px로 맞춰짐

2. flex-grow

반응형 웹사이트 만들기

Fri, 14 Jan 2022 17:53:19 GMT

나는 너무너무 궁금했었다.. 어떻게 글자가 자동으로 줄바꿈이 되게하고,, 가독성을 높일 수 있는건지..

방법은 여러개가 있는듯 해서 배운 것을 위주로 정리를 해보려고 한다!

🔻grid 사용하기

◼ html 살펴보자


    
        
        TOP
        
            LEFT
            CENTER
            RIGHT
        
        BOTTOM

이 코드를 해석해보면,

구조

영역은 총 TOP, container(LEFT, CENTER, RIGHT), BOTTOM으로 크게보면 3개 유심히 보면 5개로 구성되어있다.

배치

css를 해석해보면, main이라고도 볼 수 있는 container 영역을 grid로 지정하고, grid-template-colums를 통해 같은 행 안에서 열 배치를 1fr, 2fr, 1fr로 주었다. 그 아래 div에 대한 css는 각 영역을 눈에 보이게 하기 위한 장치이므로 무시하자.

결과

정말 감동적인 결과가 나온다.. 내가 원했던 바로 그것,, 그치만 여기서 더 공부해야할 부분이 생긴다. 바로 fr, em, rem, px 등 수치에 대한 값을 이해할 필요가 있다. 그리고 grid를 더 폭 넓게 보기 위해 다른 속성을 알면 좋을 것 같다.

Grid 더 알아보기 fr, em, rem, px 등.. 무슨 말일까?

🔻@media 사용하기

미디어쿼리를 사용하는 방법이 있다. 미디어쿼리의 기본 원리는 특정 조건 하에서 css를 대체 또는 추가하는 것이다. 마우스를 갖다 대면~ 이라는 조건이 가능해서 이 기능에 한정하여 주로 실습하였는데, 조건부 성질과 float를 이용하면 잘 해볼 수 있다. 공부하던 당시 w3school의 웹사이트 에서 참고하여 필기해둔 내용을 적어두었다.

◼ media query 알아보기

you can apply styles to only those screens that are greater, or smaller, than a certain width.
> 적용 방법

@media not/only mediatype and (mediafeature and/or/not/ mediafeature) { CSS -code; 
}

only는 현대 브라우저에서는 no effect
media types
- all: 디폴트
- print: 프린터기
- screen: computer screen, tablets, smart-phones etc.
- speech: screenreaders that reads the page out loud
media features
- aspect-ratio: the ratio betwen the width and the height of the viewport
- color
- hover height width 등등등

◼ 폭 줄였을 때 층지게 만들기

아무튼 위에서 언급한 건 하나도 중요하지 않고, 그래서 어떻게 웹사이트를 디자인할 수 있냐는거다. 위에서 이미 언급했다시피, float 성질을 이용하면 된다.

float은 둥둥 떠다니는 속성이 있는데, 여러 div나 article의 width 합이 100%를 넘어가면 아래로 깨져버리는 현상이 나타난다. 바로 이 점을 이용하여 햄버거 메뉴 style을 만들 수 있다.
예제코드는 없다^^

🔻boostrap 사용하기

boostrap은 라이브러리로, 생활코딩 이고잉 선생님의 영상에도 아주 친절하게 나와있다.

정확히는 Layout > Grid 를 참고하면 된다.
먼저 같은 행의 각 열로 배치할
을 "col" class로 정의하고
같은 행이 될
를 "row" class로 정의한다
그리고 이것이 모두 .container에 담는다!

엇 그렇다면 혹시 1 container 안에 many rows가 가능한가? 궁금.
boostrap은 기본적으로 화면을 12칸으로 나누어두고있기 때문에 간격 조정은 더했을 때 12가 되도록 col을 세분화함으로써 가능하다.
그리고 우리는 col-sm-2, col-md-2 처럼 코드에 breakpoint를 심을 수 있는 기능까지 누릴 수 있다.

boostrap과 내

e_rho.log

[TS] 0. 개요

JS vs TS

JS 사용

TS 사용

TS의 Type

기본 자료형

참조 자료형

추가 자료형

튜플

enum

any

void

never

오류에 당황하지 않기

[Node.js] 3. 서비스로 모듈 간 연결하기 (번역)

Structure & Coding Practices

🗨 Use services to communicate between modules

Monolith VS. Microservice Architecture

Monolith vs. Microservice

참고문헌 References

🗨 Monolith

즉, app이 하나의 단위(single unit)로 돌아가면 monolith이다.

🗨 Microservice

독립적인 모듈 단위로 코드가 나눠져있다.

[Node.js] 2. 핸들러, 서비스, 레포지토리 구조로 만들기 (번역)

이 블로그 글은 제시된 원문을 직접 번역한 것입니다. (오역이 있을 수 있으니 꼭 원문을 참고하시길 바라요!)

Structure & coding Practices

🗨 Start with a modular monolith :: 모듈화된 monolith(architecture)로 시작하기

🗨 Split the implementation in layers :: 층으로 나누기

[Node.js] 1. 모듈로 앱 구조 짜기 (번역)

이 블로그 글은 제시된 원문을 직접 번역한 것입니다. (오역이 있을 수 있으니 꼭 원문을 참고하시길 바라요!)

서론

Structure & Coding Practices

Structure the applicaion in modules

개발문서에 대하여

기획단계에서 필요한 프로젝트 문서

기획문서

개발 범위 및 전체 일정

시스템 구성도

이해관계자

R&R 정의

시스템 흐름도

화면 정의서

프로세스 정의서

용어사전

공통 코드 정의

Code convention

기술 문서 작성 5단계

1. 문서 기획

2. 목차 구조화

3. 문서 작성

초안 작성

리라이팅

4. 리뷰

5. 배포

예시 포맷

🔻 How

Reference

Python :: 모듈과 패키지

🔻 모듈

🌊 필요성

🌊 모듈이 뭔데?

🌊 모듈 사용법

🌊 모듈 만들기

🌊 모듈 활용하기

◼ math 모듈

◼ random 모듈

◼ time 모듈

🔻 패키지

➰ 패키지가 뭐고 ?

➰ 패키지 사용법

[1]

[2]

🔻 urllib (url 라이브러리)

urllib.request.urlopen

flex를 공부해보자

🔻flex에 대한 진실

🔻flex 구성

◼ flexbox 만드는 방법

🗨 Start with a modular monolith
:: 모듈화된 monolith(architecture)로 시작하기

🗨 Split the implementation in layers
:: 층으로 나누기

`urllib.request.urlopen`