Software Engineering Note

클라이언트/서버 예제에서는 단일 스레드로 동작하던 서버를 다중 스레드로 변경하는 것과 코드를 깨끗하게 변경하는 내용을 다룬다. 다중 스레드를 적용하기전에 어플리케이션이 어디서 시간을 보내는지 알아야 한다. I/O - 소켓 사용, 데이터베이스 연결, 가상 메모리 스와핑 기다리기 등에 시간을 보낸다. 프로세서 - 수치계산, 정규표현식 처리, 가비지 컬렉션 등에 시간을 보낸다. 프로세서 연산에 시간을 보내는 프로그램은 스레드를 늘인다고 빨라지지않는다. CPU 사이클은 한계가 있기 때문이다. 다중 스레드 프로그램을 깨끗하게 유지하려면 잘 통제된 몇 곳으로 스레드 관리를 모아야 한다. 아니, 스레드를 관리하는 코드는 스레드만 관리해야 한다. 비동시성 문제까지 뒤섞지 않더라도 동시성 문제는 그 자체만으로도 추적하기..

다양한 코드 냄새에 대한 내용. 수정해야할 부분이 있을때 보통 냄새가 난다는 표현을 한다. 주석 부적절한 정보. 소스코드 관리 시스템, 버그 추적 시스템 등 시스템에 저장할 정보는 주석으로 적절하지 못하다.중복된 주석. 코드만으로 충분한데 굳이 설명을 붙이는것주석으로 처리된 코드를 발견하면 즉각 지워버려라! 소스코드관리 시스템에 어차피 남으니까 환경 빌드는 간단히 한단계로 끝나야 한다. 모든 단위 테스트는 한 명령으로 돌려야 한다. 모든 테스트를 한 번에 실행하는 능력은 아주 근본적이고 아주 중요하다. 함수 너무 많은 인수. 넷 이상은 그 가치가 아주 의심스러우므로 최대한 피한다.플래그 인수. boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다. 피할것죽은함수. 아무도 호출하지 않는 함수는..

https://www.coursera.org/learn/progfun1 6월부터 7월 말까지 수강했다.총 5개 과제를 코스가 끝나기전에 과제당 8/10점 이상으로 통과하면 된다. 늦게 제출한 댓가로 페널티도 없다. 과거에 비해 좀 완화된 느낌인데, 시간이 유동적인 사람들에게는 유리한면도 있지만 대책없이 미뤄버리면 나중에 감당이 안되기때문에 조심해야한다. 심지어 지금까지 획득한 스코어를 가지고 다음열리는 코스로 넘어갈 수 있다. 여러모로 수강하는 사람들에게는 유연해졌지만 바짝 쪼여줘야 어떻게든 끝내는 사람들에게는 수강이 언제 끝나게 될지 모르는 코스가 되었다. 최종 점수가 2% 부족한 98%. 딱 어정쩡한 나같다. 또한, scala 스페셜 코스를 준비해두었다. https://www.coursera.org/..

이 장에서는 명령행 인수(argument) 구문분석기를 구현하고, 점진적으로 개선하는 것을 보여준다. 코드가 대부분이라 여기에 적을수는 없지만 모두 타이핑 해봤다. (진짜다..) 따라하면서 느낀점은, 테스트를 꼼꼼하게 작성하고 개선을 정말 조금씩 한다는거다. 나는 보통 한번에 막 고치는 스타일인데 급한 성격을 가라앉히고 천천히 개선하는 습관을 들여야겠다. 읽다가 옳다구나! 하는 문구정도만 정리해본다. 지난 경험에서 얻은 교훈=> 프로그래밍은 과학보다 공예에 가깝다는 사실. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다. 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. => 돌아올 수 없는 강을 건너지 말고 조금씩 개선. TDD를 ..

동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. => "무엇"과 "언제"를 분리한다. 구조적 관점: 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 처리량 개선: 응답을 기다리는 웹 정보 수집기, 많은 사용자를 처리해야 하는 시스템 등에서 동시성이 요구됨 동시성에 대한 미신과 오해 동시성은 항상 성능을 높여준다 => 동시성은 "때로" 성능을 높여준다.동시성을 구현해도 설계는 변하지 않는다 => 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. => 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지 알아야 한다. 동시성에 대한 타당한 생각동시성은 다소 부하를 ..

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

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

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

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

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