개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
하나의 함수는 한가지만 해라.
메타 데이터로 처리 하는 것은 아주 중요하다. 현업에서도 피가 되고 살이 된다. 심지어 야근시간도 줄여준다.
도도새 불쌍하다.
TIL (Today I Learned) 날짜
2022.03.26
오늘 읽은 범위
5부. 구부러지거나 부러지거나
책에서 기억하고 싶은 내용을 써보세요.
결합도 줄이기와 디미터 법칙
T36 모듈간의 결합도를 최소화하라
디미터 함수법칙
논리적 결합도와 물리적 결합도
소프트웨어 개발의 지혜
Large-Scale C++ Software Design
T37 통합하지 말고 설정하라
ini 설정파일
propert 파일
conf 파일 등
도메인언어와 유사한 방식이다.
T38 코드에는 추상화를, 메타 데이터에는 세부내용을.
결합도를 줄인다. 유연하고 적응성이 있는 프로그램을 만든다.
세부사항을 코드 밖에 두어서 강하고 추상적인 디자인을 만들 수 있다.
수정사항이 있을 때마다 다시 컴파일할 필요가 없다.
메타데이터는 도메인언어에 가깝다.
설정파일을 읽는 시점
많은 프로그램들이 설정을 처음 시작 시에만 읽는다.
설정을 바꾸면 프로그램을 재시작해야 한다. 불편하다.
오랜시간동안 실행하는 프로그램이라면 설정이 변했을 때 자동으로 불러와서 반영되게 하는 것이 좋은 방법이다.
예를 들면 톰캣이 있다. 톰캣은 설정을 변경해도 재시작할 필요가 없다. 자동으로 반영되기 때문이다.
EJB 엔터프라이즈 자바 빈은 분산, 트랜잭션 기반 환경의 프로그래밍을 단순화해 주는 프레임워크다. 트랜잭션을 자동으로 처리해주기 때문에 따로 코드를 수정할 필요가 없다.
도도코드를 만들지마라. (모리셔스섬의 도도새는 환경에 적응하지 못해서 멸종당했다.)
어떤 것이 메타 데이터로 표현하기 좋으며, 어떤 것이 코드로 처리하기에 나은가?
통신포트 : Y
텍스트 편집기의 문법 강조 기능 : Y
그래픽 장치 불러오기 : N
파서 : Y
단위 테스트용 샘플값 : N
시간적 결합
T39 작업흐름 '분석'을 통해 동시성을 개선하라.
T40 서비스를 사용해서 설계하라
T41 언제나 동시성을 고려해 설계하라
모듈은 잘 정의된 단 하나의 책임만 가지는 것이 핵심이다. (253p)
로버트 마틴의 <Agile Software Development> 참조
이벤트 드리븐 방식의 유의점
출판/구독 구조와 CORBA 이벤트 서비스 :
밀기 Push : 이벤트를 구독하는 클라이언트에게 통보하기
끌기 Pull : 클라이언트들이 주기적으로 폴링을 하며 체크하는 방식
T42 모델에서 뷰를 분리하라
T43 칠판을 사용해 작업흐름을 조율하라
JavaSpace, T Space
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
칠판 모델은 잘 상상이 안되다가 후반부에 연습문제를 보다가 생각이 났다. 제니퍼 소프트에서 개발한 네트워크 모니터링 시스템 같은 경우엔 칠판모델이 적용된다. 인프라에 대해 전체적으로 감시하면서 적정한 수준으로 트래픽이 유지되고 있는지 감지하는 게 필요하기 때문이다. 만일 아주 단순히 음악을 재생하는 프로그램이거나 사진을 출력하는 프로그램이라면 칠판 모델은 필요하지 않다. 적절히 병렬 작업 큐로 작업부하만 분산해줘도 충분하다.
모델,뷰,컨트롤러 패턴은 MVC 패턴이라고 한다. 뷰와 컨트롤러는 밀접하게 연결이 되는데, 시용자의 유형에 따라서 같은 데이터라도 다르게 보기를 원할 수 있으므로 뷰는 다양하게 수정할 수 있어야 하고, 수정하거나 제공하기도 편리해야 한다고 생각한다. 물론 데이터나 모델, 컨트롤러는 왠만해서 변경되서는 안된다.
로버트 마틴이라는 이름이 자주 보인다. 리팩터링의 저자이기도 한데, 역량이 좋은 사람은 어디에서든 눈에 띄게 되는 것 같다.
메타 데이터라는 단어는 처음 들어봤지만, 실무에서 상당히 자주 쓰이고 있다. 외부 설정파일로 파라메타값을 빼서 사용자가 설정할 수 있는 데이터를 말한다. 메타 데이터가 없다면 작은 수정이 하나 있을 때마다 개발자가 새로 빌드를 해서 사용자에게 넘겨줘야 되는데, 이는 사용자와 개발자 모두에게 굉장히 피곤한 작업이다. ini 설정에서 값만 바꾸면 되는 일인데, 몇분만에 가능한 일을 훨씬 많은 노력을 기울여서 고쳐줘야 되기 때문이다. 즉 이걸 안해주면 몇 분짜리 작업이 몇 시간이 되어 버리는 것이다.
출판/구독 모델은 우리가 쓰고 있는 스마트폰의 PUSH 알림 시스템을 생각하면 쉽다. 알림을 받겠다고 설정하면 구독자가 되는 것이고, 시스템에서 알림을 발송했을 때, 스마트폰 앱에서 수신 이벤트를 발생시킨다. 그러면 해당 알림이 스마트폰에 나타나게 된다. 기술적으로는 이 정도이지만, 법적으로는 야간 알림은 따로 수락하게 되어 있어서 이것도 정책적으로 구분하는 처리를 해줘야 된다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
도메인언어 : 의미론적으로도 익숙하지않고, 실질적으로 어떻게 쓰면 좋을지 감이 올락 말락한다. 좀 더 디테일하게 파볼 여지가 있다.
오늘 읽은 다른사람의 TIL
파이프라인이나 FSM을 내가 읽는 책에서는 발견하지 못했는데, 구판(2014년 신판 1쇄)이라서 그런지 감상포인트가 살짝 다른 것 같다는 느낌을 받았네요.