팀장이 제안한대로이 프로젝트의 설계를 중단하고 설계를 시작하려면 어떻게해야합니까? [닫은]

저는 주니어 개발자 (~ 3 년)이며 업무를 수행하면서 새로운 시스템을 설계하고 있습니다. 저의 수석 개발자는 수석 아키텍트가되지만 시스템을 직접 설계 해 보도록 요청했습니다.

아이디어를 브레인 스토밍하고 아키텍처 제안으로 본 것을 제안하는 몇 가지 반복 과정에서 내 리드는 내가 수행 한 대부분의 작업이 "설계"가 아니라 "설계"라는 피드백을 받았습니다.

그는 아키텍처가 구현에 무관 한 것으로 설명했지만 디자인은 구현에 대한 설명입니다. 그는 디자이너 모자를 벗고 건축가 모자를 써야한다고 말했습니다. 그는 그렇게하는 방법에 대해 약간의 조언을했지만, 나는 당신에게도 묻고 싶습니다.

소프트웨어 디자이너 모드에서 벗어나 건축가처럼 생각하기 시작하는 방법은 무엇입니까?

다음은 제가 리드에 의해 아키텍처와 관련이없는 것으로 보이는 "디자인"의 예 입니다.

1. 시스템에서 리소스를로드 및 언로드하는 알고리즘을 생각해 냈으며 리더는 알고리즘이 아키텍처가 아니라고 말했습니다.
2. 나는 시스템이 제기해야 할 일련의 이벤트와 그것들을 어떤 순서로 올려야 하는지를 생각해 냈지만 이것도 아키텍처로 자르지 않는 것 같습니다.

나는 세부 사항에 사로 잡히고 멀리 물러서지 않는 것 같습니다. 아키텍처 수준의 무언가를 생각해 낼 때조차도 다양한 구현을 시도하고 세부 사항을 살펴보고 일반화하고 추상화하여 종종 거기에 도달했습니다. 내가 이것을 내 리드에 설명했을 때, 그는 내가 잘못된 접근법을 취하고 있다고 말했다. 나는 "하단"이 아니라 "하단"을 생각해야했다.

프로젝트에 대한 보다 구체적인 내용은 다음과 같습니다 .

• 우리가 설계하는 프로젝트는 웹 애플리케이션입니다.
• 약 10-10 만 줄의 코드를 추정하고 있습니다.
• 우리는 스타트 업입니다. 우리의 엔지니어링 팀은 약 3-5 명입니다.
• 응용 프로그램과 비교할 수있는 가장 가까운 것은 간단한 CMS입니다. 구성 요소로드 및 언로드, 레이아웃 관리 및 플러그인 스타일 모듈과 유사한 복잡성을 가지고 있습니다.
• 응용 프로그램은 ajax-y입니다. 사용자는 클라이언트를 한 번 다운로드 한 다음 서버에서 필요에 따라 데이터를 요청합니다.
• 우리는 MVC 패턴을 사용할 것입니다.
• 응용 프로그램은 인증을받습니다.
• 우리는 오래된 브라우저 지원에 대해 크게 신경 쓰지 않습니다. (HTML5, CSS3, WebGL ?, 미디어 소스 확장 등)

프로젝트의 목표는 다음과 같습니다 .

• 응용 프로그램을 확장해야합니다. 가까운 시일 내에 사용자는 수십만 명에이를 것이지만 수만 명 이상을 계획하고 있습니다.
• 우리는 응용 프로그램이 영원히있을 것이기를 바랍니다. 이것은 임시 해결책이 아닙니다. (실제로 우리는 이미 임시 솔루션을 보유하고 있으며 우리가 설계하는 것은 장기적인 대안입니다.)
• 응용 프로그램은 민감한 개인 정보와 접촉 할 수 있으므로 안전해야합니다.
• 응용 프로그램이 안정적이어야합니다. (사실, 그것은 Gmail 수준에서 안정적이지만 화성 로버의 극단에있을 필요는 없습니다.)

우선 건축과 디자인의 차이는 주로 의미론이라고 말합니다. 일부 팀에는 두 팀 사이에 점검 점이 있습니다. 기술 책임자는 설계 및 아키텍처 이전의 아키텍처를 구현과 무관하게 정의합니다. 이것에서 우리는 폭포수 모델과 같은 디자인에 대해 이야기하고 있다고 가정합니다. 산업 디자인은 소프트웨어 아키텍처에 도달하기 전에 사용자가 볼 수있는 제품을 디자인하는 데 도움이됩니다. 필자는 아키텍처가 종종 디자인에 빠져 들어가고 반드시 나쁜 것은 아니라고 생각하며, 건축가가 시스템 내에서 가능한 것이 무엇인지 깊이 이해하는 것이 도움이되는 경우가 많습니다.

모든 것을 말하면, 현재 상황에 대한 조언이 필요합니다. 소프트웨어 아키텍처, 논문, 서적, 컨퍼런스가 전세계에 있지만, 일반적으로 패턴과 추상화를 찾고 있습니다. 프로젝트에 대한 자세한 내용이 없으면 광범위한 예를들 수 있습니다. 예를 들어, 통합 작업을하는 경우 SOA (Service Oriented Architecture)가 있습니다.) 시스템의 일부를 '서비스'로 분할하여 정의 된 방식으로 각 부분에 대해 작업 할 수있는 패턴, 웹 프로그램에서 이는 종종 웹 서비스로 구현됩니다 (그러나 이에 국한되지는 않지만) 더 최근에는 JSON을 사용한 RESTful API의 등장으로 SOA 아키텍처에서 나온 디자인이라고 말할 수 있습니다. MVC (Model, View, Controller)는 일반적으로 사용되는 아키텍처 패턴의 또 다른 예이며, 부품을 교체하고 오류와 테스트를 포함 할 수 있도록 시스템 구성 요소의 책임을 분리합니다.

10,000 피트 수준에서 화이트 보드에 그릴 수 있고 해당 분야에서 일하지 않고 프로그래밍 언어와 현재 구현 세부 사항을 모르는 유능한 프로그래머에게 설명 할 수 있다면 아마도 아키텍처 일 것입니다. 회사 외부의 모든 사람이 관심을 가질만한 책을 쓸 수 있다면 아마도 건축 일 것입니다. 자신이 설명하는 세부 사항을 발견하고 다른 코드 기반 / 회사 / 산업으로 일반화 할 수 없다면 아마도 디자인 일 것입니다.

여러분이 제공하는 두 가지 예는 아키텍처가 아니라 코드 디자인이라는 데 동의합니다. 첫 번째는 리소스를로드하기위한 '알고리즘'을 생각해 냈을 때 첫 번째 해에 가르 칠 새로운 알고리즘을 디자인 한 것이 아니라 해당 작업을 수행하기위한 일련의 지침을 디자인했음을 의미한다고 생각합니다. 내년 COMSC. 두 번째 예에서는 다시 디자인에 동의합니다. 이 아이디어 중 하나를 보여 주면 무작위 소프트웨어 프로젝트에서 사용할 수 없습니다. 고객 클래스가 Person 클래스의 하위 클래스가되기보다는 Java에서 '상위 레벨'인 객체 지향 (OO)으로 이동해야합니다. 일반적으로 예외에 대해 이야기하는 것조차 너무 낮은 수준 (구현에 너무 가깝습니다)으로 간주 될 수 있습니다.

나열된 세부 사항을 해결하기 위해 웹 기반 CMS를 설계하는 방법에 대해 생각해야합니다. Wordpress에는 디자인 구현 세부 사항에 대해 많은 이야기 를하는 사이트 아키텍처 코덱 이 있지만, 주요 아키텍처가 Wordpress를 테마로 확장 가능하게 만드는 데 중심이 있다는 것은 분명합니다. 회사 외부에서 누군가가 작성할 수 있도록 테마에 대한 명확한 인터페이스를 설계하는 것은 분명히 아키텍처 결정이었습니다. 이들은 (임시가 아닌) 장기적인 솔루션을 설계 할 때 종이에 적어 두어 개발하는 동안 모든 설계 및 구현 결정 (아키텍트뿐만 아니라 모든 개발자가 수행)을 결정하는 것이 좋습니다. 이 아이디어와 일치합니다.

상황에 맞는 아키텍처의 다른 예 :

1. 모든 것을 가상 머신에 배치하고, 클라우드 제공자 또는 사내에서 호스팅하고 상태 비 저장 머신 인스턴스를 가지므로, 모든 머신에 장애가 발생하거나 정보를 잃지 않고도 가상 머신의 새 인스턴스로 대체 할 수 있습니다.
2. 카오스 시맨 스와 함께 처음부터 라이브 프로덕션 실패 테스트 구축 .

전체 시스템을 화이트 보드에 그려보십시오. 다른 수준에서 세부적으로 시도해보십시오. 첫 번째 보드는 GUI-> 디스패처-> 백엔드-> DB 또는 무언가 일 수 있습니다. 대명사를 사용할 때까지 드릴 다운하십시오.

이 두 아이디어의 구별은 내가 일할 때 정말 중요합니다.

"아키텍처"라고 부르는 것을 "영어로 프로그래밍"이라고합니다. 프로그래머가 아닌 사람에게 설명 할 수 없다면 무언가 잘못 되었기 때문에 이것은 부분적으로 중요합니다. 문제를 충분히 이해하지 못했거나 "가상"문제 (여기서는 설명하지 않음)를 해결하고있을 수 있습니다.

이 두 가지 디자인 측면에 사용되는 용어는 종종 다르지만 원칙은 모든 곳에서 쉽게 인식됩니다. 한 측면 (귀하의 경우 설계자, 필자의 경우 디자이너)은 영어로 프로그램하는 반면, 다른 측면 (귀하의 경우 "디자이너"의 경우에는 "개발자")이 특정 언어로 프로그램됩니다. 그것들은 또한 일반적으로 "디자인"과 "구현"으로 구별됩니다. "디자인"은 성취해야 할 것으로, "구현"은이를 실현시키는 코드입니다.

내가 일한 것의 몇 가지 예 :

한 프로그램의 아키텍처는 다음과 같습니다. 모듈을 쉽게 추가 할 수있는 중앙 집중식 Manager 또는 허브가 필요합니다. 이 Manager는 등록 된 모든 모듈에 이벤트를 분배합니다. 모듈은 이벤트 관리자에 자체 등록하여 이벤트를 나머지 시스템에 공개하고 관심있는 이벤트를 수신 할 수 있습니다. 각 모듈에는 원하는대로 확인하고 비울 수있는 "사서함"이 있습니다. 이것은 우리가 아직 알지 못하는 새로운 모듈을 수용하게 해줄 것입니다.

코드가 없습니다. 모든 언어로 작성 될 수 있습니다. 구현은이 설명에 의해 지시되지 않습니다.

다른 프로젝트의 아키텍처는 다음과 같습니다. 다른 프로그램을 기다리지 않고 안정적으로 시작하고 중지 할 수있는 방법이 필요합니다. 특정 프로그램을 담당하는 관리자가있을 수 있습니다. 프로그램을 시작하거나 중지하도록 지시하면 관리자가 처리합니다. 이 다른 프로그램이 중지되고 일정 시간이 지나지 않으면 관리자는 강제로 중지하고 혼란을 해결하는 방법을 알고 있습니다. 프로그램이 다른 것에 의해 시작 또는 중지되지 않았으며, 관리자에게 프로그램의 실행, 중지 또는 중지 대기 여부를 묻습니다. 이를 통해 우리가해야 할 다른 일을 계속 진행하면서 다른 프로그램을 시작하고 올바르게 중지 할 수 있습니다.

여기서도 구현을 지시하는 것은 없지만 일부 구현은 다른 구현보다 분명히 더 유용합니다.

디자인 (우리가 호출 할 패턴 또는 구현)과 아키텍처 (디자인을 호출 할 것)의 차이점 중 하나는 코딩 / 구현 문제를 해결하고 다른 하나는 실제 문제를 해결한다는 것입니다.

아마도 이것이 도움이 될 것입니다. 나는 엔지니어가 자신의 문제를 얼마나 크게 해결할 수 있는지에 대한 질문으로 항상 보았습니다.

대략, 아이디어를 전달하기 위해 :

• 작고 포함 된 작 업을 처음 접하는 사람에게 작업을 다른 부분과 통합하는 방법에 대한 많은 명시 적 지침을 제공 할 수 있습니다.

• 중간 수준 개발자는 응용 프로그램의 일부를 설명하고 해당 응용 프로그램의 컨텍스트 내에서 작동하도록 할 수있는 사람입니다.

• 선임 개발자는 상점의 기술적 제약 내에서 처음부터 중간 규모의 응용 프로그램을 구축 할 수 있습니다.

• 더 많은 상급 개발자가 그렇게 할 수 있으며, 어떤 기술을 사용하여 잘 작동하는지에 대한 기술 선택을 할 수 있습니다.

...하지만 이것들은 어렵고 빠른 규칙이 아닙니다. 그리고 어떤 사람들은 다른 제목으로 시간을 보내야하더라도“선배”IMHO로 문을 나옵니다.

건축가가 요구하는 것은 그보다 더 일반적으로 문제를 보는 것입니다. 시스템을 작동시키기 위해 여러 응용 프로그램을 구성해야하는 경우 :

• 어떤 응용 프로그램과 서비스가 필요하십니까?
• 어떤 부분이 고객과 상호 작용하고 어떤 부분이 서로 상호 작용합니까?
• 그들은 어떻게 의사 소통 할 것인가?
• 그들은 어디에 데이터를 저장할 것인가?
• 실패의 위험은 어디에 있습니까?
• 신뢰성을 어떻게 제공 할 것인가?
• 어떻게 보안을 제공 할 것입니까?

어떤 의미에서 기술 아키텍처는 빌딩 아키텍처와 같습니다. 레이아웃 또는 계획입니다. 다양한 부분에 필요한 사항, 구성 방법 및 중요한 이유를 보여 줍니다.

(BTW, 관련 애플리케이션 또는 매우 복잡한 기능의 설계, 그룹의 기술적 방향 설정, 전체 조직의 전략적 기술 결정에 이르기까지 건축가들에게 비슷한 성장 곡선을 설명했습니다. .)

즉, 모든 수준의 대부분의 엔지니어는 "아키텍처"도 수행해야한다고 생각합니다. 밝은 선이 아닙니다. 큰 그림에 먼저 초점을 맞추고 구현 세부 사항에 매달리지 않으면 그가 찾고있는 것에 더 부합 할 것입니다. BTW는 큰 그림과 작은 세부 사항을 볼 수있는 기능이이 업계에서 큰 자산이므로 훌륭한 기회처럼 들립니다.

... 여기에 비유가 있습니다. Magic Black Box를 작성하라는 요청을 받았다고 가정 해 봅시다. 엔지니어는 Magic Black Box의 내부 작동에 집착해야합니다. 그러나 건축가로서 당신의 초점은 다릅니다. 호기심으로 상자를 들여다 볼 수도 있지만 모든 Magic Black Box 주변의 모든 것에 집착 해야합니다.

그 비유와 유사하게 전체 시스템 을 마술 상자 로 보는 아키텍처의 역할을 생각할 수 있습니다 . 거대한 유리 상자를 가져 와서 고객, 클라이언트 응용 프로그램, 방화벽, 서비스 계층, 데이터베이스 및 심지어 개발자를 내부에 배치하면 건축가로서 거대한 시스템 상자를 만드는 방법에 집착해야합니다. 잘 작동 합니다 .

"디자인"과 "아키텍처"의 정확한 차이는 약간 주관적이며 약간 중복됩니다. 그러나 이것이 내가 이해하는 차이점입니다.

아키텍처 는 높은 수준의 개념을 봅니다. 시스템의 행위자는 누구입니까? 주요 대상은 무엇이며 무엇을 담당하고 있습니까? 아키텍처를 생각할 때 코드가 아닌 Visio를 생각합니다.

예를 들어, 이벤트 시스템에는 들어오는 이벤트를 승인하고 이벤트 핸들러로 디스패치하는 이벤트 관리자가있을 수 있습니다. 스레드, 비동기식 v. 동기식 및 기타 하위 레벨 개념에 대한 아이디어는 여기서 적용되지 않습니다. MVC는 또 다른 예입니다. 세 부분이 상호 작용하는 방식에 대한 세부 사항은 구체적으로 명시되어 있지 않으며, 별도의 코드 패키지로 처리되는 세 가지 문제 만 있습니다.

디자인 에는 프로토 타이핑, 코드 인터페이스 스케치, 코드 스켈레톤 등이 포함됩니다. 추상 아키텍처와 저수준 "코드 원숭이"작업 사이에 있습니다.

이벤트 프레임 워크에서 디자인은 "이벤트가이 인터페이스를 사용합니다"라고 말하고 "이벤트 관리자가 이벤트를 작업자에게 디스패치하는 데 사용하는 스레드 풀이 있습니다." MVC의 디자인은 "모델에는 최대 절전 모드, 컨트롤러에는 스프링, 뷰에는 GWT를 사용할 수 있습니다."

디자인 작업을 할 때 인터페이스와 코드 스켈레톤을 스케치 한 다음 결과를 프로그래머에게 전달합니다. 때때로 나는 그 프로그래머입니다. 그러나 그것은 두 개의 별개의 단계이며, 둘 다 건축보다 콘크리트를 향해 더 존재합니다.

아키텍처 모자를 착용 한다는 것은 코드에 대한 생각을 없애고 화이트 보드에있는 객체를 생각하는 것을 의미합니다. 객체, 패키지, 프레임 워크 및 메시지 흐름을 생각하십시오. 한 줄의 코드조차 생각하고 있다면 잘못하고 있습니다. "오, 그 메시지는 문자열 일 수도 있고 SOAP를 사용할 수도 있습니다."와 같은 말에 얽매이지 마십시오. 이 수준에서는 통신이 이루어지고 있다는 사실만으로 충분합니다. 세부 사항은 관련이 없습니다.

여기 에 무엇이든 추가 할 수 있다면 코드는 생각하지 않습니다 . 조금도.

무언가를 달성하기 위해 코드를 작성하는 방법을 생각하지 말고 그것을 달성하는 가장 좋은 방법 은 무엇인지 생각 하십시오. 해야 할 일에 대한 설명은 언어에 구애받지 않아야 하므로, 다른 프로그래밍 언어 사용자들 사이에서 공통적 인 "언어"인 디자인 패턴을 논의하여 진행 방법을 논의하게됩니다.

특정 사용 사례의 경우 내 의견으로는 더 많은 건축 질문이 다음과 같은 줄을 따라야합니다.

• 왜 MVC를 사용하고 있습니까? 당신이 아는 전부입니까? 사용하기에 더 좋은 패턴이 있습니까? 왜?
• 어떤 프레임 워크를 사용할 것이며 왜 그런가요 ?
• 어떻게 확장 할 것인가? 코드 방식은 아닙니다. 아직 중요하지 않기 때문입니다. 수평 적으로 확장하기위한 조건은 무엇입니까? 이를 위해 어떤 서비스 (AWS)를 사용 하시겠습니까?
• 인증은 어떻게 수행됩니까? 코드 방식이 아님 : 각 요청에 대해 임의의 고유 한 토큰을 생성하여 예상 토큰과 비교할 예정입니까? 코드에서 어떻게 할 것인지 생각하지 마십시오. 실제로 모든 웹 언어로 수행 할 수 있기 때문에 왜이 작업을 수행 하는지 생각해보십시오 .

기본적으로 코드에 대해 전혀 이야기하지 마십시오. 무언가를하는 방법을 모르더라도 의지가있을 때는 방법이 있습니다. 실제로 퍼즐을 맞추는 것에 대해 걱정하기 전에 퍼즐 조각이 가장 잘 맞는 방법에 대해 더 많이 생각하십시오.

시스템이 수행 할 수있는 모든 작업 (예 : 사용 사례)을 생각하십시오. 각 작업에 대해 각 작업의 비즈니스 도메인 측면에서 발생하는 상황을 문서화하십시오. 문제 영역의 관점에서만 이야기하고 구현 세부 사항을 설명해서는 안됩니다. 큰 블록을 그리고 그것을 시스템이라고 부릅니다. 이 "큰 블록"과 작업 설명의 조합은 최고 수준의 시스템 아키텍처입니다.

이 높은 수준의 아키텍처는 적절한 출발점을 제공하지만 실제 시스템을 구축 할 때 실제로 큰 가치는 없습니다. 이것을 유용한 아키텍처로 바꾸려면 한 단계의 세부 사항을 내려야합니다.

따라서 "큰 블록"접근 방식과 동일한 일반적인 개념을 따르기 때문에 각 작업을 수행하는 데 필요한 "서브 블록"만 추가하기 시작합니다. 이러한 "하위 블록"을 도메인 클래스 또는 모듈이라고합니다. 이는 작업 설명 (빅 블록 접근 방식)과 도면 시퀀스 다이어그램을 사용하여 쉽게 식별 할 수 있습니다. "실제"클래스가 아니기 때문에 도메인 클래스라고하지만 시스템의 문제 도메인 측면에서 시스템을 설명하기위한 것입니다.

모든 시퀀스 다이어그램을 작성하고 모든 "서브 블록"을 식별 한 최종 결과는 이제 도메인 클래스 목록과 해당 작업 목록이 있다는 것입니다. 이로 인해 일반적으로 상당히 유용한 소프트웨어 아키텍처가 생겨서 각 "서브 블록"/ 모듈을 설계하고 구현하기 위해 다른 개발자에게 제공 할 수 있습니다.

물론 그대로두면 디자이너가 모듈 간의 인터페이스를 정의 할 때 서로 상호 작용할 수 있습니다. 따라서 아키텍트는 모듈간에 사용될 특정 인터페이스 메커니즘 및 데이터 유형을 결정할 수도 있습니다.

또한 일부 "서브 블록"은 여전히 ​​매우 복잡합니다. 따라서 "서브 블록"접근법의 또 다른 반복이 필요할 수 있지만 이번에는 새로 식별 된 모듈 중 하나에서만 가능합니다.

마지막으로, 아키텍트가 시스템이 고수하기를 원하는 인터페이스 (예 : 이벤트 콜백 대 직접 메소드 호출) 사이에는 특정 패턴 / 제한이있을 수 있으므로 이러한 결정은 아키텍처 설계에서 논의해야합니다. 또한 건축가가 모든 사람이 사용하기를 원하는 "공통"모듈이있을 수 있습니다.

개발자는 아마도 솔루션 제공에 익숙 할 것입니다. 이는 매우 좋은 사고 방식이지만 건축에 관한 사고에 방해가 될 수 있습니다.

먼저 해결하려는 문제를 설명하는 것이 도움이된다는 것을 알게되었습니다. 요구 사항은 무엇입니까? 제약은 무엇입니까? 이러한 요구 사항을 찾기 위해 이해 관계자와 대화 할 수 있습니까?

자신 만의 디자인 목표를 설명 할 수 있다면 도움이 될 것입니다. 솔루션을 확장해야합니까, 아니면 단일 사용자를위한 디자인으로 충분합니까? 솔루션의 유효 기간은 얼마입니까? 일회성 수정입니까, 아니면 장기 인프라 솔루션입니까? 아마도 중요 할 수도 있습니다. 아키텍처의 허용 한계는 무엇입니까?

그리고 이것은 학습 경험이므로 어리석은 경우에도 질문을 두려워하지 마십시오.