블로그
-
이벤트와 명령
자주 사용되는 중개(brokered) 메시지 유형으로 이벤트(events)와 명령(commands)이 있다. 두 메시지 유형은 구현의 일부가 비슷할 수 있지만 일반적으로 서로 다른 특징을 갖는다.
-
쓸모없는 Java 패키지 이름 관습
Oracle은 이 페이지에서 다음과 같이 패키지 이름 관습을 제안한다.
Companies use their reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
관습 제안의 이유는 이렇다.
This works well unless two independent programmers use the same name for their packages. What prevents this problem? Convention.
이건 전통인가 악습인가?
-
커밋 메시지 주도 개발
나는 자신이 없는 코딩을 할 수록 계획을 작게 나눈다. 작은 계획을 실천하도록 사용하는 도구 중 한가지는 코드를 쓰기 전에 내가 어떤 코드를 쓸 지 커밋 메시지를 먼저 작성하는 것이다. 누군가에게 이 기법을 소개할 때에 ‘커밋 메시지 주도 개발’이란 표현을 쓴다.
-
좋은 코드란 무엇인가
많은 프로그래머들이 좋은 코드에 대해 얘기한다. 최근 코딩 경험이 적은 한 주니어가 나에게 좋은 코드는 유지보수 비용을 낮춘다고 말했다. 반면 잘 훈련되고 경험 많은 프로그래머들로부터는 그런 확신에 찬 얘기를 듣기 어렵다. 어떤 코드가 좋은 코드인가? 요즘 유행하는 클린 코드가 좋은 코드인가? 모르겠다. ‘코드’가 뭔지는 안다. 그럼 ‘좋은’이 뭔지만 분명해지면 좋은 코드도 이해할 수 있을 것 같다.
-
React에는 '함수형 컴포넌트'가 없다
이 글이 작성되는 시점에 React에는 ‘함수형(functional) 컴포넌트’가 없다. 내가 미쳤다고? 훗. 바로 증명하겠다. 지금 당장 공식 사이트에 들어가서 ‘functional component’라는 말이 나오는지 눈씻고 찾아보라. 한국어 사이트에 들어가서 ‘함수형 컴포넌트’라는 말도 찾아보라. 검색 기능도 제공하니 몇 초면 내가 제정신이란 걸 알게 될거다. React는 함수형 컴포넌트란 걸 제공하지 않는다.
하지만 넓은 인터넷 세상엔 React와 관련해 ‘함수형 컴포넌트’ 또는 ‘functional component’라는 말이 넘친다. 국내에 발행된 각종 서적 역시 마찬가지다. 어떻게 된거야?
-
이벤트 소싱의 본질
이벤트 소싱은 그렇게 어렵지 않다. 이벤트 소싱 패턴은 명령 패턴, CQRS, EDA, DDD 등과 자주 함께 설명되지만 그것들은 이벤트 소싱과 조합될 수 있는 설계 도구일 뿐 이벤트 소싱의 핵심이 아니다. 이벤트 소싱의 본질은 함수형 데이터 기록과 복원이다. 이벤트 소싱을 사용하는 시스템은 과거의 이벤트에 기반해 입력을 새로운 이벤트로 변환한다. 시스템의 이벤트 스트림을 만들어가는 과정이 이벤트 소싱의 정수다.
-
정말로 테스트 대역이 필요한가
얼마전 주니어 동료가 내 코드를 리뷰하며 이런 질문을 했다.
의존 대상을 추상화 해서 테스트 대역을 사용하면 테스트 조건을 설정하기 쉬울 것 같은데 왜 실제 코드를 사용했나?
처음 받는 질문이 아니다. 그동안 같은 질문을 여러 프로그래머들에게서 수십 번은 받았다. 테스트 대역(test double)보다 DOC(depended-on component)를 선호해야 한다는 주장이 최근에 시작된 건 아니지만 아직 많은 프로그래머들이 단위 테스팅을 위해 테스트 대역이 필수라고 생각한다.
다른 주니어 동료가 반문했다.
테스트를 편하게 하기 위해 운영 코드 설계를 변경하는 것이 옳은 선택인가?
-
MV* 패턴에서 모델이란 무엇인가
두괄식으로 결론부터 제시한다.
“Models represent knowledge.” - MODELS - VIEWS - CONTROLLERS, 1979
-
당신의 시스템은 도메인 주도 설계에 기반하는가
당신의 시스템은 도메인 주도 설계에 기반하는가?
이런 질문을 종종 받는데 난 그렇게 생각하지 않는다고 답한다. 도메인 전문가와의 긴밀한 협력 없이는 도메인 주도 설계(domain-driven design)의 의미와 가치가 급감하는데 이게 소프트웨어 전문가의 노력만으론 해결되지 않더라. 도메인 전문가도 도메인 주도 설계의 철학과 방식에 어느 정도는 공감을 가져야 한다. 그런데 프로그래머들도 도메인 주도 설계를 잘 이해하지 못하는데 어떻게 비즈니스 조직을 설득할 것인가?
-
현실 세상의 TDD
현실 세상에서 TDD는 가능하지 않다거나 효율이 너무 떨어져 쓸모없다는 주장은 지겹도록 들어왔지만 여전히 안타깝다. 나는 2018년에 이런 답답함을 조금이라도 풀어보고자 페이스북을 통해 5개월간 약 60명을 대상으로 ‘TDD 참관’이라는 행사를 진행했다.
-
TDD는 설계 방법론이 아니다
소셜 미디어에서 국내 저자의 어떤 서적에서 발췌했다는 다음 문장을 발견했다.
TDD는 설계를 위한 기법이다.
나는 그 책을 읽지 않았기 때문에 전후 맥락을 모르지만 만약 이 문장을 통한 작가의 의도가 TDD(Test-Driven Development)를 설계 방법론이라고 말하는 것이라면 그 위험한 생각에 서슴치 않고 반대하겠다. 나는 TDD를 즐겨 사용하지만 TDD가 잘 못 사용되어 프로젝트나 제품에 나쁜 영향을 미치는 것을 바라지 않는다.
-
코딩 시험과 TDD
구직 과정에 코딩 시험이 있었다. 면접관의 컴퓨터와 응사자의 컴퓨터가 코딩 시험 도구로 연결되어 면접관이 응시자의 코딩을 지켜보거나 개입할 수 있는 환경이었다. 어떤 문제의 답 코드를 쓰다 10줄 이상이 되니 자신감이 떨어져 TDD를 사용하기로 했다. 여기서 나는 흥미로운 경험을 했다.
-
소프트웨어 테스팅의 False Positive
False Positive는 이진 분류(binary classification) 실험 오류 중 하나로 통계 실험에서는 1종 오류(Type I Error)라고도 부르며 소프트웨어 테스팅에서도 쓰이는 용어다. 하지만 이진 분류와 통계 실험에 대한 배경지식이 없는 경우 소프트웨어 테스팅의 False Positive는 본래의 뜻과 반대의 의미로 잘 못 사용되곤 한다. 언어가 잘 못 사용되면 당연히 의사소통 장애로 이어진다.
-
TDD가 해결해 주는 것들
2014년에 DHH는 ‘TDD is dead. Long live testing.’이라는, 제목이 아니라 내용이, 다소 황당한 글을 썼고 얼마 후 Kent Beck은 관련된 글을 썼다.
DHH가 TDD를 죽여서 TDD를 대신할 방법을 찾아야 한다는 글인데, 제대로 읽었다면 누구도 이것이 Kent Beck이 TDD를 떠난다고 말하는 글이라고는 생각하지 않을 것이다. 내 가설의 증거는 댓글들이다. 재미있으니 댓글들도 한 번 읽어보기를 추천한다.
그럼 실제 내용은 뭘까? 프로그래머가 TDD를 통해 얻을 수 있는 가치의 나열이 대부분이고 나머지 조금은 DHH에 대한 조롱이다. 나는 여기에 나열된 TDD의 효과 모두를 느껴왔고 그래서 TDD를 사용한다. 그리고 이 가치들이 더욱 알려지기를 바라는 마음에 한국어로 번역했다. 내 영어 실력은 아주 형편 없어서, 노력했지만 두 구절은 충분히 이해하지 못해 직역했다. 표시해 뒀으니 좋은 해석 의견이 있다면 대환영이다. 이후로는 모두 내 글이 아니라 번역이다.
-
MVVM 아키텍처 패턴
MVVM(Model/View/ViewModel) 패턴은 UI를 가지는 응용프로그램을 위한 아키텍처 패턴(architectural pattern)이다. MVVM 패턴은 MVC(Model/View/Controller) 패턴의 변형으로 뷰의 추상화를 만드는 것이 핵심이다. 뷰의 추상화는 재사용할 수 있고(reusable) 테스트하기 쉽다(testable). 뷰의 추상화를 통해 응용프로그램 구조는 단순해지고, 이상적으로, 시각 디자인과 표현 논리를 독립적으로 구현할 수 있다.
-
두렵다면 테스트를 작성하라
얼마전 다음과 같은 코드에 매개변수
param에 대한null여부 검사가 필요한지 의견을 묻는 글을 발견했다.public void MyCode(string param) { if (TheirCode(param)) { DoSomething(); } } -
스타트업에 취업하기
박재성님의 ‘최근 구직, 구인 글을 보면서 느끼는 단상’이란 글을 읽었는데 무척이나 공감했다. 특히 다음 구절에서 생각나는 일화가 있어서 적어본다.
다양한 스펙을 쌓는 것에 집중하기 보다 프로그래밍 자체를 즐기는 진정성을 보여주면 더 좋겠다. 경험도 너무 많은 경험보다는 한 가지 경험이라도 깊이 있는 경험을 하면 좋겠다. 프로그래밍 자체에 대한 열정은 자연스럽게 드러난다.
RSS 구독