작심삼일 개발이야기

9장 단위 테스트 테스트하면 TDD가 떠오르는데 일단 공부해야 될 목록에 추가는 해두었지만... 그냥 테스트를 어떻게 하면 좋을지? 기준을 두고 읽어 보았다. TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 테스트코드는 실제 코드 못지않게 깨끗하게 짜야한다. 클린 코드 책을 읽다 보면 모든 코드를 구분 없이 깨끗하게 짜야 되는 것 같다. 물론 당연한 말이지만... 그래도 책으로 한번 보면 더 각인된다고 해야 되나? 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 ..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 단순한 설계 규칙 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1 : 모든 테스트를 실행하라 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템'이다. 테스트 케이스를 작성하면 설계 품질이 높아진다. 단순한 설계 규칙 2~4: 리팩터링 코드를 몇 줄 추가할 때마다 설계를 조감한다. 새로 추가하는 코드가 설계 품질은 낮춘다고 생각이 들면 정리한 후에 테스트 케이스를 돌려서 기존 기능이 잘 동작하는지 확인한다. 중복을 없애라 깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다. 표현하라 코드는 개발자의 의..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 8장. 경계 개발을 하다 보면 모든 기능들을 직접 구현하지는 않는다. 때로는 무료로 공개된 라이브러리들을 사용하거나 돈을 내고 사용하는 경우도 있다. 라이브러리를 사용하는 사용자들은 자신들의 요구에 딱 맞는 기능을 기대하고, 라이브러리를 만드는 개발자들은 최대한 범용적으로 사용할 수 있게 만들고 싶어 한다. 이러한 경우 때문에 문제가 생길 소지가 많다. 라이브러리를 사용하면 적은 시간에 더 많은 기능을 출시할 수 있어진다. 하지만 그 코드를 익히기 어렵다. 어떤 식으로든 나의 코드에 깔끔하게 통합해야한다. 무작정 라이브러리를 사용하기보단 간단한 테스트 케이스를 작성해서 라이브러리를 익히는 방법을 추천한다. 이를 학습 테스트..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. "오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 입력이 이상하거나 디바이스가 실패할지도 모르기 때문이다." 맞는 말이다...사용자들은 개발자가 원하는 입력 값만 입력하지 않기 때문이다. 그렇기 때문에 예외처리는 필수다. 오류 코드보다 예외를 사용하라 책에서는 if문을 사용하는 것보다 try catch문을 사용하라고 한다. public void Person() { if (mycar != stop) { // 자동차가 멈춰있으면 걸어간다. walk(); if (trafficLight !=green) { // 보행자 신호등이 초록색이면 길을 건넌다. crossTheRoad(); } else { stop(); } }..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 디미터 법칙 모듈은 자신이 조작하는 개체의 속사정을 몰라야 한다는 법칙 객체는 자료를 숨기고 동작을 공개한다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다 그래서 새로운 자료 타입 추가가 필요하면 객체가 더 적합하다. 이번 파트는 이해가 잘 가지 않는다. 어렵다..

이 글은 클린 코드를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 주석은 나쁜 코드를 보완하지 못한다. 코드를 작성하다 주석을 사용할 때는 다른 사람 또는 내가 코드를 볼 때 알아보기 힘들 거 같다고 예상이 들면 주로 주석을 작성한다. 사실 이건 주석으로 때우려고 하지 말고 코드를 고쳐야 하는 것이 맞다 하지만 역시 주석을 달고 도망가버리곤 했다.. 좋은 주석 TODO 주석 가끔 코드를 보다보면 //TODO 주석을 본 적이 있다. 말 그대로 필요하지만 당장 구현하기 어려운 일들을 기술하는 주석이다. 더 이상 필요 없는 기능을 삭제하라거나 더 좋은 이름을 생각해달라는 부탁 앞으로 어떻게 고쳐야 한다는 주의 등에 유용하다. 나쁜 주석 대다수의 주석들이 나쁜 주석들이다. 물론 아닌 사람도 있겠..