일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Study
- 일상속귀한배움
- 스터디
- Validation
- BOOK
- validator
- AWS
- nodejs
- 독후감
- googleapis
- nodemailer
- OOP
- 개발자
- 역행자
- 클린코드
- PRISMA
- Object
- 부자아빠가난한아빠2
- 객체지향의사실과오해
- UNiQUE
- 조영호
- 자청
- futureself
- 세이노의가르침
- typescript
- serverless
- 북스터디
- Nestjs
- 오브젝트
- 퓨처셀프
- Today
- Total
목록분류 전체보기 (83)
우당탕탕 우리네 개발생활
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/5b12H/btsHQzzamLo/xB3rDkpwZutY3csF2xFKmK/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.7장. 오류 처리- 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. - 확인된 예외는 OCP를 위반한다. 확인된 예외는 캡슐화를 깨버린다.-> (부연 설명) OCP란 기능 추가에는 열려있고, 기능 수정에는 닫혀있어야 함을 나타내는 객체지향의 대표적인 원칙이다. 매번 어떤 요구사항이 있을 때마다 객체의 특정 메서드를 수정해야한다면 그건 OCP를 위반한다고 볼 수 있다. 기존 기능들을 그대로 유지하..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/br9tXw/btsHKAehKkB/5QtTwH3zxwW3X4X7vP1I81/img.png)
레거시 코드를 다루며 모듈의 Circular Dependency와 관련된 다소 희귀한(?) 케이스의 문제를 경험했다. 바로 barrel files와 관련된 이슈이다.Circular Dependency와 관련된 내용은 공식문서를 통해서 이전에 공부했던 적이 있는데 그때는 유심히 보지 않았던 부분이 바로 위 문제의 원인이었다. 관련된 내용은 공식문서에 기재되어 있다.Barrelbarrel이 뭔데? 해당 사이트에서는 다음과 같이 barrel의 정의에 대해 알려주고 있다.배럴은 여러 모듈의 내보내기를 하나의 편리한 모듈로 롤업하는 방법입니다. 배럴 자체는 다른 모듈의 선택된 내보내기를 다시 내보내는 모듈 파일입니다.A barrel is a way to rollup exports from several modul..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/LXPyK/btsHIcLut1s/BsetTMmKDvBW5tMo7fm160/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.4장. 주석- (내 생각) 코드는 영어를 기반으로 되어 있다. 영어를 유창하게 사용할 수 있는 사람들과 상대적으로 그러지 못한 사람들에게 다가오는 좋은 네이밍의 편안함은 정도가 다르다. 영어가 모국어가 아닌 나라들에서는 좀 더 주석에 관대해져야 하는 부분들이 있지 않을까 생각해본다. 간단한 영어 문장조차 해석하기 버거워하는 동료에게 "이정도는 정말 자세하게 잘 작성한 네이밍이니 공부해서라도 익숙해져주길 바래" 라고 일종의 무언의 압박을 주는 편이 맞는 걸까? 그렇다면 또 이러한 동료들을 위해 매 함수들마다 친절하게 모국어로 주석을 일일이 달아줘야 하는가? 물론 저자..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bb4z0b/btsHHaNmcvR/l9XSL2nbHGgxeOa6WXnPhk/img.jpg)
책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.0장. 들어가면서- 깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생을 해야 한다. 스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야한다. 그들이 넘어지고 일어서는 모습도 봐야한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야한다. - 이 책을 읽는 동안 마음 고생할 준비를 하기 바란다. 비행기 안에서 심심풀이로 읽어보는 기분 좋은 책이 아니다. 열심히, 아주 열심히 독파해야 하는 책이다.1장. 깨끗한 코드- 비유를 하나 들겠다. 자신이 의사라 가정하..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cBNSsh/btsHCAT0eZP/ents6KolTHM2Sq9pq0Zf81/img.jpg)
왜 를 공부하기로 결심했나?근래 객체지향의 사실과 오해>와 관련하여 블로깅했다. 워낙 바이블과 같은 책인지라 그저 중요하다고 표시했던 부분들을 요약해서 정리했다(거의 대부분을 밑줄치고 메모하면서 읽었다는 게 함정이라면 함정이다). 어찌 됐건 블로그에 의식적으로라도 정리를 하다 보니 자연스럽게 중요한 부분들을 한 번 더 정리할 수 있게 되었다. 첫 부분에 이해가 안 되면서 넘어갔던 부분들이 전체를 다 읽은 후 그 배경으로 다시 보니 이해가 되는 경우들도 많아서 블로깅을 통한 생각정리의 과정이 굉장히 값어치 있었다. 배드민턴이라는 스포츠가 생각난다. 우리 삶에 비교적 가까이 있고 남녀노소 누구든지 즐기기 쉽다. 그저 적당한 높이에서의 셔틀콕을 땅에 닿기 전에 쳐서 상대편으로 넘겨주면 된다. 그렇기에 별다른..
근래 하드스킬에 대한 공부를 꾸준히 하고 있다.타입 스크립트 교과서, 리팩터링 2판, 객체지향의 사실과 오해 공부를 마치고 고대하던 클린코드를 공부하기로 마음먹었다. 앞선 3가지를 공부하면서 아쉬웠던 점이 있었다. 공부한 내용들에 대한 고민을 나눌 동반자가 없었다는 점이었다. 학생시절을 돌아본다. 같은 교실에서 같은 교육과정을 같은 선생님들께 들어왔기 때문에 서로 나누고 싶은 내용들은 배경지식에 대한 사전 설명 없이 바로바로 나눌 수 있었다. 이렇게 나눈 얘기들은 더 기억 속에 오래 남았었던 경험이 있다. 대학생 때도 크게 다르지 않았다. 그래서 스터디가 너무 고팠다. 나와 비슷한 고민을 함께 나눌 사람들이 필요했다. 고민은 그리 오래가지 않았다. 나와 절친하게 지내고 있는 나와 비슷한 연차의 개발자 동..
과 를 공부하면서 흥미로운 법칙을 알게 되었다. 바로 보이스카웃 규칙 이다. 캠핑장은 처음 왔을 때보다 더 깨끗하게 하고 떠나라 라는 원칙이는 리팩터링이라는 단어가 갖는 철학과 너무 잘 맞는다. 이전보다 더 깨끗이 정리한다는 의미는 먼지하나 없이 깔끔하게 정리하는 것을 의미하지는 않는다. 상대적으로 조금 더 깔끔하면 된다. 이 법칙을 지닌 사람이 조직 내 많으면 많을수록 그 효과는 배가되지 않을까? 학교 수업이 끝난 후 모든 학생이 본인의 자리 주변만 정리해도 청소 당번이 따로 필요 없을 것이다.최근 레거시 코드에 피쳐를 추가할 일이 생겼다. 이미 시작도 전에 나는 법칙에 충만한 한 명의 보이스카웃일 준비를 마쳤다. 내 작업분을 테스트코드 작성과 더불어 마친 후 작업분 주변의 리팩터링 필요를 살핀 후 적..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cd1UO8/btsHw4zPc3r/DurJj6UrawBplKTJCh3uIk/img.jpg)
항상 읽은 책에 대한 생각정리를 적을 때 저자에 대한 소개글을 먼저 작성하곤 했는데 오늘은 포기했다. 화려한 경력을 가지고 계신 저자님들이 9분이나 계시기 때문에 소개글을 작성하는 것만으로도 부담스러운 내용이 될 것 같았기 때문이다. 이 9분의 저자님들은 모두 책에서 표기하길 테크 리더라고 부를 수 있겠다. 보통 소프트웨어 회사에서 개발자들을 기술적으로 리드할 수 있는 리더들을 테크 리터라고 부른다. 이 저자님들은 모두 우리나라 개발씬에서 알아주는 훌륭한 분들이시며 무엇보다 내가 너무 존경한다. 저자님들의 이야기를 읽으면서 실질적으로 내 개발자 로드맵에 도움이 될 좋은 인사이트들을 많이 얻었다. 오랜 개발생활을 하시면서 당신의 철학이 어떤 식으로 변화해갔는지 귀한 경험을 나눠주신 분도 계셨고, 실질적인 ..