소프트웨어에서의 깨진 유리창의 법칙 깨진 유리창 이론이 범죄나, 사람들의 실제 생활에만 존재하는 것은 아니다. 본 포스트에서는, 소프트웨어 개발과 깨진 유리창 법칙의 관계에 대해 정리한다. 깨진 유리창/창문의 법칙이란? 우선 깨진 유리창 이론에 대해서는 아래의 글을 참고하자. 깨진 유리창의 법칙이란? 깨진 유리창의 법칙에 대해 어떤 장소/ 건물에 깨진 유리창이 있다면 어떤 생각이 들까? '하나만 봐도 열을 안다'라는 속담을 생각해 보자. 한 곳에 문제가 있다면, 다른 곳은 굳이 보지 않아도 luran.me 소프트웨어에서의 깨진 창문 팀이 소프트웨어에 어떤 변경을 한다고 가정하자. 시간에 쫓겨, 혹은 개발할 당시에 정보의 부족으로, 혹은 MVP 버전으로 개발해야 하는 상황이라서 등등. 제대로 만들었어야 하..
Law of Demeter 개요 소프트웨어 엔지니어링 관점에서 소개되는 법칙 중 하나로, Law of Demeter (디미터/ 데메테르)의 법칙이 있다. 줄여서 LoD라고도 하는데, 이 법칙이 뜻하는 바는 principle of least knowledge (최소 지식의 원칙)이다. 이 가이드라인은 1987년말, Northesatern Univsersity의 Ian Holland에 의해 소개되었다. Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to st..
개요 본 포스트에서는 Heroku 플랫폼을 통해 소개된 개념인 12-Factor 애플리케이션 요소에 대해 정리한다. SaaS(Software As A Service) 개발 방법론 관점에서 고안해 낸 개념인데, 어떤 애플리케이션이 Cloud 환경에서 잘 동작할 수 있으려면 아래의 12가지 규칙을 잘 준수해야 한다고 하는 것이다. 12요소 (twelve factors) 코드베이스(codebase) 의존성(dependencies) 설정(config) 백엔드 서비스(backing services) 빌드, 릴리즈, 실행(build, release, run) 프로세스(processes) 포트 바인딩(port binding) 동시성(concurrency) 폐기가능(disposability) 개발/프로덕션 환경 동일화..
무려 1967년에 맬빈 콘웨이(Melvin Conway)가 발표한 논문에서 소개한 내용이 요새에도 쓰이고 있다. Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure." 소프트웨어 구조는 그 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 따라간다는 말이지만, 문장의 앞뒤를 바꾸면 우리 나라사람들에게 직관적인 문장이 된다. 즉, 조직 구조/ 조직의 커뮤니케이션 구조가 소프트웨어 구조를 결정한다. 콘웨이 박사의 실험 코볼과 ALGOL 컴파일러를 제작하는 연구팀 여덟 명과 함께 수행한 콘웨이 박사의 실험 결과..
캐시(Cache) 적용 패턴 및 관리 전략 Cache-Aside: Cache 분리 (별도 관리) 캐시는 데이터베이스와 직접 연결되지 않고, 애플리케이션이 주체가 된다. 애플리케이션이 요청을 받으면, 데이터가 캐시에 있는지 먼저 검사를 하며, 그 결과(캐시에 데이터가 로딩되어 있는지 여부)에 따라 다음 액션이 결정된다. 캐시에 데이터가 없다면, 애플리케이션이 캐시에 데이터를 업데이트 한다. 캐시에 대한 의존성이 낮으므로, 캐시가 다운되더라도 원천 데이터베이스로 서비스를 계속할 수 있다. 읽기 요청이 많은 경우에 적합하다. Read-Through: Cache를 통해서 읽기 애플리케이션이 직접 바라보는 것은 데이터베이스가 아니라 캐시가 된다. through 라는 단어가 나타내듯이 캐시가 메인이다. 따라서, 캐..
교살자 무화과나무 패턴 - Strangler Fig Application Pattern 이름이 참 신기한 패턴이다. 무릇 패턴은, 사람들에게 구구절절하게 설명하지 않고, 그 이름만으로도 어떤 개념인지 알기 쉽도록 해줄 수 있어야 한다. 그런데, Strangler Fig Application Pattern 혹은 Strangler Pattern은 무엇이며, 그것을 그대로 번역해 놓은 교살자 무화과나무 패턴은 또 무슨 의도인가? 이름부터 다시 살펴보자 영어권 사람들은 strangler라고 하면 이미 쉽게 알아들었을 수도 있다. 교살자라는 한자도 마찬가지다. 일단 영어 이름과 번역본 이름을 매치해 본다. strangler = 교살자 fig = 무화과나무 보통 fig라는 글자는 figure의 줄임말로 '그림'을 ..
PlanutUML 작성 툴 PlantUML을 작성하기 위한 툴은 여러가지가 있다. Boost Note를 쓰면 별도의 설정을 하지 않아도 곧바로 문서를 작성하면서 코드로 시퀀스다이어그램을 그릴 수 있다. 만약, VS Code를 사용한다면 다음의 포스트를 참고하여 설정하면 된다. 기본 문법 PlantUML을 사용하여 시퀀스다이어그램을 작성하기 위한 주요 규칙을 살펴본다. 문서 작성 규칙 @startuml 작성본문 @enduml의 형식으로 작성하면 된다. 만약, VS Code에 extension을 사용하여, Markdown Preview Extended까지 사용했다면, ```plantuml @startuml 작성본문 @enduml ```과 같이 바깥에 한번 더 감싸줘야 한다. 혹은, @startuml ~ @e..
VS Code에서 PlantUML 사용설정 Boost Note(무료)에서는 기본적으로 제공되는 기능인데, Visual Studio Code에서도 비슷한 설정이 있지 않을까 싶어 설정 하는 방법을 정리한다. 목표는 Boost Note에서 작성하던 방법과 동일하게, Markdown 작성과 PlantUML 작성을 함께 할 수 있도록 하는 것이다. 비교 대상 - Boost Note # Test @startuml Bob -> Alice: Hello @enduml 이렇게 작성하면 아래와 같이 자동으로 렌더링 해준다. 위와 같이, 문서로서의 기능과 다이어그램을 그리는 기능을 온전히 한 세트로 해야 편리하다. VS Code상에서 설정 VS Code에서는 Extension을 통해 해당 기능을 설정해야 한다. Shift ..
Syntax Highlighter로 괄호를 인용할 때, 예를 들어 와 같이 인용하고자 한다면, 막상 인용해보면 위와 같이 표시되는 대신 과 같이 표시되고 만다. 게다가 nested expression이라면, 본인의 의도와는 다른 문서 구조로 표현되어 원치 않는 output을 만나게 될 것이다. 이럴 경우, 다음의 사이트를 사용하여 손쉽게 escape 시키자. Syntax Highlight 시킬 부분에 변환 코드를 복사해 넣으면 될 것이다. http://accessify.com/tools-and-wizards/developer-tools/quick-escape/default.php
UML 다이어그램에서 특히 집합 관계를 표시할 때, 헷갈리는 용어이다. 'A가 B에 속해있다.' 혹은 'B는 A를 포함한다'의 개념을 표현하고자 할 때 사용하는 표기인데, 어떤 경우에 이 관계는 composition 또는 aggregation이라고 말할 수 있는 것일까? 이에 대해, googling을 하던 중, 적어도 나에게는 와닿는 포스팅이 있어 소개하고자 한다. 물론, 단지 이 글 뿐만 아니라 다른 곳으로부터도 참고하였다. 참고 : http://www.bestarticle.org/computer/association-aggregation-and-composition-what-are-they-and-how-do-they-differ/ Aggregation ◇--, 실선으로 표시 대상 객체에 대한 pos..
