Software Engineering Note

착실하게 따르기만 해도 우수한 설계가 나오는 간단한 규칙! 켄트 벡은 다음 규칙을 따르면 설계는 "단순하다"고 말한다. (중요도 순) 1. 모든 테스트를 실행한다.2. 중복을 없앤다.3. 프로그래머의 의도를 표현한다.4. 클래스와 메소드 수를 최소로 줄인다. 모든 테스트를 실행하라 테스트가 불가능한 시스템은 검증도 불가능 => 검증이 불가능한 시스템은 절대 출시하면 안된다. 테스트가 가능한 시스템을 만들려고 애쓰면 설꼐 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 쉽다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다. (선순환) 리팩터링 코드..

시스템 제작과 시스템 사용을 분리하라 제작(construction) 과 사용(use)는 다르다. 소프트웨어 시스템은 준비과정과 런타임 로직을 분리해야 한다.=> 관심사의 분리 객체를 생성하는 것과 객체를 사용하는 것을 분리해야 한다는 것이 주된 이야기 - Main 분리 생성관련 코드는 모두 main 또는 main이 호출하는 모듈로 옮기고 나머지 시스템은 이미 객체가 존재한다고 가정한다. main -> application (application은 main이나 객체가 생성되는 과정을 전혀 모른다.) - 팩토리 application에서 객체를 생성하는 시점을 정하고 싶을때가 있다. 이런때는 팩토리를 구현에서 application 쪽으로 넘겨준다. - 의존성 주입 (스프링 프레임워크의 DI를 생각하면 된다) ..

kafka 메시지를 처리하는 클라이언트 입장에서는 크게 simple consumer, high level consumer로 나누어진다. 대부분 high level consumer로 문제를 해결할 수 있지만 세세한 컨트롤이 필요한 경우에는 simple consumer를 써야한다. 얼마전에 http api로 데이터를 뒷단에 줘야하는 일이 있었다. 데이터 큐로 kafka를 사용하고 있었는데 여기에 있는 데이터를 넘겨줘야 했다. 그런데 한 번 주고 끝나는 것이 아니라, 과거에 줬던 데이터들을 다시 줘야 하는 경우가 있었다. 그걸 처리하기 위해서 db에 넣었다가 주는 등의 해결책이 거추장스럽게 느껴져 바로 꺼내줄 수는 없을까? 고민했는데 아래와 같이 http client를 만들어둔걸 보고 가능하리라 생각했다. h..

apache kafka home: http://kafka.apache.org/github: https://github.com/apache/kafka kafka 홈에 가보면 "A high-throughput distributed messaging system." 이렇게 소개하고 있다. 처음에는 큐라고 생각하고 접근했는데 큐보다는 훨씬 더 광범위한 기능을 가진, 그야말로 분산 메시징 시스템이다. kafka에는 몇가지 개념이 있는데 대략 이런 것들이 나온다. 원문First let's review some basic messaging terminology: - Kafka maintains feeds of messages in categories called topics.- We'll call processes ..

클래스는 작아야 한다. 클래스의 크기는 책임의 갯수로 센다. 그리고 클래스당 책임은 "1" 이다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. Processor, Manager .. 이런 이름을 나도 많이 사용하는데 아무래도 영어 실력이 부족해서 더 그런듯책임을 명확하게 하고 클래스 이름을 어떻게 지어야할까 고민이 필요하겠다. 클래스 설명은 if, and, or, but을 사용하지 않고 25 단어 내외로 가능해야 한단다. 단일 책임 원칙 (Single Responsibility Principle) 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다. 많은 책임을 떠안은 클래스들을 우리가 자주 보는 이유? "돌아가는 소프트웨어 -> 깨끗하고 체계적인 소프트 웨어" 이 과정으로 들어가야 하는데 ..

TDD가 보편화 되고있지만, 그 본질에 대하여 하지만 우리 분야에 테스트를 추가하려고 급하게 서두르는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다. 그런면도 없지않아 있는듯.. TDD법칙 세가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째 법칙: 컴파일은 실패하지않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 필요한 코드만 작성하는 것이 핵심! 깨끗한 테스트 코드 유지하기 테스트 코드를 깨끗하게 유지해야 한다.깨끗하지 않으면 테스트 코드는 점점 부담이 될 것이므로, 실제 코드를 만드는 시간보다 테스트 코드..

문제: PI / 동적계획법 원주율을 외운다는 스토리는 뒤로하고 문제의 핵심은 끊어읽는 모든 경우를 어떻게 처리해야할까? 이다. 어떻게 돌아가는지 좀 써보자. 앞에서부터 3을 끊고, 나머지 처리앞에서부터 4를 끊고, 나머지 처리앞에서부터 5를 끊고, 나머지 처리 뒷 부분, 나머지 처리들도 마찬가지로 반복된다. 그런데, 저걸 그때그때 모두 계산하면 너무 오래 걸리잖아? 어차피 중복이 있을 것같단 말이지.. 예를들어 8까지 읽었다고 치자. 그러면 처리:남은길이 = 8:N 이 될텐데, 이 조합으로 access할 경우가 있다는 거다. 그러니까 저런 경우는 한 번 계산한걸 저장해두고 써먹자.. 이렇게 해서 쥐어짠 코드는 다음과 같다. 대충 이런 그림.. int fn(string str) { int minCost =..

https://www.coursera.org/course/reactive 2015년 4월부터 6월까지.. 플젝하면서 도움을 얻기위해 수강한 강의. 총 세명의 교수가 파트를 나누어 설명한다. (Martin Odersky, Erik Meijer, Roland Kuhn) 개인적으로 actor를 설명한 쿤 아저씨가 가장 친절하게 느껴졌고, 플젝에 가장 큰 도움이 된듯하다. 마이어 아저씨는 약간 해커 스타일? (대충설명..;;) 과제 제출기한이 하루 밀릴때마다 점수 20% 삭감 정책이라 감점을 두 번정도 당했다. 과제 하느라 몇 주 주말은 날라갔지만 그래도 배운게 많아서 뿌듯하다. (많겠지..?) 마지막 과제는 테스트 통과에만 급급해서 전체적으로 이해를 하지못했다. 그래서 아쉽다. akka를 이용해서 뭔가를 해볼..

https://www.coursera.org/course/algo 2013년에 들었던 수업.. 알고리즘 문제 푸는것에 관심이 있어 처음 들었던 수업이었다. 교과서를 읽는듯한 수업이 아니고 정말 머리속에 있는 지식을 펼쳐내는 듯한 강의에 감탄 했었지.. 프로그래밍 과제를 풀고 정답임을 확인할때는 어찌나 짜릿했던지.. Part2도 듣고자 하였으나 게으름으로 인해 아직까지 안듣고 있다. 언젠간 들어야지

많은 요인이 있겠지만 나는 개발자가 추구하는 "이상향" 이라고 꼽겠다. 그래서 실력도 중요하지만 자세도 중요하다. 예를들어, 서버 10대에서 뭔가를 설치하거나 로그를 추출해오거나 하는 일이 있다고 해보자. 어떤 개발자는 일일이 들어가서 같은 행위를 10회 반복 할 것이고 어떤 개발자는 무언가를 개발해서 서버 10대에 자동으로 돌린 후 결과를 취합하도록 할 것이다. 내 생각엔 후자쪽이 발전 가능성이 크다. 설령 내가 지금 그 방법을 잘 모른다고 할지라도 알아보도록 노력은 할 것이고 결국에는 이런 자세가 습관이 된다. 요약하자면, 계속해서 자신이 알고있는 방법으로만 문제를 풀것인가? 아니면, 잘은 모르지만 뭔가 세련된 방법으로 풀것인가? 하는 문제로 귀결된다. 이 차이가 10년쯤 되면 두 사람은 정말 다른 ..