더티 코드에 대해 몇 가지 질문하고 싶습니다. 중간 규모의 프로젝트를 코딩 한 초보자가 있습니다. 코드는 매우 거대한 진흙 공입니다. 그들은 고급 프로그래머가 아닙니다. 그들은 키보드를 Java에 대해 조금 사용하는 방법을 알고 있습니다. 그들은 메인 클래스에 12 000 라인의 코드를 작성했지만 6 000 라인은 NetBeans 자체에 속합니다.

내 직업은 코드를 분석하고 코드를 유지하는 좋은 방법을 제안하는 것입니다. 내 생각은 프로젝트를 폐기하고 OOP 방법론으로 새로운 프로젝트를 시작하는 것입니다. 최근이 사이트와 다른 사이트에서 문제에 대한 메모와 아이디어를 수집했습니다.

이제 다음과 같은 질문이 있습니다.

1. 코드를 수리하고 OOP로 변경해야합니까? 이제 디버깅 중입니다.
2. 이 코드에는 주석, 설명서, 특정 프로그래밍 스타일 등이 없습니다. 그것을 바꾸는 것은 정말 비싸고 시간이 많이 걸립니다. 우리는 이것에 대해 무엇을 할 수 있습니까?
3. 모든 규칙 (코멘트, OOP, 좋은 코드 품질 등)을 따르도록 어떻게 가르 칠 수 있습니까?
4. 코드가 잘못되어 오류가 발생하기 쉽습니다. 우리는 무엇을 할 수 있습니까? 테스트? 우리는 수정을 위해 거의 두세 개의 A4 논문을 썼지 만 끝이없는 것 같습니다.

나는 그들과 새로운 것을 말해야한다. 나는 사람들을 프로젝트에 너무 늦게 추가하는 규칙을 어겼다 고 생각합니다. 내가 그들을 떠나야한다고 생각합니까?

0 단계 : SCM으로 백업

주석에서 JBRWilkinson이 암시 한 것처럼 버전 제어 는 (돌이킬 수없는) 재해에 대한 첫 번째 방어선이기 때문입니다.

소프트웨어 구성 세부 사항, 결과물 작성 절차 등도 백업하십시오.

1 단계 : 먼저 테스트

그런 다음 테스트 를 작성 하여 시작하십시오 .

• 작동하는 방식으로
• 그리고 무엇이 실패했는지.

당신이 무엇을하기로 결정하든, 당신은 보장됩니다. 이제 다음 중 하나를 수행 할 수 있습니다.

• 시작 처음부터 와 다시 쓰기 ,
• 또는 수정 하십시오.

내 충고는 일반적인 아키텍처를 처음부터 시작하는 것이지만 체크 포인트를 확인하는 부분을 엉망에서 추출 하고 적절하다고 생각하는 부분을 리팩터링하는 것이 좋습니다.

2 단계 : 확인 및 모니터링

셋업 지속적인 통합 (편안 시스템 스텝 0 및 1 단계 AND a) 연속 검사 시스템 (위한 준비 단계 4 ).

3 단계 : 거인의 어깨에 서서

(항상해야 할 것처럼 ...)

• 패턴으로 리팩토링
• 리팩토링 : 기존 코드의 디자인 개선 .
• 레거시 코드를 효과적으로 사용 ( Jason Baker가 권장 한대로)
• 리팩토링

4 단계 : 청소

이런 종류의 말은 말할 것도 없지만 코드 자체를 감추는 대신 깨진 코드베이스에서 린터 / 정적 분석기 및 기타 도구를 실행하여 디자인 및 구현에서 오류를 찾을 수 있습니다.

그런 다음 코드 포맷터를 실행하여 하우스 키핑에 약간 도움이 될 수도 있습니다.

5 단계 : 검토

리팩토링 또는 정리 를 통해 작은 버그를 쉽게 도입 할 수 있습니다. 키를 잘못 선택하고 빠르게 누르기 만하면 처음에는 깨닫지 않고 상당히 중요한 것을 삭제할 수 있습니다. 때로는 효과가 몇 달 후에 나타납니다. 물론, 위의 단계는 (특히 강력한 테스트 하네스를 구현하여)이를 피하는 데 도움이되지만 빠져 나갈 수있는 것이 무엇인지 알 수 없습니다. 따라서 리팩토링은 적어도 하나의 다른 전용 안구 (그리고 바람직하게는 그 이상)에 의해 검토되어야합니다.

6 단계 : 미래의 개발 프로세스 증명

위의 모든 사항을 고려하여 일반적인 개발 프로세스의 본질적인 부분으로 지정하십시오 (아직 그렇지 않은 경우). 시계에서 이러한 일이 다시 발생하지 않도록하고 팀과 협력하여 프로세스에서 보호 기능을 구현하고 가능하면 정책에서이를 시행하십시오. Clean Code 생성을 최우선으로하십시오.

그러나 실제로 테스트하십시오 . 많이 .

개인적으로, 레거시 코드로 효과적으로 작업하기 편리한 사본을 얻을 때까지이 프로젝트를 시작하지 않았습니다 . 진지하게, 그것은 정확하게 이런 종류의 것을 위해 쓰여졌습니다. 까다로운 코드를 다루기위한 전략으로 가득 차 있으며 여기서 내가 제공 할 수있는 것보다 훨씬 자세하게 설명합니다.

나는 여러 번 거기에 있었다. 내 규칙은 : 소프트웨어가 사소하지 않고 (귀하의 리소스에 대해 일주일 이상 일한 경우) 작동하는 경우 소프트웨어를 유지하고 증분 리팩토링을 진행하십시오.

소프트웨어가 실제로 작동하지 않으면 (매우 많은 수의 버그, 불명확 한 요구 사항 등) 처음부터 다시 작성하는 것이 좋습니다. 아주 작은 경우에도 마찬가지입니다.

Fowler 's book과 Kerievsky의 http://www.industriallogic.com/xp/refactoring/ 에서와 같이 리팩토링의 요점 은 시스템 작동을 유지하는 것입니다. 리팩토링에는 두 배의 시간이 걸리지 만 위험은 0입니다.

처음부터 다시 작성하는 것은 오해 요구 사항에서 잘못된 구현에 이르기까지 많은 위험을 초래할 수 있습니다 (모든 팀이 동일하게 된 후).

실제로 복잡한 절차가 처음부터 두 번 다시 작성되었지만 여전히 예상대로 작동하지 않는 것을 보았습니다.

나는 그것을 완전히 다시 쓸 것입니다. 때로는 그러한 코드를 복구하는 것이 불가능합니다. 또 다른 옵션은 새로운 기능을 추가하지 않고 작동시키는 것입니다. 팀에게 좋은 코드 (잘 설계되고 문서화되고 테스트와 함께)를 작성하도록 지시하려면 현재 코드를 수정하도록하십시오. 모든 사람이 버그를 수정하고 다른 개발자의 코드가 아닌 다른 개발자의 코드를 검토하도록하십시오. 일부 시도 후에는 그러한 코드를 검토 / 수정하는 것이 거의 불가능하다는 것을 이해할 것입니다.

늦은 프로젝트에 사람들을 추가하는 것은 매우 드물게 도움이됩니다. 보통 마감일이 지났습니다. 프로젝트를 성공적으로 마치기 위해 최선을 다하고 떠나는 것에 대해 생각해야합니다.

내 충고는 전체 코드를 완전히 긁지 않는 것입니다. 이것은 모든 개발 팀이 직면 한 일상 생활 문제입니다. 한 번에 코드의 한 부분을 공격하십시오. 고치고 청소하고 문서화하십시오. 그런 다음 다른 부분으로 이동하십시오. 가장 중요한 것은 항상 선적 가능한 코드를 유지하는 것입니다. 처음부터 전체 코드를 다시 작성하는 데는 지금까지 소요 된 시간이 걸리며 현재보다 더 나은지 보장 할 수 없습니다.
그러나 사람들은 이런 방식으로 코드를 작성하지 않아야합니다. 코드 검토에서 더 많은 시간을 보내십시오. 일정한 코딩 스타일에 적응하십시오. 먼저 디자인을 논의한 다음 코드를 작성하십시오. 그러한 간단한 것들이 큰 변화를 가져올 것입니다.

Netscape가 느슨한 이유를 알려주는 좋은 블로그

작동하면 리팩터링하십시오. 그렇게하는 데 도움이되는 도구가 있습니다. 작동하지 않으면 마법 코드 개선 명령 (예 : deltreeWindows resp)을 사용하십시오. rm -rf리눅스에서.

코드를 수리하고 OOP로 변경해야합니까? 이제 디버깅 중입니다. [... 오류가없고 문서화가 없습니다 ...]

나는 거기에 있었고, 당신은 내 동정심을 가지고 있습니다. 나는 심지어 당신이 약간의 관점을 얻는 데 도움이 될 수 있는 기사 를 썼습니다 . 그러나 간단히 말하면 :

코드 에 중복 이 많이 포함되어 있으면 다시 작성해야합니다. 식별 가능한 구조가없는 경우 (명확한 인터페이스, 스파게티 없음) 리팩토링이 실패하고 다시 작성해야합니다.

모든 규칙을 따르도록 어떻게 가르 칠 수 있습니까?

그들이 개인적으로 얻을 수있는 것을 보여줌으로써 왜 그렇게하고 싶어하는지 설명하는 것으로 시작하십시오. 그들이 이것에 동의하고 배우고 자한다면, shuhari를 사용하여 가르치기 시작 하십시오 .

내 제안은 @duros와 @Manoj R의 답변을 조합 한 것입니다.

처음부터 좋은 코드 / OOP / 설명 / 등을 작성하는 것을 염두에두고 처음부터 시작하십시오. 이전 코드에서 참조 / 복사 및 붙여 넣기를 수행하십시오. 이전 코드의 나쁜 부분을 만나면 다시 작성 / 리 팩터하십시오.

개발자가 잘 훈련되지 않은 경우 코스를 보내면 좋을 것 같습니다. 빠르게 변화하는 IT 산업에서 정기적 인 재교육에 중요