당신의 돈벌이 상사에게 리팩토링 작업을 어떻게 정당화합니까?[닫은]

Question

압박감 속에서 몇 가지 중요한 기능을 제공하기 위해 코드 더미를 작성했습니다.몇 가지 모서리를 잘라내고 일부 코드를 SerialIndirectionShutoffManager.와 같은 이름을 가진 과장된 클래스로 뭉쳤습니다.

당신은 상사에게 이 물건을 청소하는 데 일주일이 걸릴 것이라고 말했습니다.

"무엇을 청소합니까?"

"내 코드는 돼지우리야!"

"버그 수정이 더 있다는 뜻인가요?"

"그렇지는 않아요. 더 비슷해요.."

"더 빨리 달리게 해줄 건가요?"

"아마 그럴지도 모르지만 그건 아니지.."

“그렇다면 기회가 있을 때 제대로 썼어야지.이제 당신이 여기 있어서 기쁘군요. 그래, 이번 주말에 당신에게 오라고 ​​부탁해야겠습니다.."

나는 Matin Fowler의 책을 읽었지만 이 문제에 대한 그의 조언에 동의하는지 잘 모르겠습니다.

• 정기적인 코드 검토를 장려하여 리팩토링 작업이 개발 프로세스의 자연스러운 부분으로 권장됩니다.
• 그냥 말하지 마세요. 당신은 개발자이고 그 의무의 일부입니다.

이 두 가지 방법 모두 관리자와 의사소통해야 하는 필요성 때문에 발생합니다.

상사에게 뭐라고 말해요?

Answer 1

원래 추정치에 리팩토링 시간을 포함하는 것이 중요합니다.제품을 배송한 후 상사에게 가서 아직 완료되지 않았다고 말하는 것은 완료되었다는 거짓말입니다.실제로 배달 가능 기한을 지키지 않았습니다.이는 마치 외과의사가 수술을 하고 나서 모든 것을 원래대로 되돌렸는지 확인하지 못하는 것과 같습니다.

개발의 모든 부분을 포함하는 것이 중요합니다(예:리팩토링, 유용성 연구, 테스트, QA, 개정)을 원래 일정대로 진행하세요.궁극적으로 이것은 프로그래머 문제만큼 관리 문제가 아닙니다.

그러나 만약 당신이 엉망진창을 물려받았다면 당신은 상사에게 마지막 프로그래머들이 프로젝트를 끝내기 위해 서두르고 있고 그것이 절뚝거리고 있다는 것을 설명해야 할 것입니다.일시적으로 문제에 대해 반창고를 붙일 수 있지만(그들이 그랬던 것처럼) 각각의 반창고는 문제를 지연시키고 궁극적으로 문제를 해결하는 데 훨씬 더 많은 비용을 들게 만듭니다.

상사에게 솔직하게 말하고 프로젝트가 완료되기 전에는 완료된 것이 아니라는 점을 이해하십시오.

Answer 2

그가 이해할 수 있는 언어로 말하세요.

리팩토링은 설계 빚을 갚는 것입니다.

상사에게 매달 회사 신용카드 대금을 지불하는 이유와 추심 통지가 있을 때까지 지불하지 않는 이유를 물어보세요.리팩토링은 월별 결제와 같다고 말해주세요.

Answer 3

그냥 하고 일반적인 프로세스에 맞게 일정을 잡으세요.새로운 변경을 시작하거나 변경을 완료하는 데 걸리는 리팩토링 시간을 예측합니다(이상적).나는 처음에 새 코드(추출 방법 등)를 탐색하는 동안 항상 리팩터링합니다.

Answer 4

거짓말하다.그에게 새로운 기술에 대한 연구라고 말해주세요.그런 다음 비용이 이점을 정당화하지 못한다고 결정했다고 그에게 말하십시오.그 사람은 당신이 훌륭한 일을 했다고 생각할 거예요.

ㅋㅋ @ 사람들이 모딩/마킹 공격적이네요.

실제로, 값싼 소프트웨어와 좋은 소프트웨어를 이해하지 못하는 푼돈 꼬집는 상사라면, 그가 모르는 것이 궁극적으로 그를 더 행복하게 만들 것입니다.저라면 회사를 떠나 개발자들의 좋은 코드 작성 능력을 존중하는 곳으로 갈 것입니다.그런데 또 이것이 내가 고위직에 있는 이유다.

Answer 5

소프트웨어 프로젝트와 관련된 비용의 80%가 수명주기의 유지 관리 단계에서 발생한다고 말합니다.미래의 문제를 완화하기 위해 지금 수행된 리팩토링과 몇 가지 예는 나중에 해당 코드를 유지 관리해야 할 필요성이 발생할 때 상당한 비용 이점을 얻을 것입니다.

이는 프로그래머의 허영심이 아니라 이유 때문에 리팩토링한다고 가정합니다.

Answer 6

리팩토링은 항상 해야 합니다....그러므로 그것을 정당화할 필요는 없습니다.

큰 혼란 정리/재설계에는 제어하기 위해 리팩토링이 포함될 수 있지만 "리팩토링"은 아닙니다.

리팩토링은 몇 분이면 완료됩니다. 도구 지원이 없다면 몇 분이면 됩니다.

Answer 7

Robert Glass의 최근 책 중 하나(참고 자료를 찾아봐야 할 것임)에서 그는 잘 관리된 코드의 비용에 대한 연구를 언급했습니다.그들이 발견한 것은 잘 관리된 코드는 제대로 관리되지 않은 코드보다 더 자주 편집된다는 것입니다.그것은 직관적이지 않은 것처럼 들리지만 더 깊이 파고들자 그 이유를 발견했습니다.

잘 관리된 코드에는 제대로 관리되지 않은 코드보다 같은 기간에 더 많은 기능이 추가됩니다.

상사가 기능을 좋아하나요?물론이죠. 모두 그렇습니다.코드의 유지 관리 가능성을 더 많이 향상시키면 제한된 예산으로 더 많은 기능을 제공할 수 있습니다.

Answer 8

나는 Martin Fowler의 "Refactoring"에 제공된 답변을 좋아합니다.당신이 아는 가장 빠른 방법으로 소프트웨어를 개발할 것이라고 상사에게 말하십시오.대부분의 경우 소프트웨어를 개발하는 가장 빠른 방법은 진행하면서 리팩토링하는 것입니다.

상사에게 말해야 할 또 다른 사항은 향후 개선을 위해 비용을 절감하고 있다는 것입니다.

Answer 9

이제 리팩토링하는 데 드는 돈이 줄어 듭니다 ...

또는 나중에 잘못된 부분을 수정하고 리팩토링할 수 있도록 더 많은 돈을 지불해야 합니다.

Answer 10

때로는 새로운 직업을 구해야 할 때이기도 합니다.당신이 "완료"하기를 원하는 특정 사람들이 있습니다.당신이 그런 상황에 처해 있고 나도 거기에 있었다면 그냥 떠나십시오.

하지만 네, 미래 비용 등에 관한 다른 모든 것들은 좋은 생각입니다.나는 대부분의 상사가 자신이 원할 때 원하는 것을 원하기 때문에 자신에게 거짓말을 하고 미래에 무슨 일이 일어날지 알 수 없다고 생각합니다.

그럼 사장님과 행운을 빕니다.그 또는 그녀가 합리적이기를 바랍니다.

Answer 11

내 생각에는 상사에게 말하지 않고 그냥 작업을 시작해야 할 것 같아요.이것이 제가 최선을 다한 방법입니다.나는 상사에게 내가 무엇을 하고 있는지 말하지 않고 시간이 있을 때 천천히 불량/레거시 코드를 교체합니다.

그것은 한 번 이상 내 엉덩이를 구해주었습니다.

Answer 12

상사가 코드를 리팩터링하거나 정리해야 할 필요성을 이해하지 못한다면 그가 엔지니어링 관리자가 되기에 충분한 엔지니어링 지식을 갖고 있는지 의심해야 합니다.

Answer 13

리팩토링할 시간을 주는 상사를 찾는 경우는 거의 없습니다. 진행하는 대로 진행하세요.

Answer 14

제 생각에는 리팩토링을 위한 가장 간단한 사례는 지나치게 복잡한 코드를 수정하는 것입니다.문제가 되는 소스 코드의 McCabe 순환 복잡성을 측정합니다(소스 모니터는 이러한 문제를 해결하는 훌륭한 도구입니다).순환 복잡성이 높은 소스 코드에는 강한 상관 관계 결함과 잘못된 수정 사항이 있습니다.간단히 말해서 이것이 의미하는 바는 복잡한 코드는 수정하기 어렵고 잘못 수정될 가능성이 높다는 것입니다.이것이 관리자에게 의미하는 바는 제품의 품질이 더 나빠지고 버그를 수정하기가 더 어려워지며 궁극적으로 프로젝트 일정이 더 나빠질 수 있다는 것입니다.그러나 복잡성을 리팩토링하면 코드의 투명성이 향상되고 모호하거나 어려운 버그가 발생할 가능성이 줄어들며 유지 관리가 더 쉬워집니다(예:이로 인해 유지 관리 프로그래머는 더 큰 유지 관리 범위를 가질 수 있습니다.

또한 프로젝트에 새로운 요구 사항이 추가될 때 복잡성이 감소하면 응용 프로그램을 더 쉽게 확장할 수 있다는 사례(유지 관리 주기에서 죽은 제품이 아닌 경우)를 만들 수 있습니다.

Answer 15

상사는 올바른 기술적 결정(리팩터링 시기 포함)을 내리기 위해 개발자를 신뢰해야 합니다.

그 신뢰를 확립하거나 상사를 교체하거나 개발자를 교체하십시오.

Answer 16

또 다른 좋은 비유는 깔끔한 건물 부지를 유지 관리하는 것입니다.여기서 유일한 문제는 프로그래머가 건설 노동자를 대표하지 않고 관리자가 감독을 대표하지 않는다는 것입니다.만약 그렇다면, "처음부터 제대로 하라"는 그의 반론은 여전히 ​​적용될 것입니다. 왜냐하면 유능하고 성실한 건설 노동자는 작업 공간에서 좋은 질서를 유지할 책임이 있기 때문입니다.

정말 코드 자체 노동자를 대표하고, 개발 과정은 감독이다.혼란은 서로의 사업을 진행하는 다양한 거래로 인해 발생합니다(예:서로 다른 코드 기능이 상호 작용하여 각 기능이 제대로 작동하지만 그 사이의 이음새가 체계적이지 않음) 감독이 확고한 손을 잡고 무질서가 시작되는 위치를 주시하고 청소하기 위해 조치를 취하여 정리합니다. 위로 (즉리팩토링을 요구하는 소프트웨어 프로세스).

Answer 17

최근에 제가 한 일은 리팩토리 프로세스가 코드의 순서와 구조가 더 좋아지고 속도도 개선할 수 있기 때문에 새로운 기능을 더 빠르게 개발하고 새로운 버그가 발생할 가능성을 줄이는 데 도움이 된다는 점을 비즈니스 담당자에게 설명하는 것입니다. 이전보다 쉽게 ​​코드를 검사할 수 있기 때문입니다.

사업가들이 그것을 이해하고 똑똑하다면 지속적인 리팩토리 프로세스를 수행하도록 권장할 것입니다.

이를 건물 비유로 설명할 수 있습니다.리팩토리를 수행하지 않으면 코어가 불량한 형편없는 건물이 되어 파이프, 창문, 문에 문제가 발생하게 됩니다.

Answer 18

하지 않다....그냥 당신과 더 잘 맞는 곳에서 새 직장을 구하세요.