나는 아름답게 쓰여진 과잉 엔지니어링 코드의 나의 부분을 발견했습니다 ... 한 순간 나는 "그것은 그것을 할 수있는 흥미로운 방법입니다"라고 생각하고 있으며, 다음 순간 당신은 "여기에 무엇이 일어나고 있는지 궁금해하고 있습니다!" · The (You Are Not Gonna Need It) 원칙은 과잉 엔지니어링에 대항하는 좋은 방법입니다 : 기능은 당신이 그들을 필요로 할 때만 구현되어야하며, 당신이 그들을 필요로 할 가능성에 따라서는 안됩니다. 이제 YAGNI 이제 매우 간단하게 말하면, 과도한 엔지니어링은 소프트웨어/시스템 설계를 필요한 것보다 복잡하게 만드는 것이다; 이것은 일반적으로 A의 구현을 단순화하기 위해 구성 요소에 추가 기능을 추가하고 싶기 때문에 발생합니다. 우리는 초대장을 관리하기 위해이 코드베이스를 가지고 있습니다; 그것은 상속, 기술적 부채와 상속 코드베이스입니다. 귀하가 코드베이스에 더 많은 부채를 추가하기 위해 노력할수록 코드베이스에 더 많은 부채를 추가합니다. 당신은 대부분의 경우에 복구하고 모든 것을 시작해야합니다. 상속 코드 주위에 작업은 기술적 부채에 대한 관심을 축적하고 필요할 때 데이터를 공유합니다. 처음에는 이것은 응용 프로그램 전반에 걸쳐 기능을 깨뜨리거나 코드베이스에 더 많은 기술적 부채를 추가하는 것 사이의 차이점입니다. 우리가 도입 한 세 번째 솔루션은 추상이었다. 우리는 응용 프로그램에 새로운 기능이나 개선 사항을 모듈화하는 방법을 찾아야했습니다. 그리고 필요한 경우에 데이터를 노출하고 공유합니다. 처음 코드 기반으로 여러 사람과 협력할 때 (그것은 거의 항상 경우), 코드 품질보다 배송 기능에 더 관심이있는 기업을 위해, 코드 리뷰는 항상 고통을 겪습니다. 과잉 엔지니어링 및 과도한 추상과 같은 문제를 위해, 전통적인 라인 당 코드 리뷰는 종종 이러한 체계적인 문제를 놓치고 있습니다. 당신은 몇 주 전에 만든 구성 요소를 DRY 원칙에 따라 기능의 통합을 지원하고, 이제 구성 요소에 의존하는 10 개의 상호 연결 / 유사한 기능이 있다는 것을 깨닫습니다. 코드 리뷰는 이러한 건축 문제를 잡고 구성 요소 간의 의존 요구 사항을 충족하는지 확인해야합니다. 스파게티 Dry Code 우리는 DRY (Don’t Repeat Yourself) 복음을 살고 있습니다.이 복음은 작업을 단순화하고 개발자는 본질적으로 게으르기 때문에 (좋은 방식으로) DRY 원칙은 orthogonal 시스템과 잘 작동합니다. . 시스템은 서로 독립적으로 기능을 구현하는 협력 모듈의 집합으로 구성되어야합니다. Alıntılar - The Pragmatic Programmer: From Journeyman to Master - Kitap.Guru에 대한 리뷰 보기 orthogonal 시스템과 DRY 코드에 더 많은 초점이 있어야합니다; 당신이 만들 수있는 재사용 가능한 기능을 서로 결합하고 저장소가 팽창하고 과도하게 추상되지 않을 때 저장소가 진행함에 따라 그들을 확장하는 것이 더 쉽습니다.이 시점에서 당신은 서로 너무 많이 섞인 단단한 시스템으로 끝나고 정확한 규칙을 충족시키지 않는 코드의 어떤 측면을 연결하는 것이 복잡 할 것입니다.당신은 새로운 연결을 위해 작동하는 것이 오래된 시스템을 깨뜨리기 때문에 코드를 복제하는 것을 발견 할 것입니다. 복잡한 구성요소 귀하의 구성 요소는 반복을 피하는 것에만 집중해서는 안되며, 전체 시스템의 작은 추상물이기도 하다; 그렇지 않으면 연결된 구성 요소로 단일 변경으로 쉽게 깨질 수있는 복잡한 구성 요소로 끝나게됩니다. 재사용 가능한 코드를 만들 때 접근 방식은 어떤 다른 코드 블록에 의존하지 않는 코드를 쓰는 것이어야합니다. 재사용성은 도구가 아니라 목표로 사용되어야합니다; 비즈니스 또는 API 논리를 가진 재사용 가능한 UI 구성 요소가 동일한 구성 요소에있을 때, 당신은 과도한 추상에 대한 고속도로에 있습니다. 그것은 작기 시작하고, 당신이 무슨 일이 일어나고 있는지 깨닫기 전에, 질병은 당신의 저장소 전체에 묶여있다. 과도한 추상화와 과도한 엔지니어링을 피하기 위한 패턴 Modularity Modularity 모듈러성 모듈러성 모듈성은 시스템을 모듈이라고 불리는 더 작은 독립적 인 코드 / 구성 요소로 분해하는 것을 포함합니다. ‘작은’이라는 단어에주의를 기울이십시오; 필요한 것보다 많은 코드가있는 팽창 된 모듈을 가질 수 있으며, 이는 과도한 추상화를 창출하고 피해야합니다. 과도한 추상은 실제로 모듈성에 대한 실패한 시도 일뿐입니다. 모듈은 다른 모듈과 독립적으로 작동 할 수 있어야하며 필요한 데이터만 노출 할 수 있습니다. 좋은, 모듈식, 구조화 된 코드에 대한 변경은 모듈에만 영향을 미치지 않아야합니다. 최초의 기능 orthogonal 시스템을 구축하고 과도한 추상화를 쉽게 피하는 좋은 접근 방법은 기능을 먼저 구축하고 기능을 다음으로 구축하는 것입니다; 이것은 구성 요소 기반 아키텍처와 잘 일치합니다(국가적인 구성 요소로부터 UI 구성 요소를 분리).functionality 단계는 기능을 구현하기 위해 조립 된 가장 작은 재사용 가능한 코드 단위에 초점을 맞출 것입니다.Login 기능은 다음과 같은 기능으로 구성됩니다 : 사용자 이름과 암호 (UI)를 수집하고, 사용자 데이터를 검증하고, 사용자 프로필로 리디렉션 / 수집된 사용자 데이터를 거부합니다. 과도하게 정교한 코드에 대한 메달 없음 각 코드 구현을 작성한 후, 동일한 결과를 달성하는 쉬운 방법이 있는지, 아니면 더 간단한 방법이 있는지 스스로에게 물어보십시오.우리 대부분은 회사의 한 사람만이 편집하거나 작업할 수 있는 코드에 대한 이야기를 들었으며, 이는 자랑스러워 할 만한 업적이 아닙니다.당신만이 유지할 수 있는 코드를 작성하는 것은 아마도 과도하게 정교하거나 비정상적인 절차를 사용한다는 것을 의미합니다. 회사의 전직 직원은 코드를 확인하지 않고 프로그램과 코드베이스의 일부를 하드 드라이브에 가지고 있기 때문에 알려져 있습니다 (그 제품을 유지하기위한 오버 헤드를 상상해보십시오!). "We ran out of columns" - 지미 밀러의 최고의, 최악의 코드베이스 나는 방금 배운 새로운 기술 / 패키지 / 라이브러리를 사용하고 싶기 때문에 너무 정교한 코드를 쓰는 것을 발견했으며, 그것이 작업을위한 가장 간단한 도구인지 여부를 고려하지 않고 있습니다. 최종 모든 가능한 미래와 시간 여행 사례를 설명하는 완벽한 코드를 작성하기위한 탐구에서, 당신은 과도한 엔지니어링 코드베이스로 끝납니다. 당신은 완벽한 코드를 작성하는 것이 불가능하기 때문에 포기해야합니다. DRY 원칙은 근본적입니다; 반복은 여전히 소프트웨어 개발의 죄입니다. DRY 원칙은 orthogonal 시스템에 적용되어야합니다. 각 모듈이 독립적이며 별도의 회의 지점(기능 모듈)에서 데이터를 교환 할 수있는 코드베이스를 만들기 위해 orthogonal 시스템에 적용해야합니다. 이들은 유지 및 디버그가 쉬운 시스템을 만드는 데 도움이됩니다. 간단한 것은 소프트웨어 개발에서 항상 더 좋습니다.
