204th online meetup, 2024-10-12

[jongfeel]

참여 방법

토요일 오전 10시 30분에 아래 google meet 링크를 통해 접속 https://meet.google.com/jyx-mxnq-kpk

이 이슈 assignees에 자신의 github 계정을 추가 약 1시간 30분 분량의 할 내용에 대해 댓글 작성 (최소 모임 시작 전까지) 구글 캘린더 일정 등록 메일 확인을 통해서도 가능 (일정 관리에 도움도 드립니다) 모임 시간에 각자 개발 관련된 공부 진행

• 시작: 10시 30분, 각자 오늘 진행할 것 이야기 5분 ~ 10분 간 진행
  • 자기소개: 새로 오신 분이 있으면 각자 짧은 자기소개가 진행됩니다
• 진행: 2시간, 하지만 쉬는 시간 및 기타 잡일 감안해서 1시간 30분 정도로 진행
• 완료: 12시 30분, 이후 각자 진행한 것 이야기, 12시 40분 전후로 종료.

모임 끝난 후 공부한 내용 정리 & 링크 추가 => 최소 다음 모각코 전까지 확인 가능해야 함.

주의: 회사일 혹은 마감 기한 임박한 일 처리의 경우는 최대한 자제해 주세요. 주말 아침에 일하면 우울하니까요. ㅜㅜ

[Chul-Hwan]

안녕하세요, 모각코 첫 참가 신청합니다!

할일

대마왕의 유니티 URP 셰이더 그래프 : Part 1 ~ 6 복습 : 링크

[yeslee-v]

To do

firebase 강의 듣기: chapter 1-2

• 다음 일정 때문에 12시 쯤 나가보겠습니다.

[aquamagic9]

할 일

개발자로 살아남기 7,8장 (136p ~ 186p) 정리 노션 링크

[ohdair]

할 일

개발자 원칙 3장

정리

개발자 원칙 3장 정리

## Contents 많은 개발자들에게 언급되는 SOLID 원칙이라 할지라도 정답이 아닐 수도 있다는 것에 생각해야 되는 거 같다. 기존에 `BDD` 를 자주 적용했었는데, 단순하게 개발이 끝이 아니라 유지보수를 할 때에도 시스템의 일관성을 유지하기 위해서는 계획서을 제대로 만들고 유지해야 되는 거 같다는 걸 느꼈다. 또한, 생성형 AI를 통해서 무엇을 할 수 있을까 생각해보면, 저자가 말한대로 내가 설계를 잘 구축한다면 그에 맞게 코드를 생성할 수도 있기 때문에 고민하고 바로 코드를 작성하는 게 아닌 설계 도면을 만들면 균일한 제품을 만들 수 있듯이 코드도 그렇게 생성할 수 있지 않을까? ## Quotes #### p. 106 객체지향 프로그래밍에서 많이 회자되는 SOLID 원칙은 소프트웨어의 '유연성, 확장성, 유지보수성'을 갖추게 하는 데 필요하며, 원칙으로 이루어지지 않은 소프트웨어가 가지는 문제점을 `클린 소프트웨어`에서는 `디자인 악취`[^1]로 부릅니다. [^1]: 경직성, 취약성, 부동성, 점착성, 불필요한 복잡성, 불필요한 반복, 불투명성 분명 좋은 원칙이지만 출간된 지 20년도 지난 지금 시점에 이 주장을 액면 그대로 받아들여야 하는지는 생각해봐야 합니다. 원칙이라는 글자를 붙이기에는 이론적 근거가 거의 없고 가장 중요한 소프트웨어 디자인에 대해서 정의가 없기 때문입니다. #### p. 110 디자인이란 무엇일까? 디자인의 한국말은 설계입니다. 소프트웨어 제품을 개발할 때 적용해볼 수 있는 의미는 **목적**에 따라서 `실제적인 계획`을 세우고 `구체적으로 도면`을 그려 명시하는 일이 설계입니다. 현대 소프트웨어는 `민첩 개발`^{agile development} 형태로 만들어져야 한다면서 이러한 자료 만들기를 거부하는 자세에는 문제가 있다고 생각합니다. 민첩 개발이 `마이크로 폭포수 개발`과 같다고 늘 이야기 합니다. > [!note] micro waterfall development > 소프트웨어 개발의 효율성과 유연성을 높이기 위해 이를 **작은 단위로 분할**하여 수행하는 방식 > 1. **순차적 개발**: 요구사항 수집, 설계, 구현, 테스트, 배포가 차례로 이루어지며, 각 단계가 완료되면 다음 단계 > 2. **작은 단위로 쪼개기**: 전체 프로젝트를 작은 단계나 모듈로 나눠 개발, 이는 각 단계가 독립적으로 수행되기 때문에, 문제가 발생했을 때 빠르게 수정할 수 있고, 전체 프로젝트에 영향을 최소화 > 3. **유연성 강화**: 변화에 더 유연하게 대처 가능 > 4. **테스트와 피드백 주기**: 각 단계에서 피드백과 테스트가 신속하게 이루어지며, 이를 통해 문제를 조기에 발견하고 수정 > 5. **리스크 관리**: 리스크가 국소화되어 쉽게 관리 `구체적인 도면`은 소프트웨어랑 연결해보기가 쉽지 않을 수 있습니다. 도면을 가지고 있으면 세계 어디를 가더라도 같은 제품을 만들 수 있습니다. 제품에 대한 백그라운드와 히스토리를 알지 못하더라도 그리고 설계 원칙을 알지 못하더라도 같은 제품을 만들어낼 수 있습니다. #### p. 115 소프트웨어 제품은 아직 설계와 제작과 관련된 표준이 없습니다. 100년도 안 된 짧은 역사를 가졌기 때문이기도 하지만 소프트웨어 제품 개발을 작가가 소설을 쓰듯이 자유롭게 그리고 민첩하게 만들면 모든 문제가 해결된다는 근거 없는 주장을 종교처럼 받드는 사람들의 영향이 크다고 생각합니다. #### p. 117 스티브 잡스는 '소비자는 제품을 보여주기 전까지 자신이 뭘 원하는지 모른다'라고 멋진 말을 했지만, 상황이 이러하다면 제품을 만드는 생산자라도 **어떤 제품을 만들지 명확하게 정의해야 한다**는 뜻이기도 합니다. 설계 단계에서는 만들 제품이 주어진 요구사항을 잘 충족하는지 증명할 수 있는 조건을 정의해야 합니다. 설계 조건이 정해지면, 테스트에 필요한 조건도 정확하게 그리고 자연스럽게 정해지기 때문에 테스트 계획이나 조건은 당연한 결과물입니다. 그래서 설계에는 `TDD`나 `BDD`[^2], `DDD`[^3] 개념이 들어 있습니다. [^2]: `Behavior-Driven Development`, "Given-When-Then" 형식으로 행동 시나리오를 쉽게 이해할 수 있는 자연어로 작성하고 시나리오에 만족하는 테스트 및 코드 작성 [^3]: `Domain-Driven Design`, 비즈니스 도메인을 깊이 이해하고 그에 맞는 소프트웨어 설계를 중심으로 개발 설계를 하다보면 미리 갖추어야 할 선행 조건 역시 자연스럽게 파악할 수 있게 됩니다. 이를 기본 사항 또는 환경이라고 부릅니다. 마치 기차가 가려면 기차 선로가 있어야 하듯이 말입니다. #### p. 120 소프트웨어를 설계할 때 최대한 많은 정보를 기반으로 요구사항을 정리해야 합니다. 기획서에 화성을 가자가 아니라 화성을 가려면 탈출 가속도가 얼마 이상이어야 하고, 옮겨야 할 화물의 무게와 부피는 얼마인지 자세히 그리고 `측정 가능한 조건`을 기술해야 합니다. #### p. 122 명시적 설계의 4가지 요소 - 기능 설계 - 시스템이 요구사항을 만족시키도록 조건을 정하는 것 - 기능 동작의 여부 - 성능 설계 - 설계에 임의성이 적용되어 해당 자료를 기반으로 같은 제품을 만들기 어려움 - 클라우드를 범용적으로 사용하는 시대가 되어 `IaC`[^4]나 `오케스트레이터`[^5]가 발달 - 증명할 수 있는 조건을 눈으로 확인 가능한 수치로 만드는 부분이 편리 - 설계의 결과물로 반드시 성능과 관련된 부분들도 표시 또는 기록 - 유지보수 설계 - `IaC` 시대가 되면서 베이스 OS 업그레이드가 쉬워짐 - 애플리케이션 단위를 바꿔 정상 작동 여부를 확인 문제가 생기면 백업 - 미적 설계 - 정보 아키텍처를 검증할 목적 - 정보 배치와 제시 측면에서 상호작동 가능한 화면을 구성 [^4]: 인프라를 코드로 정의하고 관리하는 방식, 수동으로 서버를 설정하거나 네트워크를 구성하는 대신 스크립트나 선언형 언어를 사용해 인프라를 자동으로 배포, 관리, 업데이트 가능 [^5]: 여러 개의 서버, 컨테이너, 또는 서비스들이 상호작용하는 복잡한 인프라를 자동으로 관리하고 조율하는 시스템, 애플리케이션의 배포, 스케일링, 네트워킹, 롤백 등을 자동으로 처리 #### p. 134 암묵적 설계는 유지보수만을 위한 설계는 아지만 많은 부분이 소프트웨어 제품을 지속적으로 운영하는 데 필요한 요소를 고려하기 때문에 유지보수 개념도 포함됩니다. 대개는 빨리 기능을 구현해서 출시하고 수익 창출을 도모합니다. 그래서 암묵적 설계는 `오퍼레이션 영역`[^6]으로 치부됩니다. [^6]: 시스템이 실제로 동작하고 유지되는 단계, 설계가 없이 운영 단계에서 많은 결정을 내리게 되면 시스템의 일관성을 유지하기 어려워짐 #### p. 148 출간 후 2년, 생성형 AI가 만든 코드들이 완벽하게 돌아가진 않지만 적어도 내 설계가 어떠한지 곧바로 확인할 수 있게 되어서 `구현부터 하지 말고, 제발 설계부터 하자!` 는 원칙을 훨씬 더 강화해서 적용해도 될 환경이 마련되었습니다. 제품 개발 전이나 신규 항목을 리뷰할 때 `RFDC 세션`[^7]을 만들어서 진행했습니다. 막상 도입하고 나니 제품 개선에 많은 도움을 받았다고 인정을 받으면서 제품 설계와 사전 리뷰가 유익하다는 걸 검증하였습니다. [^7]: Request for Design Comments, 소프트웨어 개발에서 설계에 대한 피드백을 요청하는 공식적인 논의 시간

[chichoon]

할 일

자바스크립트 딥다이브 18장 함수와 일급객체 읽고 정리

한 일

• 일급 객체

  • 런타임에 생성가능함
  • 변수나 자료구조 (객체, 배열) 에 저장 가능함
  • 함수의 매개변수로 전달할 수 있고, 반환값으로 사용될 수 있다
  • 자바스크립트의 함수는 위의 조건을 모두 만족하므로 일급 객체라고 볼 수 있다
  • 함수를 객체처럼 사용 가능
  • 함수형 프로그래밍을 가능케 한다

• 함수 객체

  • 함수도 객체이므로 고유 프로퍼티를 갖는다
  • Object.getOwnPropertyDescriptors 로 확인가능
  • arguments, caller, length, name, prototype 등
  • 이는 함수 객체의 고유 프로퍼티가 아니라, Object.prototype 객체의 프로퍼티를 상속받은 것이다
  • Object.prototype 객체의 프로퍼티는 모든 객체가 상속받아 사용가능하다

• arguments 프로퍼티

  • 함수 호출시 전달된 인수들의 정보가 들어간다
  • Function.arguments 로 호출가능 했으나 ES3에서 폐지됐고 그냥 arguments 로 호출하면 된다
  • 자바스크립트는 함수 선언시 설정한 매개변수와 실제 들어온 인수의 개수를 확인하지 않으므로 오류가 발생하지 않는다
  • 대신 설정된 매개변수 개수를 초과한 인수는 arguments 에 보관되므로 여기서 열람 가능하다
  • arguments.caller 는 누가 이 매개변수를 호출했는지
  • arguments.length 는 인수의 개수
  • arguments 프로퍼티는 가변인자 함수를 구현할 때 매우 유용하게 사용할 수 있다
  • iterable 하기 때문에 순회 가능하지만 특수한 방법으로 호출 해야 하는 번거로움이 있다
  • ES6 에서는 Rest 파라미터 (...rest 형식으로 모든 인수를 배열 형식으로 가져올 수 있다) 때문에 arguments 는 잘 사용되지 않는 추세

• caller 프로퍼티

  • ECMAScript 표준이 아니고 표준화될 예정이 없어 잘 사용되지 않음
  • 함수 자신을 호출한 함수를 가리키는 프로퍼티
  • 브라우저에서 호출한 함수는 caller 가 null 이지만 Node.js 환경에서 호출한 함수는 caller 가 다른 값을 갖는다

• length 프로퍼티

  • 함수를 정의할 때 선언한 매개변수의 개수
  • arguments.length 와는 다를 수 있다
  • arguments.length 는 실제 들어온 인수의 개수
  • length 는 선언할 때의 매개변수의 개수

• name 프로퍼티

  • 함수의 이름을 가리킨다
  • 익명함수의 경우 ES5에서는 빈문자열을, ES6에서는 함수 객체를 가리키는 식별자를 값으로 갖는다

• proto 접근자 프로퍼티

  • Prototype 내부 슬롯을 접근 할 때 사용하는 프로퍼티
  • 해당 슬롯은 직접 접근이 불가능하다

• prototype 프로포티

  • 생성자 함수로 호출가능한 함수만이 갖는 프로퍼티

[jongfeel]

도메인 주도 설계 읽고 정리하기

• https://github.com/jongfeel/BookReview/issues/896
  • https://github.com/jongfeel/BookReview/issues/949

14장 모델의 무결성 유지 Unifying an Elefant(코끼리 통일하기) 부분 읽고 정리

[jongfeel]

책 선물 이벤트 알림

@yeslee-v 님 지난 203회차 모각코 참여가 181회 부터 해서 20회 출석을 달성한 횟수가 되었습니다. 지윤님에 이어 책을 두 권 받으신 분이 되셨고, 매우 축하할 만한 일이라고 봅니다. 읽고 싶은 책을 코멘트로 남겨주시면 전달 드리겠습니다.

[yeslee-v]

@jongfeel 오! 영광입니다. 비록 오늘은 늦잠으로(..) 참여를 못했지만 종필님 덕분에 매 주 토요일 오전을 알차게 보낼 수 있었습니다. 제가 받고 싶은 책은 따끈 따끈한 소프트웨어 엔지니어 가이드북으로 신청하겠습니다!