다른 사람이 리팩토링 문제가 있습니까? [닫은]

상당한 양의 코드를 작성한 후에는 가능한 한 최선의 방법으로하지 않은 것처럼이 불안한 느낌이 들며 계속 리팩토링하고 프로젝트에 너무 많은 시간을 소비하거나 결코 얻지 못하는 것처럼 보입니다. 가끔 했어요 다른 사람에게도 이런 일이 있습니까? 어떻게 처리합니까?

나는 그들이 나에게 일어날 때이 순간을 즐길 수 있습니다.

그 이유 : 내가 일을 되돌아 보지 않고 개발자로서 발전하지 못했을 것보다 더 잘한 일이 있다고 생각한다면. 그러므로 깨달음의 순간이 생길 때 그들을 포용하고 배운 것을 기록하십시오. 현재 프로젝트의 시간표를 고려하고 가능한 경우 코드를 리팩터링하십시오. 가능하지 않은 경우 학습을 수행하여 향후 프로젝트 구현에 사용하십시오.

어느 쪽이든, 자신의 실수에서 배우는 것이 좋습니다!

이 활동을 제한하고 생산성을 높이기위한 몇 가지 규칙이 있습니다.

• 타이머를 25 분으로 설정하십시오.
• 적절한 테스트 범위가있는 경우에만 수행하십시오.
• 다음 몇 가지 기능 개발에 리팩토링을 유용하게 사용하십시오.

항상 리팩터링 할 수있는 것처럼 보이지 않습니까? 다른 문제를 해결하려고 할 때만 리팩토링을 제한하려고합니다. 예를 들어, 성능 문제가있는 경우 리팩토링하고이를 해결하는 데 도움이되는 리팩토링-새 기능을 추가해야하는 경우 리팩토링하면 리팩터링이이를 해결하는 데 도움이됩니다.

솔직히 말해서, 당신이 엄청난 양의 코드를 찾고 있고 그것이 완벽하고 리팩토링이 필요하지 않다고 생각한다면 더 걱정할 것입니다 ...

젊고 경험이 부족할 때, 나는 프로그래밍 능력에 대해 매우 오만했으며, 항상 실제로 디자인하고 계획하는 것이 가능하다는 것을 상상하는 경향이 있었고, 일단 구현 단계에 도달하면 그냥 빠져 나올 것입니다. ' 모든 것이 완벽 할 것입니다.

현실은 거의 반대입니다. 일부는 코딩을 시작하자마자 유지 보수 모드에 있어야한다고 말합니다. 여기서 아이디어는 SDLC의 "구현"단계가 실제로 존재하지 않는다는 것입니다. 버그 수정이나 리팩토링을 제쳐두고 제작하는 코드가 "신선하고"완벽하다고 가정해서는 안되기 때문입니다.

말했다 모두, 나는 가정 입니다 리팩토링에 대해 너무 강박 관념에 사로 잡힌 얻을 수. 나는 아직 그것을 보지 못했다. 경험이 많을수록 더 많은 소프트웨어 팀이 특허 마감일을 지키지 않고 기술 부채에 들어가기를 거부하면 좋은 일이라고 생각합니다. 결국 이것이 리팩토링이 현실 세계에서 제외되는 가장 일반적인 이유입니다.

느낌이나 코드 냄새에 전적으로 의존하지 말 것을 제안합니다.

코드의 문제점과 솔루션의 문제점을 명확하게 열거하십시오. 당신의 리 팩터가 이것에 얼마나 효과적인지 검토하고 싶기 때문에 진지하게 적어 두십시오.

리팩터링을 달성 가능한 덩어리로 분류하고 우선 순위를 정하는 방법을 식별하십시오. 각 청크의 범위에만 초점을 맞추고, 작업을 방해 할 수있는 접선을 피하도록 훈련하십시오.

또한 진행하기 전에 기존 코드에 대해 작성할 수있는 단위 테스트를 식별하십시오. 이미 광범위한 테스트가 있다면 좋은 것입니다. 단위 테스트의 부족은 일부를 만들 수있는 좋은 기회입니다.

내가이 함정에 빠지는 것은 의심의 여지가 없지만, 향후 지원 / 디버깅에는 일부 리팩토링이 중요합니다.

주요 코드를 작성할 때 코드 행을 통해 현재 작성중인 메소드에 쉽게 보관할 수 있습니다. 주요 코드를 완성하면 할 일 : 코드 검토 주석이 있습니다. 그런 다음 며칠 후에 코드 검토를 수행하고 그에 따라 리팩터링합니다. 며칠 후에 읽지 못하는 경우 몇 개월 또는 몇 년 내에 무슨 일이 일어날 지.

언어 나 기술을 처음 배울 때이 함정에 빠지게됩니다. 예를 들어, 처음 Java를 배울 때 서블릿을 사용하여 웹 앱을 작성한다고 생각하면 올바른 방법이라고 생각합니다. 그런 다음 jsp가 있다는 것을 깨닫고 아마도 그것이 더 최신이라고 생각합니다. 그런 다음 반쯤되면 Struts와 EJB 항목을 찾은 다음 스프링 (xml 기반)을 찾은 후 멋진 @MVC 주석을 찾은 다음 너무 자세하고 부패합니다. 그루비 / 그레 일과 스칼라 / 리프트 중 선택! 요점은 대개 배우고 마감일을 맞추지 않아도되기 때문에 개인 프로젝트에는 완벽하게 적합합니다.

나는 또한 직장에서 우버 리 팩터로 사용되었습니다. 그러나 더 많은 경험을 쌓으면서 리팩토링 할 내용에 대해 더 선택적으로되었습니다. 회사를 떠날 때 코드를 가져 가지 않으며 일반적으로 다른 엔지니어가 코드를 수정하는 것보다 거의 빨리 코드를 망칠 수 있습니다.

내가 따르는 경험의 규칙은 다음과 같습니다. 당시 최적화 될 때까지 리팩토링 한 다음 상황이 바뀌지 않는 한 다시 리팩터링하지 않거나 더 새롭고 더 나은 방법에 대한 영감을 얻는 경우가 더 적습니다. 새로운 언어 기능을 사용하여 작업을 수행하십시오.

예를 들어, 기존 애플리케이션을위한 새로운 코드 모듈을 작성해야했습니다. 나는 그것을 특정한 방식으로 썼고, 다음날 나는 그것을 더 많이 생각하고 그것을 리팩토링하고 다른 용도로 사용하기 위해 길을 뻗을 필요가 있다고 확신했기 때문에 그것을 리팩토링하고 더 추상적으로 만들 수 있다고 생각했다. 그래서 코드를 리팩터링했습니다. 그런 다음 나는 그것이 너무 일반적인 것이라고 결정 하고 같은 기능을 얻기 위해 Generics (C #)를 사용하여 기본적으로 같은 일을하고있는 클래스와 인터페이스를 통합했습니다. 이 시점에서 나는 아마 수더 리팩토링하여 더 좋게 만들지 만 "충분히"충분합니다. 코드는 잘 작성되어 있고 적절한 디자인 패턴과 엔지니어링 개념을 따르며 확장 가능합니다. 요구 사항으로 인해 코드를 다시 평가해야하거나 코드를 더 명확하고 읽기 쉽게 만들 수있는 언어 기능이있는 경우에만 다시 리팩터링합니다.