우리는 구식 코드를 개선해야 할 책임이 있습니까?

내가 쓴 오래된 코드를 살펴 보았습니다. 작동하지만 훌륭한 코드는 아닙니다. 나는 당시보다 더 많은 것을 알고 있으므로 그것을 향상시킬 수 있습니다. 현재 프로젝트는 아니지만 현재 작동하는 프로덕션 코드입니다. 과거에 작성한 코드를 되돌아 가서 개선해야 할 책임이 있습니까? 아니면 "파손되지 않은 경우 수정하지 마십시오"라는 올바른 태도입니까? 우리 회사는 몇 년 전에 코드 검토 수업을 후원했으며 주요 장점 중 하나는 때로는 충분하다는 것입니다. 어서

따라서 어느 시점에서 그것을 충분히 호출하고 계속 진행해야합니까, 아니면 더 나은 것으로 생각 될 때 이전 코드를 개선하기 위해 프로젝트를 추진해야합니까?

버그를 수정하거나 기능을 추가하기 위해이 "이전 코드"를 변경하지 않는 한,이를 위해서만 개선하지 않아도됩니다. 궁극적으로 개선하고 싶다면 코드 리팩토링을 시작하기 전에 코드를 테스트 할 유닛 테스트가 있는지 확인하십시오.

"이전 코드"를 사용하여 더 나은 방법을 배울 수 있습니다. 이렇게하면 파트 타임 학습 경험이되므로 클라이언트 / 고객이 현재 릴리스하거나 배포 한 내용을 해당 코드로 대체하지 않아야합니다.

가장 자주 수정해야하는 코드 영역을 리팩터링하십시오 . 이러한 영역을 자주 방문하기 때문에 리팩토링은 코드를 다시 방문해야 할 때 코드에 대한 이해와 가독성을 향상시키는 반면, 아무도 다시는 보지 않을 코드를 리팩터링 할 필요가 없습니다.

또한 코드 영역을 수정해야 할 때만 리팩토링 하는 경우 리팩토링으로 인해 회귀가 발생하는 경우 유효한 변명을 제공합니다 . 물론 단위 테스트로 리팩토링을 다루려고하지만 특히 레거시 코드에서는 항상 가능하지는 않으며 큰 리팩토링이 가끔씩 회귀를 생성해야합니다.

기능을 추가해야하고 디자인 속도가 느려지거나 복제가 발생하는 경우 리팩터링하십시오 . 코드를 디자인 할 때 앞으로 어떤 변경이 필요할지 정확히 예측하지 못합니다. 그러나 새로운 기능을 추가하면 일반적으로 공유 코드를 리팩토링합니다. 그때까지 세 번째 기능 / 리팩토링주기를 추가했는데 리팩토링이 이미 비용을 지불하고 공유 코드가 상당히 안정적입니다.

TLDR : 필요에 따라 리팩터링 할 의무가 없습니다.

당신이하는 모든 비용이 있습니다. 프로그램 시간이 제한되어 있습니다. 프로그래밍에서하는 모든 일은 "이 작업의 이점은 무엇입니까?"에 대해 살펴 봐야합니다. "다른 일을하면 어떤 이점이 있습니까?"

기회 비용 (기타 비용은 무엇입니까?)을 고려하지 않으면 품질은 무료입니다. 코드를 개선하는 것이 좋습니다. 당신은 뭔가를 배울 것입니다. 더 잘 작동합니다. 더 많이 팔 것입니다.

진짜 질문은 당신이 당신의 시간으로 할 수있는 다음으로 가장 좋은 일이 무엇입니까? 그리고 당신은 절충을했습니다.

더 많은 소프트웨어를 판매 할 예정입니까?

지원하는 두통이 줄어 듭니까?

무엇을 배울 것입니까?

더 심미적으로 즐거워 질까요?

그것은 당신의 명성을 향상시킬 것인가?

대기열에서이 활동 및 기타 활동에 대해 다음 질문 (및 기타 관련 질문)을 요청하면 해결해야 할 가치가있는 경우 답변하는 데 도움이됩니다. 이러한 절충은 프로그래머에게 경제가 중요한 이유입니다. 조엘 은 내가 그렇게하기 전에 그것을 말했고, 오래된 멘토는 조엘 앞에서도 그것을 말했습니다.

더 간단한 답변을 원한다면 코드를 고칠 때까지 TV 시청을 중단하십시오. :-)

나는 당신이 놓친 것 같은 질문을 스스로에게 시작해야한다고 생각합니다. 코드는 어떤 식으로 나쁜가요? 그리고 이것으로 당신은 정말로 다음을 묻습니다.

• 코드가해야 할 일을하지 않습니까?
• 소프트웨어를 유지 관리 할 때 코드로 인해 문제가 발생합니까?
• 코드가 완전히 포함되어 있습니까?
• 가까운 시일 내에 언제든지 코드를 업데이트하거나 교체 할 계획이 있습니까?
• 관련 코드를 업데이트하기 위해 건전한 비즈니스 사례가 있습니까?

몇 년 동안 내가 배운 것이 있다면, 사실 이후에 다시 추측 할 여유가 없다는 것입니다. 코드에서 문제를 해결할 때마다 무언가를 배우고 아마도 솔루션이나 비슷한 것이 어떻게 몇 년 전에 다르게 해결 한 문제에 대한 더 나은 해결책 이었는지 알 수 있습니다. 이것은 당신이 당신의 경험에서 배운 것을 보여주기 때문에 좋은 것입니다. 그러나 실제 질문은 이전에 작성한 코드가 시간이 지남에 따라 다루기가 더 어려운 레거시 문제가 될 가능성이 있는지 여부입니다.

여기서 실제로 이야기하고있는 것은 유지 관리가 쉽고 어려운 코드인지 여부와 시간이 지남에 따라 유지 관리 비용이 얼마나 비쌀 지에 대한 것입니다. 이것은 본질적으로 기술 부채에 대한 질문이며, 현재 약간의 외과 적 유지 관리를 사용하여 부채를 상환 할 가치가 있는지, 또는 부채가 당신이 잠시 동안 움직일 수있을 정도로 작은 지 여부에 대한 질문입니다.

이러한 질문은 현재 및 미래의 작업 부하에 대해 실제로 계량해야하는 질문이며, 자원을 어디에 투자해야하는지, 이전 코드의 가치에 대한 이해를 높이기 위해 경영진 및 팀과 긴 시간 동안 논의해야합니다. 시간을 투자해야 할 수도 있습니다. 변화를 도입하기위한 좋은 사업 사례를 만들 수 있다면, 반드시 그렇게하십시오. 그러나 코드 작성 방식이 창피하다고 느끼기 때문에 코드를 수정하려는 충동에 직면 한 경우, 오래된 코드를 유지하는 데있어 개인적인 자부심의 여지가 있습니다. 그것은 작동하거나 작동하지 않으며 유지 관리가 쉽고 유지 보수 비용이 많이 들며 어제 오늘의 경험을 이용할 수 없었기 때문에 결코 좋지 않습니다.

확실히 그것을 개선하지 않는 단지 그것을 개선을 위해. 다른 사람들이 말했듯이 (그리고 상식적으로), 시간이 지남에 따라 우리 모두는 (일부 "더 나은"가치를 위해) 더 좋아집니다. 즉, 공식적인 또는 비공식적으로 코드를 검토하면 종종 우리가 결코 다시는 빛을 보지 못했던 이러한 비트와 조각을 조명합니다.

기본적으로 깨지거나 안전하지 않거나 더 이상 사용되지 않는 / EOL 목록의 기능에 의존하지 않는 코드를 개선하고 개선 해야 할 책임 이 있다고 생각하지는 않지만 이 상황에서 과거에 수행 한 작업은 다음과 같습니다. :

• 팀의 일원으로 돌아가서 코드를 개선하는 사람들을 성취감을주는 일종의 두뇌 정리 또는 훌륭하고 한 입 크기의 작업으로 식별하고, 일정에 따라 정기적으로 수행 할 시간을 찾으십시오. 나는 항상 팀에 이런 종류의 사람들 중 적어도 한 명을 가지고 있었고, 우리가 모두 소멸하거나 다운 된 경우이 접근법은 또한 사기 (또는 적어도 기분)를 높일 수 있습니다.

• 학습 연습의 기초로 사용하십시오. 인턴, 학생 또는 팀의 신입생 또는 주니어 신입생의 경우, 팀의 선임 구성원의 지시에 따라 기존 코드를 리팩토링하면 새로운 팀원과 의사 소통하고 시스템에 대해 더 많이 이해하며 작문 / 습관에 빠질 수 있습니다 단위 테스트 업데이트 및 지속적인 통합 작업. 이 연습은 지침에 따라 수행되며 현재 표준 / 규범에 맞지 않기 때문에 코드를 개선 하기 위한 연습 으로 명확하게 구성되어 있습니다.

따라서 그것을 고칠 책임은 없지만 그 오래된 것들이 실제로 유용 할 수 있습니다. 그리고 단위 테스트와 CI는 당신의 친구입니다!

반드시 그런 것은 아닙니다. 그러나 코드 유지 관리를 수행하고 더 나은 무언가를 우연히 발견하는 경우 회귀를 만들지 않도록 적절한 단위 테스트가 있으면 코드를 변경할 수 있습니다.

그러한 테스트가 존재하지 않고 정확히 어떻게 동작하는지 확신 할 수 없다면 혼자 두는 것이 좋습니다.

엔지니어의 관점에서 볼 때 더 이상 개선 할 수 없을 때까지 오래된 코드로 작업하고 싶습니다. 그러나 비즈니스 사례가 있습니까? 하루가 끝나면 코드가 직장의 수익성에 영향을 미칩니다. 그렇지 않은 경우 그대로 두십시오.

코드를 개선하여 버그가 발생하는 것을 피할 수 있다면 큰주의 사항이 있습니다 (큰 Y2K 공을 여기에서 생각하십시오.) 나는 누군가 더 높은 사람, 아마도 귀하의 사업부 관리자와 코드 개선의 결과에 대해 논의합니다.

나에 관해서는, "이 구체적인 코드가 지금 제대로 작동한다면 왜 누군가가 추가 자원 (시간, 돈, 정신 등)을 소비해야 하는가? ? "

레거시 코드를 찾을 때마다 중요해 보이는 몇 가지 사항에 대해 생각합니다.

1. 무엇을 변경하려고합니까?
2. 이 코드를 지원해야합니까? 가까운 시일 내에 얼마나 빨리 일어날 수 있습니까?
3. 이 코드는 작업하기에 충분히 편안합니까? (지금)
4. 내가 수행 한 모든 변경 사항이 안전한지 확인할 수 있습니까? 다른 테스트는 일반적으로이 질문에 대한 답변을 제공합니다.
5. 코드 수정 중에 실수를하면 어떤 결과를 얻을 수 있습니까? 변경 사항을 빠르게 되돌릴 수 있습니까? 시간 낭비일까요?
6. ...

실제로 많은 질문을해야합니다. 전체 및 최종 목록은 없습니다. 당신과 아마 당신의 팀원 만이 답을 찾을 수 있습니다.

추신 : 나는 코드를 자주 다시 쓰는 경향이 있지만 친구와 팀원은 그대로 두는 경향이 있음을 알았습니다. 언급 된 질문에 다르게 답변하기 때문입니다. 그리고 우리는 미래에 대해 예측할 수 없기 때문에 우리가 그들에게 자주 잘못 대답한다고 말해야합니다.

Microsoft가 창을 업데이트해야합니까? 모든 * nix Distros는 계속 발전해야합니까? 아니면 더 실용적인 예가 모두 1970 년대 자동차를 운전하고 있습니까?

일반적으로 두 번째 라운드에서 코드를 더 잘 작성할 수 있습니다. 처음에 도메인을 작성하여 도메인에 대해 더 많이 배웠습니다.

재평가 할 가치가 있는지에 대한 간단한 대답은 없습니다. 일반적으로 a) 좋은 학습 연습이 아니거나 b) 더 나은 코드로 장기적으로 시간을 절약하지 않으면 안됩니다. 모든 변화는 버그의 위험이 있음을 기억하십시오.

참고로 단위 테스트를 강력하게 옹호합니다. 자동 휴식으로 현재의 행동이 명확하게 표시되어 있지 않은 경우, 특히 재조명을 정리하는 것이 매우 쉽습니다.

현재 가능한 최상의 코드를 작성해야 할 책임이 있다고 생각합니다. 그것은 우리가 과거에 배운 모든 것을 사용하고 디자인을 단축하는 것을 거부한다는 것을 의미합니다. 일정 압력으로 인해 무언가가 잘리는 경우, 애니메이션이 적은 작은 종이 클립과 같은 소프트웨어의 품질을 고려해야한다고 생각하지 않습니다 ...

이제 작업 중이고 상호 작용 해야하는 코드가 현재 작성할 수있는 수준까지 작성되지 않은 경우 제어 된 방법으로 코드를 작성할 수 있다면 수정하는 것이 합리적입니다. 나는 개인적으로 이런 종류의 리팩토링에 대해 최소한의 경험을 가지고 있습니다. 모든 사람 (거의 모든 사람)? 나는 "모든 것을 바꾸고 작동하도록기도합시다"라는 전체 시도를했고 그 나쁜 것에 물린 것입니다. 이 문제에 대한 Martin Fowler의 토론 ( 그의 책 이나 많은 기사 중 하나)을 살펴 보는 것이 좋습니다 . 그는 그 과정에 대한 현재의 생각의 대부분을 영감을 얻은 것 같습니다.

물론 때로는 원하는대로 코드를 정리하지 못할 수도 있습니다. Joel Spolsky는 코드를 리팩터링하기 위해 몇 주를 바친 이유에 대한 기사를 썼습니다. 여기를 읽으십시오 . 그렇습니다. 약간 낡았지만 정보는 여전히 관련이 있다고 생각합니다.

나는 그것이 도움이되기를 바랍니다

나는 오래된 코드를 리팩토링 / 개선하면 프로그래머 자신을 정의한다고 생각합니다. 1 년 전에 작성한 코드를 향상시키려는 것은 진행 상황 만 보여 주므로 응용 프로그램을 개선하고 개선 할 수있는 능력, 시간 및 승인이있는 경우 수행하십시오.

더 나은 / 개선 된 것은 다축 비교입니다. 더 빠르고, 작고, 더 효율적이고, 더 읽기 쉽고, 더 유용한 정보, 더 정확한 결과, 더 유연하고, 더 일반적이며, 더 많은 시스템에서 실행할 수 있고, 별도의 제품에 대한 종속성을 제거 할 수 있다고 생각하십니까?

회사에서 새 코드를 작성하거나 다른 코드를 다시 작성하는 대신이 코드를 다시 작성하는 데 시간을 투자해야하는 이유는 무엇입니까?

기회가 제시되면 개선해야하지만 기회는 이미 코드를 작성 중이거나 변경해야 할 비즈니스 이유를 식별했음을 의미합니다.

생산 변경을 추진하면 제로가 아닌 물건을 깰 가능성이 생깁니다 (단위 및 기능 테스트는이 기회를 줄이며 제거하지는 않습니다). 예상 이익이 위험을 능가하는 경우에만 수행해야합니다.

고려해야 할 또 다른 사항은 다음과 같습니다.이 변경 사항을 프로덕션 또는 단순히 개발 지점으로 푸시하려고합니까? 두 시나리오의 막대는 완전히 다릅니다. 그것이 개발 브랜치에서만 진행되고 생산에 들어 가지 않을 수 있다면 기회는 기본적으로 어떤 이유로 코드를보고 있다는 것을 의미하며 시간이 많이 걸리지 않습니다. 푸시가 발생해야하는 경우 필요에 따라 검토 할 수 있으며, 그 시점에 보증되지 않은 것으로 간주되면 제외됩니다 . 반면에 위에서 말했듯이 이제 프로덕션 환경으로 전환하려는 경우 이러한 변경이 비용 가치가 있는지 여부를 고려해야합니다. 푸시에 소요되는 시간과 새로운 코드 사용의 이점 측면에서 말입니다.

경험에 대한 좋은 규칙은 코드가 수행하는 작업을 이해하는 데 시간이 걸리고, 잘 선택된 리팩토링을 통해이 시간을 단축 할 수 있다면 비즈니스 및 팀의 요구를 충족시키는 것입니다. 이 단계를 수행하십시오.

코드가 분석에서 도움이되지 않는 경우, 필드 이름이 코드 의도를 표현하지 못하고 메소드가 읽을 수있는 덩어리로 분류되지 않은 경우 비즈니스는 가치있는 것을 잃어 버렸습니다. Visual Studio 및 ReSharper와 같은 도구를 사용하면 이러한 종류의 리팩토링은 안전하고 논리 중립적이며 향후 개발자 생산성과 자신감에 큰 가치가 있습니다.

밥 마틴 아저씨가 말했듯이 "항상 캠프장을 찾은 것보다 더 깨끗하게 두십시오."

이것은 회사의 경영진에게 물어볼 질문입니다.

돌아가서 이전 코드를 변경하는 데 필요한 시간과 리소스가 있습니까?

품질 보증팀에서 변경 사항을 테스트하여 손상되지 않았는지 확인할 시간과 리소스가 있습니까?

버그를 수정하는 모듈에 들어가기 전에이 함정에 빠졌으며 비효율적이거나 우아하지 않은 코드 나 다른 사람이 작성한 코드를보고 변경 한 다음 방금 수정했을 때보 다 처리해야 할 더 많은 문제가 발생합니다. 내가 고쳐야 할 버그.

따라 다릅니다.

문제의 코드가 실제로 깨져서 불가피하게 한 지점에서 드러날 수있는 버그 (예를 들어, 어떤 지점에서 오버플로되어 불쾌한 문제를 일으킬 수있는 카운터)가 포함 된 경우이를 수정하면 노력할 가치가 있습니다. 새로운 버그를 피하기 위해 가능한 모든 안전 장치를 먼저 설치하십시오. 만지는 모든 것을 포괄하는 의미있는 단위 테스트를 수행하고, 유능한 누군가가 모든 변경 사항을 검토하고 철저히 테스트하고, 이전으로 되돌릴 수 있는지 확인하십시오. 버전은 언제든지 제작에 들어가기 전에 모든 데이터를 백업하고, 수용 환경에 먼저 배포하고 실제 사용자에 의해 테스트되도록하십시오. 또한 버그가 실제로 시한 폭탄 인 경우 계속 진행하기 전에 승인을 받으려고합니다. 귀하의 관리자는 다소 유능합니다.당신은 그 / 그녀가 당신이 그것을 고치도록 설득 할 수있을 것입니다 (그리고 당신이 승인을받지 못하면, 그것은 당신이 틀렸다는 표시 일 것입니다).

OTOH, 불만 사항이 코드 우아함이 부족한 경우 감히 만지지 마십시오. 지금은 프로덕션 환경에서 꽤 오랫동안 충실한 서비스를 해왔으며 코드를 변경하면 만족할 수 있지만 가치를 추가하지는 않으며 모든 변경 사항과 마찬가지로 무언가를 깰 위험이 있습니다. 그렇지 않은 경우에도 귀하의 시간은 소중합니다 (문자 그대로 : 귀하가하는 일에 대해 비용을 지불하므로 매 1 분마다 비용이 소요됨). 실제 가치를 추가하지 않기 때문에 그러한 변화는 회사와 프로젝트에 대한 순 손실.