M.House

10.2 멋진 다이어그램 그리기훌륭한 다이어그램은 그저 아름다운 그림이 아닙니다. 훌륭한 다이어그램은 아키텍처의 개념적인 토대를 반영한 정확한 모델 입니다. 아키텍트는 상자와 선으로만 그린 다이어그램으로 악명이 높지만, 실상은 추상적으로 그린 수준보다 더 많은 직업이 필요 합니다. 다이어그램으로 다양한 설계 아이디어를 보여줄수 있습니다. 다이어그램은 다른 매체보다 사실적으로 아키텍처를 시각화할 수 있습니다. 다이어그램은 멋지게 만들면 모든 사람이 아키텍처에서 더 수월하게 다가올 수 있습니다.아래처럼 하세요주의하세요범례를 만들어서 다이어그램과 연관된 메타모델을 요약한다.내가 사용하는 용어를 상대가 당연히 알 거라고 단정하지 않는다.(통합 모델링 언어(UML)에서도 함부로 단정하면 안된다.)구체적인 제목을 ..

아이디어를 공유하는 최선의 방법은 아이디어를 손에 잡힐 듯하게 만드는 것 입니다. 아키텍처 다이어그램을 그리는 방법을 배우고 개발자들과 수월하게 대화하는 방법을 알아보겠습니다. 10.1 다양한 관점으로 아키텍처 표현하기그림 한장에 아키텍처의 모든 내용을 담을 수는 없습니다. 다이어그램 하나에 모든 것을 담기보다는 다양한 관점에 기초해 다이어그램을 여러 개에 나눠 담는 게 좋습니다. 여기서 관점이란 특정 이해관계자 또는 그와 긴밀하게 연관된 고려사항의 시각에서 바라보는 것을 의미 합니다. 아키텍처의 경우 여러 이해관계자들의 질문에 답을 할 수 있도록 여러 관점으로 다이어그램을 그릴 필요가 있습니다. 개발진도는 어떻게 되나요? 누가 이 컴포넌트를 만들고 있나요? 품질 속성 시나리오를 충족하기에 부족한 점은 ..

목록을 표현하는 태그태그설명비고순서가 없는 목록 순서가 있는 목록type, start 속성 사용 가능목록 아이템ul, ol 태그의 1촌 자식으로 이 태그만 가능 예시 이틀치 옷 세면도구 수건 학습도구 노트북 필기구 교재 용어와 정의 나열하는 태그 태그설명비고순서가 없는 목록 순서가 있는 목록type, start 속성 사용 가능목록 아이템ul, ol 태그의 1촌 자식으로 이 태그만 가능

9.2 적절한 설계 활동 선택하기디자인 스튜디오의 주최자는 모든 참가자가 '만들기-공유하기-비평하기' 과정을 빠르고 효율적으로 즐길 수 있도록 적절한 활동을 선택해야 합니다. 설계 활동에는 여러가지가 있습니다. 모든 활동이 아키텍처 설계에 적합하지 않습니다. 시스템에 대해서만 생각할 때는 더욱 아키텍처에 집중할 수 있는 아키텍처에 효과적인 활동을 선택해야 합니다. 활동소요시간목적전체적인 맥락과 목표 소개하기15분참가자 모두 능동적으로 참여하며 워크숍에 임하도록 한다.활동 18 라운드 로빈 설계30분지식을 빠르게 융합하고 구분하며 진행한다. 계획상 한 번만 수행하지만 여러번 해도 무방하다.활동 17 그룹 포스터30분알아낸 사항들을 포스터로 만들어서 공유하기 쉽게 한다. 지식의 공감대를 형성포스터로 발표하고..

디자인 스튜디오는 그룹 협업을 장려하고 팀이 짧은 시간 내에 광범위한 아이디어를 낼 수 있는 프로그램을 말한다. 9.1 아키텍처 디자인 스튜디오 계획하기디자인 스튜디오를 진행할 때 엄격하게 제한된 시간을 설정하고 시간 안에 다양한 아이디어를 가능한 빠르게 많이 쏟아내게 합니다. 디자인 스튜디오 워크숍은 3F 원칙(빠르고, 효과적이며, 재미있게)으로 운영하며 설계 의사 결정을 만들어 갑니다. 재미는 참여를 도모해 탐색 과정을 효과적이고 빠르게 만들어 줍니다. 디자인 스튜디오를 진행하면 3가지 유형의 아이디어를 도출할 수 있습니다.구체화할 아이디어 : 어떤 아이디어는 유망해 보입니다. 유망한 아이디어는 모델이나 프로토타입을 만들어 세부사항을 구체화합니다.연구가 더 필요한 아이디어 : 어떤 아이디어는 옳아 보..

모델로 아키텍처를 유추할 수 있지만 함부로 추측했다간 오해를 살 수 있습니다. 하지만 생각해 보면 아키텍처 모델의 대부분은 코드로 온전히 구현할 수 있습니다. 아키텍처 모델을 코드로 구현하면 많은 이점이 있습니다.  8.3 코드로 모델 구현하기8.3.1 아키텍처 용어를 코드에 적용하기추상적인 아키텍처르르 코드로 옮길 때 흔히 겪는 혼란으로 용어 불일치 문제가 있습니다. 아키텍처는 레이어, 서비스, 필터에 대해 이야기하지만 코드는 패키지, 클래스, 메서드를 구현해야 합니다. 모델을 코드에 담는 가장 간단한 방법은 아키텍처의 어휘를 그래도 사용하는 것입니다. 레이어를 사용하는 경우 코드에서도 레이어라고 이름을 짓습니다. 파이프와 필터 패턴을 채택한 경우 클래스 이름도 파이프와 필터로 지정합니다.  모델과 코..

소프트웨어 복잡도가 증가할 때 요구사항을 수정하거나 코드의 일정 부분을 덜어내서 다시 소프트웨어를 좀 더 작게 만들 수 있습니다. 큰 소프트웨어를 나누면 파악하기도 쉽고 관리하기도 수월합니다. 세부적인 사항을 따지기 보다는 한발 물러나서 큰 그림을 보며 다시 생각해보는 시간을 가질 필요도 있습니다.  8.1 아키텍처 파악하기좋은 아키텍처 모델의 장점을 알아보자모델이 곧 디자인 용어 사전이다.요소의 이름을 지을때 이름에 그 의미와 의도가 잘 담겨 있어야 합니다. 우리의 모델을 만들때마다 시스템의 사전이 조금씩 두꺼워집니다. 우리는 이 용어 사전으로 회의하고, 코딩할 때도 이름 짓기에 활용하고 시스템을 바라보는 관점도 만들어갑니다.모델은 관심사를 더 자세한 수준으로 이끌어 준다.소프트웨어 개발은 디테일이 전..

7.5 서비스 지향 아키텍처 패턴service-oriented architecture pattern서비스 지향 아키텍처 패턴(SOA)은 특정 기능을 가진 컴포넌트를 독립적인 서비스로 구현합니다. 시스템은 실행 중에 서비를 조합해 작업을 수행합니다. 다시 말해, 서비스를 사용하는 측에서는 각 서비스가 어떻게 구현되는지는 몰라도 서비스를 불러내고 실행할 수 있어야 합니다.  SOA를 구현하는 방법은 다양합니다. 전통적인 SOA는 SOAPsimple object access protocol통신하는 메서지 버스에 강하게 의존 했습니다. 최신 SOA 구현 방법은 마이크로서비스로 더 세분화하고 더욱 가벼운 HTTP 프로토콜을 서로 잇습니다. 복잡한 조직에서 큰 시스템을 만들때 부서마다 각자 맡은 부분을 구현하도록 ..

노련한 아키텍트는 새로운 문제를 접할 때 사진의 설계 패턴 목록을 뒤적이며 유사한 해법을 찾은 후에야 새로운 설계를 시작합니다. 적당한 패턴을 찾을 때는 문제의 특이사항 몇 가지를 채워 넣은 후에 요구사항에 맞게 조금 수정합니다. 7.1 아키텍처 패턴이란 무엇인가?아키텍처 패턴이란 특정 문제에 대해 재사용할 수 있는 해법입니다. 소프트웨어 아키텍처 패턴은 알려진 몇 가지 구조의 조합으로 품질 속성을 끌어올리는 방법입니다. 문제에 적합한 패턴을 선택하면 함정을 피할 수도 있고 바닥부터 디자인하는 수고를 덜 수도 있습니다. 그 외에도 패턴의 장점이 더 있습니다. 잘 알려진 패턴을 사용하면 대화하고 설득하기에 용이합니다. 그림 한 장이 백 마디 말보다 낫습니다. 패턴은 수천 장의 그림과 같은 효과가 있습니다...

제목 및 본문에 넣는 태그(Tag)는 아래와 같다. 제목, 본문 태그 정리태그 또는 구문설명내용 ~ 제목숫자가 높을 수록 낮은 단계문단각각 줄바꿈이 됨(기본 스타일일 때)줄바꿈닫는 태그 필요 없음., 와 혼용되지도 함가로줄닫는 태그 필요 없음 공백(스페이스)스페이스를 강제로할 때 사용글자를 굵게 중요한내용명시 글자 기울림 위 첨자지수, 서수아래 첨자각주, 변수, 화학식 철자오류표시예전에는 밑줄로 사용더이상 유효하지 않는 정보  주석 처리 방법윈도우 : 본문 테스트 입력 후 ctrl + / 태그 쉽게 하는 방법(Tip)를 제거한채 태그 영문 입력 후 tap을 누르면 앞뒤 태그가 자동을 생긴다.p*6과 같이 영문 입력 후 tap을 누르면 태그가 6개 생긴다.

안녕하세요. 착한 선배 입니다. VSCode 사용시 편리한 플러그인 정리를 하였습니다. VSCode 사용하기 전에 셋팅하여 코딩시 어려움이 없었스면 합니다. VSCODE 용 한글어 팩VSCode 한글어 팩 사용 버전 Material Icon Them프로그램 코드에 유형에 따라 그 유형의 Icon 형태로 표기 One Dark Pro에디터 색 테마 Live Server새로고침 없이 코딩 중인 웹 업데이트 하기. 실습할때 유용하게 쓰임 indent - rainbow들여쓰기 할때 색으로 구부됨 Bracket Pair Colorizer여는 괄호와 닫는 괄호 짝을 지어 줌따로 다운로드 받을 필요는 없고 설정(Ctrl+ , )으로 들어간 후 Bracket Pair로에서 체크박스 클릭 체크박스 클릭 및 Braket P..

6.3 품질 속성 끌어올리기아키텍트는 소프트웨어 시스템에서 품질 속성을 더 촉진할 수 있는 구조를 선택해야 합니다. 구조를 선택하는 가장 일반적인 방법은 패턴을 탐색하는 것입니다. 모든 디자인은 다시 디자인한다. 원하는 품질 속성을 촉진하는 패턴을 찾아 해당 패턴을 아키텍처의 시작점으로 잡으세요. 6.3.1 품질 속성을 염두해 두고 패턴 찾기웹 브라우저용 데이터 기반 애플리케이션을 구축한다고 생각해 봅시다. 이 애플리케이션에 어떤 패턴을 선택할까요? 적절한 선택지는 3가지가 있습니다. 3 계층, 발행/구독, 서비스 지향 패턴이 있습니다. 위에 패턴은 서로 다른 품질 속성을 촉진합니다. 어떤 패턴을 선택하는 게 좋을까요? 3 계층 패턴은 대부분의 경우 적합합니다. 쉽게 테스트할 수 있고, 쉽게 배포할 수 ..

소프트웨어 아키텍처 설계란 불확실함 속에서 의사결정을 내리는 일입니다. 이 결정에는 절충과 타협이 있으며 좋은 것을 포기하는 대신 나쁜 것을 받아들임으로써 다른 것을 더 좋게 하는 결정을 하기도 합니다. 받아들일 수 있는 수준의 절충안을 선택하다 보면 아키텍처 핵심 요구사항을 충족하고 이해관계자들의 비즈니스 목표도 달성할 수 있습니다. 6.1 대안 위한 분기, 결정을 위한 융합무언가를 결정한다는 말은 선택할 수 있는 여러 가지 대안이 있다는 뜻이기도 합니다. 만약 옵션이 하나뿐이라면 결정할 필요가 없습니다. 아키텍처 설계 시 다양한 대안을 보려면 설계 공간을 살펴볼 필요가 있습니다.설계를 위한 탐색은 분기와 융합을 반복하는 여정입니다. 먼저, 문제를 파악하면 여러 갈래로 생각을 뽑아보고 문제를 해결할 수..

5.3 기능 요구사항 찾아내기기능 요구사항은 성공적인 소프트웨어 시스템을 만드는 데에 필수적이지만 모든 기능이 아키텍처에 중요한 것은 아닙니다. 어떤 기능 요구사항이 아키텍처의 의사결정을 주도할 정도로 중요하다면, 우리는 이를 '영향력 있는 기능 요구사항'이라고 부릅니다. 영향력 잇는 기능 요구사항은 아키텍처 킬러라고도 불립니다. 아키텍처가 높은 가치와 높은 우선순위를 가진 기능 중 하나라도 소화하지 못하면, 아키텍처를 해체하고 다시 만들어야 합니다. 영향력 있는 요구사항을 만들어 내는 방법먼저 현재의 생각을 요약한 추상적인 수준의 아키텍처를 간단히 작성해 보세요.비슷한 문제끼리 묶은 후 일반적인 요구사항을 분류합니다.앞서 작성해 본 아키텍처로 해결 가능한지 분류별로 살펴봅니다. 만약 요구사항이 모호하고..

아키텍처 핵심 요구사항(ASR)이란 아키텍처를 선택하거나 구성할 때 큰 영향을 미치는 요구사항을 말합니다. 어떤 요구사항이 중요한지 선별하는 일이야 말로 아키텍트의 책무 입니다. 요구사항은 크게 4가지로 구분 할 수 있습니다.  제약 : 바꿀 수 없는 결정사항. 대체로 이미 결정된 사항을 받지만, 가끔은 선택권이 있음품질 속성 : 시스템을 다른 시스템과 구분 짓는, 겉으로 보이는 요소. 구체적인 상황에서 시스템이 어떤 작업을 수행 등영향력 있는 기능 요구사항 : 아키텍처에서 특히 주목해야 하는 기능기타 : 시간, 지식, 경험, 능력, 내부 규정, 개인의 개성 등 설계에 영향을 미치는 요소 5.1 제약으로 설계 선택지 줄이기저약은 이미 정해져서 변경이 불가능한 설계상의 의사결정을 의미 합니다. 잘 선택된 ..

3.3 위험요소 가이드로 삼기3.3.3 위험이 줄면 수동적인 설계로 전환한다.아키텍트는 아키텍처가 시스템에서 위험 요소가 아닐 때까지 기술적 위험을 줄여야 한다고 말했습니다. 아키텍처에서 발생할 위험을 충분히 줄이면 그 다음부터는 다른곳에 시간을 쏟는 편이 좋습니다. 아키텍처가 더는 시스템에서 가장 큰 위험 요소가 아니라면, 그래프에 보이는 것처럼 능동적인 설계에서 수동적인 설계로 전환하세요. 능동적인 설계는 위험을 줄이기 위한 설계 프로세스 입니다. 수동적인 설계는 시스템에 구현된 아키텍처를 관찰하고 필요에 따라 수정 조치를 취합니다. 아키텍처가 다시 위험을 품게 되면 그땐 다시 능동적인 설계로 전환하고 새로운 현실을 반영해 아키텍처를 조정해야 합니다.  3.4 설계 계획 세우기설계 계획은 팀이 아키텍..

디자인 싱킹은 복잡한 문제에서 해법을 찾아가는 완벽한 방법 입니다. 디자인 싱킹은 단번에 정답을 만들기 보단 학습과 실험을 중요시 합니다.  3.1 만족스럽게 설계하기소프트웨어 아키텍처는 최적의 방법을 찾는 문제 풀이보다는 아래 같은 활동을 장려해 만족스러운 설계를 찾아가는 과정입니다.  1.실험으로 해결하기아키텍트는 모든 기술에 통달한 현자가 아닙니다. 생각해 볼 수 있는 모든 해결책을 평가해야 할 실험이라고 생각하세요. 가설을 빠르고 저렴하게 평가할수록 이해관계자들이 만족할 만한 구조로 더 빨리 조합할 수 있고, 그만큼 빠르게 이해관계들의 이익을 실현 할 수 있습니다. 2.위험 요소 줄이기소프트웨어의 가치는 우리가 끝까지 지켜야 하는 변수 입니다. 아키텍처는 소프트웨어 시스템의 기반이며, 아키텍처 설..

매일 소프트웨어 만드는 일을 할수록 새롭게 알게 되는 소프트웨어 지식도 많아 집니다. 새로운 지식으로 더 나은 아키텍처를 만들고 또 이를 이용해 새로운 정보를 창출할 수 있습니다. 이 선순환을 계혹하려면 설계할 때 빠른 피드백 순환 고리를 만들어서 지속적인 변화로 기회를 만들어야 합니다. 그 3단계가  생각 - 실행 - 확인 하기 입니다.2.3.1 지속적인 학습을 위한 선순환생각 : 무엇을 배우고 싶은가? 어떤 질문에 대한 답을 구해야 하는가? 현재 제일 위험한 요소는 무엇인가? 생각하기 단계는 무엇을 배울지 계획하는 것을 포함합니다. 구체적인 질문에 대한 답을 생각해보거나 위험요소를 줄이는 방법을 생각해 봅시다.실행 : 계획한 바를 실천합니다. 순에 잡히는 결과를 만들어보며 필요한 정보를 파악하거나 아..

쉘 명령어 env, man명령어내용env리눅스 내 환경 변수를 출력하기 위한 명령어man기본적인 명령에 대한 도움말 메뉴얼을 제공예시)man [명령어] : man의 메뉴얼을 보고 싶으면 'man man'으로 조회를 하면 됨간단한 필수 기능방향키 up↑을 누르면 이전에 실행했던 명령을 보여주는데 이처럼 쉘은 명령어 history를 저장한다. up을 누른후 down을 누르면 원래의 공백라인을 다시 볼 수 있다.키내용left(←)왼쪽으로 커서 이동, 문자를 지우지 않고 문자 하나를 이동한다.right(→)오른쪽으로 커서를 이동, 문자 하나를 이동한다.up()명령 히스토리에 있는 이전 명령어를 출력한다.down()명령 히스토리에 있는 다음 명령어를 출력한다.Ctrl+b왼쪽으로 커서 이동, 문자를 지우지 않고 문..

리눅스의 파일 시스템은 윈도우즈와 다르다. 윈도우즈는 일반적으로 파티션별로 C:, D:, E: 와 같은 방식으로 구분을 하지만 리눅스의 경우 디렉토리를 기준으로 구성하는 방식을 사용한다.  리눅스에서 최상위 디렉토리는 /로 표시하고, 그 하위에 /root, /usr, /etc, /boot, /tmp 등으로 구분하며, 각 디렉토리는 파티션으로 구성될 수 있다. 디렉토리 중 하드디스크와 같은 디바이스 관련 파일이 있는 디렉토리는 /dev 디렉토리 인데, 이 디렉토리를 보면 여러 가지 장치 들이 디바이스 파일로 매칭 되어 있음을 확인 할 수 있다. 이 중에서 캐릭터 디바이스 파일은 쉘 프로그램잉에 있어서 없어서는 안될 디바이스 파일이다 표1. /dev 디렉토리 디바이스 장치디바이스 장치명의미/dev/tty프로..

소프트웨어 시스템을 설계 할 때는 여러 관점의 디자인 마인드셋을 가지고 진행 합니다. 디자인 마인드 셋은 4가지로 구분이 됩니다. 이 4가지 마인드 셋은 무엇을 먼저 진행하든지 상관은 없습니다. 2.2.1 문제 이해하기문제를 이해 한다는 것은 이해 관계자들이 중요하게 생각하는 비즈니스 목표와 품질 속성을 조사해 합니다. 그리고 어떻게 팀을 운영하고 설계 할 때 트레이드오프와 우선순위를 결정해야 하는지도 배워야 합니다. 2.2.2 아이디어 탐색하기소프트웨어 아키텍처를 탐색한다는 것은 여러 구조를 조합하다가 품질 속성을 최대한으로 끌어 올릴 최선의 조합을 찾는 다는 의미 입니다. 최선의 조합을 찾으려면 다양한 패턴, 기술, 구현 방법에 대해 조사해야 합니다. 아키텍처를 체계적으로 만들려면 탐색단계에서 많은 ..

소프트웨어 시스템을 설계하는 일은 문제 해경을 하는 동시에 아직 발견하지 못한 문제를 찾아가는 일 입니다.이처럼 어려운 일을 할 때 도움이 되는 방법을 디자인 씽킹이라고 합니다. 디자인 씽킹은 문제 해결의 모든 기준을 인간에 두고, 창의적이고 분석적으로 문제를 풀어가는 접근법 입니다. 2.1 디자인 싱킹의 4가지 원칙해당 원칭은 소프트웨어 아키텍처 뿐 아니라 세부적인 프로그램 설계, UI 디자인, 기타 디자인이 중심이 되는 어떤 분야에도 적용 될 수 있습니다. 인간 중심 원칙 : 모든 디자인은 사회적이다.모호함의 원칙 : 모호함을 유지하라재디자인의 원칙 : 모든 디자인은 다시 디자인한 것이다.촉각의 원칙 : 손에 잡히는 디자인이 대화를 이끌어 낸다.2.1.1 모든 디자인은 사회적이다.소프트웨어를 만드는 ..

아키텍트는 리더의 역할을 수행 합니다. 하지만 소프트웨어 아키텍트가 된다는 것은 소프트웨어 설계에 대해 제 나름의 방시으로 생각하는 사람이 된다는 걸 의미하기도 합니다. 명함에 어떤 직함으로 써 있든 상관없이 소프트웨어 아키텍트가 될 수 있습니다. 모든 팀에는 최소한 한명의 아키텍트가 있습니다. 최고의 팀에는 여러명이 있습니다.  1.개발자에서 소프트웨어 아키텍트로소프트웨어 아키텍트는 프로그래밍에서 손을 떼면 안되지만, 이는 한편으로 자연스러운 현상이기도 합니다. 개발자에서 아키텍트로 성장을 하고 있는지 알고 싶다면 프로젝트 포트폴리오를 만들어 보세요.프로젝트 포트폴리오를 정리할때 의미 있는 질문 입니다.이해관계자들은 누구였고 주요 비즈니스 목표는 무엇인가?최종적으로 어떤 결과가 나왔는가?어떤 기술을 사..

소프트웨어 아키텍처란 한 소프트웨어를 어떻게 구성해야 하는지 그리고 필요한 품질 속성을 어떻게 증진해야 하는지에 대한 중요한 결정들과 다른 소프트웨어와는 구별되는 특징들을 모아 놓은 집합이다. 중요한 결정으로 손꼽기 위해서는 몇 가지 이유가 필요합니다. 품질 속성, 일정, 비용에 영향을 주거나 한번 결정하고 나면 돌이킬 수 없는 어떤 사항이 있을 수 있습니다.  중요한 결정은 여러 사람에게 영향을 줄 수 있고, 다른 소프트웨어를 바꾸도록 강요하곤 합니다. 때론 나중에 잘못되었을을 알고 바꾸고자 할 때 많은 비용이 필요한 경우가 중요한 결정에 포함되기도 합니다. 올바른 아키텍처는 여러분이 야근할 필요 없이 제 시간에 정해진 예산으로 제 역할을 할 수 있게 합니다.  1. 필수 구조 정의 하기구조를 만드는 ..

소프트웨어 아키텍트가 하는 일소프트웨어 아키텍트는 팀에서 독특한 위치에 있다. 소프트웨어 아키텟트는 프로그램 매니저가 아니다 . 아키텍트는 소프웨어가 어떻게 전달되는지를 결정하는 사람이다. 또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람이다. 코딩은 하지만 알고리즘이나 코드를 짜기보다는 크고 많은것을 설계 하는 사람이다. 소프트 웨어 아키텍스는 여러가지 역할에 대한 책임을 지며 모든 소프트웨어 개발 업무의 중심에 있는 것처럼 보이기도 한다.1. 엔지니어링 관점에서 문제 정의소프트웨어 아키텍처는 프로덕트 매니저, 프로젝트 매니저, 그리고 모든 이해 관계자와 협업하면서 비지니스 목표와 요구사항을 만들어 갑니다.2. 시스템은 분리하고 책임은 위임하기아키텍트는 소프트웨어 시스템을 여러 조각으로 나누고 ..