앱 완성 리팩터링 또는 집중

진행하면서 앱을 리팩터링하거나 먼저 앱 완성에 집중 하시겠습니까? 리팩토링은 앱 앱의 진행이 느려지는 것을 의미합니다.

앱을 완성하면 나중에 앱을 유지 관리하기가 매우 어려워 질 것입니까?

이 앱은 개인 프로젝트입니다. "기능과 디자인을 주도하는 요소"에 어떻게 대답해야할지 모르겠지만 현재 소프트웨어의 비 효율성을 해결해야한다고 생각합니다. 나는 사용하기 쉬운 소프트웨어도 최소한으로 좋아합니다. 그래서 일부 기능을 제거하고 도움이 될만한 기능을 추가합니다.

작동하게 만들다. 그럼 빨리 해 마지막으로, 아름답게 만드십시오.

인터페이스를 사용하여 코드 (프레젠테이션, 비즈니스 및 데이터 계층)를 잘 분리하고 모 놀리 식 디자인이 아닌 경우 리팩토링이 그렇게 어렵지 않아야합니다.

리팩토링에 어려움을 겪고 있다면 아마도 코드 냄새 일 것입니다. 고체 원리 를 살펴 보는 것이 좋습니다.

인터페이스를 깨끗하게 유지 하는 것이 핵심이라고 생각합니다 . 모듈 / 클래스 /간에 구현이 무엇이든간에 통신 레이어가 제정신이라면 언제든지 리팩터링하거나 모듈 / 클래스 / 다시 구현할 수 있습니다. 나중에 변경하기 쉬운 것과 그렇지 않은 것을 알아내는 데 시간을 보내십시오. 후자를 올바르게 만드십시오.

이것은 TDD의 정신과 일치합니다. 좋은 테스트를 작성하려면 테스트 할 인터페이스가 필요합니다. 나중에 개선 할 수 있기 때문에 현재 장면 뒤에서 지저분 해지는 것이 그렇게 중요하지 않습니다.

나는 특히 TDD를 사용하여 갈 때마다 항상 리팩터링합니다.

1. 테스트 작성

2. 테스트 통과

3. 리 팩터

이를 통해 완성 된 제품에 대한 버그를 줄이고 코드를 개선 할 수 있습니다. 또한 완료 할 때 유지 관리해야 할 코드가 줄어 듭니다.

자주 그리고 자주 리팩토링하십시오! 당신이 그것을하지 않는 "저장"시간은 다음 기능을 해킹하려고 시도하고 지나치게 복잡하거나 혼란스러운 코드에서 버그를 검색하는 데 많은 시간을 소비합니다.

리팩토링은 방을 들어 올리는 것과 같습니다.

깔끔하게 정리하면 알고리즘 전문가 측면에서 코드에 대해 수행하는 생산적인 작업량에 비례하는 선형 오버 헤드가 발생합니다. 10 %의 시간을 리팩토링 (또는 방을 깔끔하게 유지)하는 데 10 %가 주어진다고 가정하면 시간이 지남에 따라 일정하게 유지됩니다.

그러나 더러운 옷을 모퉁이에 버리고 계속 계속하면 방을 줍는 데 소요되는 시간이 더 복잡해집니다. 각각의 더러운 세탁물 조각이 필요한 청소 시간에 기하 급수적으로 기여한다고 가정하면, 이제 O (e ⁿ ) 상황입니다.

알고리즘 복잡성의 개념을 파고 들어 본 사람이라면 어딘가에 손익분기 점이 있다는 것을 알 수있을 것입니다. 즉, 최적의 더러운 세탁물이 쌓일 것입니다. 그 정도는 big-O 표기법에서 버려지는 상수 요소에 따라 다릅니다. 또 다른 요인은 시간이 지남에 따른 일의 가치입니다. 지금 일할 가치가 있지만 다음 주에 값이 싸면 (즉, 이번 프로젝트 마감일이 3 일 이상이지만 그 이후에는 대부분 유휴 상태입니다 ), 방정식은 리팩토링을하지 않는 것으로 판명 될 수 있습니다.

그리고 복잡한 임계 질량이 있습니다. 어느 시점에서, 엉망 (당신이 원한다면 '중요 엉망')이 너무 나빠서 방 전체를 태우고 새 옷을 사는 것이 더 쉬워 보입니다. 실제로는 그렇지 않지만 실제로는 그렇게 나타나고 심리적 효과로 인해 문제를 해결하기가 10 배 더 어려워집니다.

분명히, 이미 여러 개의 중복 중복 엉망인 프로젝트를 시작하면 선택의 여지가 없습니다.

TL; DR : 의심스러운 경우 리팩터링하십시오. 하지 않기로 결정하기 전에 실제로 좋은 증거가 있어야합니다.

원하는 위치에 영업 / 고객 만족을 얻기 위해 기능을 추가하거나 버그를 부술 수있는 기회가 있다면 그렇게하십시오. 새로운 요구가 줄어들면 리팩토링과 균형을 맞출 수 있습니다. 어떤 시점에서 사람들이 원하는 코드를 작성하고 있는지 확인해야합니다. 모든 것이 똑같습니다 .1000보다 100 시간 코드를 버리고 싶습니다. 아무도 원하지 않으면 할 것입니다.

당신이 어디에 있는지에 따라 달라집니다!

고려해야 할 다른 것들 :

기능 설계가 제대로되어 있습니까? 사용자 피드백을받은 후 다시 디자인 할 수 있습니까?

다시 쓰는 것보다 릴리스하는 것을 선호합니다. 기능적 디자인을 완성한 후에 최적화하십시오.

언제 까지나 당신이로 확인 당신은 당신이 당신이 원하는 모든 리팩토링 수있는 기한을 만날 수 있습니다. 그러나 약간의 불확실성이 있어도 개발을 고수하는 것이 좋으며, 적당한 증분 단계에서만 리팩토링 할 수 있습니다.

리팩토링하려는 잘못된 디자인이 실제로 당신을 해칠 경우, 더 많은 코드를 작성하는 것보다 지금 수정하는 것이 좋습니다. 나중에 리팩토링하는 것이 더 어렵고 비용이 많이 듭니다. 더 이상 할 수 없을 가능성이 있습니다.

반면에, 당신의 유일한 문제가 추악함이라면, 소프트웨어를 먼저 완성해야 할 것 입니다.

신청서를 작성하는 과정에서 리팩토링이 매우 중요합니다.

+ VES

1. 명확한 흐름 : 리팩토링은 코드가 구조화되지 않은 경우 때때로 일정 시간 이 지나면 코드의 흐름을 이해 하고 리팩토링 코드가 오르막 작업이되고 버그가 발생할 수 있기 때문에 코드의 명확성을 제공합니다 .

2. 성능 향상 : 응용 프로그램을 올바르게 리팩토링하면 응용 프로그램 성능을 향상시키는 데 확실히 도움이 됩니다.

3. 유지 관리 : 마지막 으로, 장기적 으로 유지 관리 가 더 쉬울 것 입니다.

-VE

1. 소비 시간 : 진행의 모든 ​​단계에서 훨씬 더 많은 시간이 소요됩니다. 따라서 완료 가 지연 될 수 있습니다 .

결론

프로젝트 유형에 따라 현재 상황에서 요구 되는 코드 품질 또는 완료를 우선 순위로 지정할 수 있습니다 .

개인적인 경험을 바탕으로 보통 마감일이 다가온 상태에서 앱을 먼저 마무리하려고합니다. 완료하면 리팩토링 할 수 있습니다.

완료하고 리팩토링하십시오. 그러나 마감 시간이나 마감 시간이없는 경우 리팩토링을 사용하는 것이 좋습니다.