문제에 대한 두 가지 가능한 해결책이 있다고 가정 해 봅시다. 첫 번째는 빠르지 만 해키입니다. 두 번째가 바람직하지만 구현하는 데 더 오래 걸립니다. 문제를 신속하게 해결해야하므로 가능한 한 빨리 문제를 해결하고 나중에 더 나은 솔루션에 대한 작업을 시작할 계획입니다. 문제는 문제가 해결 되 자마자 할 일 목록이 급락한다는 것입니다. 어느 시점에서 더 나은 솔루션을 넣을 계획이지만 지금 구현하는 것을 정당화하기는 어렵습니다. 갑자기 완벽하지 않은 솔루션을 사용하여 5 년을 보냈고 그동안 저주를 받았습니다.
익숙한 것 같습니까? 내가 일하는 곳에서 한 번 이상 일어났다는 것을 알고 있습니다. 한 동료는 의도적으로 잘못된 GUI를 만들어 실수로 장기적으로 채택되지 않도록 설명합니다. 더 나은 전략이 있습니까?
답변
해킹이 실패한 테스트 케이스를 작성하십시오.
해킹이 실패한 테스트를 작성할 수 없다면 결국 해킹에 문제가없는 것입니다. 그렇지 않으면 테스트 프레임 워크가 부적절합니다. 전자의 경우 불필요한 최적화에 인생을 낭비하기 전에 빨리 달아나십시오. 후자의 경우 다른 접근 방식을 찾으십시오 (핵 신고 또는 테스트 …)
답변
전략 1 (거의 선택되지 않음) : kluge를 구현하지 마십시오. 사람들에게 가능성을 알리지도 마십시오. 처음에는 올바른 방식으로 수행하십시오. 내가 말했듯이, 이것은 시간 제약으로 인해 거의 선택되지 않았습니다.
전략 2 (부정직) : 거짓말과 속임수. 경영진에게 해킹에 버그가 있으며 나중에 중대한 문제를 일으킬 수 있다고 말합니다. 불행히도 대부분의 경우 관리자는 버그가 문제가 될 때까지 기다린 다음 버그를 수정하라고 말합니다.
전략 2a : 실제로 버그가 있다는 점을 제외하면 전략 2와 동일합니다. 그래도 같은 문제입니다.
전략 3 (그리고 개인적으로 가장 좋아하는) : 가능할 때마다 솔루션을 설계하고 인턴 또는 코드 원숭이가 할 수있을만큼 충분히 잘 수행하십시오. 자신의 급여를 정당화하는 것보다 적은 양의 코드 원숭이 돈을 지출하는 것을 정당화하는 것이 더 쉽기 때문에 그냥 끝낼 수도 있습니다.
전략 4 : 재 작성을 기다립니다. 계속 기다리십시오. 조만간 (아마 나중에) 누군가가 그 일을 다시 작성해야 할 것입니다. 그때 바로 할 수있을 것입니다.
답변
다음은 기술적 부채 에 대한 훌륭한 관련 기사입니다 .
기본적으로 그것은 당신이 내리는 모든 기술적 결정과 부채의 비유입니다. 좋은 부채와 나쁜 부채가 있습니다. 그리고 최소한의 장기 비용으로 원하는 목표를 달성 할 부채를 선택해야합니다.
최악의 빚은 신용 카드 빚과 유사한 작은 누적 지름길입니다 … 각각은 다 치지 않지만 곧 가난한 집에있게됩니다.
답변
이것은 마감일 중심의 작업을 할 때 중요한 문제입니다. 이 방법을 선택한 이유에 대한 자세한 설명과 코드 작성 방법에 대한 힌트를 추가하면 도움이됩니다. 이렇게하면 코드를 보는 사람들이 코드를보고 최신 상태로 유지할 수 있습니다.
작동 할 또 다른 옵션은 재 작업을 자세히 설명하는 추적 프레임 워크에 bug.feature를 추가하는 것입니다. 그렇게하면 볼 수 있고 어느 시점에서 문제가 발생할 수 있습니다.
답변
이러한 문제를 수정하는 것을 정당화 할 수있는 유일한 경우 (실제로 손상되지 않았기 때문에 추악하기 때문)는 동일한 코드 섹션에 영향을주는 또 다른 기능이나 버그 수정이 있고이를 다시 작성하는 것이 좋습니다.
개발자의 시간 비용에 대해 계산해야합니다. 소프트웨어 요구 사항이 충족되고 있고 유일한 잘못된 것은 코드가 내부적으로 난처하다는 것입니다. 실제로 수정할 가치가 없습니다.
열성적인 엔지니어가 불안 해지면 매년 재건축을 고집하기 때문에 기업 전체가 사업을 중단 할 수 있습니다.
버그가없고 요구 사항을 충족하면 완료된 것입니다. 그것을 발송하십시오. 움직여.
[편집하다]
물론 저는 모든 것이 항상 해킹 당한다고 주장하는 것은 아닙니다. 정상적인 개발 과정에서 신중하게 코드를 설계하고 작성해야합니다. 그러나 신속하게 수행해야하는 해킹이 발생하면 코드를 정리할 가치가 있는지 여부에 대한 비용 편익 분석을 수행해야합니다. 응용 프로그램의 수명 동안 문제를 해결하는 것보다 복잡한 해킹을 코딩하는 데 더 많은 시간을 할애한다면 당연히 고쳐야합니다. 그러나 그렇지 않은 경우 소스를 보면 질병이 발생하기 때문에 버그가없는 작동하는 애플리케이션 을 다시 코딩하는 것은 너무 비싸고 위험합니다 .
답변
중간 솔루션을 수행하지 마십시오.
가끔은 프로그래머에게이 말만하면된다고 생각합니다.
미안하지만 심각하게 해키 솔루션은 쓸모가 없으며 첫 번째 반복에서도 솔루션의 일부를 올바르게 수행하는 것보다 더 오래 걸릴 수 있습니다.
유지를 위해 쓰레기 코드를 남기지 마십시오. 항상 올바르게 코딩하십시오. 얼마나 오래 걸리고 누가 당신에게 소리를 지르 든 상관 없습니다.
다른 사람들이 어리석은 해킹을 디버깅하는 동안 일찍 배달 한 후 엄지 손가락을 빙빙 돌리고 앉아있을 때 고마워 할 것입니다.
자신이 훌륭한 프로그래머라고 생각하지 않더라도 항상 최선을 다하기 위해 노력하고 지름길을 사용하지 마십시오. 제대로하는 데 시간이 걸리지 않습니다. 당신이 나를 믿지 않는다면이 진술을 정당화 할 수 있습니다.
답변
갑자기 완벽하지 않은 솔루션을 사용하여 5 년을 보냈고 그동안 저주를 받았습니다.
저주하는 경우 TODO 목록의 맨 아래에있는 이유는 무엇입니까?
- 그것이 당신에게 영향을 미치지 않는다면, 왜 저주하고 있습니까?
- 그것이 당신에게 영향을 미치고 있다면, 지금 해결해야 할 문제입니다.
