블로그

김민성

[워밍업 클럽 스터디 2기 - BE] (클린코드, 테스트코드) 2주차 발자국

인프런 워밍업 클럽 스터디 2기 - 백엔드 클린코드, 테스트 코드(Java, Spring Boot)Readable Code : 읽기 좋은 코드를 작성하는 사고법해당 강의를 학습하며 정리하는 내용입니다. 1주차 발자국에 이어서 이번주도 배운 내용을 정리하고 회고를 작성한다.이번주는 지난주에 이어 Readable Code 나머지 모든 강의를 수강하는 한주였다.키워드 형식으로 정리한다. 객체 지향 적용하기상속과 조합상속보다 조합을 사용하자!상속은 시멘트처럼 굳어지는 구조다. 수정이 어렵다.부모와 자식의 결합도가 높다.조합과 인터페이스를 활용하는 것이 유연한 구조상속을 통한 코드의 중복 제거가 주는 이점보다, 중복이 생기더라도 유연한 구조 설계가 주는 이점이 더 크다.[객체지향 적용하기 - 상속과 조합 - 셀을 상속에서 조합으로 바꾸기](https://github.com/iamminseongKim/readable-code/commit/86a49db553a752eca745a0d462125ee0d0b4ad70)Value Object도메인의 어떤 개념을 추상화하여 표현한 값 객체값으로 취급하기 위해서 불변성, 동등성, 유효성 검증 등을 보장해야 한다.불변성 : final 필드, setter 금지동등성 : 서로 다른 인스턴스여도(동일성이 달라도), 내부의 값이 같으면 같은 값 객체로 취급한다. equals() & hashCode() 재정의 필요유효성 검증 : 객체가 생성되는 시점에 값에 대한 유효성을 보장하기만원 지폐가 일렬번호(인스턴스)가 다르다고 가치가 다른 즉 다른 만원인가?객체의 동등성을 보장해주자! VO vs Entityclass UserAccount { private String userId; // 식별자 private String 이름; private String 생년월일; private Address 집주소; }이건 Entityclass Address { private String 시도; private String 시군구; private String 도로명; private String 건물번호; }이건 VO이다. Entity는 식별자가 존재한다. 식별자가 아닌 필드의 값이 달라도, 식별자가 같으면 동등한 객체로 취급한다.equals() & hashCode()도 식별자 필드만 가지고 재정의할 수 있다.식별자가 같은데 식별자가 아닌 필드의 값이 서로 다른 두 인스턴스가 있다면, 같은 Entity가 시간이 지남에 따라 변화한 것으로 이해할 수 있다.VO는 식별자 없이 내부의 모든 값이 다 같아야 동등한 객체로 취급한다.개념적으로, 전체 필드가 다 같아야 식별자 역할을 한다고 생각해도 된다.[Value Object - Cell의 상태를 value object로 만들기.](https://github.com/iamminseongKim/readable-code/commit/b667b43de3dfa2fa78fc6a4baf24af570acf69d6) 일급 컬렉션 일급 시민다른 요소에게 사용 가능한 모든 연산을 지원하는 요소변수로 할당 될 수 있다.파라미터로 전달될 수 있다.함수의 결과로 반환될 수 있다.ex) 일급 함수함수형 프로그래밍 언어에서, 함수는 일급 시민이다. 함수는 변수에 할당될 수 있고, 인자로 전달될 수 있고, 함수의 결과로 함수가 반환될 수 있다.일급 컬렉션 컬렉션을 포장하면서, 컬렉션만을 유일하게 필드로 가지는 객체컬렉션을 다른 객체와 동등한 레벨로 다루기 위함단 하나의 컬렉션 필드만을 가진다.컬렉션을 추상화하며 의미를 담을 수 있고, 가공 로직의 보금자리가 생긴다.가공 로직에 대한 테스트도 작성할 수 있다.만약 getter로 컬렉션을 반환할 일이 생긴다면, 외부 조작을 피하기 위해 꼭 새로운 컬렉션으로 만들어서 반환해주자. [일급 컬렉션 - Cell을 가진 Cells 일급 컬렉션](https://github.com/wbluke/readable-code/commit/e72454d3cacea5fb818317b7755551f8a6ae1459)[일급 컬렉션 - CellPosition을 가진 CellPositions 일급 컬렉션](https://github.com/wbluke/readable-code/commit/f297f57d950389deda905a001a94919ef45d25c6)Enum의 특성과 활용Enum은 상수의 집합이며, 상수와 관련된 로직을 담을 수 있는 공간이다상태와 행위를 한 곳에서 관리할 수 있는 추상화된 객체특정 도메인 개념에 대해 그 종류와 기능을 명시적으로 표현해줄 수 있다.만약 변경이 정말 잦은 개념은, Enum보다 DB로 관리하는 것이 나을 수 있다.다형성 활용하기 변하는 것과 변하지 않는 것을 분리하여 추상화하고, OCP를 지키는 구조[다형성 활용하기 - CellSign을 다형성을 가져서 개발해보기](https://github.com/iamminseongKim/readable-code/commit/83f472152ec7a4b82d5d92c17bdb742089b381f6) 숨겨져 있는 도메인 개념 도출하기도메인 지식은 만드는 것이 아니라 발견하는 것객체 지향은 현실을 100% 반영하는 도구가 아니라, 흉내내는 것이다.현실 세계에서 쉽게 인지하지 못하는 개념도 도출해서 사용해야 할 때가 있다.설계할 때는 근시적, 거시적 관점에서 최대한 미래를 에측하고, 시간이 지나 만약 틀렸다는 것을 인지하면 언제든 돌아올 수 있도록 코드를 만들어야 한다.완벽한 설계는 없다. 그 당시 최선이 있을 뿐.코드 다듬기주석의 양면성주석은 죄악이다! VS. 주석 좀 남겨줘라!주석이 많다는 것은, 그만큼 비즈니스 요구사항을 코드에 잘 못 녹였다는 이야기.코드를 설명하는 주석을 쓰면, 코드가 아니라 주석에 의존한다. 주석에 의존하여 코드를 작성하면, 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드가 만들어진다.아니 그럼 주석은 언제 씁니까? 좋은 주석은 뭘까우리가 리팩토링 할 때, 정말 큰 난관 중 하나는 히스토리를 전혀 알 수 없는 코드다.후대에 전해야 할 의사 결정의 히스토리를 도저히 코드로 표현할 수 없을 때 주석으로 상세하게 설명한다.주석을 작성할 때, 자주 변하는 정보는 최대한 지양해서 작성한다.만약 관련 정책이 변하거나 코드가 변경되었다면, 주석도 잊지 않고 함께 업데이트 한다.주석이 없는 코드보다, 부정확한 주석이 달린 코드가 더 치명적이다.우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보 남았을 때 사용하는 주석[주석 제거 - gameStatus - 제거 후 책임 변경](https://github.com/iamminseongKim/readable-code/commit/5810a74a9cbfc41b2d2bc638f58a437f26bec2b5) 변수와 메서드의 나열 순서변수는 사용하는 순서대로 나열한다.인지적 경제성메서드의 순서도 고려해보야햐 하는데, 객체의 입장에서 생각해보자.상태변경 >> 판별 >= 조회 메서드 순서비공개 메서드는 공개 메서드에서 언급한 순서 대로 배치공통으로 사용하는 메서드라면 (가장 하단 같은) 적당한 곳에 배치한다.중요한 것은, 나열 순서로도 의도와 정보를 전달할 수 있다는 것[코드 다듬기 - 변수와 메서드의 나열 순서](https://github.com/iamminseongKim/readable-code/commit/c3fea40a581cfd0a418114473350fe430686a0d9) 패키지 나누기패키지는 문맥으로써의 정보를 제공할 수 있다. 패키지를 쪼개지 않으면 관리가 어려워진다.패키지를 너무 잘게 쪼개도 마찬가지로 관리가 어려워진다.대규모 패키지 변경은 팀원과의 합의를 이룬 시점에서 하자.[코드 다듬기 - 패키지 나누기](https://github.com/iamminseongKim/readable-code/commit/8f650421839f7b68021dc1a983a2a1cf29a64b8f) 기능 유지보수하기 (1) - 버그 잡기이전 코드에선 지뢰판에 깃발을 전부 꽂으면 승리했다. 이걸 수정해보는 과정인데 셀을 체크하는 과정의 핵심이 뭔지 파악하고 고치는 작업이었다. [코드 다듬기 - 기능 유지보수하기 (1) - 버그 잡기 - 객체의 책임을 명확하게 했기 때문에 고치기 쉽다.](https://github.com/iamminseongKim/readable-code/commit/8654bb3d727a9bffe4f7b2b8ab06211446a3cae8)객체의 책임을 명확하게 분리했기 때문에 고치기 매우 쉬웠다. 기능 유지보수하기 (2) - 알고리즘 교체하기재귀함수를 Stack으로 변경해서 주변 셀을 여는 로직을 개선했다.[코드 다듬기 - 기능 유지보수하기 (2) - 알고리즘 바꾸기. 재귀함수 -> stack](https://github.com/iamminseongKim/readable-code/commit/3bbcfe61b7f0dca6fcee51efc2f3adbfb298aa3d)원리는 이해하겠는데, 솔직히 이걸 일상에서 떠올릴 수 있을지 내 실력이 부족하다는걸 또 한번 느끼는 시간이었다. IDE의 도움 받기코드 포맷 정렬 : Option + Cmd + L | Ctrl + Alt + L코드 품질 : Sonarlintlint(linting) : 잠재적인 문제가 될 수 있는 오류, 버그, 스타일 등을 미리 알려주는 코드 품질 체크 도구포맷 규칙 : .editorconfig (https://editorconfig.org/)여러 사람과 협업을 염두하면 IDE 기본 포맷팅에 익숙해지는 것이 좋다.스타일은 혼자 결정하는 것이 아니라, 팀 내 합의도 도출되어야만 한다.한번 정해지면 절대적인 것이 아니라, 사용하면서 계속 의견을 듣고 개선/반영하는 것이 좋다.[코드 다듬기 - IDE의 도움 받기, 코드 정렬, Sonarlint, .editorconfig](https://github.com/iamminseongKim/readable-code/commit/11469a97f84c4a2d04e6a499fdb5f37b106ebbff)리팩토링 연습 리팩토링 (1) - 추상화 레벨중복 제거, 메서드 추출[의미 단위로 공백넣기](https://github.com/iamminseongKim/readable-code/commit/f3d08ed8cae33db74b0a5d7c812da9f81c28d9e2)[중복 로직 제거, 메서드 추상화](https://github.com/iamminseongKim/readable-code/commit/0e7504e10dca82d411937631c470cc8dd8e779f7)객체에 메시지 보내기[null대신 Optional넘기기](https://github.com/iamminseongKim/readable-code/commit/716b682d2ea7149448adc8a149dd89067a99b3fe)[객체에게 정중히 묻기. getter로 무례하게 하지 말고!](https://github.com/iamminseongKim/readable-code/commit/fd468510e9d3c144d4e938494825105e02624232)이 순서대로 리팩토링하면 좀 정리하기 쉽다.리팩토링 (2) - 객체의 책임과 응집도IO 통합[Input, Output 하나로 통합](https://github.com/iamminseongKim/readable-code/commit/4e2f36eceed58ada1d22316fe6f4b54ffca989ce)일급 컬랙션[StudyCafePass, LockerPass에 대한 일급컬랙션 생성](https://github.com/iamminseongKim/readable-code/commit/82a05d1493c516a31e41cb5bc9dc9b7aef2f6e07)display()의 책임[display를 IOHandler에서 하도록 하고, 하다보니 pass 인터페이스로 추상화](https://github.com/iamminseongKim/readable-code/commit/ae2546b1b76a44a5186333ec3bb66c165bb8b4b0)Order 객체[계산 로직을 IO에서 할게 아니라 PassOrder라는 주문 객체를 만들어서 위임](https://github.com/iamminseongKim/readable-code/commit/b74355e67420c138a0ac4ca31ea913667e52eba6)코드를 이해하고 도메인을 이해한다면 다음과 같이 로직을 수정할 수 있다. 이 기법들을 자유자재로 사용할 수 있다면 해당 도메인을 이해했다고 생각한다!리팩토링 (3) - 관점의 차이로 달라지는 추상화FileHandler를 바라보는 관점provider 인터페이스를 만들었는데, 구현체는 io에 provider 패키지를 만들어서 따로 분리 보관했다.io에 만드는 구현체는 파일을 읽는, 그런 내용이 중요한것이기 때문에 따로 보관했고,나중에 파일이 아니라 DB에서 읽는다면, 또 다른 패키지에서 인터페이스를 구현해서 갈아 끼우기만 하면된다. 핵사고날 아키텍쳐 - 포트(인터페이스)와 어댑터(구현체) [FileHandler를 Provider 개념으로 리팩토링](https://github.com/iamminseongKim/readable-code/commit/e33dadae25724a61cf52713cc1fcaea5ed81c40e)해당 챕터에선 추가적으로 개선할 방향을 찾고, 클린 아키텍쳐를 위한 새로운 사고를 열어 볼 수 있었다.기억하면 좋은 조언들능동적 읽기핵심 목표는 우리의 도메인 지식을 늘리는 것. 그리고 이전 작성자의 의도를 파악하는 것.오버 엔지니어링필요한 적정 수준보다 더 높은 수준의 엔지니어링은탄환은 없다클린 코드도 은탄환이 아니다.실무 : 2가지 사이의 줄다리기지속 가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물도구라는 것은, 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법이다.Day 7 미션 섹션 7에 나오는 StudyCafe를 이전 까지 배운 내용으로 스스로 리팩토링 하는 과제였다.아쉬운점은 내가 기한을 착각하고 마감일에 리팩토링을 시작했다는 점이고, 다행인건 그날이 한글날이라 그래도 시간이 좀 있었다.내가 이 미션을 하면서 중점적(순서)으로 생각한 점은 다음과 같다.의미단위로 공백 끊기큰 단위로 메서드 추출하기의존성 주입을 할 수 있는 부분을 찾기 (DIP)객체 단위로 추상화(추출)할게 있는지 찾기메서드의 책임이 올바른 위치에 있는지 판단하기일급 컬랙션 적용하기도메인을 이해해서 추가적인 개념을 도출하기해당 순서를 중요하게 생각하면서 리팩토링을 진행했다.그리고 다음날 깨끗한 정신으로 다시한번 보니깐 진짜 좀 별로였다 ㅋㅋ ㅠ 그래서 다음날 내가 추가한 부분은 다음과 같다. 기존에는 OutputHandler 문자를 출력하는 부분에서 계산을 해서 콘솔에 출력하였다.그래서 나는 PassCost라는 계산하는 객체를 만들어서 계산은 여기서 다 하고 출력할 때는 여기서 getter를 통해 값만 얻어 오도록 수정했다.[PassCost 만들기](https://github.com/iamminseongKim/readable-code/commit/4c01ec8cf31203349d3ebacadf5fe4cdf0299bb2#diff-2a97fd57d1b72b30fddf91a8cb3453fff97b46bab75082461641cfe8b4a491ff)전체 회고이번주를 끝으로 Readable Code 읽기 좋은 코드를 작성하는 사고법 강의가 끝났다.솔직히 시간이 좀 있었는데 TestCode강의를 시작하지 못한게 조금 아쉽긴 하다. 그래도 이번 강의를 통해 진짜 좋은 코드가 무엇인지, 물론 이 강의에서 나오는 개념들이 정답은 아닐지 몰라도해당 강의를 통해 사고를 넓일 수 있는 계기가 되어서 너무 좋았다. 메서드를 추상화 하는 행위가 이 강의를 듣기 전까지는 명확하게 인지하진 못했다. 그냥 남들이 하니깐, 조금 하고 솔직히 많이 안했다. 하지만 내가 추상화를 해보면서도 코드가 더 읽기 쉬워지고 도메인을 이해하고 있다는걸 느껴서 적극적으로 적용해보려고 한다. 다음주에는 공휴일이 없으니깐 출 퇴근 후에 빡세게 들어야한다 ㅠㅠ. 그래도 좀 열심히 들어서 여유로운 주말을 맞이하고 싶다~          

워밍업클럽클린코드

세지

워밍업클럽CS2기 2주차 미션

운영체제1. FIFO 스케줄링의 장단점이 뭔가요?장점은 단순하고, 직관적이다. 단점은 한 프로세스가 끝나야 다음 프로세스가 시작되어 실행기간이 짧고 늦게 도착한 프로세스는 실행기간이 길고 빨리 도착한 프로세스의 작업이 끝날 때까지 기다려야한한다.2. SJF를 사용하기 여러운 이유가 뭔가요?어떤 프로세스가 얼마나 실행될지 예측하기 힘들다. 또한, Burst Time이 짧은 프로세스가 계속 추가 되면 그만큼 지연 되고, Burst Time이 긴 프로세스는 오랫동안 실행되지 않을 수도 있기 때문이다.  3. RR 스케줄링에서 타임 슬라이스가 아주 작으면 어떤 문제가 발생할까요?컨텍스트 스위칭이 자주 일어나고 타임 슬라이스에서 처리되는 프로세스 처리량보다 컨텍스트 스위칭 처리량이 더 많아진다. 4. 운영체제가 MLFQ에서 CPU Bound Process와 I/O Bound Process를 어떻게 구분할까요?CPU 사용률과 처리량을 중요하게 생각하면 CPU Bound Process, 응답속도를 중요하게 생각하면 I/O Bound Process이다.5. 공유자원이란무엇인가요?프로세스 간 통신할 때 공동으로 이용하는 변수나 파일을 말한다. 각 프로세스의 접근 순서에 따라 결과가 달라질 수 있고 컨텍스트 스위칭으로 시분할 처리를 하기 때문에 어떤 프로세스가 먼저 실행되고 나중에 실행되는지 예측하기 힘들다.6. 교착상태에 빠질 수 있는 조건은 어떤 것들을 충족해야할까요?상호배제, 비선점, 점유와 대기, 원형대기가 있다.프로세스가 한 리소스를 점유했다면 다른 프로세스에게 공유되면 안되고(상호배제), 프로세스 A가 리소스를 점유하고 있을 때 프로세스 B가 리소스를 뺏을 수 없어야한다.(비선점) 어떤 프로세스가 리소스 A를 가지고 있는 상태에서 리소스 B를 원하는 상태여야하며(점유와 대기), 점유와 대기를 하는 프로세스들의 관계가 원형을 이루고 있어야한다. (원형대기) 자료구조와 알고리즘1. 재귀함수에서 기저조건을 만들지 않거나 잘못 설정했을 때 어떤 문제가 발생할 수 있나요?콜스택이라는 메모리 공간이 가득 차서 자동으로 종료될 때까지 함수를 실행한다. 2. 0부터 입력 n까지 홀수의 합을 더하는 재귀 함수를 만들어보세요.function sumOdd(n) { // 재귀 로직 if (n <= 0) return 0; if (n % 2 == 1) { return n + sumOdd(n - 1); } else { return sumOdd(n - 1); } } console.log(sumOdd(10)); // 25

웹 개발CS인프런워밍업클럽자료구조및알고리즘운영체제

ronnie

백엔드 클린코드, 테스트코드 회고 2주차

해당 회고는 'Readable Code : 읽기 좋은 코드를 작성하는 사고법' 강의에 대한 회고입니다.2주차 동안..강의 완강은 하지 못했지만 한 것들을 정리하고자 합니다.강의를 따라 리팩토링 해보면서 가장 느낀 점은 리팩토링은 정해진 답이 있지 않고 상황에 따라 유연한 생각이 뒷받침되어야 한다는 것이었습니다. 따라서 앞으로 코드를 칠 때 고려할 수 있는 아이템을 많이 만든다는 생각으로 수강했습니다. 배운 것들 객체와 고려할 점추상화된 객체의 구성비공개 필드 (데이터)비공개 로직 (기능 구현부)공개 메서드 선언부 → 외부에서 어떤 기능을 제공하는지 알 수 있게 해줌 고려할 점객체 생성 시 1개의 관심사로 책임이 정의되어 있는지 확인하자 메서드 추상화랑 비슷시간이 지나면서 객체의 요구사항이 변경되면서 책임이 변경될 수 있음.. 잘 변경해야 함 생성자, 정적 팩토리 메서드에서 유효성 검증이 가능 검증 로직도 같은 관심사로 취급될 수 있는지 확인 필요 setter 사용은 자제하고 getter는 웬만하면 자제데이터는 불변이 최고, 변해도 객체가 핸들링 가능해야 함외부에서 데이터 변경 요청을 해야 하는 경우 set같은 남용될만한 단어가 아닌 update와 같이 의도를 명확하게 드러내는 단어를 선택!getter는 반드시 필요한 경우에 추가Don't Tell, Ask 필드 수는 적을 수록 좋다필드 계산 기능이 있다면 메서드의 기능으로써 제공하자미리 가공하는 것이 성능 상 이점이 있다면 필드로 빼도 무방 객체 설계하기지뢰 찾기 게임을 객체 지향적으로 리팩토링!String 배열을 사용해서 구현하고 있던 지뢰 보드를 Cell이라는 객체를 만들어 지뢰 보드의 각 셀의 상태를 물어보는 방식으로 바꾸었다.리팩토링 중 몇가지...Cell 객체 생성정적 팩토리 메서드를 사용 모든 셀에 대해서 sign 확인하기Cell 객체에 대해 getSign을 해서 가져오고 싶지만 객체에 물어볼 수 있는지 확인 후 메서드를 만들었다보드 그리기반대로 보드를 그릴 때는 객체에게 부탁하는게 이상하다. 내가 그리면서 객체에게 부탁하는 것은 맞지 않다.이때는 과감하게 getter를 사용해서 객체에게 데이터를 받아서 그릴 때인 것이다. 지뢰 수 board와 지뢰 여부 board 적용Cell에 근처 지뢰 수 필드와 지뢰 여부 필드 추가한다, 생성자도 변경한다.그러면 팩토리 메서드도 변경되고.. 나머지 Cell을 리턴하는 메서드들은 어떻게 값을 주어야 할까??? Cell의 필드와 필드들이 가질 수 있는 상태에 대해 생각해 보았을 때Cell의 필드 : nearbyLandMineCount, isLandMineCell이 가질 수 있는 상태 : 깃발 있음/없음, 셀 열림/닫힘, 사용자가 확인함 여기서 깃발이 꽂힌 셀은 사용자가 지뢰가 있을 것을 예상해 닫힘과 동시에 확인한 셀이다.깃발을 꽂는 것을 생각했을 때 셀이 열렸다, 닫혔다와 사용자가 확인했다는 서로 개념이 다르다!깃발을 꽂는 경우 셀은 닫혀있지만 사용자가 확인한 셀이다.현재 게임종료 조건에 모든 셀이 열렸을 경우 끝내는 것이었지만 사실은 닫혀있어도 이미 확인된 셀이 존재했다. 따라서 현재 게임종료조건은 부적절하다!강의에서는 이런 고려들을 새롭게 알게된 도메인 지식이라고 했다.결론은..주변 지뢰 개수나 지뢰 여부 같은 경우 별도의 String기반 배열로 관리했기 때문에 해당 기능이 가능했다.(별도의 BOARD를 확인해 원래 BOARD에 값을 넣는 식)Cell이라는 데이터와 기능을 가지는 객체를 생성함으로써 사용자의 입력에 따라 Cell의 상태를 변화하는 로직으로 바꿔야 한다!!Cell로 인해 관련 데이터들이 캡슐화되어서 Cell 자체를 변경하는 것이 아닌 상태를 변경시켜 달라고 Cell 내부의 상태를 변경하는 식으로 변경해야 한다원래 Cell의 상태변경 후 Cell의 상태  board의 Cell객체가 가지는 정보에 따라 Cell의 sign 상태를 리턴하기Cell 객체는 상태를 보여주는 필드들을 관리했다. 이들에 기반해서 현재 Cell의 sign은 무엇인지 리턴해준다.  중간 점검스케줄 상 readable code 강의를 완강한 주에 다같이 모여 중간점검을 진행했습니다.전체적인 리뷰와 미션 피드백을 해주셨는데요, 좋은 질문과 답을 들을 수 있었습니다.들으면서 작성한 메모입니다.코드 짤 때 사용자와의 구체적인 인터렉션이 도메인에 직접적으로 영향을 미치는 것은 좋지 않다static메서드를 인스턴스 메서드로 대체할 수 없는 경우..는 인스턴스 메서드로 할 수 없는지 충분히 고려하자객체지향에서는 내부에 있는 객체의 상태를 확인하기 위해 bypass되는 메서드가 있을 수 밖에 없다충분한 설계에 대한 고민을 하다가 도메인을 새로 배우게 되는 계기가되고 그에 맞게 리팩토링을 하면된다totalPrice라는 변수는 view일까 domain일까.. 3:7로 domain 왜냐하면 totalPrice라는 변수가 단순 결과를 내는 것 외에도 여러 곳에서 쓰일 수 있다. 예를 들어 그 후에 합계금액에 대한 결제 로직을 진행할 때 도메인안에서 해당 변수가 쓰인다면? 도메인의 발전 방향을 예측했을 때 어디 두는 것이 쓰임이 편할지 고려하자중복을 정말 꼭 고려하자 유지보수 시 중복되는 만큼 작업을 해줘야 한다!다르게 처리해줘야 하는 부분이 있으면 왜 다르게 처리해주는지를 명확하게 보일 수 있는 것이 좋다!enum(정적)이나 config(동적)를 적용할 때 어디까지 적용하는 것이 좋을지 고려해보자null대신 NPE를 방지할 수 있는 emtpy 개념을 고려해볼 수 있다.. 만약 여러 군데에서 디비나 API를 통해 데이터를 가져와야 한다면 NPE는 절대 나면 안된다 마무리 회고앞으로 코드를 짤 때 유용한 자원이 되어줄 리소스를 모은 듯한 한 주였습니다.다음 주도 이런저런 준비로 할 일이 산더미지만 커리큘럼을 조금씩 잘 따라갔으면 좋겠습니다.다음 주도 화이팅!!

백엔드워밍업클린코드테스트코드

세지

워밍업클럽CS2기 2주차 발자국: 운영체제

운영체제 CPU 스케줄링SJF (Shortest Job First)Burst Time이 짧은 프로세스를 먼저 실행한다 SJF 문제어떤 프로세스가 얼마나 실행될지 예측하기 힘듦 => 종료시간 예측 어려움Burst Time이 긴 프로세스는 오랫동안 실행 안될 수 있음BUrst Time이 짧은 프로세스가 계속 추가되면 추가되는 만큼 지연됨 RR (Round Robin)프로세스에서 일정시간만큼 CPU를 할당하고 할당 시간이 지나면 강제로 다른 프로세스에게 일정시간만큼 CPU를 할당하고 강제로 CPU를 뺏긴 프로세스는 큐의 가장 뒷부분으로 밀려남 알고리즘 성능타임슬라이스(프로세스에게 할당하는 일정시간, 타임퀀텀이라고도 부름) 에 따라 다름타임 슬라이스가 작은 경우 컨텍스트 스위칭이 자주 일어나고 타임 슬라이스에서 처리되는 프로세스 처리량보다 컨텍스트 스위칭 처리량이 더 많아짐 => 오버헤드가 더 크다 FIFO와 Round Robin 비교평균 대기 시간이 비슷하다면FIFO가 더 효율적Round Robin은 컨텍스트 스위칭이 있어 컨텍스트 스위칭 시간이 더 추가됨 MLFQ (Multi Level Feedback Queue)RR의 업그레이드 된 알고리즘CPU 사용률과 I/O 사용률이 좋게 나오는 작은 크기의 타임 슬라이스를 선택함우선 순위를 가진 큐를 여러 개 준비한 후 우선순위가 클수록 타임 슬라이스가 작고 우선순위가 낮을수록 타임 슬라이스가 커짐타임 슬라이스 크기를 오버해서 CPU를 뺏기면 우선순위가 더 낮은 큐로 이동 => 최종적으로 무한대에 가까운 타임슬라이스를 할당 받아 FIFO처럼 연속적으로 작업을 마칠 수 있음.  프로세스 동기화프로세스 간 통신한 컴퓨터 내에서 프로세스 간 통신파일을 이용하는 방법: 통신하려는 프로세스들이 하나의 파일을 읽고 쓰는 것파이프를 이용하는 방법: 운영체제가 생성한 파이프를 이용해 데이터를 읽고 씀쓰레드를 이용한 방법한 프로세스 내에서 쓰레드 간 통신쓰레드의 데이터 영역에 있는 전역변수나 힙을 이용하면 통신가능네트워크를 이용한 방법운영체제 제공 소켓 통신RPC 통신공유자원과 임계구역공유자원프로세스 간 통신할 때 공동으로 이용하는 변수나 파일각 프로세스의 접근 순서에 따라 결과가 달라질 수 있음컨텍스트 스위칭으로 시분할 처리를 하므로 어떤 프로세스가 먼저 실행되는지 예측하기 어려움 => 연선 결과 예측 어려움 => 동기화 문제 발생임계구역여러프로세스가 동시에 사용하면 안되는 영역경쟁조건공유자원을 서로 사용하기 위해 경쟁하는 것상호배제메커니즘임계구역 문제 해결 방법요구사항임계영역엔 동시에 하나의 프로세스만 접근여러 요청에도 하나의 프로세스의 접근만 허용임계구역에 들어간 프로세스는 빠르게 나와야함세마포어상호배제 메커니즘 중 하나 모니터세마포어의 단점을 해결한 상호배제 메커니즘 데드락데드락이란?교착상태 (데드락)여러 프로세스가 서로 다른 프로세스가 끝나기를 기다리다가 아무 작업도 진행 못하는 상태공유 자원으로 인해 발생필요조건 (한 가지라도 충족되지 않으면 교착 상태가 발생하지 않음)상호배제 : 프로세스가 한 리소스를 점유했다면 다른 프로세스에게 공유되면 안됨비선점: 프로세스A가 리소스를 점유하고 있을 때 프로세스 B가 리소스를 뺏을 수 없어야함점유와 대기: 어떤 프로세스가 리소스 A를 가지고 있는 상태에서 리소스 B를 원하는 상태여야함원형대기 : 점유와 대기를 하는 프로세스들의 관계가 원형을 이루고 있음 데드락 해결교차상태 회피프로세스들에게 자원을 할당할 때 어느 정도 할당해야 교착 상태가 발생하는지 파악해서 교착 상태가 발생하지 않는 수준으로 할당함전체 자원의 수와 할당된 자원의 수로 안정상태와 불안정 상태로 나눔운영체제는 최대한 안정상태를 유지하려고 자원할당함불안정상태 사용 가능한 자원이 적어 프로세스 요청 예상 자원을 충족시키지 못하는 상태교착 상태에 빠질 확률 높음은행원 알고리즘(각 프로세스가 현재 요청이 예상되는 자원을 구함) 은 비용이 비싸고 비효율적임타이머 이용가벼운 교착 상태 검출에 이용일정 시점마다 체크 포인트를 만들어 작업을 저장하고 타임아웃으로 교착상태가 발생했다면 마지막으로 저장했던 체크 포인트로 롤백억울하게 종료되는 프로세스 발생할 수 있음자원 할당 그래프무거운 교착 상태 검출에 이용현재 운영체제에서 프로세스가 어떤 자원을 사용하는지 지켜보고 교착상태 발생 시 해결지속적으로 자원할당 그래프 유지 및 검사 -> 오버헤드 발생교착상태 일으킨 프로세스 강제종료 후 다시 실행 시 체크포인트로 롤백타이머 이용 시 발생했던 억울하게 종료되는 프로세스 발생 안 함메모리메모리 종류레지스터가장 빠른 기억 장소로 CPU에 위치컴퓨터가 꺼지면 데이터가 사라짐 => 휘발성 메모리CPU가 계산할 때 메인 메모리 값을 가져와서 계산하고 결과는 다시 메인 메모리에 저장시킴캐시레지스터와 속도 차이가 많이 나는 메인 메모리가 필요할 데이터를 예측해 가져온 데이터를 저장하는 곳레지스터와 메인 메모리 사이에 위치휘발성 메모리성능의 이유로 여러 개 있음.메인메모리속도는 빠르지만 비싸기 때문에 실행중인 프로그램만 올림휘발성 메모리보조저장장치비휘발성 메모리메모리와 주소주소메모리를 관리하기 위해 1바이트 크기로 구역을 나누고 숫자를 매김32bit보다 64bit가 한 번에 처리할 수 있는 양이 많아 속도가 빠름물리주소공간메모리를 컴퓨터에 연결하면 0x0번지부터 시작하는 주소공간논리주소공간사용자 입장에서 바라본 주소공간사용자는 물리주소를 몰라도 논리주소로 접근할 수 있음상대주소(논리주소)컴파일러는 0x0번지라고 가정해서 프로그램을 만듦절대주소(물리주소)메모리 관리자가 바라본 실제 프로그램이 올라간 번지경계레지스터하드웨어적으로 운영체제 공간과 사용자 공간을 나눔메모리 관리라는 사용자 프로세스가 경계 레지스터를 벗어났는지 검사하고 종료시킴재배치 레지스터프로그램의 시작 주소가 저장되어있음메모리 할당방식메모리 오버레이큰 프로그램을 잘라서 당장 실행시켜야할 부분만 메모리에 올리고 나머지는 용량이 큰 하드디스크의 스왑영역에 저장하는 기법스왑스왑영역에 있는 데이터 일부를 메모리로 가져오고 메모리에 있는 데이터를 스왑영역으로 옮김가변분할방식프로세스의 크기에 따라 메모리를 나누는 방식프로세스 크기에 맞게 할당되기 때문에 낭비 공간인 내부 단편화가 없음단점외부단편화: 연속되지 않은 공간은 새로운 프로세스에게 메모리를 할당할 수 없음외부단편화가 발생한 공간을 합쳐주는 조각모음을 하면 됨조각모음을 할 경우 프로세스를 일시중지 해야하고 메모리를 옮겨야해서 오버헤드 발생 고정분할방식비연속 메모리할당프로세스 크기와 상관없이 메모리를 정해진 크기로 나누는 방식구현이 간단하고 오버헤드가 없음단점내부단편화: 분할되는 크기를 조절해서 내부 단편화를 최소화버디시스템2의 승수로 메모리를 분할해 할당함가변분할방식과 고정분할방식을 합쳐 단점을 최소화함프로세스 크기에 따라 할당되는 메모리 크기가 달라짐외부 단편화를 방지하기 위해 메모리 공간을 확보하는 것이 간단함내부 단편화가 발생해도 많은 공간의 낭비가 발생하지 않음

웹 개발운영체제인프런워밍업클럽CS

ea04638

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

2주차  Day 6Iterator, Generator, Design Pattern 강의요약우와 여긴 진짜 처음 듣는 내용들이었다.Id와는 다른 방식으로 고유값을 부여하는 Symbol, 반복가능한 요소인지여부를 판단해주며 value, done값을 Iterator, 생성자 Generator, 많이 사용되는 설계의 권장방식을 설계화해둔 Design pattern 등에 대해 수강한다.Iterator : 반복 가능한 요소(Iterable)인지 여부를 판별해주며, next()를 통해 {value:'', done:''} 를 가진 객체를 반환한다는데. 그래서 이걸 어떻게 사용하고, 왜 만들어진지에 대한 설명이 아무것도 없어서 이해와 별개로 굉장히 의문이 들었다. 찾아보니 class, interface 등 ef6에서 등장하는 문법들에서도 작동이 가능하며, 모든 요소들을 순회하는 map, filter, 그리고 반복문인 for과 같은 역할을 수행한다고 한다.디자인 패턴 : 일반적으로 발생하는 문제를 해결하는 데에 사용할 수 있는 모범 사례. 이는 여러 사용으로 인해 검증되었으며, 의사소통의 경제성을 높이고, 이미 효율적으로 제작된 코드이기때문에 리팩토링 등 여러 상황에 대응이 유용하다.Singleton : 클래스의 인스턴스화를 하나의 객체로 제한, 다수가 하나의 메인 컨트롤러를 조정할 경우.Fatory : 특수 함수인 팩토리 함수를 이용하여 비슷한 객체object의 반복적 생성 가능.Mediator : A에서 B로, C에서 D로 등의 전송이 있을 때에, 모든 전송이 중재자 E를 거치는 패턴.스팸 메세지 등 중간처리 과정 가능.여러 대상이 상호간에 소통하지만, 서로에게 직접적으로 의존하지 않는다.Observer : 대상 A를 여러 존재 B, C, D, E 가 SNS의 팔로우 등을 통해 관찰하는 형태.게시자, 구독자 모델.Module : use strict 로 실행되며, 인라인 모듈 스크립트도 비동기로 처리 가능하다.strict 선언 시 해당 파일 안, 해당 모듈 안에 자신만의 모듈 레벨의 스코프가 생성되면서, 모듈 내부에서 선언한 변수, 함수를 다른 스크립트에서 접근할 수 없다. 이런 식으로 정보, 코드가 오염되는 것을 방지.모듈화를 통해 각 기능을 명확히 인지 가능.  과제비밀번호 생성조건대문자, 소문자, 숫자, 특수문자 네개의 체크박스를 제공한다.체크된 항목을 포함하는 랜덤한 비밀번호를 반환한다.이 체크박스는 특수문자 단독으로 체크될 수 없다.input창에 입력한 숫자를 글자 길이로 갖는 비밀번호를 반환한다.최소 5, 최대 70 값을 입력 가능하다.진행html 의 element들을 정의하고, 비밀번호 생성에 사용될 글자를 사전 정의한다.비밀번호 길이를 입력할 pwLength Inputnumber, smLetter, capLatter, Symbols 등 조건 여부를 확인하기 위한 각 checkbox위 요소들을 입력 후 생성 버튼 generateBtn을 클릭하도록 한다.사전정의 된 요소들을 활용하여, 화면상에서 "비밀번호 생성" 버튼을 누르면input에 입력된 숫자를 인식하여 pw의 길이로 정의.비밀번호 생성 조건 체크박스의 체크 여부들을 확인체크박스가 정상적으로 체크되어있는지, input에 입력된 숫자가 정상범위인지 확인한다.모두 정상범위라면 길이, 조건TF여부를 generatePassword() 함수에 인자로 넘긴다.generatePassword함수는 input과 option를 인자로 받으며, 각각 비밀번호 길이, 비밀번호 조건이 된다.비밀번호 조건에 따라 미리 생성한 'a~z', 'A~Z', '0~9' 등의 문자열을 다 합친뒤 (ex. abc...xyz123...789) 랜덤한 index를 뽑아 비밀번호 배열을 생성, 화면에 출력하려고 하였다.그러나 위처럼 완전 랜덤하게 뽑을 경우, 예를 들어 숫자, 소문자, 특수문자를 조건으로 설정하였음에도 숫자는 단 하나도 뽑히지 않고 소문자와 특수문자만 뽑혀, 그 둘만으로 이루어진 비밀번호가 생성될 수 있다. (조건이 제대로 반영되지 않음.)따라서 사전에 각 배열에서 최소 1개씩의 요소들을 미리 랜덤하게 선별하여 저장(ex. abc...xyz 중 하나, 123...789 중 하나)하고, 그 이후 완전 랜덤에 의한 비밀번호 배열을 생성한다.  Day 7프로젝트 만들기 강의요약스톱워치, 투두, 스프레드 시트 등을 만들며 학습한 JS 기능들을 활용한다.과제타이핑 테스트 앱조건예문을 제시한다.예문을 따라서 입력할 input창을 제시한다.입력한 input의 값 만큼 예문의 색이 녹색으로 변경된다.예문과 다르게 입력된 부분은 변경되지 않는다.input에 값이 입력되기 시작하면 time의 초 수가 1초씩 줄어든다.예문과 input값이 얼마나 일치하는지 정확도를 제시한다.한 예문을 전부 입력하면 다음 예문이 뜨며, 정확도는 100%로 리셋된다. (예문별 제시)반드시 전부 일치해야만 넘어가는 것이 아닌, 예문의 글자수 = 입력 글자수 가 되면 넘어간다.이는 정확도 계산을 위해.전체 예문을 전부 입력하면 전체 정확도 평균을 보여주며, CPM와 WPM을 제시한다. 진행하긴 했는데 제대로 한건지 모르겠다. 미리 유저가 따라칠 예문(문자열)이 저장된 배열을 준비한다.유저가 예문을 입력할 수 있는 input창을 준비한다. input의 value가 최초 추가되는 순간 타이머를 작동시킨다.isTime 등 변수를 미리 선언해놓고, 최초 입력시에 true로 변경시킨다.이미 isTime이 true인 상태에선 타이머를 새로 작동시키지 않는다.유저가 입력한 값과 유저가 보고있는 예문을 비교한다.input에 입력된 value인 string과 예문의 string을 배열화한다.(ex. ['s','t','r','i','n','g']) 각 index끼리 비교해가며 정확도를 비교한다. (input string의 길이가 예문보다 짧은 수 밖에 없으니, input string 길이만큼 조회한다.) 정확히 일치하는 값은 색상을 변경한다.정확히 일치하지 않는 값의 수를 세어 정확도를 계산할 때 차감한다. (100 - ((틀린 글자 수 / 전체 글자 수)*100)해당 input string과 예문 string의 배열의 총 길이 수가 서로 일치하면 다음 예문으로 넘어간다.반드시 정확도 100%로 넘어갈 필요는 없다. 각 예문마다 정확도는 초기화하되, 각 예문의 정확도를 별도로 저장해둔다.모든 예문을 입력했다면. input창을 없애고 end 표시를 띄운다.총 소모된 시간, 각 예문의 정확도, 전체 예문의 글자 수 등을 불러온다.WPM 과 CPM을 계산하여 화면에 출력한다.  Day 9리액트 기본 및 Todo 앱 만들기 강의요약리액트란 SPA를 구현 가능한 라이브러리로, 화면을 구성하는 각 요소를 컴포넌트로 구성한다.브라우저, 가상돔 등 리액트가 화면을 그리는 과정을 설명하는 이론을 배운다.리액트 프로젝트를 생성해주는 Create react app 을 설치한다.리액트를 활용할 때에 사용하게 되는 JSX, State 등을 배우고 활용하며 Todo App 을 배운다.과제예산 앱조건항목명, 가격을 입력할 수 있는 두개의 input과 추가버튼을 제공한다.값 입력 후 추가버튼을 클릭하면 list에 항목명, 가격을 추가한다.list에 존재하는 가격들을 더해 하단에 총액을 제시한다.list에 존재하는 항목에 수정버튼을 누르면, input에 항목명, 가격이 입력된다.입력된 상태에서 값을 수정한 뒤 다시 추가버튼을 누르면 수정된 값으로 list에 추가된다.list에 존재하는 항목에 대해 삭제버튼을 누르면 해당 값이 list에서 삭제된다. 진행 state, setState정의를 통해 추가 할 예산(제품명, 가격), 수정 할 예산 (제품명, 가격) 관리를 진행한다.추가한 예산 목록은 items라는 배열 안에 {} 형식으로 추가하고, 배열의 수만큼 li를 return하며, 각 배열 요소에서 제품명, 제품 가격 등을 불러와 자동생성하도록 한다.items안의 모든 가격 요소를 더해 totalPrice를 계산하도록 한다.하지만 추가, 삭제, 수정에 의한 반영이 실시간으로 되어야함을 주의해야했다.최초 작성 시 수정, 삭제, 추가가 한박자 느렸는데, (새로 뭔가 작동을 해주어야 했음.) price계산 함수를 따로 두고, 계산값을 setTotalPrice(계산값)으로 반영하다가, setTotalPrice((prev) => prev + Number(price)); 코드로 작성하여 totlaPrice set을 prev를 통해 바로 실행시킴으로써 해결함.   회고 리액트 첫 과제라 state개념만 알면 크게 어렵지 않았다. totalPrice처럼 실시간 반영 순서가 좀 헷갈렸다.이번과제는 단순해서 cdn을 통해 리액트를 불러왔다. 업로드하기 쉬우려고...   Day 10리액트로 Netflix 만들기 강의요약create-react-app을 통해 본격 프로젝트를 진행한다.api, fetch, async, await 등을 활용하여 서버에서 데이터를 전해받고, 이를 확인한다.전달받은 데이터를 가공하여 ui상에 구현한다. state를 통해 상태를 관리하고, 이를 활용하여 로그인여부, 모달open 등을 구현한다.input의 value를 실시간으로 반영하여 검색기능을 구현한다.react-router-dom 의 navigation 을 통해 SPA안에서도 url을 통한 페이지 이동을 구현한다. 과제disney plus 앱 만들기조건Api를 통해 영화, 프로그램에 대한 정보를 서버에서 받아올 것.대시보드에서 로그인 시 메인화면으로 이동검색창에 값 입력 시 실시간 반영하여 검색결과 출력썸네일 클릭 시 모달창을 통해 썸네일이미지, 제목, 개봉일, 작품설명을 출력. 진행사실 강의영상의 netflix만들기 과정을 다시한번 따라하면 그대로 구현 가능해서, 학습하는 기분으로 작성하였다. 다만, 구글 api와 useDebouce부터 말썽이 발생했는데, 정정하려면 발자국 쓸 시간이 없을 것 같아... 일단 두 부분은 빼고 구현하였다. react-router-dom을 통해 각 페이지를 구분한다.Navigation 기능을 통해 Dashboard, Main, Search 페이지를 이동한다.공통 레이아웃으로 Nav.js, Footer.js 를 둔다.대시보드Dashboard/index.js 로 구성된다.로그인 버튼을 누르면 메인페이지로 이동한다. 이 이동은 react-router-dom의 navigation 기능을 이용한다.두 페이지를 나누는 분기는 로그인 여부.로그인 여부는 isLogin state로 저장하며, isLogin이 false경우 url을 / 가 되도록 처리한다.Nav.js에 위치한 로그인 버튼, 혹은 아바타 아이콘을 클릭 했을때 isLogin = !isLogin 되도록 처리한다.메인페이지Components/ Banner.js, Row.js, MovieModal/index.js로 구성된다.랜덤한 영화가 상단 배너로 설정되고, 서버에서 전달받은 영화 썸네일, 영상 링크, 제목, 설명을 출력한다.Row.js component를 반복적으로 사용하되, 넘기는 props를 변경하여 다른 카테고리의 영화들을 불러온다.영화 썸네일을 클릭하면 영상 썸네일, 제목, 설명, 개봉일, 평점이 담긴 모달창을 띄운다.Modal의 상태를 관리하는 state를 생성하여, 영상 썸네일 클릭시 true로 setState시킨다.modal state가 true일 시 <Modal/> 창을 화면에 출력한다.해당 컴포넌트를 불러올 때, props를 통해 선택된 영화의 정보를 전달.전달된 정보를 통해 데이터를 불러올 영화가 무엇인지 알게된다.nav 에 input을 입력하여 검색페이지로 이동한다.이 이동은 react-router-dom의 navigation 기능을 이용한다.메인 <-> 검색페이지 간의 이동은 검색input에 값이 존재하느냐 여부. 검색input에 값이 존재한다면 url을 /search 로 이동시키도록 한다.검색페이지input에 입력한 값을 검색어로, 일치하는 영상 목록을 띄운다.검색결과가 없다면 안내 문구를 띄운다.검색결과가 있다면 메인페이지의 row처럼 해당 영화 목록을 띄운다.영화 썸네일을 클릭하면 메인페이지에서와 마찬가지로 영화 정보가 담긴 Modal을 띄운다.Modal을 띄우는 과정은 메인페이지와 같다.   이번엔 저도 코드박스나 이미지를 넣어보려고했는데, 코드박스 안에서 탭도 안먹고 const 정의 인식도 못하고 다 깨먹어버리길래 너무 힘들어서 다 뺐습니다... 덕분에 코드 입력을 예정에 두고 1번, 코드 입력을 포기하고 1번 총 두번을 작성해서 좀 급하고.. 중구난방이고...모르는 것도 많고, 헤멘 것도 많은 주간이었습니다.create-react-app을 통해 만든 프로젝트는 배포는 무리여도 빌드까지 해서 개발코드랑 같이 올리고 싶었는데, 아니나 다를까 역시 빈페이지 오류가 뜨더라구요... 결국 개발코드 그대로 올렸습니다.이번주까진 그래도 진도에 맞출 수 있었는데, 다음주는 좀 걱정이 됩니다. 일단 부딪혀 보겠습니다. 아자아자..  

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

박민지

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

2주차에는 계속해 컴포넌트를 만들었다.피그마를 제대로 처음 배우게 된 건 이번이 처음이었고 그 전까지는 주먹구구식으로 여러 회사의 디자인 시스템 피그마 파일을 뜯어보면서 공부했는데 이미 완성된 파일을 뜯어보면서 하기에는 내 지식으로 잘 안보이는 부분도 많았고 효율적으로 만드는 방식이 무엇인지 알기 힘들었다.하지만 이번에는 강의를 따라하며 컴포넌트에 베리어블을 적용하면서 만들어 보니 내가 그동안 만들었던 컴포넌트에서 어떤 부분이 비효율적이었는지 알수 있었다.특히 베리어블을 적용하지 않고 매우 원시적으로(!) 만들곤 했는데 계속해 강의와 함께 베리어블 적용을 반복하니 기존에 만들었던 컴포넌트를 보아도 내가 어떤 부분을 어떻게 적용할 수 있는지 머릿속에 그려지는 부분이 제일 좋았다. 그리고 한 번 적용 하면 작업속도도 빨라져 매우 효율적이라 생각했다.포트폴리오에서는 컴포넌트를 어떻게 만들었는지 까지는 보지 않지만 나중에 실무에서 하게되면 매우 도움이 되리라는 생각이 들었다. 사이드 프로젝트를 진행할 때 제일 고생했던 컴포넌트가 아코디언과 툴팁이었는데 이번 기회에 제대로 만들어보면서 어떻게 적용할 수 있는지, 그리고 다른 팀원들에게 문서화 하며 어떻게 펼쳐 보여줄 수 있는지 알게되었다.또 테이블을 구성할때 하나하나 말하자면 노가다식으로 적용해 만들곤했는데 이번에 배우면서 이렇게 간단하고 쉬운 방법이 있다는 걸 알게되었고 매우 유용했다. 그리고 여러 브랜드의 디자인 시스템 파일을 보면서 디바이더를 어떻게 만들어야 할지 잘 몰랐는데 이 기회에 배우게 되어서 도움이 되었다. 그리고 토요일에 진행 된 챗GPT를 통한 디자인 시스템 문서화는 도움 되는 플러그인을 알게 된것 만으로도 좋았다.이전에도 여러 목적으로 챗GPT를 사용했기에 이런 방식으로 데이터를 얻는 건 그렇게 낯선 방식은 아니었지만 프롬포트를 어떻게 구성해야 하는지에 관한 정보가 매우 유용했다. 그 전까지는 하나하나 학습가면서 사용했는데 한꺼번에 물어보면 된다는 걸 이제야 배웠다 ^^;;;솔직히 주변에서 이런 인터넷 강의를 굳이 왜 듣냐, 독학하면 되지 않냐는 말을 많이 들어 결제하면서도 반신반의 했는데 (그냥 손해볼거는 없다고 생각을 했다.) 듣기를 정말 잘했다고 강의듣는 내내 생각했다. 그리고 워밍업 클럽 덕분에 제대로 익히고 있다.빨리 실무에 적용할 날이 오면 좋겠다. 잘한점 - 시간 맞춰서 제출.잘못한점 - 정리를 못했다.반성 - 미루지 말고 강의를 끝낸 뒤 다른 걸 하자. 

UX/UI피그마워밍업클럽컴포넌트디자인시스템

wisehero

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

이번 주차에는 다음과 같은 내용을 수강했습니다. 코드 다듬기클린코드 리팩토링 실습 기억하기 좋은 조언들 1주차와는 달리 스터디카페 이용권을 예시로 진행을 했는데요.  코드 다듬기코드 다듬기에서는 주석의 양면성이 가장 인상 깊었습니다. 주석은 클린 코드에서 가장 많은 논란이 있는 주제인데요. 최근에 개인적으로 느끼기에는 주석을 사용하는 걸 무조건적으로 죄악시하는 풍조가 있다고 느꼈고, 오히려 주석을 달지 않아서 문제가 생기는 경우가 많았습니다. 개인적으로 주석을 무조건적으로 지양하기보다는 과연 내가 주석이 필요 없을 정도로 남이 보기에 쉽게 이해할 수 있는 코드를 작성했는지를 먼저 스스로에게 되묻는 자세가 필요하다고 생각합니다. 결국 내가 짠 코드도 누군가가 보기에는 어려울 수도 있고 꽤나 코드의 클린함이라는게 자의적인 판단이 많이 들어갈 수 있는 영역이라고 생각하기 때문입니다. 변수나 메서드의 나열 순서 파트에서도 좋은 팁을 얻었습니다. 늘 private 메서드를 따로 빼고나서 걱정이었는데 우빈님께서 사용하시는 상태의 변경 / 판별 / 값 조회 순서를 따르면 좋을 것 같다는 생각을 했습니다.  리팩토링 연습리팩토링 실습 편에서는 지뢰찾기에서 배웠던 것들을 스터디카페 이용권을 발급하는 프로그램을 리팩토링했는데요. 우빈님께서 접근하는 방식 자체가 굉장히 좋았습니다. 처음엔 중복을 제거하는 관점에서 리팩토링을 수행하고, 일급 컬렉션을 적용할 수 있는 부분을 찾고, 객체의 책임을 분리하고, 새로운 도메인 개념을 도출해내는 단계적인 절차를 밟아가면서 리팩토링을 하는 법을 배울 수 있었습니다. 저는 이전에 이러한 명확한 관점 없이 리팩토링을 수행했던 경험이 있던지라 하나의 커밋에 너무 여러 수정과정이 섞여서 정확히 무얼 했는지 스스로도 알아보기 힘들었는데, 새로운 접근법을 얻어간다는 느낌을 받아 좋았습니다. 기억하면 좋은 조언들기억하면 좋은 조언들에서는 오버 엔지니어링을 경계하자는 챕터가 가장 인상 깊었습니다. 사실 얼마전 만든 백오피스 프로그램에서 너무 이르게 추상화한 것 때문에 오히려 새로운 기능을 구현하는 것보다 기존 코드를 고치는데 시간이 너무 많이 들었던 경험이 있습니다. 단순한 문제를 괜히 복잡하게 풀어보려는 욕심이 앞섰기 때문에 발생한 문제였는데, 구체적인 구현체들을 미리 만든다음에 그 구체들로부터 추상화할 수 있는 부분을 뽑아내어 추상화를 하는 것이 더 낫다는 것을 다시 한번 깨달았습니다.  금주에는 과제도 있었고 지뢰찾기에서 배운 것을 적용도 해보는 시간이었는데 개인적으로 코드를 작성하는 시간에 건강 이슈로 인해서 스스로 고민하고 코드를 작성하는 과정이 빈약했습니다. 그래서 과제도 사실 거의 제 생각은 없은 채로 제출했는데 좀 부끄러웠습니다. 최근에는 많이 좋아져서 다시 심신을 가다듬고 테스트 코드 주차에는 이를 만회해보도록 노력해야겠다는 생각을 했습니다. 

Rojojun

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

1주일간의 학습 회고테스트코드의 강의를 듣기 시작하였다.80% 정도 듣게 되었고, 항상 회사에서 테스트 코드에 대한 필요성을 느끼며 팀원 몇 명과 함께 테스트 코드를 작성하고 있었는데, 팀원이 추천한 강의로 항상 이 강의의 개념에 대해서 적용하도록 도와주었다...그 때 보라할 때 볼걸 그랬다...ㅠㅠㅠ 코드 리뷰를 받다강의를 일찍 끝내서 숙제를 강사님에게 빨리 제출하였다.내가 잘해서 검사를 맡은게 아니라 코드가 형편 없어도 200명 앞에서 내 코드는 이래요~~!! 하는 자신감을 보여줘야한다고 생각해서, 코드 리뷰를 신청했다. 일단, 결론은 더 잘하기 위한 동기부여가 되었다.  동기부여가 왜 되었을까?일단 나의 지적사항은 두 가지 그리고 질문도 두 가지였다. 첫번째, 내가 잘해서 지적이 두 가지라고 생각하지 않는다.두번째, 나는 못하니깐 많은 사람들 앞에서 까이고 싶다. 그래야만 더 잘하려고 노력하기 때문이다.세번째, 질문... 내가 고민하는 것들은 많은 사람들이 고민하는 거라는 것을 느꼈다. 첫번째 지적 사항public enum StudyCafePassType { ... public static StudyCafePassType sendTypeBy(String userInput) { try { int inputCode = Integer.parseInt(userInput); return Arrays.stream(values()) .filter(type -> type.inputCode == inputCode) .findFirst() .orElseThrow(() -> new AppException("잘못된 입력입니다.")); } catch (NumberFormatException e) { throw new AppException("입력값은 숫자가 되어야합니다."); } } }이러한 코드를 enum에서 작성하였다.일단, 작성하면서도 코드 스멜을 느꼈다.'비즈니스 로직에 대해서 Enum이 너무 깊게 연관하는게 아닐까?'위의 고민을 가지면서, 만들었는데 아니나 다를까 강사님은 역할과 책임을 이야기 하면서 이 부분의 코드를 지적하였다. 참고로 ㅋㅋ 같이 워밍업 클럽 참여하는 동료도 회사내 클린코드 적용하면서 이런식으로 적용했는데... 그 날 당일에 나는 저 코드는 문제 있는거 같다고 계속해서 지적했다! 두번째 지적 사항은... 그냥 실수다... static 남발인데... 이게 가끔씩 ㅋㅋ 귀찮아서 static 쓰는 경우가 있는데... 이 부분은 진짜 화끈거렸다... 이번 주 학습에서 잘한 점이번 주 학습에서 내가 스스로 잘했다고 생각한 부분은 숙제를 하면서 나 스스로 생각을 많이 했다는 것이다.물론, 코드에서 좋은 것들을 가져와서 쓸 수 있지만, 내가 하는거고 나의 공부기 때문에 강사님의 코드 스타일 포맷을 그대로 따라가지 않으려고 노력했었다. 아쉬웠던 점: 리뷰를 하자성격이라 그런가... 숙제나 그런거를 낼 때는 그냥 리뷰를 안한다...그러다가 이번처럼 참 ㅋㅋ 어이없는 실수를 해서 지적할 받을 때가 있다... 이것을 그냥 '아, 이건 실수~' 하고 무시하는게 아니라 이게 실력이다 ㅠㅠ...  회사 팀원들과의 협업팀 동료 중 한 분이 이번에 인프런 워밍업 클럽을 들으면서 클린코드를 적용하였다.정말, 너무 좋았고 같이 듣는 동료와 함께 세명이서 그 코드에 대해서 토론하고 좋은 방향 등에 대해서 이야기를 하였다.배움이, 단지 배움이 아니라 실제적으로 적용되서 살아있는 공부가 되었다.앞으로도 이러한 스터디를 하고 이러한 문화를 팀동료들과 계속해서 이뤄가고 싶다.그러려면 더 잘해야겠지 ㅠㅠ...

백엔드백엔드클린코드자바스프링

성규

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

주석의사 결정의 히스토리를 코드로 표현할 수 없을 때, 주석으로 상세하게 설명자주 변하는 정보는 지양코드도 변경되면 주석도 함께 변경좋은 주석?우리가 가진 모든 표현 방법을 동원해 코드에 의도를 녹여내고그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석변수와 메서드의 나열 순서정답은 없지만 중복이 없을 수 있게 정렬변수사용하는 순서대로사용하는 곳 근처메서드공개 메서드를 상단에중요도, 종류별로 그룹화상태 변경 >> 판별 ≥ 조회나열 순서로도 의도와 정보를 전달 할 수 있는 것!!!코드를 보는 사람이 인지하기 쉽게!!패키지 나누기패키지는 문맥으로써의 정보를 제공할 수 있다.패키지는 적당(?)하게 나눠야 좋다리펙토링null 을 반환하는 것은 nullPointException 을 발생시키기 때문에 안티패턴파라미터로 Optional 을 보내는 것도 안티 패턴Optional 이 자체가 nullOptional 에 들어있는 객체가 nullOptional 에 들어있는 객체가 존재 한다 받는 입장에서는 위 3가지 처리를 해야함Optional.ifPresentOrElse 앞에는 값이 있을 때, 뒤에는 값이 없을 때 액션을 지정할 수 있음optionalLockerPass.ifPresentOrElse( lockerPass -> outputHandler.showPassOrderSummary(selectedPass, lockerPass), () -> outputHandler.showPassOrderSummary(selectedPass) ); Git Commit 은 짧게 짧게작업을 쪼개서 유지 관리에 용이 해짐IO 통합세트로 묶여서 작업되는 부분들을 합쳐서 관리하는 것일급 컬렉션일급 컬렉션은 리스트를 감싸서 컬렉션 내부에서 리스트를 추상화(제어.. 등등)을 할 수 있음display 책임Order 추가헥사고날 아키텍쳐포트와 어댑터포트 : 인터페이스, 스펙!어댑터 : 포트에 맞는 구현체능동적 읽기목표 : 우리의 도메인 지식을 늘리는 것!!오버 엔지니어링필요한 수준보다 더 높은 수준의 엔지니어링!구현체가 하나인 인터페이스구현체를 수정할 때마다 인터페이스도 수정해야함코드 탐색에 영향, 어플리케이션이 비대해 짐너무 이른 추상화정보가 숨겨지기 때문에 복잡도가 높아진다다른 개발자들이 의도를 파악하기 어렵다.클린코드는 절대적인 것이 아니다.미래에 잘 고치도록 할 수 있는 코드 센스가 필요!결국 클린코드의 사고법을 기반으로 결정!지속가능한 소프트웨어의 품질 vs 기술부채를 안고 가는 빠른 결과물

백엔드

전석희

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

2주차때 배운 것입력 컴포넌트 (버튼, 컨트롤, 라벨, 텍스트필드, 텍스트박스, 셀렉트)디스플레이 컴포넌트 (아바타, 아코디언, 뱃지, 툴팁, 구분선, 인터랙티브 칩, 상태칩, 카드, 테이블)피드백 컴포넌트 (토스트, 로딩 스피너, 스켈레톤 로더, 슬롯컴포넌트를 활용해 모달 제작)Slot 컴포넌트를 활용해서 모달을 만드는 것을 알게된 점이 좋았다.예전에 회사 다닐 때에는 필요한 모달 다 만들어놨는데.. 저렇게 컴포넌트를 만들어서 활용할 수 있다는 것을 알게되어서 좋았던 것 같다.그리고 오늘 들었던 온라인세션에서도 좋은 인사이트를 얻을 수 있었다.AI 활용을 부끄럽게도 잘 안했었는데 (지피티로.. 자소서나 그런거만 물어봤었다) 지피티를 통해 디자인 문서 초안을 세울 수 있다는게 좋은 것 같았다. 그리고 다른 사람들의 의견을 조금이나마 알 수 있는 시간이 있어서 좋았고... 몰랐던 디자인시스템을 알게되었던 점도 되게 좋았다. 역시 다른 이들의 생각을 들어야 인사이트를 얻을 수 있구나하는 시간이어서 너무 좋았다 아쉬웠던 점또 시간 계산을 잘못했었다는 점..?ㅋㅋㅋㅋㅋ 아침에.. 일찍 일어나는게 쉽지 않다. 또한 아침에 바로 강의를 듣는 것도 쉽지 않았다.이래저래 지원서 계속 넣는 것을 도전하기 위해 다른 곳에 신경 쓰다보니 강의 듣고 미션 수행하는데에 시간 분배를 못했던 것 같다. 얼마 안남았으니 다음주에는 꼭 일찍 일어나서 아침에 강의와 미션을 수행하는 것으로...! 다음에 시도할 점온라인 세션에서 들었던 플러그인 사용해서 문서 정리하기!개인 드래프트에 다시 만들어보면서 복습해보기 3주차도 열심히 미션 밀리지 않게 매일매일 강의 들어야겠다.+인프런 워밍업 클럽으로 하니까 뭔가 매일 공부하게되고... 열심히 사는 것 같은 기분이 들어서 좋은 것 같다 ㅋㅋㅋㅋ

UX/UI디자인시스템워밍업클럽피그마UXUI컴포넌트

rhrud0412

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

인프런 워밍업 클럽 2기 2주차커리큘럼을 따라서 꾸준하게 강의 수강하기를 목표로 함.‘강의를  마냥 따라가는게 아니라 이해하면서 미션 수행해보자’라는 마음가짐을 가지고 시작 2주차 학습 내용입력 컴포넌트 만들기(Label&control group, text field&text area, select&dropdown)디스플레이 컴포넌트 만들기(avatar, accordion, badge, tooltips, divider, chips, basic cards, table)피드백 컴포넌트 만들기(alert, toast, skeleton loader, progress bar, slot&modal) 잘한점헷갈리거나 안되는 부분이 생겨도 포기하기 않고 될때까지 시도함 모르는 부분은 질문해서 선생님 피드백에 따라 수정해보면서 강의를 따라감. 이번주 커리큘럼에 따라 미션 제출까지 완료함. 아쉬운 점컴포넌트의 instance를 조립 과정에서 일부 오토레아웃의 Fill, Hug, Fix의 설정이 잘못되어 있어서 수정함.Absolute poison된 프레임의 Constraint부분에서 헷갈리는 등 부분 부분에서 예상대로 되지 않는 점에서 아쉬움을 느낌. 전체 회고 및 다음주 목표컴포넌트의 반복학습을 하다 보니 어느 정도 익숙해졌다고 생각했는데, 막상 하다보니 생각보다 시간이 오래걸렸다....잘못된 부분이 눈에 보이니 답답하기도 하고, 한편으론 온전히 내것으로 만들고 싶다는 욕심이 생겼다.다음 주는 '이번 주에 못했던 부분은 완전히 숙지하고 다음 진도 따라가기'를 목표로 !!!

UX/UIfigma디자인시스템boldUX워밍업클럽프로덕트디자인

김예지

[인프런 워밍업 스터디 클럽 2기 FE] 2주차 과제 - 디즈니 플러스 앱

로그인 전 화면 디즈니 플러스 앱GitHub : 09-disneypluGIF 파일 목록이 너무 커서 글에 올라가지 않아 md 파일에 동작하는 GIF를 추가해 두었다.기능 목록TMDb API 데이터 받아오기 검색 후 해당 아이템 클릭 시 영화 포스터 보여주기영화 클릭 시 모달 오픈슬라이드구글 로그인 구현하기TMDb API 데이터api로 데이터를 받아오는 방법은 강의에서 넷플릭스 앱 만들기에서 배웠던 걸 그대로 사용했다.axios.js 에서 baseURL을 설정하고 나머지 데이터를 받아올 주소도 requests에 설정해준다.Google OAuth2 구글 로그인구글 로그인 구현하는 방법은 검색하면 친절하게 설명되어 있는 블로그 글들이 많아 따라했다.api 키는 .env 파일에 담아서 커밋했을 때 깃허브에 올라가지 않게 한다.const [loggedIn, setLoggedIn] = useState(false); const [user, setUser] = useState(null); const CLIENT_ID = process.env.REACT_APP_GOOGLE_ID; const CLIENT_SECRET = process.env.REACT_APP_GOOGLE_PW; const REDIRECT_URI = 'http://localhost:3000'; const SCOPE = process.env.REACT_APP_GOOGLE_SCOPE;loggedIn : 사용자가 로그인 했는지 여부를 저장. 기본 값 falseuser : 사용자 정보 저장. 로그인 되면 사용자 정보가 저장된다.CLIENT_ID CLIENT_SECRET env 파일에 있는 클라이언트ID와 비밀번호를 가져온다.REDIRECT_URI : OAuth2 인증 후, 리다이렉션할 URL 로컬 개발 환경이라 http://localhost:3000으로 설정.로그인 const handleGoogleLogin = () => { const googleOAuthUrl = `https://accounts.google.com/o/oauth2/auth?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&response_type=code&scope=${SCOPE}`; window.location.href = googleOAuthUrl; };사용자가 로그인 버튼을 클릭했을 때 호출하는 함수.googleOAuthUrl OAuth2 인증 URL을 생성하고, 그 URL로 이동. URL로 이동하면 Google 로그인 페이지가 열리고, 사용자가 Google 계정으로 로그인하게 된다.로그아웃 const handleLogout = () => { // 로그아웃 시 로컬 스토리지에서 사용자 정보 삭제 localStorage.removeItem('user'); localStorage.removeItem('access_token'); setUser(null); setLoggedIn(false); };로그아웃 버튼을 누르면 호출된다. 로컬스토리지에 저장된 사용자 정보와 액세스 토큰을 삭제하고 상태를 초기화하여 로그아웃 상태로 만든다.로그인 후 화면<Nav user={user} onLogout={onLogout} />로그인할때 받은 유저 정보를 통해 오른쪽 상단에 구글 프로필 이미지를 넣어줬다.동영상 배너<GenreContainer> {items.map((item, index) => ( <GenreContainerBox key={index} onMouseEnter={() => handleMouseEnter(index)} onMouseLeave={() => handleMouseLeave(index)} > <div> <GenreContainerVideo ref={(el) => (videoRefs.current[index] = el)} playsInline loop muted data-testid='brand-set-video' > <source src={item.videoSrc} type='video/mp4' data-testid='brand-set-video-source' /> </GenreContainerVideo> <GenreContainerBoxImg src={item.imgSrc} alt='' /> </div> </GenreContainerBox> ))} </GenreContainer>동영상/이미지를 다 넣으니 코드가 너무 길어져서 영상, 이미지 주소는 items라는 배열에 담아서 사용했다.const videoRefs = useRef([]); const handleMouseEnter = (index) => { if (videoRefs.current[index]) { videoRefs.current[index].play(); } }; const handleMouseLeave = (index) => { if (videoRefs.current[index]) { videoRefs.current[index].pause(); } }; handleMouseEnter, handleMouseLeave 마우스 이벤트를 사용해 hover 상태일 때 동영상을 재생시키고 일시 정지 시켰다. 동영상이 보였다 안 보이는 하는 건 css에서 opacity로 처리했다.처음에 다 만들고 동작 상태를 확인하다가 다른 페이지에서 메인으로 넘어왔을 때 로그인 상태가 유지가 되지 않아 유저 정보를 로컬 스토리지에 저장해서 구분했다. 로컬 스토리지에 이런 정보를 저장해도 되는 건지 모르겠지만.. 이런 로그인 연동에 대해 좀 더 알아봐야겠다.디즈니 메인 화면 보고 싶은데 볼 수가 없어서 한 달 정도 디즈니 플러스 결제를 했다. 스터디가 끝나면 재밌는 영화보는 시간을 가져야겠다.

gusdnchl7144

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

 강의 수강 Section6) 코드 다듬기좋은 주석인란? -우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여냈음에도 불구하고 전달해야할 정보가 남았을때 주석을 사용해야 함. 주석을 사용하면 코드가 아닌 주석에 의존한다는 것을 알아야 함   변수와 메서드의 나열 순서- 변수는 사용하는 순서대로 나열- 메서드는 1순위가 공개 메서드, 2순위가 비공개 메서드 순으로 나열     Intellij IDE 활용- 코드 포맷 정렬 단축키 : Ctrl + ALT + L- Sonarlint : 오류, 버그, 스타일 등을 알려주어 문제점 개선을 도와주는 Plugin- .editorConfig : 확장자마다 스타일을 다르게 줄수 있게 도와주는 설정파일 Section7) 리팩토링 연습리팩토링 포인트- 추상화 레벨 : 중복 제거, 메서드 추출, 객체에 메시지 보내기- 객체의 책임과 응집도 : IO 통합, 일급 컬렉션, display()의 책임, Order 객체- 관점의 차이로 달라지는 추상화 : 구현에 초점을 맞춘 추상화 VS 도메인 개념에 초점을 맞춘 추상화 Section8) 기억하면 좋은 조언들능동적 읽기- 복잡하거나 엉망인 코드를 읽고 이해하려 할때, 리팩토링하면서 읽기-> 공백으로 단락 구분-> 주석으로 이해한 내용 표기하며 읽기-> 메서드와 객체로 추상화 해보기- 핵심 목표는 우리의 도메인 지식을 늘리는 것이고, 이전 작성자의 의도를 파악하는 것.2. 오버 엔지니어링- 필요한 적정 수준보다 더 높은 수준의 엔지니어링을 말함-> ex) 구현체가 하나인 인터페이스 : 구현체를 수정할 때마다 인터페이스도 수정해야 함.-> ex) 너무 이른 추상화 : 정보가 숨겨지기 때문에 복잡도가 높아지고, 후대 개발자들이 선대의 의도를 파악하기가 어려움  3. 은탄환은 없다- 항상 정답인 기술은 없음.- 오버 엔지니어링이 되더라도 한계까지 리팩토링 연습을 해보고, 적정 수준, 적정 시점을 깨닫기가 필요. 회고)2주차까지 쉼 없이 달려왔는데, readable code 강의가 끝난것이 끝이 아니라, 새로운 시작인 것 같다.이 강의를 통해 클린코드로 가는 발검을을 한 발자국 내딛은것 같다. 클린코드 책도 한번 읽어봐야 겠다는 생각도 들었다.3주차부터 Practical Testing 강의가 시작되는데, 테스트 코드 강의도 빠짐없이 수강하여 포기하지 않고 스터디를 끝까지 이어 나갈 것이다. 미션Day7-Mission3) '스터디 카페 이용권 선택 시스템' 프로젝트 리팩토링리팩토링 진행 내용코드 중복 제거- if문 내에 중복된 지역 범위 코드들을 전역화메서드로 추출- 동일한 맥락의 코드들을 메서드화NullPointException 방지 - Null 값 처리를 위한 Optional 사용메서드 오버로딩 추가 - Null 매개변수 사용을 외부에 드러내지 않기 위해 메서드를 오버로딩하여 사용Github Code 회고- 추상화 관점에서의 리팩토링을 어느정도 진행하였는데, 객체의 책임과 응집도 관점에서 좀 더 리팩토링을 진행해야 겠다는 생각과 함께 리팩토링에는 끝이 없다는 것을 느끼고 있다. 어쩌면 내가 진행한 readable한 code가 관점에 따라 누군가에게는 그렇지 않을수도 있다는 생각이 든다.  출처https://inf.run/zgJk5https://inf.run/kHiWM

백엔드워밍업클럽클린코드

yoon

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

워밍업 클럽 2기에 열린 BE 클린코드&테스트 스터디에 참가하고 있습니다. 2주차에는 1주차에 배운 클린코드 관련 내용을 예제 프로젝트에 적용하는 시간을 가졌습니다.아래에 2주차 동안 배운 내용을 요약했습니다. [배운 점]1. 코드 다듬기1.1 주석의 양면성주석은 코드의 이해를 돕는 중요한 도구이지만, 과도한 사용은 오히려 코드의 가독성을 해칠 수 있다는 것을 배웠습니다. 좋은 코드는 그 자체로 문서가 되어야 한다는 점을 명심하게 되었습니다. 1.2 변수와 메서드의 나열 순서코드 구조화의 중요성을 깨달았습니다. 변수와 메서드를 일관된 순서로 배치하면 코드의 가독성과 유지보수성이 크게 향상됩니다. 1.3 패키지 나누기큰 프로젝트를 관리 가능한 단위로 나누는 것의 중요성을 배웠습니다. 잘 구조화된 패키지는 코드의 모듈성을 높이고 재사용성을 증가시킵니다. 1.4 기능 유지보수하기버그 수정과 알고리즘 교체 과정을 통해 유지보수의 실제적인 측면을 경험했습니다. 이는 초기 설계의 중요성과 함께 변화에 유연한 코드 작성의 필요성을 일깨워주었습니다. 1.5 IDE의 도움 받기현대적인 IDE 도구들이 제공하는 다양한 기능들을 활용하면 생산성을 크게 향상시킬 수 있다는 것을 배웠습니다. 리팩토링, 코드 분석, 자동 완성 등의 기능들이 특히 유용했습니다. 2. 리팩토링 연습2.1 추상화 레벨적절한 추상화 레벨을 찾는 것의 중요성을 배웠습니다. 너무 낮은 추상화는 코드의 복잡성을 증가시키고, 너무 높은 추상화는 실제 구현을 이해하기 어렵게 만듭니다. 2.2 객체의 책임과 응집도단일 책임 원칙(SRP)의 중요성을 실감했습니다. 각 객체가 명확한 책임을 가지고 높은 응집도를 유지할 때, 코드의 유지보수성과 재사용성이 크게 향상됩니다. 2.3 관점의 차이로 달라지는 추상화같은 문제도 다른 관점에서 보면 전혀 다른 추상화 모델이 나올 수 있다는 점을 배웠습니다. 이는 문제 해결 시 다양한 시각을 가지는 것의 중요성을 일깨워주었습니다. 3. 기억하면 좋은 조언들3.1 능동적 읽기코드를 단순히 읽는 것을 넘어 적극적으로 이해하고 분석하는 습관의 중요성을 배웠습니다. 이는 코드 품질 향상과 문제 해결 능력 개발에 큰 도움이 됩니다. 3.2 오버 엔지니어링때로는 단순한 해결책이 최선일 수 있다는 점을 배웠습니다. 불필요한 복잡성을 피하고 현재 요구사항에 맞는 적절한 수준의 솔루션을 제공하는 것이 중요합니다. 3.3 은탄환은 없다모든 상황에 완벽하게 들어맞는 단일 해결책은 없다는 점을 인식하게 되었습니다. 각 문제와 상황에 맞는 최적의 해결책을 찾는 노력이 필요합니다.  [앞으로의 다짐]이번 학습을 통해 코드 품질 향상과 리팩토링의 중요성을 깊이 있게 이해하게 되었습니다. 이는 단순히 기술적인 스킬을 넘어 소프트웨어 개발에 대한 전반적인 접근 방식을 바꾸는 계기가 되었습니다. 앞으로도 지속적인 학습과 실천을 통해 더 나은 개발자로 성장하고자 합니다.

백엔드워밍업클럽클린코드

히데

CS 전공지식 스터디 미션 02

CS 전공지식 스터디 미션 02 운영체제1. FIFO 스케줄링의 장단점?장점: 단순하고 직관적 (먼저 온 프로세스가 먼저)단점: 먼저 들어온 프로세스의 작업이 다 끝나야 다음 작업이 실행2. SJF를 사용하기 어려운 이유?Short Job First, 실행 시간이 짧은 프로세스만 실행되기 때문에 긴 작업들이 끝없이 미뤄지는 사태 발생프로세스 종료 시간 예측 어려움3. RR 스케줄링에서 타임 슬라이스가 아주 작으면 어떤 문제가 발생할까요?컨텍스트 스위칭에 많은 시간이 할당되어, 오버헤드가 커짐4. MLFQ에서 CPU Bound Process와 I/O Bound Process 구분법스스로 CPU를 반납하면 CPU 사용률이 적은 것이니 I/O 바운드 프로세스일 확률이 높음 (CPU 사용률에 따라 구분)5. 공유자원이란?프로세스 간 통신을 할 때 공동으로 이용하는 파일- 동기화 문제 발생 (동시에 실행됐을 때 발생)6. 교착상태에 빠질 수 있는 조건?(1) 상호배제 - 어떤 프로세스가 리소스를 차지하였다면 그 리소스는 다른 프로세스에 공유되어서는 안 됨(2) 비선점 - 다른 프로세스가 리소스를 빼앗을 수 없어야 함(3) 점유와 대기(4) 원형대기 - 점유와 대기를 하는 프로세스들의 관계가 원형을 이루고 있음 알고리즘1. 재귀함수에서 기저조건을 만들지 않거나 잘못 설정했을 때 발생하는 문제점? 함수가 무한히 실행되거나 의도치 않게 종료될 수 있음2. 0부터 입력 n까지 홀수의 합을 더하는 재귀 함수 작성function sumOdd(n) { if(n%2 == 0) { return sumOdd(n-1) } else { if(n==1) return 1; return sumOdd(n-2)+n } } console.log(sumOdd(10)) 

하양이

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

Day 6. 리팩토링: 코드 다듬기주석의 양면성좋은 주석우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석변수와 메서드의 나열 순서중요한 것은, 나열 순서로도 의도와 정보를 전달할 수 있다는 것패키지 나누기패키지는, 문맥으로써의 정보를 제공할 수 있다.처음 만들 때부터 잘 고민해서 패키지를 나눠놓는 것이 제일 좋다. IDE의 도움 받기코드 포맷 정렬 : Option + Cmd + L | Ctrl + Alt + L코드 품질 : Sonarlint (https://www.sonarsource.com/products/sonarlint)포맷 규칙 : .editorconfig (https://editorconfig.org/)Day 7. 클린코드 리팩토링 실습미션 - 스터디 카페 이용권 선택 시스템 리팩토링 https://github.com/japygo/readable-code/tree/mission6-1회고강의를 통해 배운 것을 생각하며 리팩토링하려 했지만 생각보다 쉽지 않다.변수명, 메서드명이 잘 떠오르지 않았다. Day 8. 리팩토링 연습 | 기억하면 좋은 조언들리팩토링 연습추상화 레벨중복 제거, 메서드 추출객체에 메세지 보내기 객체의 책임과 응집도IO 통합일급 컬렉션display()의 책임Order 객체관점의 차이로 달라지는 추상화FileHandler를 바라보는 관점 어떤 데이터를 필요로 하는가데이터를 어디로부터 어떻게 가져올 것인가기억하면 좋은 조언들능동적 읽기능동적으로 리팩토링하면서 물고 뜯고 맛보면서 읽기오버 엔지니어링필요한 적정 수준보다 더 높은 수준의 엔지니어링오버 엔지니어링을 경계하고 꼭 필요한 곳에 알맞게 사용은탄환은 없다한번은 개발자와 체스를 구현하는 방법에 대해 논의한 적이 있습니다.나는 그가 어떻게 할 것인지 물었습니다.객체 지향 프로그래밍에 정통한 그는 “인터페이스와 클래스를 사용한다”고 답했습니다.나는 “하드코딩하는 편이 더 쉽지 않을까요?” 라고 운을 띄웠습니다.그는 “물론이죠. 하지만 잘 유지보수 하시기 바랍니다.” 라고 말하면서 내가 농담을 한 것처럼 씩 웃었습니다.“체스는 지난 500년 동안 변하지 않았습니다.”내 말에 그의 눈이 커졌습니다.- 크리스찬 클라우젠, 「파이브 라인스 오브 코드」, 위키북스, 2023, 302p항상 정답인 기술은 없다.마무리하며전문가는 언제나 탑다운(top-down)으로 깔끔하게 생각할 것이다.라는 미신.- 김창준, 「함께 자라기」, 인사이트, 2018, 153p추상과 구체를 넘나드는 것Day 9. 중간 점검헥사고날 아키텍쳐 - 만들면서 배우는 클린 아키텍처(https://www.yes24.com/Product/Goods/105138479)클린 코드, 테스트 코드, 더 나아가서 소프트웨어 개발은 팀 게임, 혼자는 한계가 있다.아주 작은 단위, 메서드 분리부터 시작 -> 책임을 정의하고 객체로도 분리잘 만들어진 라이브러리, 프레임워크에서 배우는 것도 좋은 방법 - https://github.com/spring-projects파라미터 수가 많을 경우 의도에 따라 줄일 수 있으면 좋다.도메인따라 다르지만 NPE 방지를 위해 empty 객체 반환회고1주차도 그렇고 2주차때도 꼭 강의를 들으려 하면 일이 생긴다.일을 다니며 하는건 쉽지 않다.그동안 궁금하고 답답한 부분을 시원하게 긁을 수 있는 강의라서 매우 좋았다.출처https://inf.run/zgJk5 https://inf.run/kHiWM 

백엔드워밍업클럽클린코드

gotjd9773

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

개요2주차 종료!Readable Code: 읽기 좋은 코드를 작성하는 사고법 을 완강했다.2주차 공부한 내용목요일에 Readable Code 강의를 완강하고, 금요일 부터는 Practical Testing 강의를 수강 시작했다. 배운 것들1. 일급 컬렉션일급 컬렉션이란 걸 처음 알게 되었다.일급 시민과 컬렉션(List, Set, Map)이 합쳐진 개념이다.컬렉션을 가공하는 로직을 캡슐화할 수 있는 장점이 있다.처음 접하는 개념이라 코드로 적용하는 하는 부분에서 어려움을 느꼈다.그렇지만, 잘만 사용하면 엄청 유용한 기법이라는 생각이 든다. 2. supports()이 메서드를 Spring Security 학습하면서 많이 봤었다.그 때는 이게 왜 필요하지 했었는데, 강의를 보면서 궁금증이 해소되었던 것 같다.다형성, 객체지향에 대해서 좀 더 가까워진 느낌? 3. 주석을 어떨 때 써야하는지주석은 웬만하면 사용하지 않는 편이 좋다고 생각했다.하지만, "코드에 히스토리, 개발자의 의도를 전부 녹일 수 없을 때"에는 주석을 써야 한다는 걸 배웠다. 4. 메서드 배치 순서이거 진짜 유용했다.메서드를 어떤 기준으로 배치해야 하는지 고민이 많았었는데,덕분에 기준을 세울 수 있었다. 5. sonarlint정적 코드 분석 도구로, 인텔리제이에서 플러그인 형태로 사용 가능하다.앞으로 Stack 과 Queue 를 쓸 일이 있을 때는 무조건 Deque을 사용할 거다.sonarlint가 Deque을 사용하라고 추천해줬음. 미션이번 주차에는 Day.7 미션이 있었다. Day.7 미션 - 스터디 카페 프로젝트 리팩토링 실습하기강의에서 배운 것을 토대로 실제로 리팩토링하는 실습이었다.추상화 레벨, 일급 컬렉션, DIP, SRP 를 염두에두고 리팩토링 했다.생각보다 쉽지 않았다.스스로 해보고 답지(강의)를 보니 갈 길이 멀어보인다.나의 가장 큰 문제점은 주어진 틀에서만 해결하려고 한다는 점이다.그래서 새로운 객체를 만든다든지, 기존의 if 문들을 다른 구조로 변경하는 것에 두려움을 느끼는 것 같다.문제를 마주할 때 넓게 보는 연습이 필요한 것 같다. 차분히.리팩토링을 더 잘하기 위해서 섹션 8 - 기억하면 좋은 조언들 - 능동적 읽기 강의 내용을 적용하면 좋을 듯 하다. 공백으로 단락 구분하면서 읽기메서드와 객체로 추상화하면서 읽기주석으로 이해한 내용 표기하면서 읽기Day.7 미션을 수행할 때 위의 조언들을 적용했더라면 좀 더 나은 결과물을 얻을 수 있었을 것 같다. 마무리2주 동안 Readable Code 보면서 많이 배웠다.배운 내용들을 체화시키려면 좀 더 노력해야 할 것이다.일단은 3주차부터 테스트 코드 진도를 나가야하니 테스트 코드에 신경을 쓰도록 하고테스트 코드를 빨리 끝낼 수 있다면, Readable Code의 내용을 복습하면 좋겠다. 

백엔드읽기좋은코드클린코드워밍업클럽객체지향추상화

geyun6026

워밍업 클럽(CS) 첫 스타트🐣 1주차 발자국🐾

전공자 만큼의 지식을 갖기 위한 나의 첫걸음, 인프런 워밍업 클럽과 함께❤비전공자에 공무원인 내가 개발자가 되기를 꿈꾸며 시작한 인프런 워밍업클럽!진짜 먼 여정이 남았지만 첫 시작을 이번 워밍업클럽과 하게되어 너무 즐겁고,그 첫 발자국을 이렇게 남깁니다. 강의 한줄평✏'감자'님의 강의는 깔끔한 화면과 깔끔한 설명으로 공부하면서 눈도 즐거운 완벽한 강의다.1주차 발자국📓 그림으로 쉽게 배우는 자료구조와 알고리즘프로그램 = 자료구조 + 알고리즘자료구조  데이터가 어떤 구조로 저장되고 어떻게 사용되는 지를 나타냄예시 : 변수, 배열알고리즘  어떤 문제를 해결하기 위한 확실한 방법 알고리즘의 속도 => 성능의 척도 "시간복잡도"특정 알고리즘이 어떤 문제를 해결하는 데 걸리는 시간코드에서 성능에 많은 영향을 주는 부분 -> "반복문"성능 평가  Big-Ω 최선의 경우 한 번에 찾음Big-Ο 최악의 경우 배열의 길이만큼 걸림 ✔Big-Θ 평균의 경우 배열의 길이 중간만큼 걸림 배열일반적인 배열 배열을 선언할 때 배열의 크기를 알려준다.예시 int arr[10] = {1, 2, 3, 4, 5};운영체제는 숫자 10개가 들어갈 수 있는 연속된 빈 공간을 찾아 1,2,3,4,5 할당운영체제는 배열의 시작 주소, 즉 1이 들어간 주소만 기억배열의 인덱스 참조는 길이에 상관없이 한 번에 가져오기 때문에 Ο(1)의 성능을 가진다.읽기 쓰기 참조 성능 Good, 데이터의 삽입 삭제 성능 Bad 자바스크립트의 배열 상황에 따라 연속적, 불연속적으로 메모리 할당불연속적으로 할당된 메모리는 내부적으로 연결 연결리스트(Linked List)크기를 모르면 메모리가 낭비될 수 있다는 배열의 단점을 해결하기 위해 등장저장하려는 데이터를 메모리 공간에 분산해 할당하고 데이터들을 서로 연결노드(Node)를 만들어서 수행 , 노드 = 데이터를 담는 변수 + 다음 노드를 가리키는 변수연결리스트는 데이터들이 전부 떨어져 있기 때문에 바로 접근 X데이터 참조 성능 : O(n)추상자료형 : 어떠한 데이터와 그 데이터에 대한 연산연결리스트의 추상자료형 모든 데이터 출력 printAll()모든 데이터 제거 clear()인덱스 삽입 insertAt(index, data);마지막 삽입 insertLast(data); 인덱스 삭제 deleteAt(index);마지막 삭제 deleteLast();인덱스 읽기 getNodeAt(index);"Node" 클래스 선언, "LinkedList" 클래스 선언class Node{ constructor(data, next = null){ this.data = data; # 자바스크립트에서 클래스 내의 변수는 프로퍼티 this.next = next; } } class LinkedList{ constructor(){ this.head = null; this.count = 0; } insertAt(index, data){ if(index > this.count || index < 0){ throw new Error("범위를 넘어갔습니다."); } let newNode = new Node(data); if(index==0){ newNode.next = this.head; this.head = newNode; } else { let currentNode = this.head; for(let i = 0; i < index - 1; i++){ currentNode = currnetNode.next; } newNode.next = currentNode.next; currentNode.next = newNode; } this.count++; } } 스택(stack)First In Last Out(FILO)먼저 들어간 데이터가 나중에 나오는 규칙head에만 삽입, 제거큐(Queue)First In First Out(FIFO)먼저 들어간 데이터가 먼저 나오는 규칙head에 삽입하고 tail에서 제거덱(Deque)데이터의 삽입과 제거를 head와 tail 두 군데서 자유롭게 할 수 있는 자료구조해시 테이블(Hash Table)해시(Hash), 맵(Map), 해시맵(HashMap), 딕셔너리(Dictionary)Key만 알면 Value에 Ο(1)의 성능으로 읽기 가능삽입, 수정, 삭제까지 Ο(1)의 성능셋(set)데이터의 중복을 허용하지 않는 자료구조그림으로 쉽게 배우는 운영체제운영체제가 하는 일프로세스 관리메모리 관리하드웨어 관리파일시스템 관리운영체제의 역사1940년도 애니악1943년부터 미군지휘하에 펜실베니아 대학교에서 개발최초 목적 : 미사일 탄도계산스위치와 배선 연결을 통한 프로그래밍 1950년도 초반 진공관과 전선으로 만들어진 논리 회로를 아주 작은 크기로 만든 직접 회로(IC) 개발현대적인 컴퓨터 모습 갖춤CPU, 메모리 있었지만 키보드와 모니터는 없었음펀치카드 이용, 프로그래머가 카드에 구멍을 뚫어 프로그래밍 1950년도 중후반 "싱글스트림 배치시스템"프로그래머가 여러개의 펀치카드를 오퍼레이터에 전달, 컴퓨터는 순서대로 실행입출력 I/O 디바이스 컨트롤러를 만들어 입출력 중에도 CPU가 계산할 수 있도록 만듦한계 : 입출력에도 CPU를 기다려야 하는 작업이 있음 1960년도 "시분할 시스템"프로그램을 동시에 여러개 사용여러 사용자들이 여러 터미널로 하나의 컴퓨터에 접근하여 사용 -> 파일시스템 등장UNIX AT&T벨 연구소에서 C언어로 유닉스 운영체제 개발멀티 프로그래밍, 다중 사용자, 파일시스템 구현메모리 침범 이슈 발생베이스 레지스터 : 프로그램의 시작 주소 저장, 모든 프로그램은 0번지에서 실행한다고 가정 1970년도 이후 개인용 컴퓨터의 시대 시작애플의 매킨토시, 마이크로소프트의 MS-DOS가 많이 사용 운영체제의 구조운영체제의 핵심은 커널 폰 노이만 구조CPU 스케줄링운영체제는 모든 프로세스에게 CPU를 할당/해제하는데 이를 CPU 스케줄링이라고 한다.CPU 스케줄링에서 스케줄러(운영체제)가 고려해야 할 사항 첫번째, 어떤 프로세스에게 CPU 리소스를 줘야하는가?두번째, CPU를 할당받은 프로세스가 얼마의 시간동안 CPU를 사용해야하는가?스케줄링 목표 리소스 사용률오버헤드 최소화공평성 처리량대기시간응답시간스케줄링 알고리즘 FIFO(First In First Out)SJFRRMLFQ   

알고리즘 · 자료구조워밍업클럽CS

인프런 워밍업 클럽 스터디 2기 백엔드 - 2주차 회고록

벌써 워밍업 클럽 스터디를 진행한지 2주차가 마무리가 되었다. 1주차에는 추상에 대한 이해도를 높이기 위한 여러 예시와 상황들을 배웠으며2주차에는 배운 내용을 깊이 이해할 수 있도록 많은 예시들을 보며 설명을 해주었고그 과정에서 미션3 을 통해 배운 내용을 써 먹을 수가 있었다. 특히 섹션5 객체지향 적용하기 에서 배운 내용은 정말 인상적이었다.상속과 조합 (상속보다는 조합 사용하자)Value Object, Entity (불변성, 동등성, 유효성 검증)일급 컬렉션Enum추상화와 다형성 활용하여 반복되는 if 문 제거, OCP 지키기숨겨져 있는 도메인 개념 도출하기.간단하게 이렇게 키워드를 정리해주셨는데 실무에서 1,2,4,5 는 최대한 지키기 위해 노력하고 있지만 일급컬렉션 부분은 처음듣는 내용이라 어려웠다 그리고 마지막 섹션인 '기억하면 좋은 조언들'위 부분은 키워드만 줄여서 회사 모니터앞에 출력해두고 매번 상기시키면서 코드를짜려고 실천하는 중이다. 능동적 읽기복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링 하면서 읽기공백으로 단락 구분하기메소드와 객체로 추상화 해보기주석으로 이해한 내용 표기하며 읽기우리에게는 언제든 돌아갈 수 있는 git reset --hard 가 있다.핵심 목표는 우리의 도메인 지식을 늘리는 것.그리고 이전 작성자의 의도를 파악하는 것이 중요하다.오버 엔지니어링필요한 적정 수준보다 더 높은 수준의 엔지니어링의 오버 엔지니어링 이라고 한다ex) 구현체가 하나인 인터페이스 를 추상화 한다.인터페이스 형태가 아키텍처 이해에 도움을 주거나, 근시일 내에 구현체가 추가될 가능성이 높다면 OK구현체를 수정할 때 마다 인터페이스도 수정해야 함불필요 인터페이스가 많으면, 코드 탐색에 영향을 줌. 애플리케이션이 비대해 진다.ex) 너무 이른 추상화 or 과도한 추상화정보가 숨겨지기 때문에 복잡도가 높아진다.후대 개발자들이 선대의 의도를 파악하기가 어렵다.지금까지 배운것이 절대법칙은 아니고 경험을 쌓으면서 필요한 곳에서 잘 적용을 해야한다은탄환은 없다'파이브 라인스 오브 코드' 라는 책이 있다.클린 코드도 은탄환이 아니다.실무 : 2가지 사이의 줄다리기지속 가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물대부분의 회사는 돈을 벌고 성장해야 하고, 시장에서 빠르게 살아남는 것이 목표다이런 경우에도, 클린 코드를 추구하지 말라는 것이 아니라, 미래 시점에 잘 고치도록 할 수 있는 코드 센스가 필요하다.ex) TODO , 주석 달아 두기결국은 클린 코드의 사고법을 잘 알고 있는 것이 중요하다.위 2가지 사이에서 줄타기를 잘해야 한다고 생각한다.모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다.ex) 당장 급하게 배포 나가야 하는데, 동료에게 style 관련된 리뷰를 주고 고치도록 강요하는 사람도구라는 것은, 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법이다.적정 수준을 알기 위해, 때로는 극단적으로 시도해보자.-> 항상 정답인 기술은 없다.-> 한계까지 연습해보고, 적정 수준, 적정 시점을 깨달아보자객체지향의 꽃은 '추상' 이라는 개념을 정말 잘 이해해야 한다."함께 자라기 애자일로 가는 길" 책을 추천 : 탑-다운(추상 -> 구체)추상과 구체를 넘나들 수 있게끔 노력을하자 소프트웨어 장인이 되보자 미션미션은 총 1개를 진행하였고 내용 자체가 어려웠다.배운 내용을 토대로 리팩토링을 하는 것이였는데 딱 주어진 코드를 보자마자망치로 한대 맞은듯이 멍해졌다. 뭐부터 시작해야 하지 고민을 30분정도 한 것 같다.그리고 제일 쉬운 메소드 추출부터 시작하였고 그 이후로는 어떻게 접근 해야할지에 대한 고민을 하다결국 강의를 보며 인사이트를 얻기로 했다.정말 객체지향, 추상화 위 내용은 개념을 안다고 해서 무언가를 잘 할수있다? 이런건 대부분 없는 것 같다.많은 경험과 많은 인사이트를 직접 채득을 하는게 중요하다고 생각한다.이제는 리팩토링 파트에서 넘어가 실용적인 테스트 파트 강의를 앞두고 있는데 기대가 많이 된다.실무에서 한 프로젝트는 JPA 를 다른 프로젝트는 MyBatis 를 사용하고 있지만테스트에 대한 기본 개념과 내용을 알아두면 분명 큰 도움이 될거라고 생각한다. 모든 정리 내용은 Github 에 기록을 해두었습니다.

웹 개발Java

w3w

[2주차] 발자국

강의 수강이번 2주차에는 데이터 리포지토리를 개발하고 테스트 코드를 작성하고, 성능을 개선하는 것과 클래스를 생성하고 DTO 개발, 리포지토리, 서비스 개발과 서비스 테스트 코드를 작성하는 것을 배웠다.이번 주차 강의를 들으면서 가장 뿌듯했던 점은 강의를 밀리지 않고 모두 맞춰 수강했다는 점이다. 아쉬웠던 점은 아직 코드들이 어떻게 연결되고 하는 지 완벽하게 이해한 것은 아니기 때문에 추가적으로 공부를 해야 함을 느꼈다는 것이다. 강의를 들으면서 테스트 코드를 작성하다 오류가 발생하였었는데 원인을 모르겠어서 질문을 통해 해결했다. 테스트 코드에 문제가 있는 것은 아니고 프로덕션 코드에 문제가 있었는데 엔티티간 cascade 옵션이 설정되지 않아 발생한 것이었다. cascade Type은 영속성의 전이에 대한 설정인데, 영속성 컨텍스트에 특정 엔티티가 PERSIST, MERGE, REMOVE, DETACH 등이 될 때 그 엔티티와 연관된 다른 엔티티도 똑같이 상태를 전이할 지 말 지에 대한 것이었다. 미션이번 미션은 REST API 설계하기였다. 아직 java나 강의에서 사용하는 방식에 대해 익숙하지 않은 상황이라 테이블 설계를 간단하게 했어서, 설계할 api도 많지 않았던 것 같다. 지난 미션 때 마크다운 작성 방식을 구글링하여 했어서 이번에도 그때 그 내용을 참고하여 readme파일에 작성하였다. 나중에 조금 더 익숙해진 다음에는 테이블도 확장시켜서 조금 더 많은 서비스들을 제공할 수 있게끔 해보고 싶단 생각이 들었다.

백엔드

w3w 1개월 전
채널톡 아이콘