가끔 프로젝트에서 작업하고 갑자기 예기치 않은 일이 발생하여 작업에 막대한 스패너가 발생하고 복잡성이 크게 증가하는 것은 드물지만 일반적인 경험처럼 보입니다.

예를 들어, 나는 다양한 다른 컴퓨터에서 SOAP 서비스와 통신하는 응용 프로그램을 작업하고있었습니다. 나는 잘 작동하는 프로토 타입을 채운 다음 정기적 인 프론트 엔드를 개발하고 일반적으로 멋지고 매우 간단하며 따라하기 쉬운 방식으로 모든 것을 시작했습니다. 더 넓은 네트워크에서 테스트를 시작하고 연결 지연 시간과 원격 컴퓨터에서 계산을 수행하는 데 필요한 시간으로 인해 SOAP 서비스에 대한 요청 시간이 초과되어 페이지가 시간 초과되기 시작했을 때까지 훌륭하게 작동했습니다. 요청을 자체 스레드로 스핀 아웃하고 반환 된 데이터를 캐시하도록 아키텍처를 변경해야 요청별로 요청을 계산하는 대신 백그라운드에서 점진적으로 업데이트 할 수 있음이 밝혀졌습니다.

이 시나리오의 세부 사항은 그다지 중요하지 않습니다. 실제로는 예견 할 수 없었기 때문에 좋은 예는 아닙니다.이 유형의 환경에 대해이 유형의 많은 앱을 작성한 사람들은 예상했을 수 있습니다. 하나는 간단한 전제와 모델로 시작하여 갑자기 프로젝트 개발에 복잡한 단계를 거치게됩니다.

나중에 사양 변경이 아닌 환경 적 요인의 결과로 개발 프로세스에서 또는 테스트의 결과로 이러한 유형의 기능적 변경을 처리하기위한 전략은 무엇입니까? 조기 최적화 / YAGNI / 과도한 엔지니어링 위험을 피하는 것 사이에서 어떻게 효과가 있을지 모르지만 준비를 포함하지 않는 간단하고 쉬운 솔루션을 개발하는 것보다는 가능하지만 반드시 발생할 수있는 문제 를 완화 할 수있는 솔루션을 설계 할 때의 균형을 맞추는 방법 가능한 모든 사건?

편집 : Crazy Eddie의 답변은 "당신은 그것을 빨고 새로운 복잡성을 구현하는 가장 저렴한 방법을 찾는 것"을 포함합니다. 그것은 그 질문에 암시적인 것을 생각하게 만들었지 만 구체적으로 제기하지는 않았습니다.

일단 그 충돌에 부딪 치면 필요한 변경 사항을 통합합니다. 프로젝트를 가능한 한 일정에 가깝게 유지하지만 유지 관리에 영향을 줄 수 있거나 아키텍처로 돌아가서 더 세부적인 수준으로 다시 작업하여 유지 관리가 가능하지만 개발 중에 모든 것을 되돌려 놓는 일을합니까?

이것을 읽는 것은 민첩한 속담입니다. 프로젝트 수명주기 내에서 가장 위험하고 이해가 잘 안되는 작업을 먼저 처리하십시오 . 즉, 가능한 한 빨리 프로젝트의 골격을 구성하여 개념이 작동 함을 증명하십시오. 이는 또한 실제 상황에서 아키텍처가 실제로 약속을 이행하는지 여부를 감지하기 위해 모든 종류의 잔인한 테스트를 실행할 수있게합니다. 또한 솔루션에 포함되어있는 알려지지 않은 새로운 기술 / 플랫폼 / 도구가있는 경우이를 조기에 수행하십시오.

핵심 아키텍처가 정상이면 개별 기능을 상대적으로 적은 비용으로 점진적으로 추가 및 테스트하고 필요할 때 리팩터링 할 수 있습니다. 아키텍처를 변경해야하는 것은 큰 위험이며,이를 사전에 처리해야합니다. 이는 빠른 피드백을 제공합니다. 최악의 경우 전체 개념이 분리되면 조기에 알고 최소한의 손실로 프로젝트를 중단 할 수 있습니다.

귀하의 사례는 프로그래밍의 가장 까다로운 측면, 즉 분산 컴퓨팅 및 동시 프로그래밍 과 같은 일부 영역을 다루었습니다. 분산 컴퓨팅 및 동시 프로그래밍 은 점점 더 널리 사용되고 프로그래머가 더욱 어려워지고 있습니다.

"정상적인"프로그래밍 (한 시스템의 단일 스레드)조차도 사소한 프로그램에 비해 매우 복잡하기 때문에이를 잘 활용하려면 많은 기술과 경험이 필요하지만 여전히 "해결 된"과는 거리가 멀습니다. 대부분의 조합 폭발 로 인한이 수준의 복잡성조차도 인간 두뇌가 완전히 이해하고 이해하는 능력을 훨씬 능가합니다. 다르게 생각하는 것은 어리석은 일입니다.

분산 컴퓨팅과 동시 프로그래밍은 "복잡성"공간의 크기에 2 차원을 더 추가하며, 이는 "정상"프로그래밍과 비교하여 최소한 입방 (sp?) (n ^ 3)으로 커집니다. 예를 들어, 우리가 극복해야 할 몇 가지 새로운 문제와 오류 에 대해 생각해보십시오 . 이 규모에서 상호 연결과 부작용을 추측 할 수 있다는 아이디어를 가지고 놀 수도 있습니다.

나는 분명히 은색 총알이 없지만, 내가 할 수 있는 가장 큰 실수 는 당신이 그것을 모두 이해하고 해결했다고 생각하는 것입니다.

다른 모든 답변에서 이미 다룬 내용 외에도이 모든 것에 대처하는 방법에 대한 몇 가지 아이디어 :

• 큰 겸손
• 시스템 / 프로그램이 불완전하고 영구적이며 불완전하다는 것을 인정하십시오 .
• 오류 준비
• 변화를 수용하다
• 중복 계획
• 향후 교정 에 대해 생각하십시오
• 복잡한 시스템이 어떻게 작동하는지 생물학 또는 사회학을 보거나 연구하십시오.
• 변경 가능한 상태를 피하기 위해 최대한 노력하십시오. 상태 비 저장 프로토콜 (예 : REST 및 HTTP)로 이동하십시오.
• 함수형 프로그래밍은 약간의 고통을 완화시킬 수 있습니다

나는 계속 갈 수있을 것 같아요. 매우 흥미로운 주제 :)

@ Péter Török의 대답은 팀 (또는 개인)이 프로젝트 라이프 사이클 초기에 가장 위험한 항목을 반드시 예측할 수 있다고 가정하기 때문에 동의하지 않습니다. 예를 들어, OP의 경우, 팀 은 후면이 벽에 닿을 때까지 멀티 스레드 솔루션에 첨부 된 증가하는 복잡성을 예측할 수 없었습니다 .

OP의 질문은 좋은 질문이며 많은 소프트웨어 개발 상점에서 가지고있는 문제를 말합니다.

다음은 문제를 해결하는 방법입니다.

1. Fred Brooks의 조언을 따르고 개발자를 수술 팀 처럼 구성하십시오 .
2. 다음을 모두 수행 할 수있는 현명하고 "선명한"주치의를 선택하십시오. A) 동료의 신뢰와 존중; B) 적시에 어려운 결정을 내린다.
3. 마스터 외과 의사가 개발 프로세스의 프런트 엔드 및 백 엔드에서 복잡성을 줄일 것으로 예상합니다.

포인트 3에 대한 추가 정보 :

1. 주치의는 가장 간단한 해결책을 제안하기 위해 의식적으로 노력해야합니다. 수년간의 의미있는 경험을 통해 주치의는 그렇게 할 수있는 위치에 있어야합니다.
2. 마스터 외과 의사의 상사 인 더 광범위한 조직은 팀에게 선적 날짜 이후의 복잡성을 줄일 수있는 충분한 시간과 자원을 제공해야합니다. 이를 통해 개발 팀은 적시에 코드를 배송하고 카이젠 을 수행 하여 복잡성을 지속적으로 줄일 수 있습니다.

인터페이스 코드

다른 기능과 인터페이스하는 새로운 기능을 작성할 때는 모든 것이 통과하는 인터페이스 (Java 종류)의 형태로 경계를 만드십시오. 이것은 것입니다

1. 사용되는 기능을 완벽하게 제어
2. 동일한 기능을 여러 번 구현할 수 있습니다.
3. 모듈이 완전히 꼬이지 않고 얇게 연결되어 있기 때문에 전반적인 복잡성을 줄입니다.

하나는 간단한 전제와 모델로 시작하여 갑자기 프로젝트 개발에 복잡한 단계를 거치게됩니다.

놀랍지 않습니다.

이것은 소프트웨어 개발입니다. 새로운 것을 발명하지 않으면 입증 된 기존 솔루션을 다운로드하는 것입니다.

중간 근거가 거의 없습니다.

새로운 것을 발명하는 경우 완전히 이해하지 못하는 기능이 하나 이상 있어야합니다. ( 완전히 이해 하려면 사용하려는 실제 구현이 있어야합니다.)

이것을 관리하는 방법?

1. 현실적인 기대를하십시오. 새로운 무언가를 발명하고 있습니다. 이해하지 못하는 부분 이 있어야합니다 .

2. 현실적인 기대를하십시오. 처음부터 제대로 작동한다면 무언가를 간과 한 것입니다.

3. 현실적인 기대를하십시오. 간단하다면 다른 사람이 먼저 해본 것이므로 해당 솔루션을 다운로드하기 만하면됩니다.

4. 현실적인 기대를하십시오. 미래를 잘 예측할 수 없습니다.

더 이상 사용되지 않는 디자인 및 코드. 오늘 코딩하는 내용을 잘라 내고 내일 교체해야한다고 가정합니다.

환경은 사양의 일부 여야합니다. 따라서 환경의 변화는 규격의 변화입니다. 반면에, 프로토 타입과 디자인을 사양에 포함되지 않은 환경에 기반한 경우 어리석은 실수를했습니다. 어느 쪽이든, 당신은 그것을 빨고 새로운 복잡성을 구현하는 가장 저렴한 방법을 찾습니다.

대부분의 프로그래밍 문제와 마찬가지로 내 의견에 달려 있습니다. 이 문제는 고장이 일어날 것, 것을 잊지 것을, 창조적 인 작업에 너무 본질이다 과의 OK 있음 . 프로그래밍은 사악한 문제이며, 이미 해결하기 전까지는 문제에 대한 올바른 해결책을 모릅니다.

그러나 여기에는 다음과 같은 여러 가지 현지 특정 요소가 영향을 줄 수 있습니다.

• 이 시스템의 목표. 일회성입니까? 이 시스템을 중장기 적으로 사용 하시겠습니까?

단기적으로는 실행하기에 충분하다고 생각할 가치가 없습니다. 리팩토링은 비싸고 사용자에게 즉각적인 최종 가치를 창출하지 않는 것입니다. 하나, 절대 폐기 소프트웨어 이외의 소프트웨어를 생각할 수있는 경우는 거의 없습니다. 단기간에 설계를 개선 할 가치가 없습니다. 지금 끝내는 것보다 자신이 한 일을 이해하고 신속하게 해결하는 것이 훨씬 중요합니다. 그것이 장기적 인 경우 결국에는 결국 (그리고 아마도 모든 사람들이 생각하는 것보다 훨씬 빨리) 돈을 지불하거나 그 반대의 행동을 취하지 않을 것입니다. 나는 "항상 더 나아지기 위해 항상 시간이 걸린다"고 말하고 싶은 유혹이 있지만 불가능한 경우도 있습니다.

• 팀의 목표. "지금은 아무 비용이 들지 않습니까"아니면 "올바르게하자"일까요?

이것은 당신의 결정에 막대한 영향을 미칩니다. 팀은 재 설계 할 리소스를 제공하여이 결정을 지원하거나 지금 빠른 솔루션을 수행해야합니다. 제 생각에는 팀이 당신을 일관되게 잘못된 방향으로 밀고 있다는 것을 알게되면, 그것은 큰 붉은 깃발입니다. 나는 이런 종류의 일이 끊임없이 진화하는 시나리오에서 끝나는 것을 보았습니다. 불쾌한 디자인으로 인해 발생하는 문제를 항상 해결하기 때문에 다시 디자인 할 시간이 없습니다. "덕트 테이프"는 이제 중간 정도가 될 수 있지만 최대한 빨리 수정하십시오 (그러나 실제로 그렇게하십시오).

• 문제에 대한 이해 이전 솔루션이 작동하지 않는 이유는 무엇입니까?

정말 중요합니다. 오류나 문제가 무엇이고 왜 발생하는지 생각해보십시오. 이런 종류의 상황은 결함이있는 (또는 누락 된) 가정, 제약 및 상호 작용을 찾을 수있는 좋은 기회입니다. 일반적으로 현재 문제를 해결하는 대신 항상 문제를 더 잘 이해하는 것이 좋습니다. 이것은 아마도 YAGNI / overengineering에 대한 가장 큰 방어책 일 것입니다. 문제를 충분히 이해하면 다른 문제가 아닌 문제를 해결할 수 있습니다.

마지막으로, 올바른 방식으로 구축하십시오 . 나는 당신이 문제 나 본질적인 인간의 실수에 대해 더 많이 이해할 때 직면하는 오류와 문제에 대해 이야기하고 있지 않습니다. "실수하지 않고 처음부터 완벽하게 해"라는 의미는 아닙니다. 불가능합니다. 즉, 일상 업무에서 복잡성을 잘 관리하고, 깨진 창을 수정하고, 가능한 한 간단하게 유지하고, 코드와 생각을 항상 향상 시키십시오. 그렇게 하면 (만약) 변화가 문을 두드리면 샷건 대신 팔을 벌려서 환영 할 수 있습니다.