일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- AWS
- Study
- 세이노의가르침
- futureself
- 스터디
- nodemailer
- 오브젝트
- 북스터디
- Object
- 퓨처셀프
- 역행자
- googleapis
- nodejs
- Nestjs
- 일상속귀한배움
- Validation
- 독후감
- BOOK
- 조영호
- 부자아빠가난한아빠2
- UNiQUE
- 객체지향의사실과오해
- 클린코드
- OOP
- typescript
- serverless
- 자청
- 개발자
- validator
- PRISMA
- Today
- Total
목록전체 글 (83)
우당탕탕 우리네 개발생활
최근 , , 등의 책들을 공부하면서 '추상화', '책임' 이라는 단어들이 뇌리에 박혔다. 객체들의 의사소통은 명확히 분리되어 있는 각자의 책임하에 정해놓은 외부 인터페이스를 통해서만 이뤄지는 것을 원칙으로 한다. 규모가 좀 더 커져 컴포넌트간의 소통, 서비스들간의 소통 역시 마찬가지인 것 같다. 이러한 외부 인터페이스(메서드)의 input(인수)과 output(리턴값)이 구체적이지만 그 외부 인터페이스의 내부 과정(구현)이 어떤식으로 이뤄지는지는 구체적으로 드러내지 않는다. 예를 들어, 캐셔에게 아이스아메리카노를 주문한 고객이 있다고 하자. 고객은 돈을 지불했고 그에 대한 결과로 아이스아메리카노를 캐셔를 통해 받기만 하면 된다. 고객은 캐셔가 아이스아메리카노를 직접 만들든 캐셔가 바리스타에게 주문을 건..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bAImLm/btsIx0KsTIM/ZLHT19t96ge3mojfxvRsh1/img.jpg)
왜 를 공부하기로 결심했나?최근 스터디를 마쳤다. 이 스터디에 대한 기록은 스터디 리포지토리에 남겨 두었다. 는 개발자들이 기본기를 다지기 위해 읽을 수 있는 바이블로 오랫동안 알려져 왔다. 내 주변의 동료들도 대부분 이 책을 공부한 것 같았다. 그동안 묘한 소외감을 느껴왔었는데 드디어 이 책을 공부하게 되었다. 저자인 엉클 밥(로버트 C 마틴)의 오랜 경험과 고민이 녹아있는 철학을 이렇게 저렴하게 경험해도 되나 싶은 마음이 공부하는 내내 들었고 정말 몰입해서 가르침을 받을 수 있었다. 공부하면서 밑줄치고 메모했던 내용들을 블로그에 기록도 해두었다. 와 를 공부하면서 반복적으로 나에게 각인됐던 단어는 바로 '책임'이었다. 코드에서 책임을 분명히 나누는 것은 중요하다. 책임을 제대로 나누지 못한 코드는 ..
평상시 점심을 먹고 동료와 함께 커피를 살 겸 산책을 나선다(정확히는 동료가 커피 사러 가는 길을 따라 나서는 것이다). 오늘은 동료의 부재로 나 혼자 산책을 나섰다. 항상 회사 스틱커피를 즐기는데 금요일이고 날씨도 무덥고 음.. 그냥 기분이 내켜 바나프레소에서 저렴한 아아를 테이크아웃 했다. 점심시간 직전까지 도메인 객체 구현 작업에 푹 빠져있었다. 책임소지를 어느 객체에 더 줄 수 있을지 고민하면서 코드를 썼다 지웠다 반복했다. 레거시 데이터베이스 구조에서 추출해오는 영속화 된 데이터들을 처음부터 고려하지 않은 채 객체의 명확한 책임을 먼저 고려하고 시작한 건 아주 잘한 일이었다. 책임에 대한 행위들을 러프하게 정의했고 이를 기반으로 객체를 하나 만들어 외부 인터페이스(메서드)를 선언만 해뒀다. 그..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/b5dX1G/btsH9LlxTM9/4E0eFvQ5gRGRxNYde9xdck/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.17장. 냄새와 휴리스틱- 경험상 당연한 플로우의 동작을 구현해야 한다. 당연한 동작을 구현하지 않으면 코드를 읽거나 사용하는 사람이 더 이상 함수 이름만으로 함수 기능을 직관적으로 예상하기 어렵다. 저자를 신뢰하지 못하므로 코드를 일일이 살펴야 한다. - 경계를 올바로 처리해야 한다. 코드는 올바로 동작해야 한다. 너무나도 당연한 말이다. 그런데 우리는 올바른 동작이 아주 복잡하다는 사실을 자주 간과한다. 흔히 개발자들은 머릿속에서 코드를 돌려보고 끝낸다. 자신의 직관에 의존할 뿐 모든 경계와 구석진 곳에서 코드를 증명하려 애쓰지 않는다. 부지런함을 대신할 지름길..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/b93Kcf/btsIaDAx6pp/KVKYnT1t0FsrkHCqzg2OeK/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.14장. 점진적인 개선- (내 생각) 해당 장은 Args 클래스에 대한 첫 작성부터 리팩터링까지의 과정이 디테일하게 기록되어있다. 그렇기에 양이 방대하다. 해당 장을 어떻게 공부하는 것이 내가 인사이트를 많이 얻을 수 있는 방법일까 생각해 봤을 때 우선은 전 과정을 차근차근 읽고 밑줄을 치거나 기록을 하는 방법이라고 생각했다. 공부를 하다 보니 원론적인 해당 클래스에 대한 기능 이해 자체가 부족함을 느꼈다. 그렇기에 메서드의 정확한 기능과 선언된 프로퍼티들의 의도의 파악이 어려웠고 이에 따라 리팩터링 역시 완전한 공감이 어려웠다. 그래서 아래와 같이 Nestjs +..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bx8tfp/btsH3rG4b95/Fyk5OqhFCwcKwitlrc5Kb0/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.12장. 창발성- 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다.응집도 높이기결합도 낮추기관심사 분리하기시스템 관심사를 모듈로 나누기함수와 클래스 크기 줄이기더 나은 이름 선택하기- 코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.우선, 좋은 이름을 선택한다.둘째, 함수와 클래스 크기를 가능한 줄인다.셋째, 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다. 클래스가..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dtZLiL/btsHTgeKr6b/0o0aMlzAwAAYUsp9y11mkk/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.11장. 시스템- 시스템 제작과 시스템 사용을 분리하라. 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. public getService(): Service { if (service === null) { service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까? } return service;}- 위 방법은 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluati..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/D8WQh/btsHSENTbCZ/1zII6CfdbUPML4PhEmFBBk/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.10장. 클래스- 클래스 체계. 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. 정적(static) 공개(public) 상수가 있다면 맨 처음에 나온다. 다음으로 정적 비공개(private) 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다. - 캡슐화. 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시..