현재 지원하지 않는 응용 프로그램에서 놀라운 품질, 확장 성 및로드 문제가 발생했습니다. 고맙게도 나는 온전한 정신을 유지하기 위해 처음부터 새로운 프로젝트를 진행했습니다.
원래 팀은 20 명의 일부 개발자 (대부분 숙련 된 기술 세트를 보유한 개발자)로 구성되어 있으며 비즈니스 요구 사항 문서 나 품질 보증 테스터가 없으며 처음부터 폭포 방식으로 제대로 관리하지 못했습니다. 생산 초기는 훨씬 더 취성 수정으로 취성 절차와 같은 코드를 패치하는 것과 관련된 당혹스러운 악몽이었습니다. 나중에이를 지원할 의도가없는 데이터 모델에 쇠약하게 정리 된 기능이 추가되었으며 동일한 코드가 10 번 이상 중복되어 안전하게 닫히지 않는 리소스와 수만 개의 엔터티를 가져 오는 ORM 쿼리를 보는 것은 드문 일이 아닙니다. 소수만 빼고
이제 막 나에게 새로운 문제가 생길 때마다 더 나은 표준으로 모듈을 다시 작성하고 더 안정적으로 만들지 만 경영진은 왜이 모든 일이 발생하는지에 대한 적절한 설명이 필요합니다.
그들은이 응용 프로그램의 품질이 떨어지고 기술 부채가 익사한다는 개념에 충격을 받고 혼란스러워합니다. 다행히도 그들은 기술 부채의 개념을 이해하고 그것을 박멸하려는 탐구에서 저를 지원하며 저를 매우지지하고 감사합니다. 그러나 나는 원래 팀을 계속 비난 하는 것처럼 느낍니다. 분할).
결론은 내가 그 전에 프로젝트의 개발자에 대해 항상 불평하는 "그 사람" 이되고 싶지 않다는 것입니다. 나는 개인적으로 자신이 무지하고 있다고 생각했던 사람들이 자신의 방식대로 행동하도록 격려하는 환경과 디자인의 영향을 고려하지 않고 있다고 생각했습니다.
나는 더 많은 선임 멤버들이 경험하고 혜택을 누린 경험이없는 이상주의 주니어 개발자들의 열악한 디자인과 구현에 대해 이전 팀을 비난하는 태도를 보았습니다.
이러한 종류의 문제를 직원이나 팀의 평판을 밟지 않고 경영진에게보고하는 더 좋은 방법, 더 부드러운 방법이 있다고 생각하십니까?
bad-code. 코드가 실제로 버그와 문제를 일으키기 때문에 레이블을 붙였다 . 나는 bad-programmer이전 팀을 비난함으로써 하나가되는 것을 두려워하기 때문에 그것을 표시했습니다 . 처음 세 단락이 고려되는 한, 나는 그 설명적일 필요는 없지만 나의 즉각적인 상황에 대한 정확한 그림을 그리고 지금까지 수집 한 내용의 역사를 제공하고 싶었습니다.