당신이 작성한 못생긴 코드에 어떻게 대처합니까? [닫은]

따라서 고객이 코드를 작성하도록 요청하므로 그렇게하십시오. 그런 다음 그는 예상대로 사양을 변경하고 좋은 작은 젊은이처럼 그의 새로운 기능을 부지런히 구현합니다. 새 기능이 이전 기능과 충돌하는 것을 제외하면 코드가 엉망입니다. 당신은 정말로 돌아가서 고치고 싶지만, 그는 새로운 것을 계속 요구하고 당신이 무언가 청소를 마칠 때마다 다시 혼란스러워집니다.

너 뭐하니? OCD 미치광이를 멈추고 코드가 당신이 무엇을하든 엉망이된다는 것을 받아들이고이 괴물에 대한 기능을 계속 택하십시오. 버전 2의 청소를 저장 하시겠습니까?

다른 직업을 구하고 다른 사람들이 그 일을 처리하도록하십시오. Muahahahhahahaa.

.....

농담이야. :)

그러나 모든 진지함에서 : 추정 패딩 은 당신의 친구입니다. 나는 일반적으로 적절한 현실적인 평가를 한 다음 두 배로 늘립니다. 이것은 지나치게 들릴 수도 있지만 때로는 그렇습니다.하지만 버그를 수정하고 항상 견적을 불려서 나쁜 인상을 남기는 것보다 약간 과대 평가하고 때로는 느리게 보이는 것이 좋습니다. 물론 코드베이스를 해킹함으로써 기술 부채가 발생합니다.

또 다른 (관련) 팁 : 항상 괜찮은 크기의 블록에 대해 더 작고 똑똑한 작업을 예상하지 마십시오. 예를 들어, 거의 확실하다고 생각되는 항목은 단순한 한 줄 30 초 변경 일 것입니다-1 시간 제공 (또는 아마도 가장 낮은 시간 블록이 작업 표나 CR 시스템에있는 것, 예를 들어 15 분 /0.25 시간) . 그리고 약간 더 크지 만 여전히 사소한 아이템에는 반일 또는 1 일 블록을 제공하십시오.

그 이유는 주로 심리적 인 것입니다. 작은 변화를 빠르게 해킹하는 습관을들이는 경우 작업이 서두르고 리팩터링 해야하는 물건을 다시 가져 와서 리팩토링하지 않아도됩니다. 또한 실용적 수준에서 : 작지만 사소한 변경이 때때로 발생하기 때문에 일정이 늦어지고 버그가 발생하는 것처럼 끊임없이 느끼기를 원하지 않습니다. 코드베이스가 시간이 지남에 따라 해킹되는 이유의 일부입니다.

마지막으로, 사람들은 당신이 추정치를 어느 정도 채우고 있는지 알 필요가 없다는 것을 항상 기억 하십시오. 유능한 개발자이고 적절한 속도로 작업을 수행하는 한이 패딩은 눈에 띄지 않습니다. 즉, PHB에 "내 초기 추정치는 2 시간이 걸리지 만 반나절을 줄 것"이라고 말하지 마십시오. 그냥 "반나절 정도 걸릴 것 같아요." 그대로 두십시오.

다음 기능에 필요한 시간을 의도적으로 과대 평가하십시오. 그 여분의 시간을 사용하여 정리하십시오.

유지 관리를 정당화 할 수 없으며 고객이 유지 관리를 필요로하지 않기 때문에 더 나은 약을 얻을 수 있도록 쓴 약 (다음 기능에 대한 약간의 비용 증가)을 제공하십시오.

새로운 기능을 통합하면서 적절한 재 설계를 시도하십시오. 더 이상 없습니다. 재 설계 없이는 더 많은 변경과 새로운 기능을 위해 점점 더 많은 마찰을 가하고 있습니다.

어느 시점에서 모든 것이 오래 걸리는 것처럼 보이는 정지 근처에서 연삭이 나옵니다. 대부분의 회사는 아마도이 시점에서 버전 2의 큰 재 작성을 시도 할 것입니다. 경제는 꽤 나쁘고 고객이 기울어 졌다고 생각하면 다른 개발 당사자를 시도하는 좋은 순간입니다.

적절한 재 설계 / 리팩토링은 고객의 투자를 보호하고 지속 가능성을 유지할 수 있습니다. 이를 구현해야합니다. 변화, 주행 조명에 맞게 최적화하십시오.

과대 평가에 대한 모든 의견으로 나는 약간의 포인트 (웰 기회)가 누락되었다고 생각합니다.

코드를 수정하는 데 걸리는 시간을 추정하고 (그냥) 일부를 추가하는 것은 코드를 수정하는 데 필요한 시간 (리 팩터!)을 변경하여 안전하게 변경 될 수있는 지점으로 가져 와서 변화 (아마도 함께 녹아 내림). 좋아, 이것은 똑같은 일이지만 ... 퍼지 또는 스트레칭 또는 과대 평가에 대한 의문의 여지가 없습니다. 단순히 말하면 문제를 해결하기 위해 먼저해야한다고 말하면됩니다. 전체적으로. 여기서 핵심은 변경 사항이 의존하는 시스템 부분에서 더 이상 작업하지 않는다는 것입니다. 다른 곳에 끔찍한 코드가있는 경우 ... 어려우면 거기에 넣으십시오.

원래의 질문으로 돌아 조금 올 - 많은 세월 후에하지 않는 한 당신이 뭔가를 구현할 때 그것의 나를 위해이 내려와 알 (? (용의자를 기대하지, 믿을 수), 생각하지만 알고 추가적인 물건입니다) 또한 요구 사항을 구현하는 데 필요한 작업을 수행해야하며 더 이상 깔끔하고 우아한 방식으로 할 수 있어야합니다.

다음에 구현하려고 할 때 (때로는 나중에) 코드베이스 (및 데이터베이스 등)를 가능한 한 단정하고 우아하게 해당 기능을 구현하는 데 필요한 상태로 만드는 데 필요한 단계를 수행합니다. 이 리팩토링은 프로젝트가 발전함에 따라 자연스럽게 발생하는 혼란을 처리하는 곳입니다. 더 많은 혼란을 피하십시오 (또는 최소한 레벨을 일관되게 유지하십시오).

여기에있는 토론 영역 중 하나는 "기술 부채"입니다.-초과 인출과 같이 상환해야하며, 더 오래 버릴수록 더 많은 관심을 가져야합니다 (이 경우 수정하는 데 필요한 시간). 기술 부채를 최소화하기 위해 시간을 투자해야한다는 주장.

이것은 또한 단위 테스트와 다른 자동 테스트가 시작되기 시작하는 곳입니다 (내가 더 행복하다고 말할 수있을뿐만 아니라 내가 할 수 있다면!) 적절한 빌드 서버 (적어도 일부는 실행할 수 있음) 테스트 중). 이것들과 결합하지만 가치 자체는 의존성 주입 및 제어 역전과 같은 패턴입니다 (두 가지가 "동일"하다는 것을 확신하지 마십시오). 배관을 쉽게 변경하고 따라서 변화를 처리하기 때문에 격리.

마지막으로, 그것이 깨지지 않았다면 고치지 마십시오. 깔끔하게 정리하기 위해 코드를 정리하는 것은 만족스럽지 만 오류를 유발할 수있는 기회이므로 코드를 변경하지 않아도되고 코드를 작성하지 않으면 고통 스러울 수 있습니다. 혼자-수정하거나 교체 할 수있는 기회는 결국 롤오버됩니다!

1) 적절한 변경 관리는 당신의 친구입니다

고객이 사양을 올바르게 변경하면 그의 권리가 맞습니다. 그러나 변경 사항이므로 청구해야합니다 (또는 프로젝트 구조 / 관계에 적절한 방식으로 비용이 청구 됨).

해당 변경에 대한 추정에는 필요한 리팩토링 비용이 포함되어야합니다 . 클라이언트는 비용이 많이 드는 것처럼 보일 수 있지만 그 시점에서 코드가 이미 절반으로 작성되었으므로 향후 강력하고 지원 가능하도록 다시 작성 해야하는 요소가 있으며 그 점을 설명해야합니다. 그렇지 않으면 향후 지원 또는 변경 비용이 훨씬 비싸지면서 문제가 발생할 가능성이 높습니다.

2) 리팩토링은 고객에게 진정한 장기적인 혜택을 제공하는 것으로 완료되어야합니다.

리팩토링을 고려할 때는 항상 실제로 필요한 것과 중요한 것을 고려해야하며 리팩토링 작업이 진정한 장기적 가치를 제공하는지 확인해야합니다.

결국, 우리는 코드가 중장기 적으로 확장 가능하고 지원 가능한 상태로 남아서 이론적 완벽 성을 추구하는 것보다 고객의 투자가 유효하게 유지되도록해야합니다. 리팩토링 작업 (및 해당 추정값)은이를 범위 내에서 수행해야합니다. 이제는 약간 더 나은 방법이 있다고 생각하기 때문이 아닙니다.

일부 프로그래머는 클라이언트의 문제를 제어하는 ​​방법이 클라이언트에 서명하고 초기 사양을 승인하는 것이라고 제안합니다. 그런 다음 초기 사양에없는 요구 사항 변경을 요청하면 추가 비용 및 시간 지연을 계산하기 위해 계약 및 프로젝트 시간표를 거쳐야한다고 계약에 추가합니다. 분명히 클라이언트가 새로운 (예기치 않은) 기능을 고집하지 못하게하는 것은 놀라운 일입니다.

현재 작업중 인 코드베이스에 다음과 같은 주석이 있습니다.

/*
 * Every time I see this function, I want to take a shower.
 */

나는 당신이 묘사하는 상황을 잘 알고 있습니다. 내가하는 일은 일이 진정되고 모든 종류의 '크립'이 할 모든 일을 '크레프'할 때까지 기다리려고 노력합니다. 그 당시에는 아마도 사용 가능한 무언가가 출시되었을 것입니다. 물건을 정리하고 약간 다르게 구현하는 데 시간이 걸릴 수 있습니다.

작은 엉망진창을 반복해서 많이 청소할 수는 없습니다. 그것은 당신의 일과 좌절의 세 배에 불과합니다. 하나 더 커질 때까지 기다리십시오.

우선이 상황을 피하는 것이 좋습니다.

사양을 읽는 방법에 따라 다릅니다. 그것들을 석판으로 생각하기는 쉽지만 실제로는 대부분의 사양이 변경됩니다. 코드를 디자인 할 때 사양의 각 부분이 변경 될 가능성에 대해 살펴보십시오. 시간이 지남에 따라이를 예측하는 데 능숙 해집니다.

혼란에 빠진 경험과 판단은 매우 중요합니다. 이 스파게티 코드로 인해 새로운 버그를 작성하고 있습니까? 구현하는 데 시간이 더 걸립니까? 이것들은 전술적 리 팩터를하는 것을 가리킨다.

앞으로는 고객과 협력하여 작업해야 할 것 같습니다. "이 제품은 원래 사양보다 크게 확장되고있는 것 같습니다. 원래 디자인은 해당 수준에 적합하지만 X 방향과 Y 방향으로 확장하면 디자인에서 일부 구조 조정이 필요합니다." 고객이 비용을 지불합니다.

시간에 따라 요금을 부과하고 변경을 원하면 괜찮지 만 좋은 코드를 작성하는 데 필요한 시간을 방정식에 통합하십시오. 또한 더 깔끔한 코드를 작성하면 유지 관리해야 할 때 장기적으로 이익을 얻습니다. 시간을 절약하면 나중에 비용이 발생할 수 있습니다.

소프트웨어 작성은 비즈니스 요구와 함께 진행되어야한다고 생각합니다. 일주일에 빌드해야하는 프로토 타입과 같이 매일 새로운 입력이 오는 유망한 프로젝트 인 경우, 코드 유지 관리 및 기타 사항에 대해 걱정할 필요가 없습니다. 시간이 중요하며 필요한 경우 가능한 빨리 문 밖으로 코드를 밀어 넣으십시오.

그러나 장기 응용 프로그램을 작성하는 경우 새로운 기능을 구축하고 기존 버그를 수정하고 다른 응용 프로그램 및 기타 항목에 통합하는 데 걸리는 시간에 상당한 영향을 미치기 때문에이 모든 것을 고려하는 것이 좋습니다. 이는 나중에 더 많은 시간과 비용이 필요하기 때문에 비즈니스에 영향을 미칩니다.

따라서 의사 결정자에게 필요할 때마다 코드를 리팩토링하지 않는 실제 비용을 감수하는 것이 좋습니다. 내 경험상 두 옵션의 비용과 시간 영향이 의사 결정자에게 측정 가능한 용어로 설명되면 결정은 두뇌없는 사람. 사람들이 '예, 두 배의 시간이 걸리고 추가 혜택을주지 않아도 아름다운 코드를 작성해 나갈 것'이라고 말하지 마십시오. 그것은 그렇게 작동하지 않습니다.

프로세스의 일부로 만들어 "익스트림 리팩토링"이라고 부르면 커질 것입니다! ;) 신속하게 작업을 수행하고 흉터 조직이있는 충분한 새로운 기능이 추가되면 리팩터링하십시오. 계속해서 스스로에게 "이제 처음부터 시작했다면 어떻게 했을까"

그들이 모든 것을 미리 설계하고 생각할 수 있다고 생각하는 사람들은 대부분 자신을 속이는 것입니다. 그 교훈을 사용하십시오.

당신이 좋은 프로그래머라면 당신은 꽤 빨리 리팩토링 할 수 있고, 계속해서 코드를 작성하면 코드가 "적절한 형식"이되기 시작합니다. 즉, 의존성이 적을수록 더 유연 해집니다.

고객이 당신이 물건을 재 작업하는 "시간을 낭비하고"있다는 것을 알고 있다면 혼란 스러울 수 있습니다.

이러한 방식으로 개발 된 코드는 결국 많은 시간을 절약하고 새로운 기능을 추가하기가 점점 쉬워 질 것입니다.

또한 잘못된 코드의 가장 큰 이유 중 하나는 일부 프로그래머가 더 큰 구조적 리팩토링을 할 때의 두려움이며, 더 오래 기다릴수록 더 나빠질 것이라고 말합니다.

더 높은 전력에 의존

기도한다는 의미는 아닙니다. 내 말은, 당신과 당신의 고객 사이에 패딩으로 놓을 수있는 비즈니스 사람 (예 : 프로젝트 관리자 또는 이와 동등한)이 있는지 확인하십시오. 고객이 너무 많은 것을 요구하는 경우, 비즈니스 담당자가 발을 내딛고 "할 수 있지만 사양의 범위 내에 맞는지 확실하지 않은 경우 [비즈니스 담당자]"를 참조하십시오.

정상적인 프로젝트 흐름에서는 심각한 개발이 이루어지기 전에 일반 사양을 동결해야합니다.

많은 고객들은 귀하가 허락하는 한 계속해서 변경 / 개선 / 향상을 추구 할 것입니다. 많은 사람들은 자신의 돈을 최대한 활용하고 있다고 느끼기 때문에 (프로젝트를 방해하는 경우에도) 그 능력을 최대로 남용 할 것입니다.

사양을 조기에 완벽하게 완성하고 동결시키고 나중에 시행 할 것을 전담하는 사람이 있어야합니다.

클라이언트와의 약간의 업장을 위해 약간의 여분의 일을하는 것은 아무 문제가 없지만 그들이 손을 when을 때 더 높은 힘을 미룰 준비를하십시오. 사양에 엄청나게 많은 양의 변경이 필요한 경우 비즈니스 루프로 돌아가서 계약을 재평가하거나 계약에 추가 사항을 추가해야 할 때가 있습니다 (공정한 금전적 보상).

이 문제가 발생한다는 사실은 코딩 방법과 거의 관련이 없습니다. 프로젝트 관리자가 프로젝트에서 활용률이 낮다는 표시입니다 (오류, 결함 또는 둘 다).

다른 사람들이 많은 답변에서 말했듯이, 모든 프로젝트에는 우발 상황에 대한 시간 버퍼를 추가해야하지만 사양이 동결되어 PM에 의해 고객에게 전달되기 전에 닫힌 문 뒤에서 결정되어야한다고 결정합니다.

초기의 적절한 디자인은 문제를 피하는 데 도움이되지 않습니다. 그리고 미래의 모든 "아마도"요구 사항을 고려하는 것은 거의 불가능합니다. 그래서 얼마 후 Big Re-factoring이 도착할 것입니다. 가장 좋은 해결책은 모든 것을 다시 쓰는 것입니다.

한 마디로 : 빨간색 페라리에 포탑을 장착하는 대신 요구 사항을 다시 고려하고 탱크를 만드십시오.

불로 그것을 죽이다.

가능한 한 빨리 리팩토링합니다. 향후 코드를 디버깅하기가 훨씬 어려워 질 것입니다.

현재 상태를 테스트 한 프로젝트에 대한 단위 테스트를 작성하고 시간이있을 때 리팩터링하십시오. 이렇게하면 프로젝트를 정리하는 동안 프로젝트가 중단되지 않습니다.

가장 간단한 답변. 나는 그가 원하는대로 정확하게 최종 사양을 갖기 전까지는 어떤 종류의 코딩도 중단 할 것입니다.

그런 다음 기능 목록 등의 우선 순위를 정하여 현재 가지고있는 항목과 나중에 수행 할 수있는 항목을 확인해야합니다 ....

경험을 사용하여 각 기능의 시간 / 비용을 결정한 다음 원하는 경우이를 알려면 x의 시간과 비용이 소요됩니다.

기능 범위 크립의 큰 범죄를 처리하고 아무런 조치도 취하지 않거나 잘못 수행 될 때까지 계속해서 기능을 추가합니다.

최종 목록을 얻은 후에는 나중에 원하는대로 수정할 수 있지만 지금 당장 가지고 있어야 할 상위 15/20에 집중해야한다고 알려주십시오.

그런 다음 완료 시간을 바탕으로 발표 된 후 다음 버전에 대해 토론 / 브레인 스토밍 할 수 있다고 알려주십시오.

현재 버전에서 수행 할 작업에 대한 최종 결정이 내려지면 모든 토론 / 아이디어 / 제안을 100 % 중지해야합니다.

그가 아이디어를 끝없이 얻는다면, 다음 버전의 기능 목록에 아이디어를 적어 놓고 지금 당장 원하는 가장 중요한 기능을 제공하는 데 집중하도록하십시오.

그들이 당신의 시간을 계속 낭비한다면 마음을 계속 바꾸십시오. 그런 다음 결정을 완료 할 때까지 프로젝트 작업을 중단하고 다른 프로젝트에서 작업합니다.

어려운 일이지만, 기능 범위의 크리프는 시간, 에너지, 동기 부여 및 명확한 사고를 파괴합니다.

프로젝트 전체 관점에서 :

팀과 함께 코드에서 배우고 다음에 리팩토링하고 재사용 할 수있는 것을 확인한 다음 맥주를 마시십시오.

개발 중 관점에서 :

개발이 중단 된 이유를 설명하고 모든 사양이 표에 있고 이해 될 때까지 계속할 수없는 이유를 설명하십시오. 그런 다음 맥주를 마시십시오.

계획 관점에서 :

모든 사양을 미리 요청하고 모든 사람과 협력하여 개발 경로를 명확하게 이해하십시오. 고객 / 이해자를 최대한 밀접하게 참여시켜 모든 사람이 같은 페이지에 있도록하십시오. 그날 밤, 모든 사람들에게 맥주를주세요. 내일, 프로젝트를 시작하십시오.