Reimaginer

테스트 코드가 작성하는 것이 어렵다고 많이 이야기한다. 테스트 코드가 없는 상태로 성장한 프로젝트들, 그리고 외부 의존성(DB, 외부 API, 파일 쓰기 등)이 많은 프로젝트들의 코드가 보통 테스트가 어려운 경우가 많다. 과연 그때 우리는 어떤 선택을 해야할까? 추측하건데 보통은 그냥 작성하고 배포한 후, 직접 API를 호출해보거나 확인해볼 수 있는 UI를 통해서 테스트를 해볼것이다. 이런 사용자 테스트는 비용이 크다. 테스트할 여러가지 상황을 재현하기도 쉽지 않을 수 있고, 버그 발견 후 수정하고 다시 확인하는데도 오래 걸린다. 혹자는 실 사용자에게 테스트를 넘길 수도 있다. 테스트 없이 그냥 서비스를 배포하는 것이다. 이런 상황에서 예상되는 결과는 다음과 같다. 문제없이 기능이 배포 되었다. 문제가 ..

1장. 표기법과 메타모델 UML을 사용하는 방법들 스케치, 청사진, 프로그래밍 언어 필자의 편견으로는, 이 셋 중에서 가장 보편적인 것은 UML을 스케치로 생각하는 것이다. 이 방식에서는 개발자가 시스템의 어떤 측면에 대해 다른 사람과 의사 소통하는 것을 돕는 목적으로 UML을 사용한다. ... 스케치는 순공학(Forward Engineerging) 또는 역공학(Reverse Engineering)에 사용될 수 있다. 스케치의 핵심은 선택성이다. 순공학에서는 작성하고자 하는 코드의 어떤 문제에 대해서 대강 스케치를 해서 팀 내의 사람들과 의논을 한다. 이 책은 설계를 스케치하는 용도의 UML을 소개하는 책이다. 적법한 UML이란 무엇인가? 언어의 두가지 카테고리 규범적인 규칙(Perscriptive ru..

신림프로그래머 클린코드 Jpg from Yeomyeong Woo 어제(2016.06.18) 제가 정말 좋아하는 신림동 프로그래머에서 공개 세미나를 했습니다. 저도 용기내서 "클린코드"라는 주제로 발표를 했는데요. 참 좋았습니다. 발표자료를 공유합니다. http://www.slideshare.net/YeomyeongWoo/jpg-63215333 이상하게 키노트에서 pdf로 만든 파일을 slideshare에 올리면 한글이 다 사라지는 경우가 있었습니다. slideshare에 있는 슬라이드는 이미지로 만든 슬라이드입니다. 그래서 텍스트가 있는 pdf 파일도 여기에 같이 공유 드립니다. 조금이라도 도움이 되길 바랍니다.

오늘은 TDD 8장 까지 스터디를 하였습니다. 8장의 내용은 Dollar와 Franc이라는 각 지역별 화폐 객체에서 Money라는 상위클래스를 추출함으로써 한 단계 추상화하고 각 코드의 중복을 제거하는 부분이었습니다. 캔트 백은 중복을 제거하면서 상위 클래스에 펙토리 메서드를 만듭니다. 저는 이 부분이 너무 어렵게 느껴졌습니다. 과연 내가 그런 상황에서 펙토리 메서드를 생각해낼 수 있었을까 하는 의문이 들면서 말이죠.좀 더 고민해보니까, 이런 결론을 얻었습니다. 추상화를 하고 나서 구상 클래스 (Concrete class)와 클라이언트 코드간의 의존성을 제가하는 것은 당연한 것이다. 펙토리 메서드를 생각해 낼수 있느냐의 문제가 아니고, 구상 객체와 클라이언트 코드간의 의존성 제거를 위해서 꼭 해야하는 일..

스터디는 거의 한달전에 마무리가 되었습니다. 천천히 공부한 걸 정리중인데 잘 안되네요.조만간 스터디 회고한 내용에 대해서도 포스팅을 해야겠네요.회고를 통해서 정말 좋은 경험을 했거든요. 이번에 정리한 내용은 주석입니다.원래 4-5장 같이하려고 했는데 못했어요.ㅠㅠ혹시라도 도움이 되시길 바랍니다.

클린 코드 스터디를 시작했습니다. 열정적인 분들과 함께해서 참 재미있습니다. 책도 볼 때마다 저를 채워주는 느낌이 들어서 너무 좋습니다. 팀 내에서 공유를 좀 해보고자, 발표자료를 만들어 보았습니다.책 배끼기 수준이지만, 팀원분들께 어떻게 하면 쉽게 설명할까 많이 고민했습니다. 다음 번에는 예제 코드들도 제가 만든 것들로 채울 수 있었으면 좋겠습니다. 클린코드 세미나 Clean code 1-3 from Yeomyeong Woo

1. 구구절절 설명 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락을 하고 자동으로 내용이 갱신되도록 하는 방식입니다. 상태가 바뀌는 객체를 주제(Subject)라고 하고 그 주제의 상태에 의존하는 객체를 옵저버(Observer)라고 하며, 주제와 Observer가 일대다( one-to-many)의 의존성을 갖습니다. 위 클래스 다이어그램을 보실까요. 주제가 있죠. 주제에서 옵저버 인터페이스를 구현한 클래스들을 추가 삭제할 수 있습니다. 보통 리스트의 형태로 옵저버들을 저장하고 있습니다. 그리고 notifyObserver를 통해서 옵저버들을 update해줍니다. 이처럼 주제와 옵저버들은 일대다 관계를 맺고 있습니다. 2. 특별한 특징 옵저버들은 주제에 의존성을 가지고 주제가 갱신될 때 ..