블로그 모아보기 - 인프런

[인프런 워밍업 스터디 클럽 2기 FE] 2주차 발자국

2주차 발자국[ 강의 ]이번주에는 Javascript의 Symbol, Iterator, Generator, Design Pattern에 대해 배웠다.Symbol, Iterator, Generator에 대해 정확하게 알지 못한 개념이라 강의를 구간마다 멈추면서 이해하려고 노력하였다. 지금 당장은 코딩하면서 적용하긴 어려울거 같고 더 공부를 해야 적용할 수 있을 거 같다.. 어렵다..SymbolSymbol은 유니크한 식별자를 위해 사용하는 것으로, 객체 안에 속성을 특별하게 유니크한 id의 속성으로 줄 수 있다.Symbol은 getOwnPropertyNames와 for/in에서는 속성이 숨겨진다.Iterable과 Iterator반복이 가능하다는 것을 Iterable이라 하고, Iterator은 next()를 호출해서 {value: , done: } 두개의 속성을 가지는 객체를 반환하는 객체이다.generator제너레이터 함수는 사용자의 요구에 따라 일시적으로 정지될 수도 있고, 다시 시작될 수도 있다.제너레이터 함수는 function* 이렇게 *이 붙는다.디자인 패턴 종류Singleton PatternFactory Design PatternMediator PatternObserer PatternModule Pattern 저번 과제에 <script type="module"> 이걸 썼다가 오류가 났었는데, Module Pattern과 관련이 있어 보여서 공부를 더 해봐야겠다는 생각이 들었다. Javascript 강의가 다 끝나고 React 강의로 넘어왔다.React 개념을 정리해보자면,React는 라이브러리이다.React는 컴포넌트로 이루어져있다. 컴포넌트 두가지 유형으로, 클래스형 컴포넌트와 함수형 컴포넌트가 있다. 요즘에는 Hooks가 등장하고 나서부터 함수형 컴포넌트를 이용해서 개발을 많이 한다.React는 가상 돔으로 렌더링한다.React를 시작하기 전에 node.js가 필요한데, 자바스크립트는 웹 브라우저에서 실행되는 코드여서 node.js와 직접적인 연관은 없지만, 프로젝트를 개발하는데 라이브러리들이 node.js를 사용하기 때문에 필요하다.React는 SPA(Single Page Application)이다.React는 JSX(Javascript syntax extension)이라는 자바스크립트의 확장 문법을 사용한다.React 설치 명령어 => npx create-react-app <폴더 이름>React App 실행 명령어 => npm run start[ 과제 ]비밀번호 생성 앱GitHub URL => 비밀번호 생성 앱이번에는 bootstrap를 이용했다. 오랜만에 써봤는데 다음에는 한번도 안써본 tailwind CSS를 적용해봐야겠다.기능 요구 사항으로,비밀번호 길이를 입력하는 type이 number인 input 태그에 비밀번호의 최소 길이와 최대 길이가 있어서 유효성 체크를 한다.포함할 문자(Numbers, Small Letters, Capital Letters, Symbols)를 체크하는 항목이 있다. => checkbox비밀번호 생성하기 버튼을 누르면 랜덤 문자열로 비밀번호가 생성된다.생성된 비밀번호를 copy 가능하다.고민했던 부분은,포함할 문자를 체크한 것으로만 랜덤 문자열로 생성하게 되는데, 체크한 것을 먼저 문자열로 이어붙여서 해당 문자열에 해당하는 random 문자열이 불러져 오게 했는데,, 예를 들어, Number이면 0부터 9까지, 소문자면 a부터 z까지 다 적어주는 방식이 뭔가 맘에 들지 않지만 다른 방법을 아직 생각해 내지 못했다. 더 효율적인 방식이 있을 거 같아 찾아봐야겠다.문자를 복사하는 기능을 처음 구현해보았는데, 이번 기회에 구현해볼 수 있어서 좋았다. 예산 계산기 앱GitHub URL => 예산 계산기 앱함수형 컴포넌트로만 사용했어서 이번에는 클래스형 컴포넌트로 구현해보았다.기능 요구 사항으로,1. 항목과 지출 금액 추가, 삭제, 수정 기능.항목 추가 시, 삭제와 수정 버튼이 존재하는데 수정 버튼을 누르면 기존 항목을 수정 가능하게 하여야 하고 삭제 버튼을 누르면 해당 항목이 삭제가 되어야 한다.전체 목록 지울 수 있는 버튼이 존재하여 전체 삭제가 되어야 한다. 전체 지출을 모두 더해서 총 지출 표시한다. 고민했던 부분은,총 지출을 표시하는 부분을 어떻게 구현해야 할까 하다가 state 객체 안에 allcount를 주어 생성, 삭제, 수정 될 때마다 setState({ }) 안에서 계산이 되게 하였다. 이 방법이 맞는지 모르겠다.[ 2주차 회고 ]인프런 워밍업 일정이 이제 얼마 안남았다,, 퇴근하고 집에 오면 공부 의지가 약해질 때가 많은데 이렇게 스터디에 참여해보니 혼자 할 때 보다는 훨씬 의지가 강해져서 좋은거 같다. 조금이라도 일정을 따라가 보고 싶어서 급하게 강의와 과제를 하고 있는데, 강의에서 이해가 잘 안 갔던 부분이나 또는 과제를 하면서 나온 오류나 이런 것을 정리 못하고 넘어가고 있었다. 앞으로는 모르는 것에 초점을 맞춰서 더 알아보고 정리하면서 스터디 하고 싶다.

프론트엔드･인프런워밍업클럽･프론트엔드

0

워밍업 클럽 2기 백엔드 클린코드&테스트 2주차 발자국

주간 요약객체 지향 적용: 상속과 조합, Value Object, 일급 컬렉션, Enum 활용, 다형성, 도메인 개념 도출코드 다듬기: 주석 작성, 변수와 메서드 나열, 패키지 구조화, 버그 수정, 알고리즘 교체, IDE 활용리팩토링 연습: 추상화 레벨 조정, 객체의 책임과 응집도 개선, 다양한 관점에서의 추상화개발 철학: 능동적 읽기, 오버 엔지니어링 주의, "은탄환은 없다" 개념학습 회고칭찬할 점리팩토링 연습을 통해 코드 개선 능력을 향상시켰습니다.아쉬운 점학습한 내용을 실제 프로젝트에 적용해볼 기회가 부족했습니다.Value Object, 일급 컬렉션에 대해 더 많은 예제를 통한 학습이 필요할 것 같습니다.보완하고 싶은 점학습한 개념들을 실제 코드로 구현해보는 연습이 필요하다고 생각합니다.다음 주 학습 목표이번 주에 배운 개념 중 하나를 선택하여 기존 프로젝트에 적용해보기 주간 미션접근기존 코드의 책임 분리와 메서드 개선에 초점을 맞추었습니다.의존성 주입 방식의 개선, 파일 핸들링 책임 재정의, 초기화 메시지 추가 등 다양한 측면에서 리팩토링을 진행했습니다.과정 StudyCafePassMachine 필드 주입 변경의존성 주입 방식을 개선하여 객체 간의 결합도를 낮추었습니다.StudyCafeFileHandler 책임 재정의파일 처리 관련 책임을 명확히 하고 관련 기능을 개선했습니다.initializeMessage 추가초기화 메시지를 추가하여 사용자 경험을 개선했습니다.결과책임 분리를 통해 각 클래스와 메서드의 역할을 명확히 하고 코드의 응집도를 높였습니다.의존성 주입 방식 개선으로 객체 간 결합도를 낮추고 테스트 용이성을 높였습니다.파일 핸들링 책임 재정의를 통해 관련 로직을 중앙화하고 재사용성을 높였습니다.초기화 메시지 추가로 사용자 경험을 개선하고 프로그램의 시작을 명확히 했습니다.

0

워밍업 클럽 2기 백엔드 클린코드&테스트 코드 2주차 발자국

Readable Code: 읽기 좋은 코드를 작성하는 사고법 섹션 6~7까지의 강의 수강과 미션을 진행하고 남긴 2주차 발자국입니다. 강의평소에 주석을 남기기 보단 따로 문서로 작성해서 관리하는 편이었는데, 주석에 대한 생각이 바뀌었고, 활용 방안에 또한 다시 생각해 볼 수 있는 기회였습니다.강의에서 제시한 변수와 메서드를 배치하는 하나의 방법을 배웠습니다. 메서드 순서 또한 팀원들과 협의 후 프로젝트 전반에서 일관성을 지켜야하는 컨벤션이라는 생각이 들었습니다. 미션스터디 카페 리펙토링코드를 분석하는 과정에서 메서드 분리가 필요한 부분들을 발견했습니다. 그러나 합성, VO(Value Object), 일급 컬렉션을 적용하면 해당 메서드들이 불필요해질 것으로 판단하여, 메서드 분리 전에 합성을 활용한 리팩토링을 진행했습니다.합성과 VO 사용에 익숙하지 않아 리팩토링을 완전히 마무리하지 못한 채 마감 기한에 도달했고, 계획했던 개선 사항들을 전부 적용하지 못한 상태로 미션을 제출하게 되었습니다.이 경험을 통해 점진적 리팩토링의 필요성을 느꼈습니다. 회고Keep 자소서 작성을 맞췄습니다.정해진 루틴에 맞춰 운동했습니다.Problem자소서 작성 때문에 강의와 미션에 몰입할 수 없었습니다.Try다음 주차 끝나기 전까지 밀린 강의 듣기점진적 리펙토링을 통해 스터디 카페 미션 다시 해보기

0

[워밍업 클럽_CS 전공 스터디 2기] 2주차 미션

운영체제 FIFO 스케줄링의 장단점이 뭔가요? 장점: 데이터나 작업이 수신되는 적합한 사례에서 사용하면 순서를 보장하기 때문에 데이터나 작업을 처리할 때 공정성을 보장합니다.단점: 먼저 들어온 작업이 먼저 처리되기 때문에 긴급한 작업이 중간에 들어와도 앞에 있는 모든 작업이 끝난 후에 실행되어 대기 시간이 증가합니다. SJF를 사용하기 여러운 이유가 뭔가요?어떤 프로세스가 얼마나 실행될지 모르고, Burst time이 긴 프로세스는 아주 오랫동안 실행이 되지 않을 수 있습니다. RR 스케줄링에서 타임 슬라이스가 아주 작으면 어떤 문제가 발생할까요?Context Switching 에 사용이 많이 되어서 overhead가 그만큼 커집니다. 운영체제가 MLFQ에서 CPU Bound Process와 I/O Bound Process를 어떻게 구분할까요?타임 슬라이스 기준으로 CPU 사용률과 처리량 중요하면 CPU Bound Process, 응답 속도 중요하면 I/O Bound Process 로 구분합니다. 공유자원이란무엇인가요?여러 프로세스간에 공유할 수 있는 자원을 공유자원이라고 합니다. 교착상태에 빠질 수 있는 조건은 어떤 것들을 충족해야할까요?상호배제비선점점유와 대기원형대기 자료구조와 알고리즘재귀함수에서 기저조건을 만들지 않거나 잘못 설정했을 때 어떤 문제가 발생할 수 있나요? 무한 루프에 빠질 수 있습니다. 0부터 입력 n까지 홀수의 합을 더하는 재귀 함수를 만들어보세요.function sumOdd(n){ // 재귀 로직 if (n <= 0) return 0; if (n % 2 !== 0) { return n + sumOdd(n - 2); } else { return sumOdd(n - 1); } } console.log(sumOdd(10)) // 25

0

[인프런 워밍업 클럽 2기 - CS] 2주차 미션

운영체제FIFO 스케줄링의 장단점이 뭔가요? - First In First Out으로 먼저 들어온 작업이 먼저 나간다. 이 방식은 먼저 들어온 프로세스가 먼저 나가야 다음 프로세스가 실행될 수 있다. 장점으로 직관적이나 한 프로세스가 끝나야 다음 프로세스가 끝나기 때문에 늦게 들어온 프로세스는 기다려야한다. 또한 I/O 작업이 들어온다면 CPU는 I/O 작업이 끝날때까지 쉬고있기 때문에 CPU 사용률이 떨어지게 된다.SJF를 사용하기 여러운 이유가 뭔가요? 짧은 작업 먼저 실행한다는 뜻으로 이론적으로는 FIFO보다 성능이 더 좋으나 문제가 있다. 하지만 떤 프로세스가 얼마나 실행될지 예측하지 힘들고, Burst time이 긴 프로세스는 오랫동안 실행되지 않을 수도 있다. 즉 Burst time이 짧은 프로세스를 계속 먼저 실행되기 때문에 Burst time이 긴 프로세스는 실행이 되지 않아 불공평하게 느껴질 수 있다. 따라서 이런 문제때문에 사용하지 않는다.RR 스케줄링에서 타임 슬라이스가 아주 작으면 어떤 문제가 발생할까요? - 컨텍스트 스위칭이 자주 발생하여 오버헤드가 발생한다.운영체제가 MLFQ에서 CPU Bound Process와 I/O Bound Process를 어떻게 구분할까요?- CPU 사용량이 많으면 CPU Bound Process, 적으면 I/O Bound Process으로 판단한다.공유자원이란무엇인가요?- 프로세스 간 통신을 할때 공동으로 이용하는 변수나 자원을 공유자원이라고한다.교착상태에 빠질 수 있는 조건은 어떤 것들을 충족해야할까요? - 밑의 조건이 동시에 충족되면 교착상태가 발생한다.상호배제 - 식사하는 철학자에서 포크가 이에 해당된다. 먼저 포크를 집었다면 그 포크는 다른 사람이 사용할 수 없는 리소스이다.비선점 : 프로세스 A가 리소스를 선점하고 있을때 프로세스B가 리소스를 빼앗길 수 없어야 한다. - 식사하는 철학자에서 철학자 A의 포크를 철학자 B가 뺏을수 없다.점유와 대기 : 어떤 프로세스가 리소스A를 가지고 있는 상태에서 리소스B를 원하는 상태여야 한다. - 식사하는 철학자에서 오른쪽 포크를 가진 상태에서 왼쪽 포크를 원하는 상태이다.원형대기 : 점유와 대기를 하는 프로세스들의 관계가 원형을 이루고 있다. - 식사하는 철학자에서 서로가 서로의 포크를 원하는 상황이 원형을 이룬다. 자료구조와 알고리즘재귀함수에서 기저조건을 만들지 않거나 잘못 설정했을 때 어떤 문제가 발생할 수 있나요? - 무한재귀호출이 발생하여 콜스택 메모리가 가득차서 종료된다.0부터 입력 n까지 홀수의 합을 더하는 재귀 함수를 만들어보세요.function sumOdd(n) { // 재귀 로직 if (n == 0) return 0; if (n % 2 !== 0) { return n + sumOdd(n - 1); } else { return sumOdd(n - 1); } }

0

인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 2주차 발자국

2주차 발자국 회고코드 다듬기좋은 주석?코치님께서 하신 "주석이 많다는 것은 비즈니스 요구 사항을 코드에 잘 녹이지 못 한 것"이라는 이야기는 너무나 충격적으로 다가왔다. 알고리즘 스터디를 진행 해오면서 문제를 풀고 코드를 공유하며 부가 적인 설명 및 이해를 돕기 위한 방법으로 모두 주석을 사용하였는데 지금까지 짜왔던 코드가 읽는 이로 하여금 코드가 아닌 주석에만 집중 하게끔 만든 것이 아닌가 하고 반성하게 되었다.클린 코드 강의에서 주어진 순서에 따라 리팩토링을 하는 과정에서 논리 전개의 과정이 메서드명, 변수명 등을 통해 한 눈이 읽히고 이해되도록 코드를 구성해야 한다는 것을 다시금 반성하고 깨닫게 된 것 같다.리팩토링 연습Day 7 미션지금까지 배워왔던 내용을 바탕으로 주어진 코드를 리팩토링 해보는 것은 굉장히 귀중한 경험이었던 것 같다. 배워왔던 내용들을 직접 적용해 봄으로써 연습하는 것만이 아닌 내가 강의를 들으면서 놓쳤던 부분, 덜 중요하다고 착각 했던 부분을 깨닫게 해줬다. 또한 리팩토링의 여러 관점에 대한 고민을 할 수 있는 넓은 시야를 주었던 것 같다. 처음 미션을 진행할 때는 막연히 중복되는 부분을 쳐내기 바빴지만 그 과정에서 리팩토링의 필요성을 계속해서 고민해 보고 좋은 아이디어를 떠올리기 위해 노력하는 자세를 갖추는 것, 단순히 코드를 고치는 방법이 아닌 개발자로서 꼭 필요한 것을 얻은 것 같았다.강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 (박우빈)

백엔드

0

[워밍업 클럽 스터디 2기 :: BE 클린코드 & 테스트] 2주차 발자국

섹션 6) 코드 다듬기좋은 주석우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석변수와 메서드의 나열 순서객체는 협력을 위한 존재외부 세계에 내가 어떤 기능을 제공할 수 있는지를 드러냄(정해진 답은 아니지만.. ) 공개 메서드를 상단에 배치하는 것이 좋음공개 메서드 : 객체에서 외부 세계에 제공할 수 있는 기능공개 메서드들끼리도 기준을 가지고 배치하는 것이 좋음중요도 순, 종류별로 그룹화하여 배치공개 메서드 중요도가 높은 순메서드에서 상태 변경메서드가 가지고 있는 상태를 변경하는 메서드판별boolean값으로 반환받는 상태조회값을 가져오는 조회 메서드비공개 메서드는 공개 메서드에서 언급된 순서대로 배치공통으로 사용하는 메서드라면 (가장 하단과 같은) 적당한 곳에 배치중요한 것은, 나열 순서로도 의도와 정보를 전달할 수 있다는 것Intellij IDE 활용코드 포맷 정렬 단축키 : Ctrl + ALT + LSonarlint : 오류, 버그, 스타일 등을 알려주어 문제점 개선을 도와주는 Plugin.editorConfig : 확장자마다 스타일을 다르게 줄수 있게 도와주는 설정파일섹션 8) 기억하면 좋은 조언들능동적 읽기복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기공백으로 단락 구분하기메서드와 객체로 추상화 해보기주석으로 이해한 내용 표기하며 읽기git reset --hard 가 있다핵심목표는 우리의 도메인 지식을 늘리는 것, 그리고 이전 작성자의 의도를 파악하는 것오버 엔지니어링필요한 적정 수준보다 더높은 수준의 엔지니어링ex) 구현체가 하나인 인터페이스인터페이스 형태가 아키텍처 이해에 도움을 주거나 근시일 내에 구현체가 추가될 가능성이 높다면 Ok구현체를 수정할 때마다 인터페이스도 수정해야 함코드 탐색에 영향을 줌. 애플리케이션이 비대해 짐ex) 너무 이른 추상화정보가 숨겨지기 때문에 복잡도가 높아진다.후대 개발자들이 선대의 의도를 파악하기가 힘들다.은탄환은 없다.만능해결사는 없다!클린 코드도 은탄환이 아니다.실무 : 2가지 사이의 줄다리기지속 가능한 소프트웨어의 품질 VS 기술 부채를 안고 가는 빠른 결과물대부분의 회사는 돈을 벌고 성장해야 하고 시장에서 빠르게 살아남는 것이 목표이런 경우에도 클린 코드를 추구하지 말라는 것이 아니라 미래 시점에 잘 고치도록 할 수 있는 코드 센스가 필요하다. 결국은 클린 코드의 사고법을 기반으로 결정하는 것모든 기술과 방법론은 적정 기술의 범위 내에서 사용되야 함도구라는 것은 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법적정 수준을 알기 위해, 때로는 극단적으로 시도해보자클린코드는 도구이다. 필요한 상황에서 적정 기술을 사용하도록 하자회고 읽기 쉬운 코드로 다른 동료 개발자가 내가 작성하고 있는 코드를 파악하기 쉽게 하는 것이 중요하다.회사에서 주어진 규칙 내에서 회사 내 코드를 능동적으로 읽고 필요에 따라서 툴을 사용하여 코드를 정리하며 코드를 다듬는 습관을 들이자

0

인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 1주차 발자국

1주차 발자국 회고 클린 코드를 추구해야 하는 이유누구를 위한 가독성?사실 처음에는 마음에 크게 와닿지 않았다. 코드를 짜는 방법에 대하여 수 많은 개발자들이 각자의 방식을 통해 공부하였을 것이고 그 방법은 분명 천차만별일 것이기 때문이다. 예를 들자면 어떠한 사람에게는 지저분하고 정리 되어있지 않는 책상으로 보이는 것이 그 책상의 주인에게는 잘 정리된 책상으로 보일 수 있을 것이다. 결국 정말 누구에게나 지저분해 보이는 코드가 아니라면 코드를 짠 당사자에게는 언뜻 가독성이 높을 것이라는 생각이 들었다.하지만 혼자 하는 것이 아닌 이후 새로이 팀에 합류할 사람들 또한 단번에 이해 가능해야 한다는 말에 개발은 혼자 하는 것이 아니라는 사실을 다시금 깨달았다. 많은 경험은 아니지만 프로젝트를 진행할 당시 코드 리뷰를 진행 했던 경험이 있었지만 문제가 될 수 있는 요소를 같이 찾는 과정에 불과했고 각자의 코딩 방식에 서로 개입하지 않았기에 각자 담당한 역할만 잘 소화해낸다면 충분할 거라는 생각을 갖고 있었기 때문인지 나의 코드를 다른 사람이 이어받을 수 있다는 생각을 전혀 하지 못했던 것 같다. 워밍업 클럽이 끝난다면 이전 프로젝트에서 작성하였던 코드를 다시 읽어보며 과연 타인에게도 읽기 좋은 코드였는지 오랜만에 읽어보는 자신에게도 막힘이 없었는지 확인해 보는 시간을 갖고 또 부족한 부분에 대해 파악하고 싶다는 생각이 들었다.추상적 사고 기반의 이름 짓기이름 짓기에 대한 강의는 무척 간단해 보이면서도 굉장히 큰 깨달음을 주는 듯한 내용이었다. 예전부터 변수명, 함수명에 대한 표현의 중요성을 자주 접해왔지만 적절한 예시를 보지 못했기 때문인지 충분히 잘 해내고 있었다고 생각했지만 강의 안에서 차례로 큰 흐름에서 코드의 추상화 레벨을 맞추어 나가는 과정에서 추출해내고 이름을 붙이는 각 함수와 변수들을 통해 이름 짓기가 가독성에 얼마나 많은 정보를 전달 가능한 지 배울 수 있었다.객체 지향 패러다임 관심사'단 하나의 관심사로 책임을 정의 하는 것' 그리고 '그것을 파악하는 눈'에 대한 공부는 굉장히 놀라웠던 것 같다. 단계적으로 관심사를 분리해나가는 과정에서 언뜻 완벽해 보이지만 높은 결합도는 계속해서 발견되었고 그것을 분리해 내는 과정은 인상적이었다. 관심사를 분리해 내는 것은 어떻게든 해낼 수 있을 것 같았지만 그 결합을 발견해내는 것은 어려운 일이었다. 그렇기에 클린 코드를 추구하며 결합도를 보는 눈을 끈임 없이 연습해야함을 느낄 수 있었다." 객체에 메세지를 보내라! "setter의 위험성에 대해서는 수 없이 들어왔지만 getter의 필요성에 대한 의문은 단 한번도 가지지 않았던 나에게는 놀라운 사실이었다. 정말이지 익숙하지 않아 강의 도중 객체의 필드가 필요해 질 때마다 "지금이야말로 getter가 필요한 타이밍인가?"라는 생각이 수 없이 들었던 것 같다. 그리고 나는 개발을 할 때 불필요한, 코치님의 표현에 의하면 객체에게 굉장히 무례한 코드를 남발하였던 것 같다. 항상 왜 필요한 지, 반드시 필요한 것인지에 대한 의문을 제기할 줄 알아야함을 깨달을 수 있었다.SOLID각각의 원칙을 이론이 아닌 상황에 맞춰 직접 실습해 볼 수 있는 것은 좋았지만, 만일 혼자서 코드를 리팩토링하게 된다면 코드를 어떠한 원칙을 기반으로 수정을 해야겠다는 생각이 들었는지 다른 사람들에게 잘 설명할 자신이 없었다...SOLID 원칙을 이해하고 적용하는 것의 중요성과 반복적인 학습의 필요성을 느꼈다. 객체 지향 적용완벽한 설계는 없다. 그 당시의 최선만 있을 뿐 인터페이스, Value Object, 일급 컬렉션, Enum 등의 활용에 대한 많은 것을 배울 수 있었지만, 가장 흥미로웠던 과정은 도메인에 대해 이해하게 되는 과정이었던 것 같다. 객체 지향을 위해 활용하면 좋은 내용들은 많지만 그러한 것들은 결국 도메인에 대해 이해하고 그 필요성을 얻는 과정이 선행되었던 것 같다. 도메인을 설계하면서 생각해낸 개념이 아닌 개발해가는 과정에서 숨겨져 있던 도메인의 개념을 도출하고 그것을 언제든지 받아들일 수 있도록 대비할 수 있는 개발자가 되어야겠다는 생각이 들었다.강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 (박우빈)

백엔드

0

[인프런 워밍업 클럽 2기 - BE] 2주차 발자국

강의--회고이전에는 프로젝트를 하면서 테스트 코드를 작성해 본 경험이 많지 않은데, 생각보다 중요한 작업이라는 것을 알게 되었다. 테스트 코드는 독립적으로 항상 동일한 결과를 내야하며, 로직의 수정에 있어서 어떤 오류가 있었는지 없었는지 확인을 할 수 있게 해준다.IntelliJ는 특정 클래스의 테스트 클래스를 쉽게 만들어주는 기능을 제공한다.→ 자신이 테스트 코드를 생성하려고 하는 해당 클래스에 가서 '마우스 오른쪽' → 'Generate'또한 부모-자식의 관계인 엔티티가 존재하는 경우, 부모와 자식 엔티티를 한꺼번에 처리하려고 하면 CascadeType을 설정해야 한다는 것을 깨달았다. 이전에 CascadeType에 대해서 배운 적은 있지만 어떻게 사용해야 하는 지 와닿지 않았는데 오류를 직접 접해보면서 이해하게 되었다.CascadeType.PERSIST: 부모 엔티티가 영속화될 때 자식 엔티티도 함께 영속화됨CascadeType.REMOVE: 부모 엔티티가 삭제될 때 자식 엔티티도 함께 삭제됨CascadeType.MERGE: 부모 엔티티가 병합될 때 자식 엔티티도 함께 병합됨CascadeType.ALL: 모든 영속성 전이를 포함하는 설정(PERSIST, REMOVE, MERGE 등을 모두 포함) 출력을 하기위해서는 println을 사용하는 것보다 logger을 사용하는 것이 좋다고 한다. JAVA 출력하면 무조건 println을 사용해야하는 줄 알았는데 println은 '동시성과 스레드 안전성'에 있어서 더 좋다고 한다. 미니 프로젝트--회고이번주차에는 저번 주에 만든 database ERD를 바탕으로 API 설계를 해보았다. 이전에도 API를 설계해본 적은 있지만 직접적으로 API 명세를 내가 만들어본 적은 없었다. 강사님께서 말씀하신 툴인 swagger을 사용해보고 싶었지만 찾아보니 그것은 api 구현이 되어야 사용할 수 있다고 해서 구현 없이 사용할 수 있는 명세 툴을 찾아보다 'gitBook'을 발견하게 되었고 API 명세를 위한 템플릿이 존재하여 쉽게 만들 수 있었다. ERD를 만들면서 놓쳤던 부분들이나 미처 신경 쓰지 못했던 부분들을 API 명세를 작성하면서 좀 더 구체화하고 수정할 수 있는 기회가 되었다. 다음 주에는 설계한 API를 구현하게 되는데 이를 통해서 다시 한 번 더 수정해야겠다.foreignKey에 대한 설정? 관계?이 아직 완전히 머릿속에 들어오지 않아서 이는 구현을 하면서 다시 한 번 봐야 할 것 같다.reviews를 디자이너와 연결 시켜야 할 지 리뷰어(예약자)랑 연결 시켜야 할 지 아니면 둘 다에 연결 시켜야 좋을 지 아직 정하지 못하였다. 이 역시도 한 번 더 고민해보아야 할 것 같다.이제 시험 기간인데 시험 공부랑 이 스터디의 밸런스를 잘 잡아서 두 마리 토끼를 다 잡아야 겠다. 화이팅!

0

[인프런 워밍업 클럽 2기 클린코드&테스트코드] 2주차 발자국

출처 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈1. 학습 내용 요약주석의 양면성주석이 많다그만큼 비즈니스 요구사항을 코드에 잘 녹이지 못함코드를 설명하는 주석을 쓰면, 주석에 의존 → 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드 생성그럼 언제써야 하나리팩토링 할 때 난관 중 하나는 히스토리를 전혀 알 수 없는 코드후대에 전해야 할 “의사 결정의 히스토리”를 코드로 표현 할 수 없을 때 주석으로 설명모든 표현 방법을 총동원해 코드에 의도를 녹여냈음에도 불구하고 전달해야 할 정보가 남았을 때 사용작성 주의점자주 변하는 정보는 최대한 지양관련 정책이 변하거나 코드가 변경되었다면, 주석도 잊지 않고 함께 업데이트주석이 없는 코드보다, 부정확한 주석이 달린 코드가 더 치명적변수와 메서드 나열 순서변수는 사용하는 순서대로 나열 객체 입장에서도 생각해보자 외부 세계에 내가 어떤 기능을 제공할 수 있는지를 드러냄공개 메서드를 상단에 배치하는 것을 선호물론 정해진 답은 절대 아님!공개 메서드끼리도 기준을 배치, 비공개도 마찬가지상태 변경 >> 판별 ≥ 조회 메서드공통으로 사용하는 메서드인 경우 적당한 곳에 배치패키지문맥으로써의 정보를 제공 가능패키지를 쪼개지 않으면 관리가 어려워짐패키지를 너무 잘게 쪼개도 관리가 어려워짐대규모 패키지 변경은 팀원과의 합의를 이룬 시점에 해야 함오버엔지니어링필요한 적정 수준보다 더 높은 수준의 엔지니어링Ex> 구현체가 하나인 인터페이스, 너무 이른 추상화2. 미션 회고Day 7 미션. 이번 미션은 스터디카페 좌석 예약 시스템 코드를 리팩토링하는 것이었다. 추상화, 일급컬렉션 등 앞선 강의에서 배웠던 개념들을 적용해 볼 수 있었다. 리팩토링 과정에서는 추상화레벨에 대해서 많이 생각하였다. 코드를 처음 보는 사람도 코드가 어떤 구조로 동작하고 있는지 메서드 이름 등으로 최대한 파악할 수 있도록 하였다. 그러나 이전에 경험이 많지 않았기에 추상화를 하는 과정은 쉽지 않았다. 레벨을 높이자니 내용이 날아가는 것 같고 그 반대는 오버엔지니어링이 아닐까하는 고민을 하게 되었다. 그래도 Order와 같은 새로운 도메인 개념 도출, 일급 컬렉션 등 여러 개념들을 십습해 볼 수 있는 기회였다.3. KPTKeep미션을 해결하고 다른 사람들의 코드들을 보면서 여러 관점들을 학습하였다.Problem강의 후반부에서 다루는 개념들은 앞 부분에 비해서 난이도가 조금 더 있었던 것 같다.Try강의를 들으면서 정리해 놓은 내용들을 복습하는 시간을 가져야겠다.앞으로 코드를 짜면서 강의를 통해 배웠던 개념들을 잊지 않고 잘 적용해야겠다.4. 느낀점2주간의 클린코드 강의가 마무리되었다. 강의를 통하여 실습도 해보고, 다른 사람들의 코드도 계속해서 보다 보니 확실히 시작할 때보다 코드를 보는 눈이 생긴 게 체감이 되었다. 강의를 통해 여러 개념들을 공부하면서, 이전에 코드 짜던 사람들이 이러한 구조를 생각해 내는데 얼마나 많은 고민을 했을 까 생각해보게 되는 기회였다. 그리고 이 고민의 결과물들을 강의를 통해 한번에 정리하고 실습도 해볼 수 있어서 좋았다.어느 정도 프로그래밍을 해본 사람들이라면 강의에서 여러 고민의 흔적들을 느낄 수 있을 것이라 생각한다. 또한, 이제 막 코딩을 하고 있는 사람이라면 좋은 습관을 들이는데 좋을 것 같다. 개념을 배웠다고 해서 당장 내일 짜는 코드에서 바로 나타나지는 않듯, 한 번 공부해두면 클린코드를 생각해보는 시간이 모이고 모여 한층 더 성장한 개발자가 될 수 있을 것이다.

프로그래밍 언어

0

[인프런 워밍업 클럽 2기] 프로덕트 디자인 2주차

2주차 발자국 기록 워밍업 클럽을 두번째한다고 첫번째 보다 쉬울꺼라고 생각했던 스스로를 반성합니다..ㅎ회사 프로젝트 때문에 바빠져서 오히려 더 쉽지 않네요..이번주는 피그마 작업은 많이 못해서 토요일 진행했던 라이브를 복습&회고해 보겠습니다. - 이번 주 기록 ☑ 챗gpt를 활용해서 디자인시스템 문서화하는 법개인적으로는 ant design system이 잘 만들어졌다 평소에 생각하는데라이브 투표 결과, 많은 분들이 꼽은 좋은 디자인시스템은 KRDS와 G마켓이었다.두 개의 특징은 컴포넌트가 잘 만들어져있기도 하지만 문서화 역시 잘 되어있다는 것. - 문서화를 할 때 주로 정리하는 요소들 : Spec, States, Usage, Anatomy, Behaviour, Best Practice, Accessibility, Responsive Design, Research and Testing, Props 프롬프트를 사용하면 빠르고 편하게 문서화를 할 수 있는데- 프롬프트를 입력할 때 신경 쓸 것 : CIGO.- 마지막으로 진짜로 내용이 맞는지 점검해 보고 자연스럽게 만드는 작업이 꼭 필요. - 회고 1기 때와 비교했을 때 잘 만들었다고 생각하는 디자인시스템이 매우 뚜렸하게 나와 신기했습니다.작업은 이번 주 못한 부분까지 다음주는 2배로 열심히 하겠습니다…!

UX/UI･uxui･figma･피그마･프로덕트디자인･볼드･배리어블

0

[Inf-WUP] 2주차 발자국

Spring Data JPA- 스프링에서 JPA를 더 쉽게 사용하도록 정의해둔 기능Spring Data JPA의 장점생산성 :JPA 엔티티만을 미리 정의->인터페이스만 만들면->스프링이 실행되면서->레포지토리 인터페이스를 기반으로 레포지토리 클래스들을 만들어서->스프링 bin으로 등록해줌->서비스 bin에서 레포지토리 bin들을 주입 받아와서 바로 사용 가능 DTOData Transfer Object의 약자 데이터를 담는 통 같은 역할을 하는 자바 객체dto에 엔티티에 있는 데이터를 담아 전달클라에 엔티티 데이터 바로 전달 -> 좋은 방법 x 효율적이지 않음 네트워크에 과부화, 보안 문제레이어를 분리하는게 더 안정적인 구조JPA -> open setion in view라는 옵션이 있음 개발자가 원하지 않은 변경 등을 방지하기 위해 dto 사용data 클래스에서 tostring -> 데이터의 필드들이 담고있는 내용을 key-value 형식으로 프린트 해줌 @InjectMocks, Mock 객체테스트 코드 작성 시 Mock 객체 사용하여 테스트 진행 가능실제 객체를 대신해서 외부 의존성 제거, 단위 테스트를 효과적으로 진행@InjectMocks : 의존성 주입 시 사용회고 + 미션 회고생각보다 일정을 잘 따라가는 것이 어려웠지만 막상 들으면 금방 끝나게 되었다. 미션에 어떻게 적용할 지 생각하며 수업을 따라갔는데도 미션 수행 시에는 헷갈리는 부분이 많았다. 복습은 필수라고 느꼈고 워밍업 클럽이 끝나면 다시 한 번 강의를 따라가며 실력을 다듬을 생각이다.

백엔드･워밍업클럽･백엔드

0

[인프런 워밍업 클럽 스터디 2기] 프로덕트 디자인 2주차 발자국

2주차 회고이번주는 피그마에서 가장 많이 쓰이는 컴포넌트를 만들었다.이번에는 밀리지않게 시간 분배를 잘 해야지 했는데 역시나.. 시간이 오래 걸린다배리어블은 몰라도 베리언트는 해봤으니까 잘 할 수 있을줄 알았는데...! 여태 내가 했던건 제대로된 베리언트가 아니었다ㅠㅠ배운 점입력 컴포넌트 :버튼, 컨트롤, 체크박스, 라디오, 스위치, 라벨, 컨트롤 그룹,텍스트 필드,텍스트 박스,셀렉트 디스플레이 컴포넌트 :아바타, 아코디언, 뱃지, 툴팁, 구분선, 인터랙티브 칩, 상태칩, 기본 카드, 테이블 아쉬웠던 점지금까지 베리언트를 잘 사용했다고 생각했는데 야매로 하고 있었다는 점허겁지겁 미션하느라 복습을 못한 점 다음 주에는시간 분배 더 생각해서 밀리지 않게 하기보너스 미션 수행하기

UX/UI･컴포넌트･워밍업클럽

0

인프런 워밍업 클럽 스터디 2기 - 백엔드 프로젝트 2주차 발자국

입문자를 위한 Spring Boot with Kotlin - 나만의 포트폴리오 사이트 만들기강의와 함께한 인프런 워밍업 클럽 스터디 2기 - 백엔드 프로젝트 (Kotlin, Spring Boot) 2주차 발자국 입니다. 강의 수강이번 주에는 JPA를 활용해 데이터를 초기화하고, 기본적인 CRUD 작업을 진행하면서 프로젝트의 기초적인 부분을 다졌습니다. 강의를 통해 실습을 진행하며, 코드 작성과 실행 과정을 통해 JPA와 Spring Boot에 익숙해질 수 있었습니다. 특히, 강의를 통해 코드를 작성하는 과정에서 JPA의 기본 사용법을 익히는 데 집중했습니다.주요 학습 내용Spring Data JPA의 기본 CRUD 기능 실습엔티티 간의 기본적인 연관 관계 설정JPA와 데이터베이스 초기화를 통한 실습 환경 설정테스트 코드 작성과 JUnit을 활용한 기본적인 테스트 환경 설정 회고강의와 함께 실습 프로젝트를 진행하면서 JPA와 Spring Boot의 기능을 익혔습니다. 이론 학습보다는 코드 작성에 집중하여, Spring Boot와 JPA의 실질적인 사용법을 몸에 익히는 데 중점을 두었습니다. 실습을 통해 프로젝트 구조와 JPA의 기초 개념을 이해하는 데 도움을 받았습니다.칭찬할 점매일 강의를 듣고 실습 프로젝트를 꾸준히 진행한 점새로운 기술을 익히며 이를 프로젝트에 바로 적용해 본 점실습을 통해 테스트 코드 작성법을 익혀본 점 아쉬웠던 점 및 보완할 점강의를 따라가는 데 집중하다 보니 개념적인 이해가 부족한 부분이 있습니다.실습을 통해 얻은 질문이나 궁금증을 정리해두고, 추가적인 학습을 통해 보완할 계획입니다.미션이번 주 미션은 REST API 설계하기로, 사용자가 게시글과 댓글을 작성하고, 좋아요를 추가하거나 삭제할 수 있는 RESTful API를 설계하는 것이 목표였습니다. 이를 통해 사용자 관리, 게시글과 댓글 관리, 좋아요 기능을 포함한 API를 구축했습니다. 미션 과정API 설계사용자 API: 회원가입, 로그인, 로그아웃, 사용자 정보 조회 및 수정, 비활성화 기능을 설계했습니다.게시글 API: 게시글 작성 및 수정, 삭제 기능과 더불어 게시글 목록 조회 및 특정 게시글 조회를 위한 엔드포인트를 설계했습니다. 또한, 좋아요 추가 및 취소 기능도 포함하여 사용자의 상호작용을 풍부하게 했습니다.댓글 및 답글 API: 댓글 작성, 수정, 삭제 기능과 게시글별 댓글 목록을 조회할 수 있는 기능을 설계했습니다. 댓글에 좋아요를 추가하거나 삭제할 수 있는 기능도 포함하여 사용자가 게시물과 댓글에 대해 보다 활발히 상호작용할 수 있도록 했습니다. 구체적인 API 엔드포인트 및 메서드사용자 API: /api/users 및 /api/users/{userId}를 통해 사용자를 관리할 수 있도록 하였고, 로그인, 로그아웃, 비활성화 기능을 위한 별도의 엔드포인트를 설정했습니다.게시글 API: /api/posts 및 /api/posts/{postId}를 통해 게시글 CRUD와 좋아요 기능을 관리할 수 있도록 설계했습니다.댓글 및 답글 API: /api/posts/{postId}/comments 및 /api/comments/{commentId}로 댓글 CRUD와 좋아요 기능을 관리할 수 있도록 했습니다. 회고이번 API 설계는 RESTful한 접근 방식을 유지하며, 간결하고 직관적인 구조를 갖도록 신경을 썼습니다. 테이블 간의 관계를 고려하여 API를 설계하는 과정에서 실무에서의 데이터 흐름과 REST API의 설계 원칙을 이해하는 데 도움이 되었습니다.아쉬운 점 및 보완할 점아직 JPA 관련 용어와 개념이 생소해서, 이해도가 높아지기까지 시간이 걸렸습니다. 다음 주에는 API 설계를 더욱 구체화하고, 실습하면서 느낀 궁금한 점들을 정리해 해결해 나갈 계획입니다.이번 주는 강의를 통해 프로젝트를 진행하고 API 설계를 하는 경험을 통해 많은 것을 배울 수 있었고, 다음 주에도 꾸준히 학습하며 부족한 부분을 보완해 나가겠습니다.

백엔드･인프런･워밍업클럽･스터디･백엔드･프로젝트･발자국･회고･SpringBoot

0

[인프런 워밍업 클럽 스터디 2기] 프로덕트 디자인 2주차 발자국

인프런 워밍업클럽 2기 2주차 2주차때 배운 것피그마 베리어블과 디자인 토큰 개념미션 #3) 입력 컴포넌트 만들어보기 1, 2 1/2 부분까지 진행-> 텍스트 상자부터 계속 고전하고 있어 텍스트 필드까지만 진행완료 ✅ 잘한 점- 강의 내용을 꼼꼼히 본 것디자인 시스템을 하나하나 만드는 과정을 놓치지 않기 위해 중간에 정지하면서 따라갔다.- 지난 번 피드백을 반영해 작업 수정한 것피그마 코멘트를 통한 피드백 내용을 수정해보고 복습의 기회로 삼았다. 아쉬웠던 점- 작업 중 발생되는 오류를 해결하지 못한 것앞에서 작성한대로 textarea 부분을 진행할 때 아이콘과 텍스트박스 부분을 frame안에 넣고 autolayout 처리도 했으며 아이콘 constraint과 absolute postion까지 시도했지만 박스를 늘리면 따로 분리된다...ㅠㅠ- 미션 제출을 하지 못한 것일요일까지 힘들더라도 과제 제출을 하려고 했는데 이번 주는 물건너갔다ㅠㅠ보완할 점- 미션 수행을 조금씩, 천천히 진행하기이번 주는 개인적으로 해결해야 할 일이 있어서 조금씩 진행하긴 했지만 중간에 따라하다가 막히는 부분을 작업하는 시간까지 포함하면 상당한 시간이 소요되었다. 좀 더 작은 단위로 나누어서 진행해야 겠다.

UX/UI･디자인시스템･figma･프로덕트디자인

0

[인프런워밍업클럽2기] 2주차 발자국

시작하며벌써 인프런 워밍업 클럽 2기를 시작한지 2주일이 되었습니다.제가 참여한 스터디는 하루에 2~3시간씩 들어야하는 스터디였는데요. 현재 쉬는 중이 아니었다면 완주하지 못했을 것 같습니다. 다행이도(?) 쉬는 중이라 2주차까지 완주할 수 있었네요. 강의 회고 (KPT)Keep강의를 기한 내에 다 들었다.Problem없음Try이어서 진행할 강의는 진도를 조금 더 빠르게 빼보기 과제 회고 (KPT)KeepConsole 출력 부분을 Converter로 빼서 도메인 로직과 분리Problem이용권과 사물함 이용권 도메인에 대한 고민시간을 넘겨서 다음날 코드 다시 보는 것을 하지 못함 Try다음 과제는 미리미리 화요일에 시도해보겠습니다~

인프런워밍업클럽･Readable

0

인프런 워밍업 스터디 클럽 2기 백엔드(클린코드, 테스트코드) 2주차 발자국

리팩토링.로직의 의미를 파악하고 비슷한 로직끼리 구분하여 객체의 메서드로 만든다.중복 코드를 제거하고 메서드를 추출하여 코드의 가독성을 높힌다.모든 이름은 코드의 "의미"를 적는 것이지 코드를 간략하게 적는 것이 아니다. 개발의 모든 방법에 정답은 없기에 상황에 맞게 방법들을 적용해봐야 한다.애매하게 사용할 경우 어떤 방법이든 애매하게 알 수 있다.최대한 deep하게 사용해보자.억지스러울 정도로 깊게 사용하면 방법에 대해 선이 생긴다.이 선은 앞으로 정도의 수준을 정해줄 것이다.ex. 클린 코딩이 좋다고 모두 클린 코드로 만드는 것이 아니다. 앞으로 코드를 읽을 일이 많을 것이다.그럴 때마다 주석, 리펙토링, 추상화 등을 사용하여 코드를 읽자. 추상이란, 구체에서 중요한 부분만 남기는 것이다. 미션을 하면서 실수로 제출하지 못했다. 미션을 할 때 과제의 코드가 별로 좋지 못한 코드인 것은 알지만, 어떤 부분이 별로인지는 잘 모르겠다.아직 애매하게 공부한 것 같다.앞으로 복습을 더 해야겠다.

0

[인프런 워밍업 클럽 스터디 2기] 프로덕트 디자인 1주차 발자국

인프런 워밍업클럽 2기 1주차나는 이 강의를 사놓고 디자인시스템에 대해 정복하리라 마음을 먹었지만,계속되는 건강 문제로 미루게 되어 속상하던 찰나에 워밍업클럽 2기 모집을 알고 다시 신청하게 되었다. 1주차때 배운 것피그마 베리어블과 디자인 토큰 개념미션 #1) 색상 베리어블, 간격, 타이포그래피, 아이콘 등록미션 #2) 그림자 효과, 반응형 기준점, 기타 베리어블 등록아쉬웠던 점강의를 너무 몰아서 본 것사실 나는 이론 부분은 기본적인 내용이고 이미 한번 확인한 내용이라 가볍게 생각했다.하지만 생각보다 꼼꼼하게 작업을 해야 되서 시간 지체가 있었다.단계적인 학습을 못한 것내가 주마다 해야 할 미션들이 있지만 매일 완수한다고 하면 주 3~4회 정도 되는 것 같다.나의 상황에 맞게 조금 더 작은 단위로 나누어서 미션을 꼼꼼히 수행해도 될 것 같다.그림자 효과 부분의 이해가 미흡한 점나는 그림자에 대한 강의 진행에 따라 그림자 베리어블을 제작했는데 완벽히 이해하고 완성한 것은 아니었다.물론 그림자 수치를 입력해 베리어블을 만드는 것은 수월했으나 그림자의 이론 부분을 더 숙지해야 한다.다음에 시도할 점과제를 할 수 있는 시간대 확보요즘 해야 할 일, 공부해야 하는 것들이 한꺼번에 겹친 시점이라 건강 유의 + 스케줄 정리가 필요하다.작은 단위로 나누어 미션 수행공유해주신 커리큘럼 스케줄을 보면서 개인적으로 원하는 대로 커스텀을 한 상태이다.보통 주 3~4회동안 미션 수행하는 것을 더 잘게 나누어서 몰아서 작업하는 것을 지양하고 싶다.

UX/UI･디자인시스템･UXUI･프로덕트디자인･Figma

0

워밍업 클럽 스터디 2기 [클린코드 & 테스트코드] - 2주차 회고

2주차 회고6. 코드 다듬기주석을 사용할 때 양면성과 언제 주석을 사용하고 주석 사용할 시 주의 사항을 학습변수 , 메서드를 나열 하는 순서를 고려할 때 어떤 시각을 가지고 고려하면 좋을지 학습패키지를 나눌 때 어떻게 정보를 제공하고 관리하는지 학습7. 리팩토링studycafe를 가지고 리팩토링을 진행 (Day7미션)코드의 중복 제거를 첫 순서로 시작하여 리팩토링 진행일급 컬렉션 적용 할 수 있는 부분을 찾아서 리팩토링객체의 책임 분리도메인 개념을 발견하여 리팩토링8. 기억하면 좋은 조언들능동적 읽기 오버 엔지니어링은탄환은 없다 회고Day7 미션을 하면서 내가 생각한 부분보다 더 디테일한 부분에 대해 배울 수 있었다.내가 생각한대로 리팩토링 할려하는데 시간이 없어서 강의를 참고하게 되어서 아쉬웠다.다음주도 시험이 겹쳐서 힘들겠지만 커리큘럼을 잘 따라가 마무리하고싶다.

0

[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국

오늘은 2주차 Readable Code의 완강시점으로 한 주간 진행되었던 강의에 대해 정리하고, 배우고 느낀 점을 적도록 하겠습니다. Day -7 리팩토링 연습섹션7 리팩토링 연습을 듣고 작성한 글입니다.메서드 추출로 추상화 레벨 맞추기Optional을 통한 null 반환 안하기객체에 메시지를 보내서 물어보자객체의 책임과 응집도 - IO 통합, 일급컬렉션, display(), Order 추출추상화 관점의 차이 - FileHandler 해당하는 내용에서 2가지가 가장 크게 와닿았습니다. 첫 번째 - 추상화 레벨 맞추기이부분은 이전에 [인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국 에 작성하였습니다.간단한 정리하자면고수준 추상화 레벨은 소스코드에 전반적인 흐름에 대한 내용입니다.저수준 레벨은 세부사항에 대해 작성하는 코드입니다. 하지만 실무에서는 추상화 레벨을 고려하지 않고 코드를 구현하다 보면 개발자가 쉽게 피로해지고, 유지보수하기 어렵다. 때문에 지속적으로 인지하고 변경하자는 내용이였습니다. 두 번째 - 데이터에 대한 추상화 스펙제가 강의를 보면서 제일 중요하다고 생각했던 부분은 방법에대한 추상화가 아닌 어떤 데이터를 필요로 하는지에 대한 스펙을 뽑느게 더 나은 추상화라는 구문이였습니다.데이터 중심의 추상화와 방법 중심의 추상화를 비교하면, 개발에서 중요한 것은 어떤 데이터를 필요로 하는지 정의하고 이를 통해 시스템의 요구 사항을 명확히 하는 것이라는 점 이였습니다.개발 초기에는 종종 구현 방법에 집중하여, "어떻게 코드를 작성할 것인가"에 대해 고민하게 됩니다. 예를 들어, 스타크래프트 게임에서 "배럭을 통해 마린, 파이어뱃, 고스트를 생산"한다고 가정했을 때, 일반적인 구현은 각 유닛을 객체로 만들고, 사용자가 선택할 때마다 객체를 생성하는 방식일 수 있습니다. 이 접근법은 구체적인 객체와 그 생성 방법에 중점을 둡니다.그러나, 의존성 역전 원칙(DIP, Dependency Inversion Principle)을 적용하면, 유닛에 대한 데이터를 추상화하고 이를 생성자를 통해 전달받는 방식으로 코드를 구성할 수 있습니다. 이렇게 하면 구체적인 구현에서 벗어나 유연한 객체 구조를 만들 수 있습니다. 구체적으로는, 배럭이 직접 유닛 객체를 생성하는 것이 아니라, 유닛의 속성(이름, 공격력, 체력 등)에 대한 데이터만을 전달받고 유닛 객체는 외부에서 주입된 데이터를 기반으로 생성되는 구조로 전환됩니다.이와 같은 방식으로 데이터를 추상화하면 다음과 같은 장점이 있습니다:확장성: 새로운 유닛이 추가되더라도, 별도의 객체 생성 코드 변경 없이 데이터만 추가하면 됩니다.유연성: 유닛 생성 방법이 변경되더라도, 추상화된 데이터를 기반으로 유닛을 생성하므로, 코드 수정이 최소화됩니다.재사용성: 동일한 추상화된 구조를 다른 상황에서도 쉽게 적용할 수 있습니다.따라서, 방법에 초점을 맞추기보다는 필요한 데이터의 스펙을 먼저 정의하고 추상화하는 것이 더 나은 설계로 이어질 수 있다는 것을 전달해주었고, 저에게 크게 와닿았습니다. 지속하고 싶은 부분이번 클린 코드를 들으면서 기존에 들었던 내용과 새로운 내용들이 많이 있었습니다. 알고 있던 내용들은 다시 상기시킬 수 있어서 너무 좋았으며, 새로운 내용들은 지속적으로 인지하도록 노력할 것입니다. 그러기 위해 개인 블로그에 정리할 예정이며, 개발에 대해 고민이 있을 때 꺼내 보도록 하겠습니다. 아쉬웠던 점코드 리뷰를 받을 수 있는 자리가 있었는데 날짜를 잘못 봐서 못해봤다는 것이 너무나도 아쉬웠고, 다음에는 미션을 좀 일찍 끝내서 리뷰를 받을 수 있게 할 것입니다.추가적으로 코드 리뷰 상세하게 해주셔서 감사합니다.시도해볼 점같은 프로젝트를 진행하는 팀원들에게도 공유한다면 지금보다 더 성장할 수 있는 개발자가 될 것이라고 생각되었고, 공유하는 자리를 주도적으로 만들어 보도록 하겠습니다.2주차 Readable Code 강의 정리주요 학습 내용리팩토링 연습메서드 추출로 추상화 레벨 맞추기Optional을 통한 null 반환 지양객체에 메시지 보내기객체의 책임과 응집도추상화 관점의 차이가장 인상 깊었던 두 가지 개념1. 추상화 레벨 맞추기고수준 추상화: 소스코드의 전반적인 흐름저수준 추상화: 세부사항중요성: 코드 가독성 향상 및 유지보수 용이성2. 데이터에 대한 추상화 스펙방법보다 필요한 데이터 스펙 정의가 중요데이터 중심 추상화 vs 방법 중심 추상화예시: 스타크래프트 유닛 생산 시스템장점: 확장성, 유연성, 재사용성 향상개선 및 실천 계획지속할 점학습 내용 개인 블로그에 정리개발 시 학습 내용 적극 활용아쉬웠던 점코드 리뷰 기회를 놓친 것향후 미션 일정 조율 필요시도해볼 점팀원들과 학습 내용 공유공유 자리 주도적으로 만들기

백엔드･워밍업클럽･스터디

0

[인프런 워밍업 스터디 클럽 2기_BE] 2주차 회고록 정리

주석은 죄악이다? vs 주석은 필요하다주석이 많다는 것은 요구사항을 코드에 잘못 녹여냈다는 이야기..!! 좋지 않다.코드를 설명하는 주석을 쓰면 코드가 아니라 주석에 의존한다.주석에 의존하여 코드를 작성하면 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드가 만들어진다.근데 주석은 언제쓰나요?좋은 주석 ✅ 우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석 리팩토링을할때, 조상님들이 남긴 히스토리에 대해 알수없을때 코드를 작성할때 의사소통이나 코드로 표현할수 없을때 주석을 상세하게 설명A안과 B안을 통해 ~~~ 테스트를 결정된 사항에 대해 문서는 이런식으로 작성한다.주석을 작성할 때, 자주 변하는 정보는 최대한 지양해서 작성만약 관련 정책이 변경되었다면, 주석도 잊지 않고 함께 넣는다.1 , -1 , 0 이런거는 매직넘버로 생각할수있다. 그래서 Enum으로 가독성을 올려 추상화 레벨도 맞출수있는 효과가 있다! gameStatus == GameStatus.IN_PROGRESS; 강의중에 이런 내용도 추상화 레벨을 맞추기위해 메서드로 뺀것보고 정말 추상화레벨 이해가 정말 중요한거같다.checkIfGameIsOver(); Open을하고 종료 체크를 하는것이 추상화 레벨이 동일하다 판단해서Enum을 받아서 처리하면 좀 더 직관적으로 사용하기 좋다다양한 기법을 활용하면 새로운 도메인 지식을 얻을 수 있고 더 많은 생각을 할수있다.변수와 메서드의 나열순서변수는 사용하는 순서대로 나열한다.메서드의 순서도 고려해야하는데 객체의 입장을 항상 들어보자run이라는 메서드의 출현한 순서대로 배치actOnCell이라는 메서드의 순서에 대해 배치공개 메서드는 상단에 배치하는 것을 선호또 나눈 공개 메서드의 기준상태 변경 >> 판별 메서드 ≥ 조회 메서드 순서로 하는게 좋다.비공개 메서드는공개 메서드의 출현한 순서대로public 1private 1private 2이런식으로 배치하면 좋을꺼같다.나열 순서로도 의도와 정보를 전달할 수 있다는 것.메서드와 변수를 만들때 어디다 배치하지?이게 공개 메서드에서 내부 메서드로 의심을 해본다.변경 메서드여도 private면 우선순위가 낮아진다.내부에서 돌면 private로 바꿔준다.패키지 나누기패키지는 문맥으로써 정보를 제공할 수 있다.패키지는 쪼개지 않으면 관리가 어렵다.반대로 너무 잘개 쪼개면 관리가 어렵다.대규모 패키지 변경은 팀원과의 합의를 이룬시점에 하자.commit이 끝난후 작업을 하던 해야지 아니면 머지할때 고생한다..문과적으로 생각해서 보드는 셀과 포지션의 부모와 같은 상위 개념이라 옮겨도 된다.인터페이스와 구현부랑 나눠서 패키지구조를 잡는방법을 진행했다.기능 유지보수하기1. 버그잡기기능을 추가하거나 수정할때 좋은 방법깃발을 다꽂으면 게임이 승리조건으로 끝난다. → 버그케이스왜 이렇게 될까?로직적으로 코드가 문제가 되는곳이 있었으며, 이를 개선하기 위해 코드한줄한줄을 읽고 문제점을 파악하여 변경해나갔다. 코드를 읽으며 코드의 흐름 즉 추상화레벨을 잘 파악하는 것이 버그를 잡는 포인트다.2. 추상화 레벨을 맞추기생각해낸 방법추상화 레벨을 맞추기 위해서 한줄 한줄 코드를 읽고 분류를 진행한다.중복으로 뽑아낼수 있는 부분을 뽑아낸다.이미 타입을 선택했기때문에 타입으로 필터링으로 추출해도된다.중복된 로직에 대한 범위를 잡기부가적인 요소에 대한 내용을 메서드로 추출하기같은 메서드 동작임을 판단해서 생각하는것도 필요하다.null 객체 반환은 좋지 않아 Optional로 관리를 진행할 예정이다.파라미터에 Optional을 받으면 좋지 않은 안티패턴이다.한단위가 끝날때 , 조각조각 나눠서 커밋을 하는게 중요하다.객체의 책임과 응집도IO 통합일급 컬렉션display()의 책임Order 객체IO의 통합IO를 통합하여 같은 일련의 과정으로 묶여서 통합 객체를 만들어서 사용자의 객체하나로 한다. 왜 근데 그렇게 할까?일급 컬렉션일급 컬렉션을 활용하면 장점이 컬렉션의 가공이 일급 컬렉션에서 사용된다. 추상화되어일급 컬렉션을 활용하면 테스트 코드도 짜기 편하다. 매우null을 반환하는건 좋지 않다. 그러니까 Optional을 활용하여 null 객체를 처리를 꼭하자.display의 책임코드를 옮기고 둘이 동일한 로직을 타는것을 알수있다. 다른것은 파라미터뿐!이용권에 대한 인터페이스를 만들어서 관리하면 어떨까?필드가 공통적이라면 인터페이스를 만들어서 관리하는게 훨씬 좋다 상속은 별로다!!인터페이스를 만든다.해당 인터페이스를 가져온다.출력을 담당하는로직에서 이용권 계산은 도메인과 맞지 않고 올바르지 않다. 그렇기 때문에 분리하자.관점의 차이로 달라지는 추상화FineHandler를 바라보는 관점파일을 읽어오는 모든 행위에 대해서 가져오기때문에 무거워지기때문이다.구글시트나 다른 내용에 대해 유연성이 떨어진다. 그렇기 때문에 인터페이스에 대한 응집도가 올바르지 않다.제공을 해주는 접근, 읽는 접근으로해서io와 provider를 분리하는 이유는? 되게 중요하다.읽는다는 개념은 구현의 추상화 레벨이 낮고 , 제공해주는 개념이기때문에 따로 패키지에 스펙을 둔것이다.→ 헥사고날 아키텍처 - 포트와 어댑터의 기본이 되는 개념Provider과 다양한 역할을 보면서 클래스 작성에도 큰 책임 따른다 생각을 했다.능동적 읽기복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기공백으로 단락 구분메서드와 객체로 추상화주석으로 이해한 내용 표기하며 읽기우리에게는 언제든 돌아갈 수 있는 git reset —hard 가있다.핵심 목표는 우리의 도메인 지식을 늘리는 것. 그리고 이전 작성자의 의도를 파악하는것오버 엔지니어링필요한 적정 수준보다 더 높은 수준의 엔지니어링가능성이 낮아보이는 요구사항에 대해 리소스를 투자하는 행위은탄환은 없다.클린 코드도 은탄환이 아니다.실무 : 2가지 사이의 줄다리기지속 가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물클린 코드를 추구하지만 코드 센스가 아주 중요하다. 클린 코드의 사고법을 기반으로 결정회사에서 많은 기법을 넣으려고 노력을 많이했지만 해당 강의를 들으니 많은 반성을 하게되었다. 꼭 좋은 기술 스택이여도 오히려 나에게 독이 될수 있다는 것을 느꼈다. 기술 스택을 넓히기보단 왜? 라는 중점을 두고 깊게 파고드는 개발 방향성을 잡아야겠다.2주차에 있는 day7의 과제중 객체지향적으로 코드를 설계하고 구현을 하는 내용이 있었다. 회사에서 어느정도 리팩토링을 진행해봤고 자신도 있었지만 코드를보니 머리가 하얘졌다. 첫번째로 실수한건 요구사항을 읽지않고 코드만 읽어 도메인 개념을 이해하고 개발을 진행하려했던것 코드한줄한줄을 분리하기 어려웠던 것 다양한것도 있었지만 요구사항을 파악하지 못했던 점이 가장 큰 페인이 되었던거같다. 요구사항을 재대로 보았으면 오래걸리지않고 코드를 더 빨리 구조화했을텐데 그러지못해서 많이 아쉬웠다. 다음번에는 요구사항에 대해 꼼꼼히 찾아봐야겠다또한 이번 중간평가에서 피드백을 받고 너무 많은 오버엔지니어링을 했다는 점에 반성을 했고 다른 사람들의 피드백을보며 나도 더 열심히해야겠다는 생각이 들었다 나보다 개발을 잘하는 사람은 널렸다. 겸손해야겠다.다음 강의에 대해 테스트 코드를 배우는 시간인데 너무 설렌다. 적용을 하고싶어도 구체적인 범위에 대해 어려움이 많았는데, 이번 강의에 대해 크게 얻어가는게 있었으면 좋겠다관련 코드 :https://github.com/backgom1/readable-code/tree/main/src/main/java/cleancode/studycafe/asis

0

두번째 발자국 👣

코드 다듬기주석의 양면성변수와 메서드의 나열순서 : 나열순서로 의도와 정보를 전달할수 있다. 패키지 나누기IDE의 도움 받기리팩토링 미션 회고리팩토링을 직접해보려니 생각보다 너무 어려웠다. 🥲 배웠던 접근 방법도 중구난방으로 생각이 나고, 내 생각을 코드로 나타내는 것이 쉽지않았다. 그래도 먼저 내가 생각했던 방식을 기록하고, 다시 강의를 보면서 깨달았던 부분을 적어봐야겠다.먼저 코드를 읽으면서 코드가 어떤의미를 가지고 있는지 파악했다. 그리고 패스 타입에따라 나누어진 부분에서 똑같이 반복되는 부분을 밖으로 빼서 메서드화 하면 될거라고 생각했다. 그런데 마지막 조건문에서 락커에 대한 조건 문이 추가 되었는데 그 부분을 어떻게 처리해야할지 고민이 됐다.그리고 스터디 패스권의 모음이 리스트 형식이라서, 이걸 한번 감싼 형태인 일급컬렉션을 사용해야한다는 생각도 들었다.그리고 InputHandler, OutputHandler, FileHandler는 인터페이스로 써야하는것아닌가 라는 생각이 들었다.강의를 들어보니, 무조건 메서드를 만들려고 했던 것이 더 혼란을 일으켰던 것 같고, 생각한 것을 코드로 옮기는 구현에 대한 연습이 더 필요한것과 객체의 책임에 대해 더욱더 생각해야한다는 깨달음을 얻었다. 어찌됐던 지금의 나에게는 좀 더 많은 복습이 필요하다. 너무 해야할게 많은거 아닌가 싶어서 압박감이 들기도 했지만 , 하나씩 알아가는 재미도 분명 있기때문에 힘들지는 않다. 내가 생각했던 과정을 수정해가는 과정을 통해서 조금 더 나은 내가 될 것이다.중간 점검 회고 나에게 필요한 것 메서드 분리하는 것부터 시작해보기책임을 정의하고 객체로도 나눠보기한글로 풀어써보는 것도 좋다. 프로젝트 추천 책 - 스프링 부트와 AWS로 혼자 구현하는 웹 서비스추천 책 - 함께 자라기

0

워밍업 클럽 2기 BE 클린코드&테스트 발자국 2주차

강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법섹션 6 코드 다듬기주석의 양면성코드는 유지보수 되나 주석은 유지보수 되지 않는다코드의 설명을 위한 주석은 좋지 않다주석을 사용한다면 코드로 파악이 힘든 내용들을 담도록 하자히스토리 파악이 힘든 코드에 대한 히스토리 설명패키지 나누기의미있는 단위로 패키지를 나누자 섹션 7 리팩토링 연습코드 레벨에서의 추상화가 아닌 도메인을 잘 이해하여 높은 레벨로 추상화하여 가독성을 높이자 ex) 고정석이 아니면 return 관점을 고정석이 아닌 경우라 생각하면 doesNotFixed라 메소드 이름을 짓게 된다고정석이 아니라는 건 락커를 사용할 수 없다는 의미로 더 높은 추상화 레벨로 메소드 이름을 지으면 canNotUserLocker로 메소드 이름을 지을 수 있다클래스명에 대한 추상화 ex) 파일을 읽어 어떠한 정보를 가져오는 클래스클라이언트 입장에선 어떤 정보를 가져오는지에 대한 관심만 있음정보를 가져오는 수단에 대한 관심을 지우고 어떠한 정보를 가져올지에 포커스를 맞추다~Provider, ~Generator 등의 이름을 활용하도록 하자더 좋은 네이밍은 스프링에서 찾아보도록 하자 섹션 8 기억하면 좋은 조언들객체지향이 무조건 좋은 건 아니다과한 객체 지향은 오버엔지니어링이 될 수 있고 가독성을 해친다요구사항에 따라 절차적 프로그래밍이 어울릴 수 있고 객체지향 프로그래밍이 어울릴 수 있다내가 짠 코드에 근거를 가지고 상황에 맞게 리팩토링 기법이나 객체 지향을 잘 적용하도록 하자

백엔드･워밍업클럽2기･BE클린코드&테스트

0

[인프런 워밍업 클럽 2기 - 백엔드 프로젝트(Kotlin, Spring)] 2주차 발자국

2주차 발자국테스트 코드 작성규모가 큰 운영 서비스 이거나 운영 기간이 오래 된 서비스 같은 경우 테스트 코드의 가치가 커진다. 메소드를 사용하는 다른 메소드들에서 의도하지 않은 결과가 나올 수 도 있어서 서비스 전체 기능에 미치는 사이드 이펙트들을 사전에 감지할 가능성이 올라간다. 어노테이션@DataJpaTest @Entity 및 @Repository 어노테이션이 부여된 클래스들을 검색하 여 테스트 환경을 설정@TestInstance 테스트 인스턴스의 라이프사이클을 지정@BeforeAll 테스트 클래스 내의 모든 @Test 메소드 실행 전에 한 번 실행@Test 테스트 메소드를 지정@Autowired 의존성을 주입할 때 사용@DisplayName 테스트 클래스나 메소드의 이름을 정의 리포지토리 성능 개선N+1 문제 대표적인 JPA의 단점, JPA에서는 먼저 부모 테이블에서 조회를 한 후 엔티티의 연관관계를 바탕으로 조회해온 데이터의 개수만큼 부모에 매핑된 자식 테이블의 데이터를 조회하기 위해 데이터베이스를 호출 그래서 N+1번의 쿼리가 사용 Fetch TypeLazy : 런타임에서 연관관계 필드를 호출하는 경우 데이터베이스를 호출 (부모 데이터가 100개가 조회되더라도, 단 1개의 부모 데이터에서만 자식 데이터를 사용할 경우 1개의 쿼리만 나감)Eager : 부모 데이터를 조회하는 즉시 자식 데이터를 조회 (실제로 자식 데이터를 사용하지 않더라도, 조회된 부모 개수만큼 쿼리가 나감) Fetch Join : JPA에 의존하지 않고 직접 JPQL 쿼리를 보냄. Join을 활용해 한번에 부모와 자식 데이터를 조회 (하지만 OneToMany, 또는 ManyToMany 관계의 자식 엔티티가 여러 개일 경우, 하나만 조인할 수 있다는 한계가 있음) Batch Fetch Size : IN 절을 사용해서 여러 건의 데이터를 한번에 조회 (1+N의 쿼리가 1+(N/batch_fetch_size) 정도의 수준으로 줄어든다고 할 수 있음. 하지만 DBMS에 따라 IN 절의 파라미터 개수 제한이 있기도 하고, 한 번에 많은 데이터를 불러오는 것은 애플리케이션이나 데이터베이스 에 부담을 줄 수 있기 때문에 적절한 개수 설 정이 필요) 어노테이션@Transactional 트랜잭션을 간편하게 열고 닫을 수 있게 해줌rollbackFor 어떤 예외가 발생했을 때 롤백할지를 정의readOnly 읽기 전용 트랜잭션으로 설정. JPA를 사용할 경우, 더티체킹 등을 수행하지 않기때문에 성능상 이점이 있음isoation 트랜잭션 고립 수준을 정의@ExtendWith JUnit5에서 테스트 확장을 지원하는 어노테이션@InjectMocks Mockito에서 테스트 대상이 되는 클래스에 인스턴스를 주입하기 위해 사용@Mock Mockito에서 Mock객체를 생성할 때 사용 미션 [미션 3] REST API 설계하기설계할때 네가지 기능(PUT, GET, POST, DELETE)를 주로 사용하는데 ERD를 설계한 후 API를 설계하니까 POST를 사용하려는 계획이 많아졌다. 처음부터 잘 생각하고 다시 작성해야할 것 같다. 너무 어렵게 생각하지말고 간단히 해서 완성을 해보는 것이 좋을 것 같다는 생각도 들었다. 이번주는 저번주보다 더 알아듣기 편해졌다. 1주차가 가장 힘든 것 같다. 2주차부터는 수업에 알아듣는 것이 많아졌다. 그리고 오타도 많아져서 에러가 좀 났었다. 오타확인 필수!

0