욱'S 노트

도메인 모델은 공통언어의 핵심이자 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다. 모델기반의 의사소통으로 꼭 UML을 사용해야 하는 것은 아니다. 어떠한 의사소통 수단을 사용해도 무방하며 형식에 얽매이지않는 다이어그램이나 텍스트문서도 가능하다. 또한 코드 자체를 통할 수도 있다. UBIQUITOUS LANGUAGE 도메인 전문가와 개발자가 각자 자기의 언어를 사용하면 안된다. 이는 정보 흐름의 병목으로 이어지며 그들이 번역하는 바도 정확하지 않다.유비쿼터스 언어를 사용하지 않을때 발생하는 문제는 다음과 같다. - 각자의 언어로 얘기를 하기 때문에 토론이 되지 않는다. - 용어와 코드의 정보가 단절된다.- 번역은 의사소통을 무디게 하고 지식탐구를 빈약하게 만든다. 브레인스토밍과 실험 중 언어에 공..

효과적인 모델링의 요소 모델과 구현의 연계 - 반복주기 내내 연결고리를 유지해야 한다.모델을 기반으로 하는 언어 정제 - 누구라도 모델의 내용을 별도 해석 없이 이해할 수 있어야 한다.풍부한 지식이 담긴 모델 - 데이터 스키마뿐만 아니라 행위와 규칙까지 모두 표현모델의 정제 - 중요한 개념은 계속해서 더해져야 하며, 쓸모가 없어진 개념은 제거되어야 한다.브레인스토밍과 실험 - 계속해서 토의해야 하며 실험실로 옮겨 테스트를 해야 한다. 지식탐구 폭포수개발 방식 - 업무전문가 -> 분석가 -> 프로그래머, 피드백이 전혀 없어 실패할 수 밖에 없음이터레이션 방식 - 모델을 만들지 않음. 추상화가 되지 않아 지식 축적이 실패. 모델과 구현이 떨어짐 즉 업무전문가, 분석가, 프로그래머가 함께 모델을 만들어야 하며..

도메인이란? 소프트웨어로 해결하고자하는 문제 및 관심사. 일반적인 경우 비즈니스적인 성격을 띄지만, 몇가지 예외적인 예로 인프라스트럭처 자체가 도메인이 될 수도 있다. 소스관리 시스템, 배치스케쥴링 시스템등은 소프트웨어 자체가 도메인일 수 있다. 도메인 모델이란 ? 도메인주도설계에서 모델이란 도메인의 추상화이다. 즉 현실세계에 실재하는 문제에 대한 지식을 선택적으로 단순화하고 문제해결을 위해 구조화한 형태이다. 이는 현실을 사실적으로 반영하지 않고 문제해결을 위해 인위적으로 단순화된다. DDD에서 모델의 중요성 모델과 설계는 서로 영향을 주며 구체화된다. - 모델은 구현까지 긴밀하게 유지되며 유지보수되어야 한다.모델은 모든 팀구성원이 사용하는 유비쿼터스 언어이다. - 모든 구성원들은 모델을 통해서 의견을..

외부 코드 살펴보기 인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 긴장이 존재한다. 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. Map과 같은 예를 볼 때 Map은 매우 다양한 기능을 제공하고 이로 인해 시스템에 다양한 영향을 끼칠 수 있다. 경계 인터페이스를 사용할 떄는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. Map 인스턴스를 인자로 사용하거나 반환값으로 이용하지 말아야 한다. 학습 테스트 외부 코드를 익히기는 어렵다. 외부 코드를 통합하기도 어렵다. 곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 간단한 테스트 코드를 작성하여 외부 코드를 익히자. 학습테스테에 드는 비용은 없..

오류 코드보다 예외를 사용하라 얼마 전까지만 해도 예외를 지원하지 않는 프로그래밍 언어가 많았다. 예외를 지원하지 않는 언어는 오류를 처리하고 보고하는 방법이 제한적이었다. 당시의 방법에서는 호출자의 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 불행히도 이 단계는 잊어버리기 쉽다. Try-Catch-Finally 문부터 작성하라 try 블록에서 무슨일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. 그러므로 예외가 발생할 코드를 짤때는 try-catch-finally 문부터 시작하는 편이 낫다 Unchecked 예외를 사용하라 확인된 예외가 반드시 필요하지 않다는 사실이 분명해졌다. 다양한 언어(C#, C++, 파이썬, 루비)에서 checked exce..

변수를 비공개로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 자료 추상화 변수 사이에 setter, getter를 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 아무 생각 없이 setter, getter를 추가하는 방법이 가장 나쁘다. 자료/객체 비대칭 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 기능을 추가하기 쉽다. 반면 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코드는 새로운 함수를 추가하기 ..

적절한 행 길이를 유지하라. Fitness의 경우 5000줄이 넘는 거대한 시스템이지만 각각의 클래스를 200줄 안팎으로 유지할 수 있었다. 시스템이 크다고 개별의 클래스의 코드가 길어질 이유는 없다. 신문 기사처럼 작성하라. 소스 파일도 신문 기사와 비슷하게 작서한다. 이름은 간단하면서도 설명이 가능하게 짓는다. 소스 파일 첫 부분은 고차원의 개념과 알고리즘을 그리고 아래로 내려갈수록 의도를 세세하게 묘사한다. 개념을 빈 행으로 분리하라. 패키지 선언부, import문, 각 함수 사이에 빈행이 들어간다. 간단한 규칙이지만 심오한 영향을 미친다. 세로밀집도 줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다. 즉 서로 밀집한 코드의 행은 세로 가까이 있어야 한다. 변수는 사용하는 위치에 최대한 가..

코드는 항상 변화하고 진화한다. 불행하게도 주석은 언제나 따라 가지는 않는다. 주석은 필요악이다. 주석은 나쁜 코드를 보완하지 못한다. 자신이 저지른 난장판을 주석으로 설명하려 하는 대신에 그 난장판을 깨끗이 치워라. 코드로 의도를 표현하라. 코드를 주석으로 설명하지 말고, 더 명확하게 클래스나 함수로 표현해라. 좋은 주석 라이선스에 관한 주석을 붙이는 것은 타당하다. 의도를 설명하는 주석은 옳을 수 있다. 앞으로 할 일을 TODO 주석으로 남겨두면 편하다. 공개 API를 구현했다면 Javadocs를 남겨야 한다. 나쁜 주석 주절거리는 주석.코드의 내용을 그대로 설명하는 주석은 필요가 없다.자바docs를 만들기 위한 의무적인 주석도 좋지 않다. /**** @param title CD 제목*/ 이력을 기록..

작게 만들어라 함수의 첫번째 규칙은 작게, 두번째 규칙도 작게이다. public static String renderPageWithSetupsAndTearDowns (PageData pageData, boolean isSuite) throws Exception {if (isTestPage(pageData))includeSetupAndTearDownPages(pageData, isSuite);return pageData.getHtml();} 블록과 들여쓰기는 최대한 작아야 한다. if/else/while 이 들어가는 블록은 한 줄이어야 한다. 함수의 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. 한가지만 해라. 버퍼를 생성하고 상속된 페이지를 검색하고, 경로를 랜더링한다면 각각을 함수의 쪼개라. 함수를..

의도를 분명히 밝혀라. 의도가 분명한 이름은 정말로 중요하다. 아래 예를 보면 로직의 복잡성은 변경된 것이 없지만 명명만 고침으로써 이해하기 훨씬 쉬워졌다. public LIst getThem() {List list1 = new ArrayList(); for (int[] x : theList) {if (x[0] == 4) list1.add(x); return list1;} public List getFlaggedCells() {List flaggedCells = new ArrayList(); for (Cell cell : gameBoard) if (cell.isFlagged())fraggedCells.add(cell); return flaggedCells;} 그릇된 정보를 피하라. accountList ..