SOLID를 따르는 것이 기술 스택 위에 프레임 워크를 작성하게합니까?

저는 SOLID를 좋아하며 개발할 때 최선을 다하여 사용하고 적용합니다. 그러나 나는 SOLID 접근 방식이 코드를 '프레임 워크'코드로 바꾸는 것처럼 도울 수는 없지만 느낄 수는 없습니다. 즉, 다른 개발자가 사용할 프레임 워크 나 라이브러리를 만드는 경우 설계 한 코드입니다.

나는 일반적으로 요구 사항과 KISS (일반 프로그래밍)를 통해 요구되는 것을 거의 또는 덜 생성하거나 다른 개발자가 필요할 수있는 유연성을 제공하는 매우 일반적이고 재사용 가능한 논리, 서비스 등을 만드는 두 가지 프로그래밍 모드를 연습했습니다. .

사용자가 실제로 x와 y 작업을 수행하는 응용 프로그램을 원한다면 시작하기에 유효한 문제인지조차 모를 때조차도 SOLID를 따라 추상화의 전체 진입 점을 추가하는 것이 합리적입니까? 와? 이러한 추상화의 진입 점을 추가하면 사용자 요구 사항을 실제로 충족 시키거나 기존 프레임 워크 및 기술 스택 위에 프레임 워크를 만들어 향후 추가를 쉽게 할 수 있습니까? 어떤 경우에 고객 또는 개발자의 이익을 위해 봉사하고 있습니까?

이것은 Java Enterprise 세계에서 일반적으로 보이는 것인데, J2EE 또는 Spring 위에 자신의 프레임 워크를 디자인하는 것처럼 느껴지므로 사용자의 UX에 중점을 두지 않고 개발자에게 더 나은 UX가됩니까?

관찰 결과는 정확하고 SOLID 원칙은 재사용 가능한 라이브러리 또는 프레임 워크 코드를 염두에두고 IMHO로 만들어졌습니다. 의미가 있는지 묻지 않고 모든 것을 맹목적으로 따라갈 때, 필요 이상으로 시스템에 과도하게 일반화하고 더 많은 노력을 기울일 위험이 있습니다.

이것은 절충이며 일반화시기와 그렇지 않은시기에 대한 올바른 결정을 내리기 위해서는 약간의 경험이 필요합니다. 이것에 대한 가능한 접근 방식은 YAGNI 원칙을 고수하는 것입니다-코드를 "경우에 따라"만들지 말거나 단어를 사용하지 마십시오.

다른 개발자 들이 필요로 하는 유연성 제공

대신, 다른 개발자 들이 필요 로하는 즉시 실제로 필요한 유연성을 제공하십시오 .

따라서 코드에 하나의 함수 또는 클래스가있을 때마다 재사용 할 수 있는지 확실하지 않으면 지금 프레임 워크에 넣지 마십시오. 재사용 할 실제 사례가있을 때까지 기다렸다가 "해당 사례에 대해 충분히 SOLID"로 리 팩터하십시오 . 실제 재사용 사례에 실제로 필요한 클래스에 더 많은 구성 기능 (OCP에 따름) 또는 추상화 시작점 (DIP 사용)을 구현하지 마십시오. 재사용에 대한 다음 요구 사항이 실제로있을 때 다음 유연성을 추가하십시오.

물론 이러한 작업 방식은 기존의 작업 코드 기반에서 항상 약간의 리팩토링이 필요합니다. 이것이 바로 자동 테스트가 중요한 이유입니다. 따라서 코드를 처음부터 단위 테스트가 가능하도록 충분히 SOLID로 만드는 것은 시간 낭비가 아니며 그렇게하는 것이 YAGNI와 모순되지 않습니다. 자동 코드 테스트는 "코드 재사용"에 유효한 경우입니다. 해당 코드는 테스트뿐만 아니라 프로덕션 코드에서도 사용되기 때문입니다. 그러나 테스트가 실제로 작동하도록하는 데 필요한 유연성을 추가하십시오.

이것은 실제로 오래된 지혜입니다. 우리가 쓰는하기 전에 오래 전 용어가 SOLID 인기 도착하기 전에, 누군가가 나에게 다시 , 우리가 작성해야 가능 코드를 사용할 수있는 코드를. 그리고 나는 이것이 좋은 추천이라고 생각합니다.

내 경험으로는 앱을 작성할 때 세 가지 중에서 선택할 수 있습니다.

1. 요구 사항을 충족시키기위한 코드 만 작성
2. 미래의 요구 사항을 예상하고 현재 요구 사항을 충족시키는 일반 코드를 작성하십시오.
3. 현재 요구 사항 만 충족하지만 나중에 다른 요구를 충족시키기 위해 쉽게 변경할 수있는 코드를 작성하십시오.

첫 번째 경우, 단위 테스트가없는 밀접하게 결합 된 코드로 끝나는 것이 일반적입니다. 쓰기는 빠르지 만 테스트하기는 어렵습니다. 그리고 요구 사항이 변경 될 때 나중에 변경하는 것은 올바른 왕의 고통입니다.

두 번째 경우, 미래의 요구를 예상하는 데 많은 시간이 소요됩니다. 그리고 미래의 요구 사항이 충족되지 않는 경우가 종종 있습니다. 이것은 당신이 묘사 한 시나리오처럼 보입니다. 대부분의 노력을 낭비하고 불필요하게 복잡한 코드를 생성하여 예상하지 못한 요구 사항이 발생할 때 변경하기가 여전히 어렵습니다.

마지막 경우는 제 관점에서 목표로하는 것입니다. TDD 또는 유사한 기술을 사용하여 코드를 테스트하면 느슨하게 결합 된 코드가 생겨서 수정하기는 쉽지만 작성하기는 쉽습니다. 그리고 이렇게하면 자연스럽게 많은 SOLID 원칙을 따르게됩니다. 작은 클래스와 기능; 인터페이스 및 주입 된 종속성. 그리고 Liskov 여사는 단일 책임을 가진 간단한 수업이 대체 원칙을 거의 따르지 않기 때문에 일반적으로 행복을 유지합니다.

여기에 실제로 적용되지 않는 SOLID의 유일한 측면은 개방 / 폐쇄 원칙입니다. 라이브러리와 프레임 워크의 경우 이것이 중요합니다. 자체 포함 된 앱의 경우 그리 많지 않습니다. 실제로 " SLID " 를 따르는 코드를 작성하는 경우가 있습니다. 쓰기 (읽기), 테스트 및 유지 관리가 용이합니다.

개인적인 경험에 의해 당신이 가진 관점이 왜곡 될 수 있습니다. 이것은 개별적으로 정확한 사실의 미끄러운 기울기이지만 언뜻보기에는 정확 해 보이지만 결과 추론은 정확하지 않습니다.

• 프레임 워크는 소규모 프로젝트보다 범위가 더 큽니다.
• 더 큰 코드베이스에서는 나쁜 습관을 다루기가 훨씬 어렵습니다.
• 프레임 워크를 구축하려면 (평균적으로) 소규모 프로젝트를 구축하는 것보다 숙련 된 개발자가 필요합니다.
• 더 나은 개발자는 우수 사례 (SOLID)를 더 많이 따릅니다.
• 그 결과, 프레임 워크는 좋은 연습을위한 높은 필요가 와 더 밀접하게 좋은 연습 경험이있는 개발자들에 의해 구축되는 경향이있다.

이는 프레임 워크 및 더 작은 라이브러리와 상호 작용할 때 상호 작용할 모범 사례 코드가 더 큰 프레임 워크에서 더 일반적으로 발견됨을 의미합니다.

이 오류는 매우 흔합니다. 예를 들어 제가 치료를받은 모든 의사는 거만했습니다. 그러므로 나는 모든 의사들이 거만하다고 결론지었습니다. 이러한 오류는 항상 개인적인 경험을 바탕으로 담요를 추론 하는 데 어려움을 겪 습니다.

귀하의 경우에는 작은 라이브러리가 아닌 더 큰 프레임 워크에서 주로 모범 사례를 경험했을 수 있습니다. 당신의 개인적 관찰은 틀리지 않지만 일화적인 증거이며 보편적으로 적용 할 수는 없습니다.

2 가지 프로그래밍 모드-요구 사항 및 KISS (일반 프로그래밍)를 통해 요구되는 내용을 다소 정확하게 생성하거나 다른 개발자가 필요로하는 유연성을 제공하는 매우 일반적이고 재사용 가능한 논리, 서비스 등을 생성 (프레임 워크 프로그래밍)

여기서 약간 확인하고 있습니다. 프레임 워크가 무엇인지 생각하십시오. 응용 프로그램이 아닙니다. 다른 사람들이 모든 종류의 응용 프로그램을 만드는 데 사용할 수있는 일반화 된 "템플릿"입니다. 논리적으로 이는 모든 사람이 사용할 수 있도록 프레임 워크가 훨씬 더 추상화 된 논리로 구축됨을 의미합니다.

프레임 워크 빌더는 후속 애플리케이션의 요구 사항이 무엇인지조차 모르기 때문에 단축키를 사용할 수 없습니다. 기본적으로 프레임 워크를 구축하면 다른 사람들이 자신의 코드를 사용할 수 있도록 장려합니다.

그러나 애플리케이션 빌더는 제품 제공에 중점을두기 때문에 논리적 효율성에 영향을 줄 수 있습니다. 그들의 주요 목표는 코드의 작동이 아니라 사용자의 경험입니다.

프레임 워크의 경우 최종 사용자는 코드와 상호 작용할 다른 개발자입니다. 코드 품질은 최종 사용자에게 중요합니다.
응용 프로그램의 경우 최종 사용자는 개발자가 아니며 코드와 상호 작용하지 않습니다. 코드의 품질은 중요하지 않습니다.

이것이 바로 개발 팀의 설계자가 종종 모범 사례의 집행자로 행동하는 이유입니다. 그것들은 제품 제공에서 제거되는 한 단계이므로 애플리케이션 자체의 제공에 초점을 맞추기보다는 코드를 객관적으로 보는 경향이 있습니다.

이러한 추상화의 진입 점을 추가하면 사용자 요구 사항을 실제로 충족 시키거나 기존 프레임 워크 및 기술 스택 위에 프레임 워크를 만들어 향후 추가를 쉽게 할 수 있습니까? 어떤 경우에 고객 또는 개발자의 이익을 위해 봉사하고 있습니까?

이것은 흥미로운 점이며, 사람들이 여전히 좋은 습관을 피하는 것이 정당화되는 주된 이유입니다.

아래 요점을 요약하면 : 현재 알려진대로 요구 사항을 변경할 수없는 경우에만 모범 사례를 건너 뛸 수 있으며 코드베이스에 변경 / 추가가 없을 것입니다. 스포일러 경고 : 거의 그렇지 않습니다.
예를 들어, 특정 파일을 처리하기 위해 5 분 콘솔 응용 프로그램을 작성할 때는 모범 사례를 사용하지 않습니다. 오늘은 응용 프로그램 만 사용할 예정이므로 나중에 업데이트 할 필요가 없습니다 (다시 필요할 경우 다른 응용 프로그램을 작성하는 것이 더 쉬울 것입니다).

4 주 안에 애플리케이션을 순조롭게 구축 할 수 있고 6 주 내에 애플리케이션을 올바르게 구축 할 수 있다고 가정 해 봅시다. 언뜻보기에, 그것을 건전하게 만드는 것이 더 좋아 보인다. 고객은 응용 프로그램을 더 빨리 얻을 수 있으며 회사는 개발자 임금에 더 적은 시간을 소비해야합니다. 승리?

그러나 이것은 미리 생각하지 않고 내려진 결정입니다. 코드베이스의 품질로 인해, 순조롭게 구축 된 코드를 크게 변경하는 데 2 ​​주가 걸리고, 올바르게 구축 된 코드를 동일하게 변경하는 데는 1 주일이 걸립니다. 앞으로 이러한 변경 사항이 많이있을 수 있습니다.

더욱이, 초기에 개발 된 코드베이스에서 생각했던 것보다 더 많은 작업이 예상치 않게 더 많은 작업을 필요 로하는 경향이있어 개발 시간을 2 주가 아닌 3 주로 단축시킬 수 있습니다.

그리고 버그를 찾는 데 시간을 낭비하는 경향이 있습니다. 최종 제품이 예상대로 작동한다는 가정하에 무심코 일하기 때문에 시간 제약으로 인해 로깅이 무시되거나 구현을 원하지 않는 프로젝트의 경우가 종종 있습니다.

주요 업데이트 일 필요도 없습니다. 현재 고용주에서 신속하고 더러운 여러 프로젝트를 보았으며 요구 사항의 잘못된 통신으로 인해 가장 작은 버그 / 변경이 필요한 경우 모듈 후 모듈을 리팩터링 해야하는 연쇄 반응으로 이어졌습니다 . 이 프로젝트 중 일부는 첫 번째 버전을 출시하기 전에 무너져 버렸습니다.

바로 가기 결정 (빠르고 더러운 프로그래밍)은 요구 사항이 정확하고 변경이 필요하지 않다는 결론을 확실하게 보장 할 수있는 경우에만 유용합니다 . 내 경험상, 나는 그것이 사실 인 프로젝트를 본 적이 없다 .

좋은 연습에 여분의 시간을 투자하는 것은 미래에 투자하는 것입니다. 기존 코드베이스가 모범 사례를 기반으로 구축되면 향후 버그 및 변경이 훨씬 쉬워집니다. 두세 번만 변경하면 이미 배당금을 지불하게됩니다.

SOLID는 간단한 코드를 프레임 워크 코드로 어떻게 전환합니까? 나는 어떤 방식 으로든 SOLID의 표준은 아니지만 여기서 의미하는 바는 분명하지 않습니다.

• KISS는의 본질이다 S 화롯불 책임 원리.
• 에서 어디에도 없습니다 O의 펜 / 청산 원리 (내가 이해 이상으로 봐야 존 소총을 잘 한 일을하는 코드를 작성에 들어가). (실제로 코드에 더 집중할수록 "닫힌"부분이 더 중요해집니다.)
• L의 iskov 대체 원리는 사람들이 클래스를 서브 클래 싱 할 필요가 말을하지 않습니다. 클래스 를 서브 클래 싱 하는 경우 서브 클래스는 수퍼 클래스의 계약을 이행해야합니다. 좋은 OO 디자인입니다. 하위 클래스가없는 경우에는 적용되지 않습니다.
• KISS는 또한의 본질이다 I의 nterface 독방 원리.
• D의 ependency 반전 원리 나 원격으로는 적용 볼 수있는 유일한 사람이지만, 나는 그것이 널리 오해와 과장된 생각합니다. 그렇다고 Guice 또는 Spring으로 모든 것을 주입해야한다는 의미는 아닙니다. 그것은 적절한 곳에서 추상화해야하고 구현 세부 사항에 의존하지 않아야 함을 의미합니다.

나는 Bob Martin 학교가 아니라 Gang of Four 와 Josh Bloch 프로그래밍 학교를 통해 나왔기 때문에 SOLID 용어로 생각하지 않는다는 것을 인정 합니다. 그러나“SOLID”=“기술 스택에 더 많은 레이어 추가”라고 생각하면 잘못 읽고 있다고 생각합니다.

추신“개발자에게 더 나은 UX”의 이점을 짧게 판매하지 마십시오. 코드는 대부분의 수명을 유지 관리에 소비합니다. 개발자는 당신 입니다.