수정하기 너무나 힘든 코드를 작성하거나 유지보수하는 개발자들의 필독서 서론 : 객체지향 몰라도 코드를 작성할 수 있다 요구사항은 변한다. 그 요구사항을 반영하는 것이 사실 크게 어렵지 않은 순간이 많다. 그냥 대충 DB에 컬럼 추가하고 쿼리 추가하고 맵(Map)에다 넣어서 if else 블록 추가하면 된다. 예전에 비슷한 수정사항이 있었으면 그거 복붙하면 된다. 그런데 계속 그렇게 작업하다가 보면 언젠가 엄청나게 긴 메서드와 객체를 만나게 된다. 쿼리도 엄청 복잡해진다. 뭐 하나 수정하기가 너무 여러운 코드가 된다.그런 코드는 개발자의 적이다. 읽는데 너무 힘들다. 경험상 그런 코드는 재작성하게 되는데 숨겨진 로직을 반영하지 못해서 버그가 생길 때도 많다. (그것 때문에 또 스트레스...) 지나친 비약일..
대학교 때 처음 이것을 배웠을 때는, '와! 이렇게 하면 대박 좋겠다!' 였습니다. 그런데 회사에 와서 그 패턴들을 적용하려고 할 때, 간혹 '그게 왜 좋아?' 라고 묻는 사람들이 있었습니다. 사실 저는 좋을 것 같다라는 막연한 생각만 있었고 왜 좋은 지에 대해서는 책에서 설명하는 뻔한 이야기 밖에 할 수가 없었습니다. 예를 들어 '특정한 상황에 맞는 해결책을 빠르게 찾을 수 있고, 상황에 맞는 올바른 설계를 보다 빠르게 적용할 수 있다' 이런식으로 이야기 했죠. 그런데 어느날 '과연 진짜 그 상황에 맞는 해결책인가? 남들도 쉽게 이해할 수 있고, 수정할 수 있을까?' 이런 고민을 많이 하지않았기 때문에 남들에게 코드가 허세로 보일 수도 있을 거란 생각을 하게 되었습니다. 별 것도 아닌데 패턴이랍시고 쓴..
- Total
- Today
- Yesterday
- AWS
- container
- html
- 개발자
- sanur
- 객체지향
- Clean code
- Bali
- springboot
- Docker
- S68
- ChatGPT
- spring
- 실수노트
- hands-on
- 한달살기
- ecma6
- 컨테이너
- 회고
- 웹을 지탱하는 기술
- ES6
- 사누르
- 도커
- rest
- 독후감
- javascript
- AWSKRUG
- 발리
- 웹
- spring boot
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |