사소한 응용 프로그램을 작성할 때는 작업을 빠르게 수행하고 모델 논리를 뷰와 혼합하고 캡슐화를 깨는 것과 같은 코드에서 바로 가기를 취하는 것이 가장 좋습니다. 또는 더 많은 아키텍처를 빌드하고 올바르게 빌드하는 데 시간을내는 것이 더 좋지만 디자인이 유동적이기 때문에이 추가 코드를 모두 사용하지 못할 수 있으며 피드백이 발생하면이를 버려야 할 수도 있습니다. 다른 방향으로 가고?

컨텍스트를 위해 데스크톱 응용 프로그램을 작성 중입니다. 나는 유일한 개발자이고 하루 일을 한 이후로이 아르바이트를하고 있습니다. 이제는 일을 위해 올바른 방법으로 일을하려고 노력하고 일정을 잡습니다. 그러나 사람들로부터 피드백을받을 때 변형 될 것으로 예상되는이 프로젝트의 경우 올바른 접근법인지 확실하지 않습니다. 이번 주에 몇 시간 동안 모델의 변경 사항을 뷰에 전달하기 위해 교과서 Model View Controller 설계를 작성했습니다. 이것은 일반적으로 훌륭하지만 데이터를 표시하기 위해 여러보기가 필요한지 확실하지 않으며 추가 아키텍처없이 더 빨리 표시 할 수 있음을 알고 있습니다. 일주일에 10-15 시간을 프로젝트에 쓰는 데 좋은 소프트웨어 관행을 따를 경우 시연 할 수있는 무언가를 얻는 데 오랜 시간이 걸릴 것이라고 생각합니다. 내 사용자가 내가 MVC를 내부적으로 사용했다는 점을 염두에두면 문제를 해결할 무언가를 원할뿐입니다. 그러나 나는 또한 당신이 지름길로 인해 너무 많은 기술적 부채를 겪어 코드를 유지하고 새로운 기능을 추가하기가 엄청나게 어려운 상황에 처해 있습니다. 다른 사람들이 이런 종류의 문제에 어떻게 접근하는지 듣고 싶습니다.

잘 구축하십시오 .

큰 그림을 보면 "빠른"구축은 논리적 오류입니다. 그것은 당신이 그것을 잘 구축하지 못하게 할 것이며, 결국 리팩토링을 막거나 불가능한 옆에 새로운 기능을 추가하는 버그와 근본적인 아키텍처 결함으로 인해 혼란에 빠질 것입니다.

잘 구축하는 것은 실제로 반대입니다. 처음에는 속도가 느려질 수 있지만 결국 올바른 선택을하기 위해 시간을내어 효율성을 높일 수 있습니다. 또한 향후 요구 사항에보다 쉽게 ​​적응할 수 있으며 (필요한 경우 리팩토링) 최소한의 버그로 인해 최종 제품의 성능이 향상됩니다.

다시 말해서 (이것이 일대일 계약이 아닌 한) 빠른 구축 = 느리게 구축, 잘 구축 = 빠르게 구축 .

또한 "잘 구축"하고 아키텍처를 설계 할 때 알아야 할 중요한 사항이 있습니다. 당신은 물었다 ...

...하지만 디자인이 유동적이기 때문에이 추가 코드를 모두 사용할 수없는 위험을 감수하고 피드백으로 인해 다른 방향으로 나아가는 경우이를 버려야 할 수 있습니까?

"아키텍처 시간 소비"로 인한 진정한 위험은 아닙니다. 건축 디자인은 유기적이어야한다 . 정당화 될 때까지 어떤 부분에 대해서도 아키텍처를 설계하는 데 시간을 소비하지 마십시오. 아키텍처는 프로젝트에서 관찰되고 확인 된 패턴에서 발전해야합니다.

Systemantics 의 John Gall의 법칙 :

처음부터 설계된 복잡한 시스템은 작동하지 않으며 작동하도록 패치 할 수 없습니다. 작동하는 간단한 시스템부터 시작하여 다시 시작해야합니다.

그럼 빨리

이것은 내 개인적인 경험에서 많은 다른 방법을 시도한 것입니다.

빠르게 작동하고 해제하는 것의 문제는 일반적으로 응용 프로그램에 기능 후에 기능을 적용한다는 것입니다. 기능이 릴리스되었으므로 프로그램을 근본적으로 변경하기가 매우 어렵습니다. 사운드 기반 아키텍처를 갖지 않는 것에 대해 장기적으로 가파른 가격을 지불하면 퀵 샌드에 쓰러 질을 짓는 것과 같습니다.

잘하는 프로그램은 많은 시간과 코드를 낭비한다는 것입니다. 청사진없이 저택을 짓는 것과 같습니다. 응용 프로그램 작성은 학습 과정이며 거의 (내 경험상) 초기에 설계 할 수 없습니다. 그것은 당신이 많은 리팩토링을 할 것이고, 모든 것을 "잘"작성한다면, 많은 코드를 버릴 것입니다.

따라서 빨리, 그럼!

시작할 때 가장 중요한 것은 모든 기능을 코드로 작성하여 모든 기능을 적용하고 지원해야 할 아키텍처를 확인할 수 있다는 것입니다. 이 방법론의 또 다른 좋은 점은 빠르게 무언가를 실행하기 때문에 계속 동기를 부여한다는 것입니다. 일반적인 아키텍처에 영향을 미치므로 "가장자리"기능을 구현하는 것도 중요합니다. 이 단계에서 단위 테스트를 작성하거나 세부 사항에 대해 작업하지 마십시오. 미래에 다국어를 지원해야한다고 생각한다면 플러그인 아키텍처는 구현하지 만 빠르고 더러운 것입니다. 응용 프로그램을 관리 가능하게 유지하기 위해 리팩토링을 수행하지만 과도한 작업은 없습니다.

"프로토 타입"이 작동한다고 생각되면 리팩토링을 시작할 차례입니다. 기본적으로 지금 아는 모든 것을 알고 처음부터 시작한 경우처럼 응용 프로그램을 다시 실행하려고합니다. 중요한 것은 1 단계에서 수행 한 모든 기능을 다시 구현하지 않고 아키텍처를 올바르게 작성하는 것이지만 나중에 아키텍처를 지원해야합니다.

이렇게하면 어쨌든 내 경험에 따라 가능한 한 효율적으로 사운드 아키텍처가있는 응용 프로그램을 만들 수 있습니다. :)

그것을 구축

시장 출시 시간이 품질보다 중요한 경우 빠름

잘 품질은 시장에 시간보다 더 중요한 경우

빠르게 구축하면 단기 혜택과 장기 손실이 발생합니다.

잘 구축하면 단기 손실이 발생하지만 장기적인 이점이 있습니다.

그것을 잘 만들면 인내와 지혜가 필요하지만 보상을받을 것입니다.

빠르게 구축하는 것은 빠른 프로토 타이핑 및 버리기 작업에만 적합합니다. 장기 목표는 처음부터 올바른 태도로만 달성 할 수 있습니다.

다른 사람들이 사용하기 위해 배포하려는 프로젝트의 경우 항상 선행 작업 측면에서 오류가 발생합니다. 잘 생각한 아키텍처는 필요한 경우 확장하기가 더 쉽습니다. 지름길은 기술 부채를 축적하는 모델 일뿐입니다.

때때로 실망스럽게 느려질 수 있습니다. 할 가치가있는 일은 올바르게 할 가치가 있습니다.

잘 구축 = 빨리 구축

지름길은 돌아 서서 당신이 생각하는 것보다 더 빨리 물린 경향이 있습니다. 때로는 점심 전에도.

당신의 상황에 대하여; 즉시 추상화하지 마십시오. YAGNI를 고수하고 복제를 제거하십시오. 실제로 두 번째 뷰를 가질 때 해당 뷰 기반 패턴을 구현하십시오. 두 번째보기가 추상화에 도달하면 일반적으로 첫 번째 단일 발생에 대해 작성한 것보다 훨씬 낫습니다.

이미하고있는 일을 이미 알고 있다면하지 않으면 빨리

저는 연구 과학자이며 큰 그림이 무엇인지 또는 프로젝트가 어떻게 발전 할 것인지에 대한 단서가 있기 전에 많은 탐색 코드를 작성합니다. 이 경우 "웰"이 어떻게 정의되어야하는지보기조차 어렵습니다. 또한 일반적으로 모든 세부 사항과 방법을 미리 확장하는 것은 어렵습니다. 따라서 이전 격언이 적용됩니다.

1. 작동하게 만들다.
2. 잘되도록하세요. 올바르게 사용하면 "작동"한 경험이 있다면 "올바른"을 더 잘 정의 할 수 있다는 이점이 있습니다.

잘 만드세요. 항상 그렇습니다.

그러나 빨리 만들기 위해서는 더 작게 만드십시오. 피드백을 받기에 충분히 중요한 전체의 작은 하위 집합을 만듭니다. 일정한 속도로 점진적으로 추가하면 벌레를 치는 잠이없는 밤의 연쇄 반응에 영혼을 팔지 않고 빨리 건축하는 것과 동일한 이점이 많이 있습니다.

항상 "잘 구축해야"한다고 생각합니다. 출시 시간이 큰 문제라면 점진적인 개발 프로세스를 사용하십시오. 최악의 시나리오는 기능이 적은 제품이지만, 향후 기능 릴리스에서 확장 할 수있는 고품질 제품을 제공하는 것입니다.

균형

코드를 완벽하게 엔지니어링하거나 일부 코드를 한꺼번에 모으는 것은 실용적이지 않습니까? 정말 적절한 균형을 잡는 것에 관한 것입니다. 내 의견에 중요한 것은 당신이 언제 무엇을 하는가입니다.

여기서 가장 중요한 것은 응용 프로그램의 핵심, 기본 구조가 실제로 잘 구축되도록하는 것입니다. 기밀, 밀폐 된. 일단 그것이 시간 제약에 따라 달성되면, 시간이 부족한 경우 코드를 모아 나중에 다시 리팩터링 할 수 있으며 기초를 얻기 위해주의를 기울 였기 때문에 그 고급 스러움을 줄 수 있습니다 코드를 리팩터링하는 것은 아프지 않습니다.

가능한 가장 간단한 일을하십시오. 특별한 경우에, 당신은 파트 타임으로 일하는 유일한 사람이되어서 프로그램이 크게되지 않을 것입니다. 나는 goto abuse, nondescript 변수 이름과 같은 나쁜 매너를 옹호하지는 않지만, 그것을보다 복잡하게해서는 안됩니다. 어쩌면 MVC는 특정 프로젝트에 과잉 일 수 있습니다.

사람들로부터 피드백을받을 때 변형 될 것으로 예상됩니다

당신은 그것을 가장 잘 말했다 :

그러나 나는 또한 당신이 지름길로 인해 너무 많은 기술적 부채를 겪어 코드를 유지하고 새로운 기능을 추가하기가 엄청나게 어려운 상황에 처해 있습니다.

시간이 부족한 경우에도 동일한 추론을 사용하여 고용주로부터 프로젝트를 완료 할 시간을 더 많이 요구하지 마십시오. 그들이 당신에게 그것을 줄 것이라고 확신합니다. 이것을 말하면서, 나는 좌절감이 때로는 무언가에 대해 열심히 노력하고 너무 많은 결과를 보여줄 수 없다는 느낌을받습니다. 그러나 걱정하지 마십시오. 당신은 거기에 도착할 것이고, 잘 만들면 확실히 가치가있을 것입니다.

일반적으로 구조를 잘 작성하고 특정 구현 세부 사항에 대해 걱정하지 않고 시간을 절약하고 싶습니다. 당신이 말했듯이, 그들은 어쨌든 바뀔 것입니다. 잘 만들어진 하부 구조를 만드는 배후의 아이디어는 일단 기지가 건설되면 변화가 매우 빠르게 일어날 수 있다는 것입니다. 나는 수업에서 가능한 한 일반적이고 집중할 수있는 곳에 집중하려고 노력한다. 나는 일반적으로 사용자에게 가장 기본적인 유용성 요구 사항 만 충족시키는 잘 구축 된 앱을 제공합니다. 도구가 있으면 사용자는 모든 종류의 아이디어를 얻을 수 있으므로 훨씬 앞서 생각할 필요가 없습니다.

잘 구축하십시오 . 시간이 없으면 기능 세트를 줄이십시오.

최대한 보편적 으로 설계하십시오 . 예를 들어, 플러그인 아키텍처를 설계하십시오. 아는 경우에도 처음에는 하나의 플러그인 만 사용됩니다. 처음에는 매개 변수가 하나 뿐인 경우에도 범용 구성 체계 (확장 가능한 구성, 언어 구성)를 사용하십시오. 매우 좋은 투자 이며 프로젝트 시작시에만 투자 할 수 있습니다.

작업을 빠르게 수행하고, 뷰와 모델 로직을 혼합하고, 캡슐화를 깨는 등 일반적인 코드 냄새에 집중하는 것이 가장 좋은 방법입니까? 또는 더 많은 아키텍처를 구축하는 데 시간을내는 것이 더 낫습니까?

내 귀에, 당신이 그것을 넣는 방식에, 당신은 두 가지 극단을 나열하고 있습니다. 첫 번째 선택은 캡슐화를 깨고 뷰에 모델 로직을 넣는 것입니다. IMHO는 이러한 문제를 해결하는 것이 더 많은 아키텍처를 도입하는 것과 다릅니다. 아마도 당신이 말하는 것이 아니라면 UI 코드가 SQL 문을 실행하고 있다는 것입니다. 그러나 더 많은 아키텍처를 구축한다고 말하지 않으면 디자인과 아키텍처가 완전히 부족하여 하나 더 얻어야한다고 말할 수 있습니다.

아키텍처와 관련하여 지금 당장 문제를 해결하는 가장 간단한 것을 선택하고 문제가 발생할 때 확장합니다.

예를 들어 지금은 단일 데이터베이스 테이블에서 데이터를 반환하는 기능이 필요합니다. 문제가 결국 발생한다는 것을 알고 있지만 관련 테이블에서 데이터를로드하는 방법과 같은 문제에 대해서는 걱정하지 않습니다. 해당 기능을 구현할 때 걱정하기 시작합니다.

따라서 본인의 주택 개발 프로젝트의 경우 다음과 같은 접근 방식을 사용합니다. 현재 작업중인 문제를 해결하는 가장 간단한 솔루션을 구축하지만 제대로 구축하십시오. 그런 다음 더 많은 복잡성이 필요할 때 솔루션을 리팩터링합니다. TDD 관행을 준수하면 리팩토링을 안전하게하고 코드 냄새를 피할 수 있습니다 (캡슐화를 깨 뜨리면 좋은 단위 테스트를 만들기가 어렵습니다).

그것은 우연히 전문적으로 일할 때 취하는 접근법이기도합니다. ;)

먼저 소프트웨어를 세우고 모든 측면을 다루고 소프트웨어를 먼저 세우고 점차적으로 꾸미고 성능을 향상시키는 것이 좋습니다.

일반적으로이 두 가장자리의 중간에 있어야합니다.

잘 구축하십시오 = 사람들의 삶이 의존하는 삶에 중요한 실시간 소프트웨어. 즉, 소프트웨어 제어 : 원자로, 투석기, MRI 기기 등

누구도 실제로 사용하지 않는 쓸모없는 소프트웨어를 빠르게 구축하십시오 .