Developer Cafe

동시성이 필요한 이유 한 유저의 요청을 처리하는 데에 1초가 필요한 시스템을 생각해 보자. 이 시스템은 적은 유저가 사용할 경우 그럭저럭 괜찮은 퍼포먼스를 보여줄 것이다. 하지만 유저가 늘어남에 따라 모든 유저는 자신보다 먼저 도착한 요청이 끝날 때까지 기다려야만 한다. 이러한 경우 병행성(concurrency)이 여러 유저를 동시에 처리함으로써 처리량을 향상시킬 수 있다. /* Code 1-1 */ public class ClassWithThreadingProblem { private int lastIdUsed; public ClassWithThreadingProblem(int lastIdUsed) { this.lastIdUsed = lastIdUsed; } public int getNextId() {..

창발성(Emergence) 단순한 결합이 복잡한 결과를 나타내는 것을 의미한다. 인간의 뇌를 예로 들면 하나의 뉴런은 인식능력이 없지만 수십억개의 뉴런이 결합하게 되면 자기 인식이 발생하는 현상을 말하는 것. 이 창발성은 명령을 내리는 조정자 없이 각 부분의 의사소통으로 자기 조직화를 이루게 되고 이러한 밑으로 부터의 힘은 예기치 못한 기능을 발현하는 힘쉽게 생각하면 집단 지성과 같은 것이 이에 해당한다고 볼 수 있는 것. 즉 창발적 설계란 어떤 규칙과 원칙에 따라 설계를 하게 되면, 그것들이 모여 아주 좋은 거시적 설계가 된다고 보면 될 듯. 우리들 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다. * 모든 테스트를 실행한다. * 중복을 없앤다. *..

JAVA Convention에 따르면 가장 먼저 변수 목록이 나온다. static public --> static private --> private 인스턴스 --> (public은 필요한 경우가 거의 없다) 변수목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출 하는 공개 함수 직후에 나온다. 즉, 추상화 단계가 순차적으로 내려간다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 하는 것은 아니다. 우리에게 테스트는 중요하므로 테스트를 위해 protected로 선언해서 접근을 허용하기도 한다. 하지만 비공개 상태를 유지할 온갖 방법을 강구하고, 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야 한다! 클래스는 첫째! 작아야한다. 둘째! 작아야한..

TDD 법칙 세 가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다. 이렇게 일하면 매일 수십 개, 매달 수백 개, 매년 수천 개에 달하는 테스트 케이스가 나온다. 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 테스트는 유연성, 유지보수성..

오류 처리는 중요하다. 하지만 로직을 헷갈리게 만드는 오류처리는 나쁘다. (Error handling is important, but if it obscures logic, it's wrong.) 리턴코드 대신 Exceptions를 사용하라 예전 프로그래밍 언어들은 exceptions를 제공하지 않았다. 그 경우, 개발자들은 에러 flag를 set하거나 에러 코드를 리턴, 호출하는 측에서 예외처리를 해줘야 했다. 하지만 이러한 방식은 예외처리를 잊어버리기 쉽고 로직을 헷갈리게 하기 쉽다. 그러므로 exceptions를 사용하자. 겉보기에만 아름다운 코드가 되는게 아니라 "실제 로직"과 "예외처리" 부분이 나뉘어져 필요한 부분에 집중할 수 있게 된다. // Bad public class DeviceCont..