프로젝트 관리자 나 수석 개발자에게 프로젝트의 코드베이스에 심각한 작업이 필요하다는 것을 어떻게 (정확하게) 알리는가?

방금 1 년이 아니더라도 몇 달 동안 프로젝트를 진행하는 (상대적으로) 소규모 개발 팀에 합류했습니다. 대부분의 개발자가 프로젝트에 참여하는 것처럼 첫 며칠 동안 프로젝트의 코드베이스를 검토했습니다.

이 프로젝트 (중대형 ASP.NET WebForms 내부 업무용 응용 프로그램)는보다 설명적인 용어가 없기 때문에 재난입니다. 코딩 표준에는 즉시 눈에 띄는 세 가지 문제가 있습니다.

1. 표준은 매우 느슨합니다. 해야 할 일보다하지 말아야 할 일 (헝가리어 표기법 등을 사용하지 않는 것) 을 설명 합니다.
2. 표준을 항상 준수하는 것은 아닙니다. 코드 형식이 어디에나 일치하지 않습니다 .
3. 이 표준은 Microsoft의 스타일 지침을 따르지 않습니다. 필자의 의견으로는, 프레임 워크 개발자와 언어 사양에 가장 큰 기여를 한 가이드 라인에서 벗어날 가치가 없다.

포인트 3의 경우 웹 응용 프로그램 (특히 ASP.NET)에 중점을 둔 MCPD 를 얻는 데 시간이 걸리기 때문에 아마도 더 귀찮게 할 것 입니다. 또한 팀에서 유일하게 Microsoft Certified Professional입니다. 모든 학교 교육, 자기 교육 및 실무 학습 (인증 시험 준비 포함)에서 배운 내용으로 인해 프로젝트 코드에서 간단하게 수행되지 않는 몇 가지 사례를 발견했습니다. 가장 좋은 방법은.

나는이 팀에 일주일 동안 일한 적이 있지만 코드베이스에 너무 많은 문제가 있음을 알았 기 때문에 내가 할 때보 다 "그들의 방식으로"일을하기 위해 이미 작성된 것들과 싸우는 데 더 많은 시간을 할애한다고 생각합니다. 예를 들어, 더 널리 채택 된 코딩 표준, 아키텍처 패턴 및 모범 사례를 따르는 프로젝트에서 작업했습니다. 이것은 내 질문에 나에게 온다 :

프로젝트 관리자와 팀 리더에게 프로젝트를 대대적으로 개조해야한다고 제안해야합니까 (그렇다면 어떻게해야합니까)?

그들의 사무실로 들어가서 프로젝트의 코드베이스가 쓰레기라고 말하면서 MCTS 및 MCPD 인증서를 흔들며 흔들며 싶지 않습니다. 그러나 나는 또한 침묵을 유지해야하고 꼭대기 kludgey 코드를 작성하지 않으려는 그들의 실제로 쓰기 품질의 소프트웨어를 원하기 때문에, kludgey 코드와 나는 최종 제품이 안정적이고 쉽게 유지 보수가되고 싶어요.

당신은 당신의 사건을 주장하면서 시간을 보낼 수 있습니다. 또는 시간을 정리하면서 시간을 보낼 수 있습니다.

픽업 클린 코드 및 민첩한 소프트웨어 개발 원칙, 패턴 및 실행을 하고 시스템에서 작업 할 때이 배운 것을 적용한다. 결국 사람들은 눈에 띄게 나아질 것입니다.

편집 또한 체크 아웃 레거시 코드와 효과적으로 협력

당신이 묘사 한 것에서, 문제는 대부분 코딩 표준을 따르지 않고 이름 지정 문제에 관한 것 같습니다. 그것은 재앙이 아닙니다 . 비교하자면, 이것은 실제로 재앙입니다.

어쩌면 당신은 익숙하고 높은 표준을 요구합니까? 이 경우 완벽에서 벗어난 편차는 실패로 간주 될 수 있습니다. 그것은 당신의 요구가 높을 때 빠지기 쉬운 함정이지만 사물에 대한 관점을 유지하는 것이 중요합니다.

이에 대해 개선 사항에 대해 이야기하고 팀이 가이드 라인을 업데이트하고 실제 사용을 시작하도록 코치하도록 도와주십시오. 나는 정의의 정의를 품질 벤치 마크로 사용하고 싶습니다. 하나를 만드는 것은 그 자체로 훌륭한 팀 출퇴근입니다. 그러나 나는 적어도 새로운 팀원이 아닌 그 이상을 더 많이 만들어야한다고 생각하지 않습니다.

분명히 MCSD를 흔들지 말고 사람들은 당신에게 아주 솔직하게 웃을 것입니다 .MS 자격증은 가지고 있기는하지만 결코 전문 자격이 아닙니다!

새로운 팀에 합류하여 단계적으로 변화를 제안 할 수있는 기회를 찾으십시오.

팀 코드를 내리기 전에 땅을 구할 때까지 기다리십시오.

문제가 있다고 생각할 수 있습니다. 언급 한 세 가지 중 어느 것도 응용 프로그램을 완전히 재 작업 할 가치가 없습니다. 그것들은 단순한 세부 사항입니다.

응용 프로그램의 목표는 아름다운 코드를 갖는 것이 아니라 비즈니스 문제를 해결하는 것입니다. 물론 일관성 있고 좋은 표준을 따르는 코드를 사용하는 것이 좋지만 코드가 부족하더라도 전체 코드베이스를 폐기 할 이유는 없습니다. 엔진이 유성이라고해서 엔진을 재건해야한다는 의미는 아닙니다.

봐요, 모두는 그들이 작성하지 않은 모든 코드베이스를 싫어합니다. 사실, 3 년 동안 기다렸다가 자신의 코드를 살펴보면 코드도 증오하며 완전히 다시 작성해야한다고 생각할 것입니다. 사실은 그렇지 않습니다. 비즈니스 가치를 추가하는 기능을 구축하는 대신 코드를 심미적으로 기쁘게 만드는 데 몇 달을 소비하지 않는 한 잘못된 트리를 낚아 채고있을 수 있습니다.

코드베이스에 일부가있을 수 있기 때문에 클루 지 코드를 작성해야한다고 말하는 것은 없습니다. 그리고 코드가 애완 동물 스타일을 고수하지 않기 때문에 단호하다고 말합니다. 작업하는 부분을 따라 가면서 리팩터링하고 새로운 작업을 할 때 좋은 코드를 작성하십시오.

걱정하지 않아도되지만 팀을 처음 사용하는 경우 아직 신뢰를 쌓을 때까지 보트를 흔들지 마십시오.

걱정할 세 가지 (상대적으로) 사소한 것들을 골랐습니다. 내가 더 걱정할 다른 것들이 있습니다.

• 코드가 잘 문서화되어 있습니까?
• 코드가 사양 / 디자인 문서를 준수합니까?
• 코드가 작동합니까?
• 코드가 무엇을 이해하는 것이 쉬운가?
• 이 코드베이스의 큰 덩어리를 TheDailyWTF에 제출하려고하십니까?

일주일 동안 가봤 어? 아직 프로젝트 관리자에게 제안 할만한 충분한 지식이 있는지 잘 모르겠습니다. 이 팀의 규범과 관행이 "나쁘다"는 의심이 들더라도 시간이 지남에 따라 이러한 것들에 영향을 미치는 가장 좋은 방법은 점차 신뢰와 존중을 얻는 것입니다. 프로젝트를 시작하고 일주일 후에 코드를 다시 작성해야한다고 팀에 알리는 것은 신뢰와 존중을 얻는 좋은 방법이 아닙니다.

처음 몇 달 동안 더 나은 모범을 보이고 특정 방식으로 일한 이유에 대해 질문하십시오. 이러한 질문을 할 때 소리에주의하십시오. 당신이 "모두 알고"새로운 녀석을 만난다면, 당신이 실제로 일이 이루어지는 방식에 영향을 줄 수있는 입장에있을 때 아무도 당신의 의견을 듣지 않을 것입니다.

시간이 지남에 따라 코드가 실제로 "더 나은"경우 다른 개발자가이를 알 수 있습니다. 그들은 그들이 당신의 문제를 해결하는 데 도움이되는 자료로 당신을 찾아오고, 그들이 어떻게해야하는지에 대한 조언을 구할 것입니다. 이 시점에서 코딩 표준 등에 대한 의견을 팀 (및 경영진)에게 알려줄 수있는 좋은 위치에있게됩니다. 이 프로세스에 걸리는 시간은 조직마다 다릅니다. 적응력이 뛰어난 환경에서는 몇 주일이 걸리거나,보다 험난한 문화에서는 몇 달에서 몇 년이 걸릴 수 있습니다. 한 번에 한 사람 씩 영향력을 쌓으십시오.

코드 기반이 완벽하고 모든 것이 "올바른"방식으로 완료되었다고 생각하는 새 직장에 가지 않아도됩니다. 이것을 받아들이는 법을 배우십시오. 레거시 코드로 할 수있는 것은 리팩토링하고 조금씩 앞으로 이동하는 것입니다. 왜 그들이 한 일 을 했는지 더 잘 이해할 때까지 리팩토링하고 싶지 않은 것들 . 또한 비즈니스의 어느 누구도 작업 코드를 수정하기 위해 비용을 지불하지 않으므로 시간을 늘리고 시간을 보내기 전에 왜 작동해야하는지 비즈니스 사례를 만들어야합니다. 어쨌든 변경해야 할 경우 코드 리팩터링을 기다리는 것이 좋습니다. 일부 방법으로 수행 한 방법을 선택하지 않았을 수도 있지만 작동하는 경우 변경하고 새로운 버그를 도입하는 데 매우주의하십시오. 특히 변경 요청을받지 않은 경우.

일주일 후에는 비즈니스 수행 방식에 대한 주요 제안을 할 수있는 신뢰성이 없습니다. 지금 일을 시작하면 사람들이 당신을 비웃고 당신을 진지하게 받아들이지 않을 것입니다. 먼저 좋은 코드로 자신을 증명하면 사람들이 더 잘들을 수 있습니다.

그리고 솔직히 당신이 Microsoft Certified Professional이라는 것을 신경 쓰지 않습니다. 많은 경험을 가진 사람은 좋은 사람으로 그 인증을받은 많은 나쁜 프로그래머로 여겨져 왔습니다. 나는 그것이 당신이 인증을받는 것이 나빠 보인다고 말하는 것이 아닙니다. 우리가 효과적인 프로그래머가 누구인지 보여주지 못하기 때문에 우리가 그들에게 많은 신뢰를주지 않는다고 말하고 있습니다.

나는 당신이 당신의 입장을 적절하게 정당화하지 못할 수도 있다는 의도로 제안을 제시하는 방법을 알아 내려고 노력할 것입니다. 제안을 작성하는 데 대해 고려해야 할 몇 가지 질문 :

• 여기에 설명 된 종류의 변경을 수행하면 비즈니스 가치가 얼마나됩니까?
• 처음부터 응용 프로그램을 다시 작성하거나 기존 코드를 수정하여 문제를 해결하거나 시간이 지남에 따라 약간의 변경을 수행하는 등의 옵션을 고려 했습니까?
• 원하는 변경을 수행하지 못하게하는 기능과 버그가 무엇인지 알고 있습니까?

열악한 코드베이스를 고치려고한다고 생각할 수 있지만, 비즈니스 관점에서 볼 수 있도록 무게를 측정해야합니다.

현재 잘못된 코드를 방지 할 수있는 위치에 있지 않으므로 코드를 포함하는 방법을 찾아야합니다.

PM 및 팀 리더는 작동하지 않는 PM 만 관리합니다. 다음 관심사는 변경을 요청하고 왜 '간단한'일이 그렇게 오래 걸리는지 궁금 할 때입니다. 그것이 당신이 올 곳입니다.

일관성 문제로 지금 시작하십시오. 현재 잠재적으로 표준적인 방법이 무엇이든, 그 방법을 찾아서 시행 할 수 없는지 확인하십시오. 다른 사람에게 익숙하지 않은 방법론으로 시작하면 많은 푸시 백을 얻을 수 있습니다.

다른 팀원이 인증을 받고 싶을 때 훌륭한 리소스가 될 것입니다. 바라건대 그들은 적어도 개선하고 당신에게 그들에게 길을 보여주기를 원할 것입니다.

헝가리 표기법에 대해 불평하면 동정심이 생기지 않으며 우선 순위 목록에서 마지막 전투 중 하나 일 것입니다.

이에 대해주의를 기울여야한다는 데 동의합니다. 비판을 말하고 코드 나 프로세스에 중대한 변화를 제안하기 전에 팀 내에서 명성을 쌓아야합니다. 나는 당분간 나의 발견과 제안에 대해 메모하고 팀원 및 경영진과 친분을 맺고 무료 토론에 참여할 수는 있지만 질적 인 문제 나 코딩 문제 등으로 바뀌더라도 때로는 던지기를 거부하지는 않습니다. 연못에 대한 내 자신의 질문 중 일부 (그러나이 코드베이스에서 본 구체적인 문제는 지적하지 않은 일반적인 형태). 이렇게하면 팀원의 의견을 알고 잠재적 인 동맹국을 찾을 수 있습니다.

최선의 경우, 팀 (및 / 또는 경영진)의 상당 부분이 귀하와 동일한 문제를 발견 할 수 있습니다. 단지 그들에 대해 어떤 조치도 취하지 않았거나 경영진이 부여한 자원이 없었습니다. 필요에 따라 함께 경영진을 설득하라는 말이 더 있습니다.

@Mike가 제안했듯이 정리 작업을 직접 수행해야하지만 다시 인내하는 것이 좋습니다. 너무 빨리 시작하면 다른 팀원을 소외시킬 수 있습니다. 또한 관리자가 광범위한 코드 정리 / 리팩토링을 입력하면 실제 작업에 충분히 집중하지 않았다는 표시로 사용될 수 있습니다. 따라서 좀 더 심각한 수준으로 착수하기 전에 리팩토링을해야합니다. 작은 지역 변경은 아마 괜찮습니다.

또한 경영진을 설득하려면 비즈니스 이론적 근거가 필요합니다. 일관성이없는 코딩 스타일에 대한 설명으로 관리가 거의 이동되지 않습니다. 제안 된 변경이 회사에 어떤 가치를 가져다 줄 수 있는지 보여 주어야합니다. 결론은 현금입니다. 제안 된 다양한 변경의 비용 대 장기 이점에 대한 설득력있는 계산을 작성하고 전체 균형이 명확하게 플러스 측에 있음을 보여 주면 기회가 눈에 띄게 향상되었습니다.

너 스스로해라. 특정 코딩 스타일을 소중히 생각한다면 코딩 스타일 을 위반하는 코드 로 작업하십시오 . 소스 제어에서 문제가되는 코드를 체크 아웃하고 코드를 스타일의 공백 요구 사항 (예 : 양식)으로 재 포맷하고 "공백에 대한 스타일 가이드 규칙 준수"메시지와 함께 업데이트 된 코드를 커밋하십시오.

일주일이 지나면 최악의 일이 바로 경영진에게가는 것입니다. 모든 가능성에서 그들은 코드에 많은 시간을 투자했으며 어느 정도 자부심을 가지고 있습니다. 당신은 아마 "모두 알고있다"고 생각할 것입니다.

내가 당신이라면 내가 할 일은 당신이 따라갈 때 그것을 향상시키는 것입니다. 익숙해지면서 더 많은 작업을하면 개선 할 수 있습니다. 그 시점에서 나는 당신이 다른 동료들에게하는 일의 이점을 보여주기 시작할 것입니다. 그 후, 새로운 모듈을위한 디자인 회의가 열릴 때 가장 좋은 방법으로 생각하는 것에 대한 논쟁을 제시하십시오.

솔직히 말해서, 표준은 이유가 있지만, 그것이 작동하고 잘 작동한다면 내 책에서 (특히 일주일 후) 100 배 더 가치가 있습니다. 코드를 열고 수많은 논리 오류나 그 성격을 발견하면 더 걱정할 것입니다.

이 '문제'로 경영진에게 직접 가지 마십시오.

먼저, 동료들과 이야기를 나누고 그들이 왜 그런지 알아보십시오. 그런 다음 문제가 있는지 없는지 더 잘 평가할 수 있습니다. 배우는 것에 놀랄 수 있습니다. 당신은 또한 청소를 원하는 동맹국을 찾을 수 있습니다.

당신이 처음에 어디로 왔는지 전혀 모른다면, 나가기가 훨씬 더 어려워집니다.

여기에 이미 많은 좋은 제안이 있으며, 나는 다른 사람들처럼 자신의 첫 번째 의견을 입증 할 때까지 다리를 타지 마십시오. 내가 추가 할 것은 먼저 프로젝트 관리자 나 팀장에게 가서 팀원들과 이야기를 나누는 것입니다. 그리고 그 전에 분명히 보여주십시오.

코드에서 발생하는 문체 문제에 더 가깝게 들립니다. 다른 사람의 코드를 인계하고 코를 쓰는 방식에 익숙해지면서 코를 잡고있는 것은 코드를 작성하는 방식과 같은 사소한 일이더라도 작업의 일부입니다. 당신의 '아기들'중 하나를 다른 사람에게 넘겨서 그들의 더러운 손으로 그것을 gle 아 먹는 것은 훨씬 더 나쁩니다 ...

그것이 궁극적으로 그 이상이고 문제가 문체보다 더 기능적이라면 팀 리드 / PM에 갈 경우 미래에 돈과 노력을 절약 할 수있는 곳에서 재 작업의 필요성을 피하는 것이 가장 좋습니다 개발 프로젝트. 좋은 오래된 리팩토링.