목록분류 전체보기 (147)
재 현
https://fringe-humerus-32b.notion.site/3-b21c8a9fbf8e4e9ab419e9b8ef72787e?pvs=4
일단 개인적인 후기 먼저 요구사항을 분석하고 기능 목록과 예외 사항을 작성했다. 이를 통해 예외 사항을 처리하면서 기능 목록을 잡으려고 했다. 그랬더니 자연스럽게 역할 설계로 이어졌다. 내가 만들어낸 코드를 빠르게 피드백받고 리팩터링 할 수 있다는 점이 TDD의 장점인 것 같다. 테스트가 개발을 주도한다. 그리고 지속적으로 코드 정리하면서 너무 지저분해지는 걸 막는다. 빠른 피드백을 받을 수 있어서, 바로 내가 완성된 코드가 올바른지 알 수 있다. 중요한 점은 테스트를 통과할 만큼만 코드 작성하는 거다. 처음 하면 어렵다. 단위 테스트 작성하는 것도 어색하고 어려운 내게, 테스트로 개발을 시작하는 건 어려웠다. 하지만 TDD의 장점을 알게 되고 연습하고자 마음먹었던 것 같다. 테스트 테스트란 무엇일까? ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/sP0Oa/btszYFVrvUq/nmWkSoCKy44x4m67uE5Rg1/img.png)
getter 쓰지 말라고요? 이유 1: 객체의 내부 구조를 외부에서 직접 조작하게 되면 캡슐화, 모듈화가 깨지면서 코드의 안정성이 심각하게 무너진다. 이유 2: 객체의 필드가 public이라면, 필드를 private로 하고 getter 메서드를 사용하더라도, 필드를 public으로 공개하는 것과 다를 바가 없는 구조라면 결국 똑같은 문제가 일어난다. getter가 그냥 머릿속에서 지우면 되나요? 사실상, getter가 문제인 게 아니라, 객체의 구성 요소를 외부에서 조작하게 만드는 설계 구조가 문제를 일으키는 것이다. 우리는 왜 getter가 필요한지 알아야 한다. 우리는 보통 클래스 안에 있는 필드 값을 사용하기 위해 getter를 찾는다. 그럼 왜 그 값이 필요한지 의문을 던져야 한다. 가져온 값을 ..