나는 여기에 많은 포스터가 경영상의 문제를 확신하고있는 것처럼 보이는데, 그 질문에 대해서는 언급하지 않았다.

나는 그것보다 더 나아갈 것이다 : 내 의견으로는 거칠고 코드베이스는 거의 직접 관리의 결함이 아니다. 경영진은 개발자가 작성한 코드를 작성하지 않았습니다 (현재 회사의 일부 경영진이 실제로 초기 코드베이스를 작성한 일부 예외가 있습니다). 따라서 문화 문제는 개발자들에게 있습니다. 만약 문화가 바뀌기를 원한다면, 그들 스스로 변화해야합니다.

나는이 실현과 태도의 변화를 “나의”개발자들에게 전하려고 노력한다. 그들이 “언제 리팩터링 할 시간이 있습니까?” 코드베이스를 건강하게 유지할 수 있다고 믿는 유일한 방법은 세 가지입니다.

1. 건강한 코드 만 추가하십시오.
2. 건강하지 않은 코드는 최대한 빨리 수정하십시오.
3. 마감 기한 이유로 1 또는 2를 수행 할 수없는 경우, 항상 “마감 기한 직후 수정”문제 목록을 갖고 마감 기한 후에 해당 목록을 통과하지 못한 것에 대한 변명은 수락하지 마십시오.

개발자의 다음 발언은 “언제나 그렇게 할 시간이 있습니까? 지금은 시간이 없습니까?”입니다. 정답은 (IMHO에게도) “하지 않을 시간이 없습니다”뿐입니다. 코드베이스를 건강하게 유지하지 않으면 처리 시간이 점점 길어지고 예측할 수없는 일정이 생기고 버그가 점점 더 나 빠지고 가치가 낮아집니다.

개발 팀에서 가장 큰 태도 변화는 “품질”이 특정 시점 ( “리팩터링 할 시간이있을 때”)에서 수행하는 작업이 아니라는 것입니다. 항상 수행해야하는 작업입니다.

마지막으로 경고의 이야기. 눌려지면 이런 일이 발생하지 않을 것입니다. 제가 근무한 회사에서 10 년 전부터 시작된 대규모의 레거시 코드베이스가있는 오랜 응용 프로그램이있었습니다. 저를 포함한 많은 개발자들은이 레거시 코드베이스가 최신이 아니라 나쁘거나 오래되었다고 생각했습니다. 그래서 우리는 큰 리팩토링 프로젝트를 성공적으로 수행하고 모든 것이 더 좋을 것이라고 생각한 재 작성 프로젝트를 시작했습니다.
우리는 새로운 라이브러리, 새로운 언어 기능을 사용하여 거의 모든 것을 새롭고 현대적인 방식으로 구현하기 위해 열심히 노력했습니다. 결국 우리는 새롭고 개선 된 코드 기반으로 오랜 응용 프로그램의 새로운 릴리스를 허용하기 위해 모든 것을 하나로 모으기 위해 많은 노력을 기울였습니다.
예상대로 새 릴리스에는 아직 익숙하지 않은 새 라이브러리와 예상하지 못한 코드의 일부 상호 작용으로 인해 일부 문제가 발생했습니다. 그러나 마침내 이전 릴리스와 동일한 표준으로 릴리스를 출시하고 문을 열었습니다. 우리는 “성공”에서 한숨을 쉬었다. 그런 다음 하위 그룹의 개발자가 경영진으로 돌아와 새로운 코드 리팩터링 프로젝트를 요구하면서 새로운 리팩토링 프로젝트를 요청했습니다.

이야기의 도덕 : 종종 상황이 거의 깨지지 않는 경우가 많으며 ‘다시 시작’한다는 것은 알려진 문제 세트를 거의 알려지지 않은 문제 세트와 교환한다는 의미입니다. 한 번에 한 부분 씩 리팩터링하십시오!

답변