나는 최근에 대학을 졸업하고 프로그래머로 일하기 시작했습니다. "기술적 인"문제를 해결하기가 어렵거나 해결책이 하나 있다고 말하는 것을 디버깅하는 것이 어렵습니다.

그러나 소프트웨어 아키텍처와 같은 명백한 해결책 이없는 일련의 문제가 있는 것 같습니다. 이런 것들이 나를 괴롭 히고 큰 고통을 안겨줍니다.

프로그램과 시스템을 "아키텍트"하는 방법을 결정하기 위해 몇 시간과 몇 시간을 보냅니다. 예를 들어,이 논리를 1 개 또는 2 개의 클래스로 나누고, 클래스 이름을 어떻게 지정하고, 개인용 또는 공개용으로 만들어야합니까? 나는 단지 프로그램을 만들고 싶다-건축은 저주를 받았다.

아키텍처 단계를 더 빨리, 내가 즐기는 코딩 및 디버깅 단계로 어떻게 넘어갈 수 있습니까?

완전은 선의 적입니다.

즉, 모서리를 자르면 안됩니다. 소프트웨어 설계는 오래 지속되는 영향을 미치며 향후 많은 시간과 노력을 절약 할 수 있습니다. 제대로 되려면 시간이 더 걸릴 것입니다. 프로그래밍 에 소비되는 대부분의 시간은 키보드를 망치 는 것이 아니라 문제를 해결하는 방법을 알아내는 화이트 보드입니다.

그러나 당신은 또한 완벽에 대해 걱정할 필요가 없습니다. 두 개의 디자인이 교착 상태에 맞서 싸우면, 같은 디자인 일 가능성이 높습니다. 하나만 가십시오. 해당 디자인의 결함을 파악한 후에는 변경할 수없는 것처럼 보이지 않습니다.

기술 문제를 디버그 / 해결할 수있는 유일한 방법이 없다는 것을 알게되면 도움이 되길 바랍니다.

간단하고 작은 프로그램 (예 : 소스 코드가 10,000 줄 미만) 인 경우 코드를 작성하면서이를 설계 할 수 있습니다. 반복적이고 점진적인 개발 접근 방식 을 채택하는 경우 점차적으로 아키텍처 결정을 내릴 수 있습니다. 따라서 수십 줄의 코드를 작성하고 (일부 마이크로 기능 추가) 컴파일러에서 경고가 표시되지 않을 때까지 개선하고 테스트하십시오. 디버거를 반복하십시오.

이 논리를 1 개 또는 2 개의 클래스로 나누고 클래스의 이름을 어떻게 지정합니까? 비공개 또는 공개로 설정해야합니까? 이런 종류의 질문은 시간이 너무 많이 걸립니다

그들은해서는 안됩니다. 그리고 작은 프로그램 에는 그다지 중요하지 않습니다 (작고 간단한 프로그램은 개선하기가 쉽기 때문에 (예 : 이름 변경 등)). 일관성 있고 소스 코드 의 가독성 을 우선시해야합니다 . 당신은 약간에 수시로 필요성을 찾을 수 있습니다 리팩토링 프로그램의 일부 작은 부품을 (그리고는 없는 큰 문제가).

이것을 많은 무료 소프트웨어 프로젝트 (Linux 커널과 같은 큰 프로젝트)와 비교하십시오 . 개발자는 초기 단계에서 "아키텍처 링"에 많은 노력을 기울이지 않았습니다. UML은 거의 무료 소프트웨어에서 사용되지 않습니다 . 또한 몇 가지 무료 소프트웨어 프로젝트의 소스 코드를 연구하여 상당히 배울 수 있습니다.

초보자는 팀에서 대규모 소프트웨어 프로젝트를 수행하며, 수석 개발자 (아키텍처 결정을 내림)를 신뢰하거나 소규모 프로젝트 (일반적으로 수십만 미만)를 혼자서 작업하게됩니다. 소스 코드 줄). 후자의 경우 애플리케이션을 수시로 리팩터링하여 점진적인 아키텍처 결정을 내리고 그 후에 "건축 디자인"이 자연스럽게 진화합니다.

아키텍처 단계와 코딩 및 디버깅 단계를 더 빨리 진행할 수있는 방법은 무엇입니까?

1 년 미만의 작업이 소요되는 소규모 소프트웨어 프로젝트의 경우 아키텍처를 수행하지 마십시오. 전체 디자인에 대해 30 분 정도 브레인 스토밍을하십시오. 그런 다음에, 코드 작성을 시작 반복 및 증분 개발 (모든 경고 및 디버그 정보가 활성화 된 예를 들어, 컴파일, 수십 라인을 쓰기 : 접근 g++ -Wall -Wextra -g과 GCC C ++에 대한) 더 경고를 얻을 수 없을 때까지 (그리고 몇 가지 간단한 정적 소스에 전달 하나, 예를 들면있는 경우 코드 분석기, 연타 분석기를 )하는과 그 코드를 테스트 디버거 , 당신에 커밋 버전 제어 (예를 들어 git), 린스를 반복합니다. 그러나 기술 부채 를 피하십시오: 나쁜 냄새가 나면 리팩토링과 재 구현을 통해 개선하십시오.

반면, 팀 환경에서 아키텍처 작업에는 모든 팀 구성원의 책임을 정의하기위한 초기 토론이 수반됩니다. 이 토론은 선임 개발자 (초보자가 아님)가 주도합니다. 민첩한 소프트웨어 개발 및 The Mythical Man-Month 에 대해 읽어보십시오 .

프로그램을 만들고 싶습니다. 아키텍처가 손상되었습니다.

탁월한 직관력 (적어도 소규모 프로젝트의 경우) 따라서 몇 분 동안 프로그램에 대해 생각하고 반복적이고 점진적인 개발 방식으로 코딩을 시작 하십시오. 수십 줄을 코딩하고 제대로 작동하는지 확인한 다음 반복하십시오. 그 전에는 유사한 자유 소프트웨어 프로젝트의 소스 코드를 연구하고 아키텍처를 관찰하며보다 일반적으로 서지 작업 및 연구를 수행합니다.

에서 어떤 경우에하는 생각 메타 프로그래밍 방법 : 당신이하고 싶은 경우가 있습니다 생성 일부 "소스 파일"(예를 들면 같은 파서 생성기 사용하여 포함 들소 와 같은 접착제 코드 생성기 꿀꺽 꿀꺽 , 구글 protobuf을 , 때로는 당신이 쓰기 할 수 있습니다 간단한 스크립트-또는 GPP 와 같은 일반 전처리기를 사용 하여 C ++ 또는 Java 코드 중 일부를 생성하여 반복적 인 코딩을 피하십시오).

추신. 저는 연구 엔지니어이며 컴퓨터 과학 및 40 년의 경험을 가진 박사 학위를 가지고 있으며 중소 규모의 프로젝트와 몇 가지 큰 프로젝트 (GCC 컴파일러 자체)에서 성공적으로 작업 한 적이 있지만 귀하의 질문에서 제안한 것처럼 "아키텍처"를 한 적이 없습니다. ). 저에게있어 "아키텍처"는 단지 며칠 또는 몇 주 동안의 작업의 계획 단계 일뿐입니다. (보통 컴퓨터를 사용하지 않고 연필을 쓰지 않고 꿈을 꾸거나 자고있을 때도 마찬가지입니다.) 또한 연구 보조금을 작성할 때 어떻게 든 불완전하게 아키텍처를 설계하고 있습니다.

NB : 어떤 소프트웨어 프로젝트는 다른 것보다 훨씬 더 많은 아키텍처가 필요합니다. 예를 들어, 인공 심장 또는 신경 외과 로봇의 제어 시스템을 작성하는 경우 일반 휴대 전화 애플리케이션을 작성할 때와 같은 방식으로 작동하지 않습니다. Norvig 's Teach yourself in 10 years 페이지를 참조하십시오.

내가 명심하고 싶은 3 가지 모토가 있습니다.

• "모든 것이 가능한 한 단순해야하지만 단순하지 않아야한다"

  "한 클래스 또는 두 클래스?"의 예를 들자면, "더 간단한 솔루션은 무엇입니까?"

• "명백한 버그 없음"과 "명백한 버그 없음"

  후자가 바람직하다!

  그것이 단순해야하는 이유입니다. 즉, 그것에 대해 추론 할 수 있습니다. 하나의 큰 클래스는 너무 크거나 너무 복잡하여 추론하기가 어려울 수 있습니다.이 경우 여러 개의 작은 클래스로 나눠서 "각 클래스는 작고 수행 할 작업을 수행합니다"라고 말할 수 있습니다. 그들의 인터페이스는 간단하며 올바른 방식으로 결합됩니다. "

  1. 코드는 이론적으로 (즉 머리에서) 실행되어야합니다.
  2. 그런 다음 실제로 작동하지 않으면 연습이 이론과 일치 할 때까지 디버깅 할 수 있습니다.

  초보자는 1 단계를 방해하지 않습니다. 예를 들어 머리에서 실행하는 경우 (예 : 너무 복잡하기 때문에)-이 경우 "이론"보다는 "우연히"실행되는 경우가 있습니다. 명확하지 않은 버그를 찾을 수있을 정도로 테스트했습니다

• 갈의 법칙

  이것은 일명 "리 팩터"입니다.

  실제로 이것은 다음을 의미합니다.

  1. 작동하는 간단한 시스템으로 시작
  2. 이제 새로운 기능을 추가 할 차례입니다
  3. 새로운 기능을 쉽게 추가 할 수 있도록 기존 시스템을 리팩토링

  4. 새로운 기능 추가

  5. ... 위와 같이 반복하십시오

  이것은 YAGNI와 같은 모토와 일치합니다. 즉, 아키텍처에 대해 걱정하지 말고 리팩토링하지 마십시오.하지만 특정 목적에 맞게 필요할 때 즉석에서 적절한 아키텍처를 생성하십시오.

할 수있는 것은 필요한 최소한의 추상화로 시작하는 것입니다. 예를 들어 하나의 파일에있는 Person 클래스입니다. 코드와 기능을 계속 추가하면서 다른 추상화로 옮겨야 할 것들을 보게됩니다. 예를 들어 단일 책임 원칙 (SID의 SOLID)은 Person 클래스의 주소 구문 분석과 관련된 메소드가 없음을 알려줍니다. 이제 Address 클래스가 필요하다는 것을 알게되었습니다.

그러나 "최소 추상화 수"가 시스템에 어떤 모양인지 생각하려면 항상 약간의 시간이 걸립니다. 충분한 아키텍처에서 시작하여 갈수록 개선하십시오.

편집 : @Basile answer는 최소한의 아키텍처에서 반복하고 개선하는 방법에 대한 예를 제공합니다.

시스템의 아키텍처를 생각하는 데 소요되는 시간은 시간 낭비가 아닙니다.

귀하의 질문은 "아키텍처 결정을보다 효율적으로 수행 할 수있는 방법"으로 표현 될 수 있다고 생각합니다.

이에 대한 나의 짧은 대답은 다음과 같습니다. 신뢰할 수 있고 효율적으로 의사 결정을 내릴 수있는 핵심 원칙을 발견 한 다음 실제 소프트웨어를 실제로 만들어 내야합니다. 이것은 지식, 시행 착오 및 개인적 개발을 추구하는 긴 여정이 될 것입니다.

-

그리고 더 긴 대답을 위해 ...

먼저 개념을 명확히해야 합니다. 프로세스, 서비스, API 및 데이터베이스로 작업 할 때 복잡한 소프트웨어 시스템의 구조를 설명하기 위해 아키텍처 라는 단어를 사용 합니다. 클래스, 함수 및 라이브러리로 작업 할 때 디자인 이라는 단어를 사용하여 더 복잡한 시스템에서 한 조각의 구조 만 설명합니다. 이것들은 나의 정의이며, 어떤 사람들은 다른 정의를 가지고 있습니다. 그러나이 맥락에서 나는 당신이 디자인 에 대해 이야기하고 있다고 생각합니다 .

이 주제를 논의 할 때 명심해야 할 3 가지 사항이 있다고 생각합니다.

• 아키텍처 나 디자인은 다이어그램이나 문서를 통해 명시 적으로 설명하지 않고 팀이나 사람 ( 건축가 ) 이 유지 관리하지 않아도 존재합니다 . 모든 시스템에는 사후 설명이 가능한 내장 아키텍처와 내장 디자인이 있습니다.

• 소프트웨어 개발은 ​​프로그래밍이 아니라 시간이 지남에 따라 프로그래밍됩니다. 나는 이것이 업계에 오는 사람들에게 가장 큰 사각 지대 중 하나라고 생각하기 때문에이 구별을하고 있습니다 (자체 포함, 한 시점에). 이는 대학 프로젝트 나 개인 프로젝트와 비교할 때 실제 소프트웨어 시스템에서 작업하는 것이 기하 급수적으로 더 복잡하다는 것입니다. 아키텍처 결정은 시간이 지남에 따라 시스템 개발에 큰 영향을 미치기 때문입니다. 당신의 결정은 이제 당신을 괴롭히기 위해 다시 올 것입니다.

• 아키텍처와 디자인은 본질적으로 존재하기 때문에 코드베이스는 시간이 지남에 따라 진화하는 생명체이기 때문에 아키텍처와 디자인도 진화해야합니다. 그들은 핵심 시간에 취한 의식적인 결정을 통해 통제 된 방식으로 진화하거나, 코딩에 의해 혼란스럽게 진화 할 것입니다. 이는 "아키텍처 우선 및 코드 작성 둘째"의 전통적인 접근 방식에 결함이 있음을 의미하기 때문에 이해하는 것이 중요합니다. 물론 처음부터 프로젝트를 시작할 때는 일부 건축 및 설계 작업을 선행해야합니다. 그러나 그 외에는 시스템을 개발하는 동안 여전히 많은 건축 및 설계 결정이 내려 질 것입니다.

위의 내용을 더 자세히 설명하려면 코드를 작성하는 동안 의식적으로 또는 결정적으로 디자인 결정을 내릴 것이라는 사실을 알고 있어야합니다 . 가볍게 치른 결정이 향후 작업에 큰 영향을 미칠 수 있으므로 이러한 결정을 의식적으로, 비판적으로 만드는 데 노력해야합니다 (이 영향은 일반적으로 코드를 수정하거나 기능을 구현하기 위해 변경하기가 매우 어려워 짐). Robert C. Martin은 자신의 저서 인 "Clean Architecture"(내가 추천하는 책)에서이 데이터를 아름답게 보여줍니다.

이제 아키텍처와 디자인이 중요한 이유를 알았으므로 올바른 의사 결정을위한 적절한 프레임 워크를 제공 할 수있는 핵심 원칙은 무엇입니까? 내 경력 초기 에이 질문이 있었는데 툴셋에 빠진 것이 있지만 무엇을 알지 못했는지, 그것을 설명하거나 찾는 방법을 몰랐습니다. 나는 시간이 지남에 따라 발견 된 이러한 원리 중 일부를 공유 할 것이며, 그것이 당신의 삶을 조금 더 쉽게 만들 수 있기를 바랍니다.

• Martin Fowler의 저서 "리팩토링 : 기존 코드의 디자인 개선"을 읽어 보면 매우 간단하지만 강력한 코딩 트릭을 찾을 수 있습니다. 여기에 나열 할 항목이 너무 많지만 코드 구조를 크게 개선하고 디자인 결정을 내리는 데 도움이되는 매우 낮은 수준의 코딩 시간 결정입니다. 이 책은 또한 단위 테스트를 개인 워크 플로에 통합하고 테스트 가능한 코드를 작성하는 방법을 제시합니다.

• 특히 OOP의 경우 SOLID 원칙을 살펴보십시오 . 그것들은 약간 추상적이며 처음에는 마음을 감싸기가 어렵지만 매우 강력합니다. 가장 빨리 혜택을 받으려면 처음 2부터 시작하는 것이 좋습니다.

단일 책임 원칙 : 클래스는 단일 책임만을 가져야합니다 (즉, 소프트웨어 사양의 한 부분 만 변경하면 클래스 사양에 영향을 줄 수 있어야 함).

개방 / 폐쇄 원칙 : "소프트웨어 엔티티는… 확장을 위해 개방되어야하지만 수정을 위해 폐쇄되어야합니다."

• 상속에 대한 구성 의 개념

  클래스가 기본 또는 부모 클래스로부터 상속하는 것이 아니라, 원하는 기능을 구현하는 다른 클래스의 인스턴스를 포함하여 구성에 따라 다형성 동작 및 코드 재사용을 달성해야한다는 원칙.

• 커플 링 개념 ( "소프트웨어 모듈 간 상호 의존 정도")과 응집력 ( "모듈 내부의 요소가 함께 속하는 정도")
• DRY (자신을 반복하지 마십시오) 개념
• 명령 / 쿼리 분리 개념 ( "모든 방법은 둘 작업을 수행하는 명령 또는 발신자에 데이터를 반환하는 쿼리 수 있지만해야 하나")
• 상태 저장 시스템과 상태 비 저장 시스템 의 개념 (제 경험에 따르면, 상태 처리를 피하고 가능한 한 상태 비 저장 시스템을 구축하십시오).

물론 이것은 규칙이 아니라 개념 일뿐입니다. 첫 번째 단계는 그들을 이해하고 인식하는 것입니다. 다음은 실제로 실제로 사용하고 따라야 할 때와하지 말아야 할 때에 경험을 쌓는 것입니다. 그런 다음 이러한 개념, 부정적인 측면 및 서로의 복잡한 상호 작용에 대한 이해를 구체화하는 지속적인 프로세스가 있습니다.

나는 당신에게 줄 수있는 가장 귀중한 조언은 다음과 같습니다. 당신은 길지만 충실한 길을 시작했습니다. 계속 연습하고 실험하고, 효과가있는 것과 그렇지 않은 것을 기록하고 시간이 지남에 따라 더 나아질 것입니다.

당신이 묘사하는 것의 대부분은 실제로 (중요한) 아키텍처가 아닙니다. 좋은 이름과 좋은 클래스 디자인은 당신에게 제 2의 특성이 될 것입니다. 코드가 많을수록 더 나아질 것입니다. 이러한 문제에 가장 도움이되는 것은 일반적으로 페어 프로그래밍입니다. 이러한 문제를 해결하고이를 효율적으로 학습하는 데 도움이됩니다.

프로젝트 전에 아키텍처가 필요한 경우 :

1. 정확한 요구 사항과 비 기능적 요구 사항을 수집하십시오 (지원해야하는 초당 요청 수는 몇 개입니까?). 이 단계에서 불일치가 발생하면 시간이 많이 걸리고 성가 시며 때로는 불가능한 후에 누락 된 아이디어를 통합하여 지옥을 코딩하게됩니다. 나는 이것이 코딩만큼 재미가 없다는 것을 알고 있지만 코드가 의도하지 않은 것을 수행하도록 시도하는 것은 훨씬 덜 재미 있습니다.

2. 적절한 경우, 시스템의 경계 컨텍스트를 정의하고 어휘가 올바른지 확인하십시오. 예를 들어 "Frobbels"에 대해 비즈니스에서 말하는 경우 "*** Frobbels"로 클래스 / 인터페이스 등의 이름을 지정하십시오. 사소한 것처럼 들리지만 워크 플로에 대해 이야기하고 비즈니스가 운영에 대해 이야기하는 동안 번역은 매우 성가 시게됩니다.

3. 여러 사람 / 팀과 함께 작업하여 인터페이스를 조기에 설명하고 모든 가정과 문제를 모든 사람이 이해하도록해야합니다. 공유 된 컨텍스트가없는 경우 통합은 "재미"가됩니다. 예를 들어 바나나 그림 생성기를 만들지 만 프론트 엔드 개발자는 사과 그림 생성기가 필요합니다. 또는 초당 100 개의 요청에 응답 할 수있는 것을 구축하지만 초당 10000 r이 필요합니다.

참고 : 이것은 마이크로 서비스 아키텍처에 대한 저의 작업에 큰 영향을받습니다. 서브가 내부적으로 구축되는 방식, CAN도 설계되었지만 대부분의 경우 큰 그림을 올바르게 얻는 것보다 덜 중요합니다.

나는 당신에게 많은 용어와 약어를 던지지 않을 것입니다 (대부분의 코더 / 소프트웨어 엔지니어는 거의 동의하지 않습니다). 대신 다음을 고려하십시오.

1. 당신은 배우고 있습니다-당신은 시간을 낭비하지 않고 다른 접근법을 시도하고 작동하는 것을 배우고 있습니다. 미리 생각하지 않는 첫 번째 솔루션의 문제에 뛰어 들어 작동하지 않거나 작동하지 않는 경우 변경하여 미리 계획하지 않고도이 작업을 수행 할 수 있습니다. 잘 작동하면 훌륭합니다! 문제에 대한 간단한 해결책을 찾았습니다. 간단한 솔루션은 잘 작동하면 충분 하며 때로는 충분 합니다.

2. 모든 것이 장단점입니다. 시간과 공간, 복잡성과 유연성, 추상화 및 가독성, 또는 가능한 많은 장단점 중 하나를 다양한 방식으로 동일한 시스템을 설계 할 수 있습니다. 모든면에서 완벽한 솔루션은 없으며 소프트웨어 엔지니어링에서 예외가없는 규칙은 없습니다. 달리 말한 사람은 순진하거나 무언가를 판매하는 것입니다.

3. 최근 졸업생으로서 코딩과 디버깅은 매우 흥미로울 수 있지만 시간이 지남에 따라 사라질 것이며, 지금 배우고있는 기술이 도움이 될 것입니다.

4. 나는 소프트웨어를 만드는 것이 공학보다 예술 / 공예라고 주장한다. 훌륭한 예술은 개개인의 붓질에 관한 것이 아니라 예술가 / 장인의 높은 수준의 결정과 트레이드 오프에 관한 것입니다.

나는 웹 개발 관점에서 오는이 질문에 대답하려고 노력할 것입니다 (즉, 사람들이 건축을 많이 고민하는 분야에서 왔습니다). 먼저 사람들이 아키텍처에 관심을 갖는 이유를 설명하고 아키텍처 부분을 더 빨리 지나갈 수있는 방법을 간략하게 설명하겠습니다.

아키텍처는 코드를 위해 두 가지 작업을 수행합니다.

1. 그것은 당신과 다른 사람들을위한 코드를 이해하기 쉽게 만들어줍니다.
2. 확장하고 통합하기 쉬운 방식으로 코드를 구성하는 데 도움이됩니다.

코드 스타일을 사용하면 코드를 인식하고 탐색하는 데 사용할 수있는 규칙을 제공하여 코드의 특정 부분을보다 쉽게 ​​읽을 수 있습니다. 마찬가지로 좋은 아키텍처를 사용하면 특정 기능을 처리하는 코드를 실제로 찾을 위치를 식별 할 수 있습니다. 예를 들어, 대부분의 웹 프로젝트에서 아키텍처는 폴더와 파일을 정렬하는 방법과 밀접한 관련이 있습니다. 반대로 좋은 아키텍처는 실제로 코드에 대해 덜 생각하는 데 도움이됩니다. 코드에 속하는 모든 부분이 직관적 인 위치에 있어야하기 때문입니다.

또한 좋은 아키텍처는 코드를 쉽게 사용하지 못하게하는 많은 함정을 피하기위한 속기입니다. 다시 한 번 아키텍처 결정을 내리면 코드 작성 방법에 대해 덜 생각하는 데 도움이되는 규칙을 설정해야합니다.

이제 당신이 실제로 여기있는 부분은 :

아키텍처 부분을보다 빠르게 통해 무엇을 할 수 있습니까?

1. 하지마

많은 답변이 이미 지적했듯이. 먼저 실제로 건축이 필요한지 자문 해보십시오. 코드가 많지 않을 경우 (그리고 가까운 시일 내에 프로젝트가 커지지 않을 것이라고 합리적으로 확신 할 수있는 경우) 아키텍처 부분을 건너 뛰고 단순히 작동하는 무언가를 함께 모을 수 있습니다. 그러나, 당신이 경력 초기에 있다면 가능할 때마다 연습 할 기회를 사용합니다. 어느 시점에서 당신은 더 큰 프로젝트를 수행 할 것이고, 그 시점에서 아마 배우는 데 늦었을 것입니다.

이를 통해 아키텍처를 덜 고통스럽게 만들기 위해 무엇을 할 수 있습니까?

1. 일찍 해
2. 훔치다
3. 배우고 / 붙여라
4. 과용하지 마십시오

아키텍처 결정은 계획 프로세스의 초기 단계 여야합니다. 어떤 종류의 앱 / 프로그램 / 웹 사이트를 만들 었는지 알게되면 어떤 종류의 아키텍처가이를 지원할 것인지 생각해야합니다.

이 시점에서 무모하게 도둑질 할 차례입니다. 프로그램 아키텍처를 올바르게 설정하는 방법에 대한 많은 문헌이 있으며, 이러한 기존 아키텍처 프로토 타입이 엄청나게 많은 유스 케이스를 다룹니다. 구현 방법을 모르더라도 어떤 종류의 아키텍처가 있는지에 대한 대략적인 개요를 배워야합니다.

당신이 일종의 건축에 ​​정착했다면, 그것을 고수하십시오. 대부분의 경우 아키텍처 결정은 직관적이어야하며 초기 설정 후 몇 초 밖에 걸리지 않습니다. 이 중 많은 부분이 경험하게됩니다.

마지막으로, 물건을 지나치게 생각하지 마십시오. 당신은 어떤 것이 공개적이거나 사적이어야하는지에 대한 모범을 보여 주지만, 진실은 모든 것을 공개하더라도 중요하지 않을 것입니다. 그렇습니다. 이런 식으로하지 말아야하며,이 작은 실수들 중 상당수는 시간이 지나면 쌓일 것입니다. 그러나 결국에는 프로젝트를 죽이지 않을 것입니다. 가장 먼저 작동하는 소프트웨어를 만드십시오!

(PS : 그 마지막 문장은 게으른 것에 대한 변명의 여지가 없습니다. 작동하는 소프트웨어의 우선 순위를 정한다고해서 언젠가 좋은 코딩을 배울 필요는 없습니다.)

대답은 매우 간단합니다.

• 프로토 타입 작성 (시간 상자)
• 리팩토링 (다양한 요소를 기반으로 원하는 시간만큼 사용

프로토 타입을 제작할 때는 최소한의 실행 가능한 제품에 중점을 두어야하고 리팩토링 할 때는 프로젝트 나 솔루션을 확장 가능하게 만드는 데 중점을 두어야합니다.

아키텍처 단계와 코딩 및 디버깅 단계를 더 빨리 진행할 수있는 방법은 무엇입니까?

이 작업을보다 숙련 된 동료에게 위임하거나 도움을 요청함으로써.

그러한 결정을 신속하게 내리는 데 필요한 경험이 부족합니다. Uni는 당신에게 좋은 이론적 배경을 가지고 있지만, 그것은 당신을 출발 선으로 안내합니다. 주어진 상황에서 주어진 아키텍처를 판단하는 다른 방법은 과거에 비슷한 상황에서 유사한 아키텍처가 어떻게 동작했는지 아는 것 외에는 없습니다.

당신보다 일을 잘하는 사람들과 일하는 것이 물건을 배우는 가장 빠른 방법입니다. 선임 할 사람이 없으면 더 나은 직업이 필요합니다. "당신의 요구를 더 잘 맞추기"에서와 같이 "더 나은". 지식과 경험의 필요성은 현재 딜레마에 의해 입증 된 가장 절실한 필요입니다. 코딩 및 디버깅 단계를 즐기십니까? 완벽한 주니어처럼 들립니다. 그러나 하급은 상급자지도가 필요합니다. 그것이 직업 설명의 요점입니다. 인터넷상의 낯선 사람은 지금까지 당신을 도울 수 있습니다, 당신은 멘토가 필요합니다.

이 질문에 심각한 문제가 있습니다. 시작하자.

건축 설계 시간 낭비를 멈추는 방법

이 질문은 오히려로드되었습니다. 또한 아키텍처를 디자인 하지 않습니다 . 당신은 건축가 입니다. 건축과 디자인은 상호 보완적인 활동이지만 겹칠 경우에도 동일하지는 않습니다.

마찬가지로 아키텍처를 수행하는 데 시간을 낭비 할 수있는 것과 같은 방식으로 (과도한 아키텍처로) 초과 설계 및 코드를 작성하는 데 시간을 낭비 할 수 있습니다 (필요한 것보다 훨씬 복잡한 방식으로 코딩, 또는 필요한 것들에 대한 코드.)

적절한 아키텍처는 코딩 낭비를 방지하는 것을 목표로합니다. 이는 복잡한 시스템이 1) 설계, 2) 코딩 및 테스트, 3) 제공, 4) 유지 보수, 5) 장애 복구 및 6) 궁극적으로 폐기되는 가능한 방법을 제한, 축소 및 문서화함으로써 가능합니다.

내 경험이되었습니다 만, 그들은 단지 코딩을 즐기는 사람들이 코드를 시스템이 작동하고 다음으로 이동, 긴 안목에서 유지 관리하는 방법에 대한 어떤 생각없이 뜨거운 감자 못생긴 골렘을 유지하는 불쌍한 영혼을 떠나.

하지만 난 ...

이것은 일 : 아주 간단 시스템의 아키텍처는 자명 및 사운드 디자인 및 구현 사례에서 발산.

명시적인 아키텍처가 필요한 매우 복잡한 작업을 수행하는 사람이나 시스템 수준의 소프트웨어가 많은 대규모 시스템에만 해당됩니다.

나는 최근에 uni를 졸업하고 프로그래머로 일하기 시작했습니다. "기술적 인"문제를 해결하거나 디버깅을하기가 어렵다는 것을 알 수 없습니다.

이것이이 직업에 필요한 최소한의 것입니다. 문제가 없어서 다행입니다.

그러나 하나의 해결책이없는 일련의 문제가있는 것 같습니다.

이것들은 우리 직업의 빵과 버터이며, 고용주가 우리의 (일반적으로) 평균 이상의 월급을 기꺼이 지불하는 문제의 유형입니다.

사실, 해결해야 할 문제는 둘 이상의 솔루션을 가질 수있는 문제입니다. 실제 문제는 그와 같습니다. 그리고 세계는 소프트웨어 개발자로서 우리의 전문 지식이 수용 가능한 트레이드 오프를 만들어 내야합니다.

-소프트웨어 아키텍처와 같은 것들.

사물의 아키텍쳐는 복잡한 시스템의 불가피한 특성입니다. 가상 / 소프트웨어 또는 콘크리트 세계에서든 마찬가지입니다. 작동하고 입력을 받고 출력을 생성하는 모든 시스템은 복잡하며 아키텍처를 갖습니다.

이러한 시스템 (뱅킹 시스템, 전력 모니터링 시스템, 티켓 판매 시스템 등)을위한 소프트웨어를 개발할 때 이러한 시스템 의 기능과 요구 사항 을 모방 하는 소프트웨어를 제작하는 것이 목표 입니다.

우리는 단순히 그것을 날개로 잡고 카우보이 스타일로 코딩 할 수 없습니다 . 우리는 일종의 아키텍처가 필요합니다. 프로젝트에 수십 명의 엔지니어가 필요한 경우 특히 그렇습니다.

이런 것들이 나를 괴롭 히고 큰 고통을 안겨줍니다.

괜찮습니다. 많은 연습없이 배우거나 가르치는 것은 쉬운 주제가 아닙니다.

프로그램과 시스템을 "아키텍트"하는 방법을 결정하기 위해 몇 시간과 몇 시간을 보냅니다. 예를 들어,이 논리를 1 개 또는 2 개의 클래스로 나누고, 클래스 이름을 어떻게 지정하고, 개인용 또는 공개용으로 만들어야합니까? 나는 단지 프로그램을 만들고 싶다. 아키텍처는 저주 받았다.

불행히도 이것은 소프트웨어 아키텍처가 아닙니다.

디자인이 아니라 코딩 일뿐입니다. 이 게시물의 맨 아래에 제안 사항을 제공하겠습니다.

어떻게하면 더 빨리 건축 상을 통해 코딩과 디버깅 단계에 얻을 수 있습니다 내가 즐길 ?

나는 이것에 대해 대답 할 수있는 방법을 찾는 데 어려움을 겪고 있습니다. 오히려 감정적이기 때문입니다.

우리는 일을 끝내려고 노력하고 있습니까 아니면 연습을 즐기려고 노력하고 있습니까? 둘 다 하나이고 같은 경우에는 좋지만 실제 생활에서는 그렇지 않은 경우가 많습니다.

우리가 즐기는 일을하는 것이 좋지만 우리와 같은 복잡한 직업에서 우리가 즐기는 것에 초점을 맞추는 것은 유익한 경력을 쌓는 데 도움이되지 않습니다.

당신은 발전하지 않으며, 성숙하지 않거나 새로운 지식을 습득하지 않을 것입니다.

군대에는 이런 말이있다.

다른 문구들도 비슷한 조언을합니다. "빨리 빨지 않으면 가치가 없어요."그리고 내가 가장 좋아하는 "빨리 빨면 (중요하다면) 빨지 않을 때까지 해주세요."

내 추천 :

당신이 여전히 차이점을 이해하려고 애 쓰고있는 것 같습니다.

1. 코딩 (클래스, 모듈을 코딩하는 방법 또는 그렇지 않은 것, 명명 규칙, 액세스 가시성, 범위 등)

2. 설계 (계층 수, 프론트 엔드 / 백엔드 / DB, 각각의 통신 방식, 위치) 및 간단한 시스템 설계에서 발생하는 암시 적 아키텍처 결정,

3. 아키텍처 (수십만 시간이 아닌 수천을 필요로하는 복잡한 시스템에서 발견)

따라서 첫 번째 주제 (코딩)에 대해 깊이 탐구하여 다음 단계로 넘어가는 것이 좋습니다.

깨끗한 코드

Robert "Uncle Bob"Martin의 "Clean Code" 는 시작하기에 좋은 곳입니다.

소프트웨어 응집력

또한 LCOM 또는 LCOM4라는 특정 객체 지향 소프트웨어 메트릭에 익숙해지는 것이 좋습니다.

다소 수학적으로 표현할 수 있으며 방탄하지는 않지만 클래스가 응집력이 있거나 응집력이없는 경우 경험적으로 이해하고 감지 (또는 원하는 경우 시선)하는 것이 목표입니다.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

소프트웨어 원칙

이것은 우리 모두에게 친숙해야 할 "단일 책임 원칙" 또는 SRY 와 밀접한 관련이 있습니다. SRY는 코딩에 능숙 해지려면 우리 모두가 알아야 할 5 가지 "SOLID" 중 하나입니다 .

SOLID 원칙을 살펴보면서 클래스 코딩 방식을 결정하거나 안내하는 "GRASP" 원칙 을 숙지해야합니다 .

추가 서적

마지막으로 다음 사항도 제안합니다.

• Martin Fowler와 Ken Beck의 "Refactoring" 은이 목록에서 읽은 다음 책이 될 것입니다.

• Richard Mitchell, Jim McKim 및 Bertrand Meyer (에펠의 명성의 후반부)의 "계약 별 디자인, 예제 별" 이 책은 인쇄되지 않았지만 아마존에서 저렴하고 사용 된 사본을 찾을 수 있습니다.

이를 통해 코딩 및 디자인을 시작하는 방법과 실제로는 소프트웨어 아키텍처를 이동 및 마스터 (또는 최소한 파악)하는 방법을 잘 이해해야합니다.

이 제안에 더하거나 빼거나 반대 할 다른 전문가들이있을 것이라고 확신합니다. 그들은 자신의 경험으로 검증 된 다른 제안을 제시합니다.

내가 말할 수있는 것은 이것입니다-지름길이 없습니다.

모두 제일 좋다.

여기에는 많은 정보가 있으며 솔직히 TL; DR입니다. 시스템을 설계하는 방법을 배우려고 할 때 사람들이 잘못 알고 있다고 생각하는 한 가지 중요한 사항이 있습니다. 그들은 작업이 수행되는 순서대로 시스템을 생각하려고합니다. 대신 거꾸로 작업해야합니다. 즉, 디자인 / 아키텍처의 주요 목표는 최종 결과를 결정하는 것입니다.

비유로 가정의 건축을 고려하십시오. 건축가는 "이 집에 몇 개의 창문이 있어야합니까?", "첫 번째 벽돌을 어디에 배치해야합니까?"와 같은 질문을 스스로 시작하지 않습니다. 이러한 구현 세부 사항은 디자인이 아니며 디자인에서 파생됩니다. 건축은 비전, 아마도 완성 된 집의 모습에 대한 스케치로 시작됩니다. 단독 주택입니까, 이중입니까? 고급 주택입니까, 아니면 저렴한 주택입니까? 마찬가지로 변수가 개인용인지 클래스를 분할하는지 여부는 아키텍처와 거의 관련이 없습니다.

디자인의 목표가 무엇인지 파악하는 것부터 시작하십시오. 예를 들어, 이것이 일회용 솔루션입니까? 수십 년에 걸쳐 확대되고 개정되고 유지 될 예정입니까? 이에 대한 대답은 매우 다른 디자인을 나타내며 이것이 아키텍처의 요점입니다. 무엇을해야하는지 파악한 후에는 디자인의 세부 사항이 자연스럽게 따릅니다. 이러한 세부 사항이 명확하거나 쉬운 것은 아니지만 이러한 선택의 기반이되는 높은 수준의 계획입니다.

어떤 종류의 쓰기 컴파일 테스트 루프를 받기 전에 소프트웨어를 설계하는 데 얼마나 많은 시간을 할애해야하는지 판단하는 방법은 매우 간단합니다. 머리에 맞는 충분한 정보를 제공하는 것입니다. 작업중인 프로젝트가 더 엄격한 방법론을 요구하지 않는 한. 이 경우 초보자라면 아키텍처 문서를 작성하지 말고 읽고 있어야합니다.

이름을 짓는 것에 관해서는 저에게 "쓰기"의 일부이지만 의심 할 여지없이 프로그래밍의 매우 중요한 부분입니다.

올바른 이름, 올바른 아키텍처, 올바른 모듈성 및 올바른 추상화를 찾는 것은 실수를 통해 얻을 수있는 경험의 일부입니다. 수년 동안 나는 약 5 번 같은 일을하는 프로그램을 작성했으며 과거의 반복마다 더 나은 디자인에 대한 힌트를 주었기 때문에 매번 코드가 매우 달랐습니다.