유지 관리 문제가있는 프로젝트에서 새로운 팀 리더로해야 할 일은 무엇입니까?

유지 관리 문제가있는 코드 프로젝트를 방금 맡았습니다. 프로젝트를 안정적으로 시작하려면 어떻게해야합니까?

단위 테스트, IOC, MEF, 너무 많은 정적 클래스, 순수한 데이터 세트 등과 같은 중요한 것들이 많이없는 매우 큰 멀티 티어 .NET 시스템으로 작업하고있는 곳에서 나 자신을 찾습니다. 24 살이지만 거의 3 년 동안 이곳에있었습니다 (이 앱은 5 년 동안 개발되었습니다). 대부분 시간 제약 때문에 다른 쓰레기에 맞추기 위해 더 많은 쓰레기를 추가했습니다. 여가 시간에 여러 프로젝트를 수행 한 후, 나는 그 모든 개념이 얼마나 중요한지 이해하기 시작했습니다. 또한 직원 이동으로 인해이 프로젝트의 팀 리더가되고 자신을 발견 하고이 앱을 향상시킬 수있는 현명한 방법을 찾고 싶습니다. 경영진에게 가치를 설명 할 수있는 방법. 나는 내가하고 싶은 일에 대한 아이디어가 있지만 많은 선행 이익없이 너무 압도적 인 것처럼 보입니다. 사람들이이 문제를 어떻게 처리했거나 처리했는지에 대한 이야기는 매우 흥미로울 것입니다. 감사.

기술 부채를 공격하기위한 예산 시간. 당신은 그것을해야합니다. 가장 먼저 공격하는 부분은 개발자가 현재 가장 많은 시간을 소비하는 위치에 따라 다르지만 시작한 다음 이상적인 일을 시작하는 것이 더 중요합니다. Scrum을 사용하는 경우 특정 기술 부채를 백 로그에 넣고 처리 할 때까지이를 기능처럼 취급하십시오.

레거시 코드를 효과적으로 사용 하는 것이 좋습니다. 유용 할 것입니다. 나는 그것을 읽지 못했지만 단위 테스트를 레거시 코드로 가져 오는 방법에 대한 많은 정보가 있으므로 수정하고 안전하게 최신 상태로 유지할 수 있습니다.

경영진과 신용 카드 비유를 함께 사용하십시오. 무엇이든하기 란 어렵 기 때문에 모든 일에 "이자를 지불"하고 있습니다. 기술 부채를 상환하면 해당 자원을 확보하고 향후 새로운 기능을보다 신속하게 개발할 수 있습니다. 그렇지 않으면 "이자 지불"(개발 시간에 지불)이 계속 누적되어 팀이 새로운 기능을 느리게 생성합니다.

어쩌면 이미 축적 된 금액에 대한 아이디어를주기 위해 기술 부채에 대해 어려움을 겪고있는 각주기를 소비하는 시간을 추정 할 수 있습니다. 유지 관리 가능한 시스템에서 수정 사항 또는 기능 변경이 어떻게 보이는지, 실제 시스템에서 어떻게 보이는지, 그리고 어떤 변경 사항이 필요하거나 거기에 가기위한 첫 단계가 될 수 있는지 설명하십시오.

기술 부채를 버그 수정 및 추가 기능으로 롤백하십시오.

개선에 대한 반복적 인 접근 방식으로 최상의 결과를 얻을 수 있습니다. 내 작업의 만트라는 코드를 만질 때마다 코드의 품질을 향상시키는 것입니다. 버그 수정이든 기능이든 각 작업은 수정 / 리팩터링 / 정리할 수있는 대상에 대한 분석부터 시작합니다. 우리는 완료해야 할 작업에 대해 규모에 맞게 리팩토링을 시도합니다.

코드베이스에서 문제의 순서가 지정된 목록을 작성하십시오. 모든 사람이 목록과 우선 순위를 알고 있는지 확인하십시오. 그들이 한 작품을 얻을 때마다 그들은 당신이 작업 할 코드와 관련된 목록에서 문제를 찾아야합니다.

모든 것을 고치지는 않습니다. 많은 시간과 자원이 필요한 일부 리 팩터 또는 수정 사항이 있습니다. 나는 일반적으로 그것들을 유익한 다른 큰 일들에 묶으려고 노력합니다.

나는 단지 명백한 것을 진술하고 있을지도 모른다. 그러나 이봐.

문제가있는 코드 덩어리를 실행하는 작은 단위 테스트를 작성한 다음 해당 덩어리를 리팩터링하여 테스트가 여전히 통과하는지 확인하십시오. 방금 지은 단단한 땅의 작은 부분에서 가장 쉽게 도달 할 수있는 또 다른 코드 덩어리로 이동하십시오. 오히려 헹구고 반복하십시오.

또한 코드베이스에 좀 더 익숙해지는 데 도움이됩니다.

잠시 동안이 작업을 수행 한 후 좀 더 확장 된 리팩토링을 수행 할 때가되었다는 것을 알게 될 것입니다. 중복 된 코드, DRY 원칙 위반 ... 그때까지 논란의 여지가없는 코드 적용 범위를 가지게되므로 메소드를 섞고 인터페이스와 모든 편의 시설을 추출 할 수 있습니다.

코드베이스를 항상 해킹하기 전에보다 조금 더 나은 상태로 두십시오. 나는 그것이 장기적이지 않더라도 갚을 작은 투자라고 확신합니다.

어디서 시작해야할지에 대한이 프로젝트 의 기술적 부채 에 대해 설명 할 수 있습니다. 또한 직원 이동으로 인해 코드 속도를 높이는 데 시간이 걸린다는 점을 협상 할 수 있습니다. 이는 테스트를 통해 버그를 예방하고 작업을보다 쉽게 ​​수행 할 수 있도록 향후 개발을 개선하는 데 도움이되는 몇 가지 테스트를 수행한다는 의미입니다. 새로운 사람들이 프로젝트에 참여할 수 있습니다.

그런 경우에는 가능한 한 프로젝트를 간소화하려고합니다. 앞으로 나아가려면 어떤 기능이 반드시 필요한지 알아보십시오. 오랫동안 사용되어 온 시스템은 아마도 매우 긴 백 로그를 가지고있을 것입니다. 이러한 항목 중 많은 부분이 중요하며 많은 경우 "종과 휘파람"이됩니다.

테스트를하는 한, 단위 테스트는 확실히 도움이 될 것입니다. 그러나 비 기술 직원에게 테스트에 참여하고 팀원에게 버그를 제출하도록 요청할 수 있습니다.

행운을 빕니다.

한 가지 방법은 이력서를 털어 내고 구직을 시작하는 것입니다.

스스로에게 물어보아야 할 좋은 질문은이 잘못 운영되는 프로젝트가 회사 전체의 운영 방식을 나타내는 지 여부입니다. 대답이 '예'인 경우 심하게 운영되는 회사에 머무를 수있을만큼 급여를 받도록 요청하십시오.

성능 향상을 알리거나 기존 버그를 수정한다고 상위 관리자에 의해 리팩토링을 푸시 할 수있는 경우가 많습니다. 특히 작동하는 경우에만 무언가를 변경하기 위해 리팩터링하지 마십시오. 버그 수정 시간은 이미 존재하는 일부 리팩토링에 적합한 방법 일 수도 있습니다. 자신의 동료 코더보다 나이가 어리다고 단호하게 생각하지 마십시오. 몇 가지 단위 테스트를받는 것과 같은 작은 것으로 시작하여 거기서부터 작업하면 관리 부서에 다른 문제를주기위한 몇 가지 버그가 노출 될 수 있습니다.

나는 현재 .NET에서 Brownfield Application Development를 읽고 있는데, 기본적으로 현재 문제를 처리하는 방법에 관한 것입니다. 지금까지 나는 그것이 말한 것의 대부분을 좋아한다. 그것은 몇 가지 방법으로 도움이 될 수 있습니다-그것은 당신이 혼자가 아니라는 것을 보여줍니다. 일부 문제를 해결하는 방법에 대한 힌트를 제공 할 수 있기를 바랍니다.

근본적으로 나는 대부분의 접근법에 동의합니다. 당신은 모든 것을 밤새 고칠 수는 없지만 매우 작은 단계로 점진적으로 향상시킬 수 있습니다. 그렇습니다. 기술 부채는 사용해야하는 은유입니다.

그것은 궁극적으로 사람들이 프로젝트에 얼마나 능숙한 지에 달려 있습니다. 혼란을 일으킨 동일한 승무원이라면 같은 그룹으로 더 나아질 가능성이 거의 없습니다. 직원을 분석하고 가장 약한 구성원을 찾아서 교체하십시오 (능력이있는 경우).

"뿌린 귀로 실크 지갑을 만들 수 없습니다."