소프트웨어 복잡성과의 끝없는 싸움

복잡성이란 무엇입니까?

최근에 "소프트웨어 디자인 철학"을 읽었고 두 번째 장에서는 소프트웨어 복잡성이라는 주제를 탐구합니다. 

"A Philosophy of Software Design"이라는 책에서는 복잡성을 실질적으로 정의합니다.

"복잡성은 이해하고 수정하기 어렵게 만드는 소프트웨어 시스템의 구조와 관련된 모든 것입니다."

즉, 복잡성은 다양한 형태를 취할 수 있으며 반드시 성능과 관련이 있는 것은 아닙니다. 코드는 성능을 발휘하면서도 여전히 복잡할 수 있습니다

이 기사에서는 책에 담긴 몇 가지 주요 정의와 통찰력을 공유하고 싶습니다. 하지만 먼저 여러분이 이미 겪어봤을 일반적인 상황을 상상해 봅시다...

---

짧은 공포 이야기

많은 분들이 경험하셨거나 경험하게 되실 공포 이야기 속으로 들어가 보겠습니다.

1. 간단한 CRUD 작업 관리 앱으로 시작되었습니다. 코드는 깔끔하고 모듈식이며 유지 관리가 쉬웠습니다. 개발팀은 만족했고 시스템은 초기 고객에게 완벽하게 작동했습니다.

2. 문제는 영업팀이 시스템에 캘린더 통합, 이메일 알림, 놀라운 보고서 생성 기능이 있다고 주장하면서 시스템을 대기업에 판매하면서 시작되었습니다. 판매가 마무리되면서 이러한 기능을 신속하게 구현해야 했습니다.

3. 캘린더 통합: 팀은 Google 캘린더 및 Outlook과 통합해야 했습니다. 다양한 개발자가 솔루션을 구현했기 때문에 접근 방식이 일관되지 않았습니다.

4. 이메일 알림: 이메일 알림이 다음에 추가되었습니다. 한 개발자는 특정 라이브러리를 사용했고 다른 개발자는 맞춤형 솔루션을 만들었습니다. 혼합된 접근 방식으로 인해 코드가 혼란스러워졌습니다.

5. 보고서 생성기: 보고서 생성기의 경우 개발자는 PDF, Excel 내보내기, 대화형 대시보드 등 다양한 기술을 사용했습니다. 통일된 접근 방식이 부족하여 유지 관리가 악몽이 되었습니다.

6. 점증하는 복잡성: 각 기능은 독립적으로 빠르게 개발되어 기능 간 종속성이 발생했습니다. 개발자들은 모든 것이 작동하도록 "빠른 수정"을 만들기 시작하여 시스템의 복잡성과 연결성을 높였습니다.

소프트웨어 개발은 ​​진공 상태에서 이루어지지 않습니다. 다양한 내부 및 외부 요인이 영향을 미칩니다. 우리 모두는 이런 상황에 처해 있었고, 앞으로도 그럴 것입니다.

---

종말의 시작

그런 다음 문제가 시작되었습니다.

1. 시스템의 한 부분이 변경되어 예상치 못한 다른 부분에 영향을 미쳤습니다.
2. 작은 변경으로 인해 다른 많은 파일을 수정해야 하므로 추정이 어렵습니다.
3. 코드는 매달 이해하기 어려워졌고 시행착오를 거쳐 수정되는 경우가 많았습니다.
4. 생산성이 떨어지고 모두가 유지 관리 작업을 두려워했습니다.
5. "리팩터링이 필요하다"는 불가피한 요청
6. 특정 작업은 특정 개발자만 처리할 수 있음(클래식)
7. 시간이 지나면서 한때 아름답게 작성되고 잘 문서화되었던 소프트웨어는 망가졌습니다.

증상 이름 지정

이제 시스템이 복잡하다는 것은 분명합니다.

이제 이 복잡성을 "해부"하여 이를 더 쉽게 식별하고 완화해 보겠습니다.

"완화"는 다음을 의미합니다.

"덜 심각하거나 심각하거나 고통스럽지 않게 만들다, 완화시키다."

저는 종종 코드에 복잡성이 내재되어 있다고 생각합니다. 어떤 것들은 본질적으로 복잡합니다. 개발자로서 귀하의 역할은 컴퓨터가 효율적으로 실행할 수 있는 코드를 만드는 것뿐만 아니라 미래의 개발자(미래의 자신도 포함)가 작업할 수 있는 코드를 만드는 것입니다.

“복잡성을 제어하는 ​​것이 컴퓨터 프로그래밍의 핵심입니다.”

— 브라이언 커니건

언급된 책의 저자는 복잡성이 일반적으로 세 가지 방식으로 나타난다고 말하며 여기서는 이에 대해 살펴보겠습니다.

증폭 변경

변경 증폭은 겉으로는 단순해 보이는 변경이 여러 곳에서 수정이 필요할 때 발생합니다.

예를 들어 제품 소유자가 "우선순위" 또는 "완료 날짜" 필드를 요청하고 엔터티가 밀접하게 결합되어 있는 경우 얼마나 많은 변경을 수행해야 합니까?

인지 부하

인지 부하는 개발자가 작업을 완료하는 데 필요한 지식과 시간의 양을 나타냅니다.

이런 시나리오를 상상해 보세요. 새로운 개발자가 팀에 합류했고, 그는 보고서 생성기의 버그를 수정하는 임무를 맡았습니다. 이 작업을 완료하려면 개발자가 다음을 수행해야 했습니다.

• 다양한 캘린더 통합(Google 및 Outlook)을 이해합니다.
• 이메일 알림에 대한 고유한 접근 방식을 파악하세요.
• PDF, Excel 및 대시보드를 처리하는 보고서 생성기의 단편화된 코드를 탐색하세요.
• 이러한 다양한 기술과 스타일을 통합하여 버그를 찾아 수정하세요.

이것은 작업에 1점 또는 8점이 소요되는 전형적인 "추정 불가능" 시나리오입니다. D20을 굴리고 그에 따라 응답하는 것이 좋습니다.

알 수 없음

알 수 없는 것은 자신이 모르는 것을 모르는 것입니다.

이것은 최악의 복잡성 표현입니다. 해서는 안되는 것을 변경하여 모든 것이 중단될 수 있기 때문입니다.

예: 개발자는 해당 기능에 의존하는 보고서 생성기에 영향을 미칠 것이라는 사실을 알지 못한 채 새 알림을 추가하기 위해 이메일 전송 코드를 수정했습니다. 이로 인해 고객에게 심각한 문제가 발생했으며 최악의 형태의 긴급 복잡성이 예시되었습니다.

복잡성의 원인

공포 이야기와 세 가지 주요 증상을 살펴보았으니, 복잡성을 유발하는 원인이 무엇인지 살펴보겠습니다.

1. 종속성

종속성은 소프트웨어에서 필수적이며 완전히 제거할 수는 없습니다. 이를 통해 시스템의 서로 다른 부분이 함께 상호 작용하고 기능할 수 있습니다. 그러나 종속성을 제대로 관리하지 않으면 복잡성이 크게 증가할 수 있습니다.

정의:

코드를 단독으로 이해하거나 수정할 수 없어 관련 코드를 고려하거나 수정해야 하는 경우 종속성이 존재합니다.

종속성 유형:

• 직접: 모듈 A는 모듈 B에 직접적으로 의존합니다.
• 전이적: 모듈 A는 모듈 B에 의존하고, 모듈 B는 모듈 C에 의존합니다.
• 순환: 모듈 A, B, C는 순환 방식으로 상호 의존적입니다.

2. 모호함

중요한 정보가 명확하지 않을 때 모호함이 발생합니다. 이로 인해 코드베이스를 이해하기 어렵게 만들어 인지 부하가 ​​증가하고 알려지지 않은 미지의 위험이 발생할 수 있습니다.

정의:

중요한 정보가 명확하지 않을 때 모호함이 발생합니다.

모호함의 예:

• 잘못된 이름 지정: 이름이 불분명한 변수 및 함수.
• 숨겨진 부작용: 예상치 못한 동작을 수행하는 방법
• 전역 상태: 전역 변수의 남용.
• 깊은 상속: 동작은 클래스 계층의 여러 수준에 걸쳐 퍼져 있습니다.

기억하세요: 복잡성은 증가합니다.

• 단일 '오류'나 잘못된 결정으로 인해 복잡성이 발생하는 경우는 거의 없습니다.
• 복잡성은 시간이 지남에 따라 잘못된 결정과 종속성을 통해 "천천히" 쌓입니다.

점진적이기 때문에 '이번 한 번이면 괜찮겠다'라고 생각하기 쉽습니다. 하지만 누적되면 하나 또는 두 개의 종속성을 수정하는 것만으로는 큰 차이가 없습니다.

“소프트웨어 엔지니어링에서는 모든 것이 절충안입니다.”
— 작가가 기억나지 않습니다

결론

복잡성을 피하는 방법에 대해 인터넷에서 이미 보셨을 수많은 규칙, 전략, 프레임워크(SOLID, 디자인 패턴, YAGNI, KISS 등)를 작성할 수 있습니다.

그러나 이를 모두 하나의 기본 원칙으로 통합할 수 있습니다("실용주의적 프로그래머"에서 언급한 대로). "내가 구현하고 있는 것이 변경하기 쉬운가요?" 대답이 '아니요'인 경우 아마도 복잡성이 증가하고 있을 것입니다.

코드 변경이 용이하도록 하면 유지 관리가 단순화되고, 개발자의 인지 부하가 ​​줄어들며, 시스템 적응성이 향상되고 오류 발생 가능성이 줄어듭니다.

감사합니다!

위 내용은 소프트웨어 복잡성과의 끝없는 싸움의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!