귀환의 복잡성 지점. 그게 뭐야?

소프트웨어 개발자로서 저의 주요 업무 중 하나는 복잡성을 통제하는 것입니다.

그러나 일부 프로젝트에서는 복잡성 수준이 너무 높아져서 "돌아 오지 않는"지점에 도달하는 순간이 있습니다. 이 순간이 지나면 모든 것을 처음부터 다시 작성해야하는 것보다 짧은 시간 내에 프로젝트를 허용 가능한 수준의 복잡도로 되돌릴 수 없습니다.

이 특별한 순간은 프로그래머 방언에 이름이 있습니까?

--편집하다--

확실하지 않으면 죄송합니다. 나는이 "순간"이 공식적인 이름을 가지고 있거나 진지한 척도라고 생각하지 않습니다. 나는 xkcd의 "Ballmer peak" 의 정신에서 무언가를 생각하고있었습니다 .

복잡성보다 유지 관리 의 문제입니다 .

이 현상을 "기술 부채"라고하며, 임계 수준에 도달하면 프로젝트는 파산으로 향합니다.

그게 무슨 뜻이야?

"과도한 복잡성 지점"은 영어로 다음과 같이 나타납니다.

오 나의 하나님이게 뭐야?

문제는, 이것은 실제로 간단한 것에 적용될 수 있지만, 똑같은 반응을 보이는 끔찍한 방식으로 구현됩니다.

따라서 매우 복잡한 것을 매우 끔찍한 것으로 구별하는 것은 어려울 수 있습니다.

그러나 모든 소프트웨어에서 실제로 일어나는 경향은 다음과 같이 약간 처리됩니다.

1 단계 : 좋은 사양을 가지고, 좋은 디자인을하고, 좋은 물건을 구현하십시오. 모두 행복합니다.

1 단계가 끝날 무렵 : 개발자들은 디자인의 훌륭한 우아함을 축하하며 행복하게 생각합니다. "다른 사람들이 미래에 무언가를 추가 할 수있는 훌륭한 유산이 있습니다. 더 나은 곳. "

2 단계 : 일부 변경 사항, 추가 사항, 새 기능이 포함됩니다. 1 단계의 아키텍처와 구조는이 과정을 상당히 힘들게 만들었습니다. [그러나 죄송합니다. "크 러프 팩터"가 약간 증가했습니다.]

2 단계가 끝날 무렵 개발자들은 자신의 디자인의 멋진 우아함을 축하하며 행복하게 생각합니다. "Gee 나는 1 단계에서 모든 수당을 만들어서 정말 영리합니다. 앞으로 다른 사람들이 무언가를 추가 할 수있게된다면 정말 멋지고 세상은 더 나은 곳이 될 것입니다. "

3 단계 : 더 많은 변경 사항, 더 많은 항목이 추가됨, 더 많은 새로운 기능, 많은 항목이 변경됨, 사용자 피드백이 실제로 듣고 있습니다.

3 단계가 끝날 무렵 개발자들은 디자인의 훌륭한 우아함을 축하하며 상당히 행복하게 생각합니다. "이 아키텍처는 너무나 많은 변경 사항을 쉽게 적용 할 수 있도록하기에 매우 좋습니다. 그러나 나는 조금 불행합니다. X와 Y와 Z에 대해서. 지금 조금 정리할 수 있지만 아 !!!!!! 나는 1 단계에서 모든 수당을 낸 것이 정말 영리합니다. 다른 사람들이 미래에 무언가를 추가 할 수 있다면, 그것은 훌륭 할 것이며 세상은 더 나은 곳이 될 것입니다. "

4 단계 : 3 단계와 같습니다.

4 단계가 끝날 무렵 개발자들은 다음과 같이 생각합니다. "너무 좋았던 것은 유지 관리가 어려워지고 있습니다. 정말 심각한 변화가 필요합니다. 정말이 작업을 좋아하지 않습니다. 리팩토링이 필요합니다. 내가 그에게 6 주가 필요하다고 말하면 이것의 끝에 사용자가 볼 것이 아무것도 없을 것입니다 ...하지만이 작업을 수행하면 5 년 동안 맛있는 미래 수정 범위가 생길 것입니다 .... 흠 .. 맥주를 마시 러 술집에 갈 시간이야. "

5 단계 : 많은 변경이 필요합니다.

그리고 5 단계에서 개발자들은 서로에게 다음과 같이 말합니다. "이 코드는 엉망입니다. 누가이 코드를 작성 했습니까? 그들은 쏴야합니다. 끔찍합니다. 우리는 IT를 다시 써야합니다."

5 단계는 치명적입니다. 이것은 cruft factor가 너무 나빠서 코드에 몇 가지 변경 사항이 더있을 수 없으며 약간의 변경이 필요합니다.

5 단계의 문제점은이를 버리고 다시 시작하려는 욕구입니다. 이것이 치명적인 이유는 "Netscape Factor"입니다. 구글로 이동 이 시점에서 회사 DIE는 다시 시작한다는 것은 사실 대신에 약 50 %의 가정, 지식 대신에 150 %의 열정, 겸손이 아닌 200 %의 오만으로 시작한다는 것을 의미하기 때문입니다 ( "그 사람들은 너무 어리 석었습니다!"). 그리고 새로운 버그를 소개합니다.

가장 좋은 방법은 리팩토링하는 것입니다. 한 번에 조금 변경하십시오. 아키텍처가 약간 피곤하면 수정하십시오. 추가, 확장, 개선 차례로. 각 단계에서 테스트, 테스트 및 테스트를 더 진행하십시오. 이와 같이 증분 변경은 10 년 후 현재 코드와 원본 코드가 할아버지 도끼와 유사하다는 것을 의미합니다 ( "새 머리가 ​​10 개, 손잡이가 3 개이지만 여전히 할아버지 도끼입니다"). 즉, 공통점이 많지 않습니다. 그러나 당신은 오래된 것에서 새로운 것으로 점차 조심스럽게 움직였습니다. 이렇게하면 위험이 줄어들고 고객에게는 성가신 요소가 줄어 듭니다.

나는 그 순간을 인식하기가 어렵고 적절한 과정으로 피할 수 있다는 데 동의합니다. 그러나 문제는 무엇을 호출해야하는지에 관한 것이 었습니다. 실제 경제에서는 "수익 감소"라는 개념이 있습니다. 프로세스에서 하나의 자원에 대한 입력이 증가하면 전체 단위당 수익이 감소하는 지점입니다. 이것은 분명히 코딩에 적용되며 추상화, 재사용 등과 같은 좋은 것들조차도 수익이 감소하는 지점을 가지고 있습니다. 일반적인 프로그래밍 관련 용어는 "과잉 엔지니어링"입니다. 이 작업을 수행하기 쉬운 사람에게는 Joel의 " 아키텍처 우주 비행사 " 라는 용어가 마음에 듭니다 .

새로운 도구를 사용하는 새로운 팀이 더 많은 신뢰도를 가지고 더 저렴하고 더 빨리 할 수 ​​있다는 잘못된 인상으로 좋은 코드를 버리는 경우가 종종 있습니다.

• 문서화 요구 사항에 복잡성이 있습니다.
• 새로운 도구는 사용하기가 어려우며 플래시 웹 사이트는 약속했습니다.
• 새로운 팀은 그들이 생각했던 것만 큼 '뜨거운'것이 아닙니다

아마도 당신이 묘사 한 시간은 일부 코드베이스와 함께 도착했을 것입니다 (저는 그렇게 생각했습니다). 나는 프로젝트가 엉망이되거나 프로젝트를 저장하는 코드를 다시 작성한 오래된 코드의 경우를 개인적으로 경험 한 적이 없습니다.

이 경우에는 문제가있는 특정 모듈 또는 디자인을 식별하기 위해 메트릭을 사용한 다음 수집 및 교체 한 경우는 포함하지 않습니다.

이 이론적 인 "순간"의 실제 문제는 그것이 사실 후에 만 ​​인식된다는 것입니다. 동료가 정신병자가 아닌 한, 코드베이스에 대한 모든 단일 커밋은 해당 코드베이스에 대한 개선이라는 믿음으로 수행됩니다. 당신이 그 "순간"을 통과 한 것을 볼 수있는 뒤 따르는 혼란을 되돌아 보는 것입니다.

그러나 나는 우리가 그것에 이름을 줄 수있는 것을 좋아한다. "젠트 (Gents)"는 동료 개발자들을 당신 주변으로 끌어들이면서 "유지 보수성 헬 레스 폰트를 건너 섰습니다. 부인에게 문자 메시지를 보내서 한동안 보지 못할 것임을 알려주십시오."

이름이 있는지 모르겠지만 이름이 없으면 "용융점"이라고 제안합니다.

이것은 매우 흥미로운 질문이 아닙니다.

실제로 그것은 사소한 일입니다.

우리가 대처할 수있는 수많은 방법을 발전시킨 것은 사소한 일입니다.

1. 폭포 방법론. 많은 사람들이 복잡성을 관리하기 위해 요구 사항과 디자인 문서를 검토하는 데 많은 시간을 소비합니다.

2. 민첩한 방법론. 더 적은 사람들이 다른 사람의 문제를 해결하고 소프트웨어를 배포하는 데 즉시 적용 할 수있는 것에 대해 더 적은 시간을 소비합니다. 모든 사람이 무언가를 발표하는 데 집중하기 때문에 복잡성이 관리됩니다.

누군가가 "복잡성"과 씨름하는 유일한 방법은 방법론을 따르지 않고 자신의 시간을 제대로 관리하지 않기 때문입니다.

• 폭포수 방법론에 대한 자세한 감독은 없습니다. 요구 사항, 아키텍처, 고급 설계 또는 세부 설계 검토에서 중간 작업 제품을 검토하지 않아도됩니다.

• 애자일 방법론에는 스프린트 마감일 또는 적절한 사용 사례 우선 순위가 없습니다. 가능한 빨리 사용자에게 무언가를 배포하는 데 집중하지 않습니다.

목표를 설정하여 복잡성을 제한해야합니다.

복잡하게 씨름하는 것은 목표가 제대로 설정되지 않았거나 보상되지 않음을 의미합니다.

"전환점"이 없습니다. 복잡성 관리가 문제가된다면 이미 조직적으로 문제가있는 것입니다.

(큰) 프로젝트와 코드의 복잡성이 증가 할 위험을 시각화하고 모니터링하는 방법이 있습니다. 그들이 합리적으로 적용되면 돌아올 수없는 지점에 대한 새로운 이름이 필요하지 않습니다. (openHPI에는 관련 MOOC가 있습니다 : https://open.hpi.de/courses/softwareanalytics2015/ )

구조적 복잡성은 큰 팀의 소프트웨어 디자인뿐만 아니라 일반적인 디자인 문제입니다. 시각화는 구조적 복잡성 관리의 첫 번째 단계입니다. 행렬과 방향 그래프도이 목적으로 사용될 수 있습니다.

구조적 복잡성을 줄이는 몇 가지 방법은 http://www.buch.de/shop/home/suche/?fq=3540878890입니다 .

• 모듈화
• 피드백 루프 회피
• 삼각 분할

또한 공리 설계의 개념이 있습니다.

따라서 사용 가능한 많은 방법이 있습니다. 결국 프로젝트는 충분히 커지기 때문에 항상 생각하기로 결정합니다.