코드 정리를 위해 정기적 인 시간을 예약하는 것이 좋습니까? [닫은]

소규모 개발자 팀을 관리하고 있습니다. 우리는 종종 코드를 정리하기 위해 하루나 이틀을 소비하기로 결정합니다.

코드베이스를 정리하기 위해 2 개월마다 1 주일을 정기적으로 예약하는 것이 좋을까요?

아니.

작업하는 동안 수정하십시오.

• 작업중인 비트를 리팩토링하기 위해 기다리는 경우, 많은 정보를 잊어 버리고 다시 익숙해지기 위해 시간을 소비해야합니다.
• 요구 사항이 변경되어 사용되지 않는 "골드 도금"코드를 만들지 않습니다.

내 개인적인 의견 : 프로젝트의 90 %가 절대적으로 필요 합니다.

특히 판매에 크게 의존하는 프로젝트의 경우 일반적으로 모든 릴리스에 새로운 기능을 포함시키는 데 큰 관심이 있으며 필연적으로 더 나은 본능을 손상시키고 여기저기서 몇 가지 kludges / hacks를 도입해야합니다.

결국 이러한 작은 타협을 통해 충분한 '기술 부채'가 발생하여 코드베이스의 결함을 해결하는 데 상당한 시간을 소비하게되며 그 잠재력을 최대한 활용할 수 없게됩니다.

일반적으로 이런 방식으로 생성되는 두 가지 유형의 문제가 있습니다.

• 쉽게 고칠 수 있지만 체계적 일 수있는 작은 것 (예 : 부적절하게 명명 된 매개 변수, 불완전한 오류 처리 등)은 일반적으로 코드 블록 외부에 거의 영향을 미치지 않습니다. 이것들을 다루는 가장 좋은 방법은 코드 검토 및 코드가 작성 / 수정 될 때 코드를 확인하는 것입니다. 다른 사람들이 언급했듯이 이러한 오류를 해결하기 위해 특별한 리 팩터 사이클을 따로 따로 설정할 필요가 없습니다.
• 불완전한 사양이나 초기에 잘못된 설계 결정으로 인해 발생했을 수도 있고 두 명의 개발자 / 팀이 동일한 문제에 대해 서로 다른 두 가지 솔루션을 만들었을 수도 있습니다. 이것들은 일반적으로 수정하기가 훨씬 어렵고 수정하기 위해 공동의 노력이 필요합니다. 결과적으로 그들은 영원한 성가심이 될 때까지 보통 연기됩니다. 이러한 종류의 문제를 해결하려면 전용 시간이 필요합니다.

나는 일반적으로 3-4주기마다 순수한 리팩토링 / 버그 수정주기를위한 시간을 예약하려고합니다. 나는 항상 개발자들에게 코드베이스에 좌절감을 느끼면 말해달라고 요청한다. 모든 개발자가 정리 작업을 수행해야하는 것은 아닙니다. 일반적으로 팀을 조금씩 엇갈리게 할 수 있으므로 항상 한 팀만 정리 작업을 수행하고 있습니다.

개발자가 체크인 (Subversion)하거나 주 개발 지점 (Git)과 병합하기 전에 코드를 정돈해야합니다.

나는 그들에게 다음과 같은 일을한다.

• 관련없는 댓글 제거
• 메소드, 인수 및 변수의 이름이 적절하게 지정되어 있는지 확인하십시오.
• 클래스에 구조가 있는지 확인하고 아이템을 그대로 캡슐화하십시오.
• 가독성을 높이고 코드 냄새 를 줄이기위한 리팩터링

대규모 프로젝트의 경우 개발 지점에서 기본 지점으로 병합하기 전에 코드를 공식적으로 검토합니다.

"시간을 바치다"는 것은 관련된 작업의 양으로 인해 연기되거나 연기 될 수있는 무언가를 의미한다고 생각합니다. 개발자가 체크인마다 (JIRA의 변경 요청 / 문제와 동일) 수행하도록하면 훨씬 더 관리하기 쉽습니다.

내 의견으로는 아닙니다. 기술 부채가 발생했을 때와 문제를 해결할 때 너무 많은 시간이 걸리면 문제가 무엇인지에 대한 맥락을 잃게됩니다. 수정하는 데 시간이 오래 걸리고 수정되는 경향이 있습니다. 가장 중요한 것은 사람들이 깨진 창문을 "주일 청소"가 아니기 때문에 떠난 것입니다.

개인적으로, 나는 스프린트에서 일부를 생성했다는 것을 알면 스프린트마다 기술 부채 정리를 협상합니다. 그것은 사람들의 마음에 부채를 신선하게 유지합니다. 리팩토링이 더 쉬워 지도록 문제 코드를 사용하여 코드의 양을 제한합니다. 기술 부채가 쌓이는 것을 방지합니다. 또한 개발자가 다음 스프린트에서 바로 수행하게하기 때문에 개발자가 무언가를 함께 때리는 일을 막을 수 있습니다.

나는 단 한 번도, 바람직하게는 주 단위로 행해져 야한다. 예정된 정기 코드 검토와 실제로 코드 검토에서 나오는 항목에 대한 조치가 매우 신속하게 이루어집니다. pswg의 답변보기

2 개월마다 1 주일이면 충분하지 않습니다. 이것은 귀하의 질문에 '아니오'로 응답 한 다른 답변들 대부분을 말합니다. 이 답변의 요점은 너무 오래 기다리면 더 이상 코드와 접촉하지 않으며 일반적으로 수정 / 정리 / 리팩터링하는 데 훨씬 오래 걸립니다.

코드 정리 작업을 한 번 더 추가해야한다면 분명하지 않습니다. 그런 의미에서 그렇습니다. 우리가 따르는 관행에 따라, 약간의 저하가 항상 발생합니다.

우선 SOLID 원칙 적용, 관련 단위 테스트, 검사 등 올바른 일을하지 않기위한 변명으로 사용해서는 안됩니다.

나는 현재 인기있는 "아니오" "예"라는 두 가지 대답이 동일한 진실의 두 가지 측면이라고 생각합니다. OP는 개인이 아닌 자신이 관리하는 그룹에 대해 이야기하고 있음을 기억하십시오. 그룹의 모든 개발자가 깨끗하고 쉽게 읽을 수있는 코드를 작성할 수있을만큼 잘 훈련되어 있다고 가정 할 수는 없습니다. 그리고 외부 압력과 민첩한 방법론의 문제가 있습니다. 또한 사람들의 최선의 노력에도 불구하고 스타일의 차이는 떨어져있을 때 깨끗하다고 ​​생각되지만 다른 사람들과 함께 고려할 때 부정확 한 인터페이스는 말할 것도없이 코드를 작성할 수 있음을 의미합니다.

다른 한편으로, "작업하는 동안 고치십시오"는 필자가 생각하기에 이상적입니다. 다음과 같은 방법으로 코드를 더욱 "고정"시킬 수 있습니다.

• 신중한 동료 CRing
• 코드 자체와 함께 단위 테스트 작성
• 코딩 지침 채택
• 자동 포맷터 및 린터 (YMMV) 사용
• 기타

이제 OP 팀이 위의 사항을 채택하고 코드 검토 및주기적인 코드 정리 세션과 같은 부하 직원을 격려하면 함정을 예측하고 추악함을 미리 피하려고 노력할 것입니다. 청소 시간. 그런 다음 문서 작성, 리팩토링 및 작성하고 통합 한 내용에 대한 지식 공유에 그 시간을 투자 할 수있었습니다.

정기적 인 폭포 스타일 프로젝트의 작업이든, 민첩한 스토리의 작업이든 정기적 인 시간을 예약하는 것이 매우 좋습니다. 정해진 시간을 갖는 것이 일정대로 작업하는 것만 큼 가치가 없을 수도 있습니다. 이를 통해 프로젝트에 뒤쳐져 있기 때문에 일정의 일부로 정리 일을 취소 할 수 있습니다.

엄청난 양의 코드 부채가있는 프로젝트를 관리 한 후 정기적으로 작업하는 것이 일을 원활하게하는 핵심이었습니다. 우리 물건 중 일부는 크고, 일부는 작았습니다.

이런 종류의 작업을 몇 개월 동안 수행 한 후 운영 팀장은 모든 것이 얼마나 원활하게 진행되고 있는지 알려주었습니다.

각 항목은 많이 보이지는 않지만 모든 부채처럼 광고가 게재됩니다.

이상적인 대답은 아니오입니다.이를 필수로하지 않기 위해 필요한 단계를 수행하기 때문입니다 (이미 언급 한 여러 가지 이유로 진행하면서 정리).

이것은 결국 목표 일지 모르지만, 실무에서 멀리 떨어진 팀이있을 수 있습니다.

관리자는 약간의 책임을 져야합니다 그것은 항상 개발자의 잘못이 아닙니다. 관리자는 한 가지만 말할 수 있지만 프로젝트를 끝내고 나쁜 관행을 조장하는 제안을 강요하기 시작합니다. 그들은 문자 그대로 "나중에 정리할 것"이라고 말하거나 효과가 있다면 충분합니다.

이것이 중요하다는 것을 보여주기 위해 특정 시간을 바치는 것으로 시작해야 할 수도 있습니다. 팀이 코드를 정리할 수 있다는 것을 알고 있다면 (제공되지 않음) 더 자주 통합 할 수 있습니다.

결국에는 시간을 설정하지 않아도됩니다.

개인적으로, 나는 새로운 문제를 해결하고 일을 깔끔하게 유지하려고 노력하면서 어려움을 겪고 있습니다. 나는 점점 나아지고 있지만 종종 의도적으로 휴식을 취하고 물건을 정리합니다. 저에게는 다른 사고 방식입니다. 결국, 견고한 실천은 습관이됩니다.

아니요, 코딩하는 동안이 작업을 수행해야합니다. TDD를 사용하는 경우이를 리팩토링이라고합니다. 한두 달 동안 코드를 수정하고 정리할 때 문제는 코드의 모든 부분을 기억하지 못하기 때문에 코드 동작을 변경할 수 있다는 것입니다.

먼저 코딩을 기반으로 리팩토링을 수행하여 무언가를 작동시키는 데 필요한 코드를 제안하고 작동하자마자 재 설계하고 최적화하여 예쁘게 만듭니다.