우리 코드가 짜증나게 경영진에게 알릴 올바른 방법은 무엇입니까?

코드가 잘못되었습니다. 항상 나쁜 것으로 간주되지는 않았지만 나쁘고 내리막 길만 가고 있습니다. 저는 1 년 전에 대학을 졸업했습니다. 코드의 많은 것들이 저를 믿기 어려워합니다. 처음에 나는 새로운 사람으로서 코드베이스에 대해 조금 더 배울 때까지 입을 다물어야한다고 생각했지만 그것이 나쁘다는 것을 알았습니다.

일부 하이라이트 :

• 우리는 여전히 프레임을 사용합니다 (쿼리 문자열에서 무언가를 가져 오는 것은 거의 불가능합니다)
• VBScript
• 소스 안전
• 우리는 .NET을 '사용'합니다. 즉 COM DLL을 호출하는 .net 래퍼가 있기 때문에 쉽게 디버깅하기가 거의 불가능합니다.
• 모든 것이 기본적으로 하나의 거대한 기능입니다
• 코드는 유지 관리 할 수 ​​없습니다. 각 페이지에는 새 페이지가 작성 될 때마다 작성되는 여러 파일이 있습니다. 기본 페이지는 기본적으로 Response.Write ()를 여러 번 수행하여 HTML을 렌더링합니다 (runat = "server"? 안 함). 그 후 클라이언트 측 (VBScript)에 많은 논리가있을 수 있으며 마지막으로 페이지는 자체적으로 제출되며 (종종 숨겨진 필드에 많은 것을 저장하는 경우) 저장 페이지와 같은 작업을 수행 할 수있는 처리 페이지에 게시됩니다 데이터베이스에 데이터.
• 우리가 얻는 사양은 웃을 수 있습니다. 종종 그들은 필드 Y 또는 필드 Z를 언제 선택해야하는지에 대한 표시없이 "필드 Y 또는 필드 Z로 필드 X 자동 채우기"와 같은 것을 요구합니다.

나는 이것이 소프트웨어 회사에 고용되지 않은 결과라고 확신하지만, 소프트웨어를 작성하는 사람들은 최소한 코드의 품질에 관심을 가져야한다고 생각합니다. 마감 기한이 얼마 남지 않았기 때문에 곧 완료 될 수있는 일이 생기면 상상조차 할 수 없지만 잘못된 코드를 작성하고 나쁜 관행을 계속 사용하고 있습니다.

내가 무엇을 할 수 있을지? 이 문제를 어떻게 제기합니까? 내 팀의 75 %가 나와 동의하고 과거에 이러한 문제를 제기했지만 아무런 변화가 없습니다.

지나치게 반응하지 않는지 확인하십시오. 당신은 신선하고 아마도 다른 곳에서 많은 일을하지 않았기 때문에 "실제 코드"의 세계를 위해 준비되지 않았습니다. 실제 코드는 끔찍한 것입니다. 그것은 좋은 학교 코드와 강렬하게 조정 된 개인 프로젝트 코드가 원자로의 지하실에서 섹스를하고 아기가 독성 폐기물의 하수구에서 자란 것과 같습니다. 끔찍한 돌연변이입니다.

그러나 당신이 옳고 코드가 당신이 말한 것보다 나쁘다고 가정하면 (즉, 일반적으로 나쁜 코드보다 더 나쁘다), 당신은 걱정할 권리가 있습니다. 팀과 대화하고 다른 사람들이 편에 있는지 확인하십시오. 상황을 개선하기 위해서는 노력이 필요합니다. 팀의 다른 구성원이 문제를 인식하지만 신경 쓰지 않으면 시간을 낭비하고 있습니다.

후배이기 때문에, 당신은 아마도지도 할 위치에 있지 않을 것입니다. 후배 인 신입 사원으로서 경영진에게 직접 가면, 당신의 의견은 무시 될 것입니다. 수석 개발자 또는 가장 고위 임원 중 한 명과 함께하십시오. 다시 말하지만, 노인 중 누구도 관심이 없다면 시간을 낭비하고 있습니다.

고위 기술 인력이 관심을 가질 수 있다고 가정하면 문제 영역과 가능한 솔루션을 식별하기 위해 노력할 것입니다. 예를 들어, "모든 것이 기본적으로 하나의 거대한 기능"이라면 다음에 '거대한 기능'에서 작업 할 때 약간 리팩터링해야 할 수도 있습니다. 다시, 당신은 모든 사람을 기립시켜야합니다. 문제의 작은 부분을 없애고 결국 부분적으로 개선하면 문제가 훨씬 줄어 듭니다. 코드를 만질 때마다 코드를 개선 할 수 있는지 고려하십시오.

당신은 경영진과 함께 앉아서 '모든 것이 나쁘고 다시 써야한다'고 말하지 않을 것입니다. 비용이 많이 들고 잠재적으로 매우 위험합니다. 대신 문제가 있음을 인식하고 변경 사항이있을 때 천천히 개선 할 계획이 있음을 알아야합니다. 유지 관리 가능한 코드의 이점에 대해 교육을 받아야합니다. 이것은 당신이 아닌 기술적으로나 전문적으로 신뢰하는 선배로부터 나옵니다.

재 작성을 완료 하시겠습니까? 거의 항상 나쁜 생각입니다.

당신이 새로 왔기 때문에 궁극적으로 할 수있는 일이 많지 않습니다. 아무도 개선을 원하지 않는다면 경험을 모아서 다음 장소로 이동하십시오.

Joel On Software를 읽으십시오 -절대로하지 말아야 할 것들. 그의 추론을 이해 한 다음 프로그래머가 아닌 관리자가 작성한 나쁜 소프트웨어와 그 문제를 해결하는 방법에 대한 다른 기사를 읽으십시오. 이 정보로 무장 한 경우 관리자가 이해하고 관심을 갖는 관점에서 문제를 해결하기위한 사례를 제시 할 수 있습니다. 힌트 : 훌륭한 관리자는 프로그래머의 의견과해야 할 일에 대한 느낌만으로 시간과 돈을 소비하지 않습니다.

"이 코드는 쓸모없고 다시 작성해야합니다."는 기술적으로 정확하더라도 확실히 사용자에게 되돌아 갈 것입니다.

"현재 프로젝트 일정에서 수개월이 걸리므로 비용이 적게 들고 더 안정적으로 만들 수 있습니다." 그들의 관심을 끌 것입니다 (당신이 그의 단계에서 이것을 어떻게 할 것인지에 대한 언급이 부족하다는 것을 알 수 있습니다.

당신이 무엇을 말하든, 당신이 정확하다는 것을 확신하십시오. 나쁜 말을하면 재기록은 피의 좋은 일이어야합니다. 재 작업 된 코드의 결함으로 인해 재 작업을 수행하지 않은 경우 어떤 일이 있었는지에 관계없이 개인적으로, 귀중한 비용이 발생합니다. 누군가가 당신 앞에 있었는데 다시 쓰기를 망쳐 놓거나 과매도를 포기했다면, 관리자는 바보 같은 것을 좋아하지 않으며 두 번 일어날 수 없습니다. 그 토큰으로, 추종자들을 망치지 마십시오.

일정 기간 또는 여러 프로젝트에 걸쳐 비용을 분산시키는 방법을 찾으십시오. 관리자는 위험, 투기 적 투자 및 마이너스 현금 흐름을 싫어합니다. 작고 위험이 적으며 비용이 저렴한 제안으로 시작하십시오. 당신이 올바르게 증명되면, 당신은 더 큰 물고기를 갈 수 있습니다.

우선, 스타트 업에서 일하지 않고 원래 구피 레거시 코드를 작성하는 사람이 아니라면 프로그래머로 작업하는 구피 레거시 항목을 찾을 수 있습니다. 프로그래밍 분야에서 경력을 쌓으려면 이러한 펀치로 롤백 할 수 있어야합니다.

둘째, 오래된 시스템을 개선하기 위해 비용을 고려해야하는 경우가 종종 있습니다. 예를 들어, 10 년 된 VB6과 기존 ASP 응용 프로그램이 여전히 작동하는 회사가 둘 이상있는 것을 보았습니다. 경우에 따라 .NET을 이동하는 큰 프로젝트가 잘못 실패했기 때문입니다. 다른 이유는 "파산하지 않으면 고치지 말 것"이었습니다. 그러나 다른 시스템에서는 레거시 시스템으로 인한 문제를 무시하기 때문에 이동 비용이 합당합니다.

과거에 큰 실패가 있었던 상황에서 변화를 일으키는 것은 거의 불가능합니다. 이 경우 이력서를 다듬고 새로운 일자리를 찾으십시오. 그것이 깨지지 않았다면 아마도 코드 자체에 대해 불평 할 이유가 없지만 성취하고 성장하는 경력 경로에 있지 않은 것입니다. 그것이 깨져서 귀하의 경우처럼 들리면, 그때는 기회가 생길 것입니다.

내가 본 가장 좋은 방법은 너무 물지 않고 가장 긍정적 인 영향을 줄 수있는 증분 변경으로 시작하는 것입니다. 설명을 바탕으로 변경 요청을보다 잘 관리하는 것이 시작의 장소입니다. 제어가 완료되면 서비스 프레임 워크 또는 기타 증분 설계 / 코드 개선을 검토 할 수 있습니다.

내가 본 최악의 접근 방식은 레거시 시스템에서 최신 및 최대 시스템으로 직접 도약하려고 시도하는 것입니다.

"Hay Boss, Big Project 후 저와 팀은 코드를 정리하는 데 이상적인 X 개월의 시간을 원했습니다. 몇 분 안에 완료 될 수있는 작업은 모두 매우 체계적으로 구성되어 있지 않기 때문에 몇 시간이 걸릴 수 있습니다. 빅 프로젝트 직후에 현실적인 일정을 계획하고 싶습니다. "

(질문에 대한 Azkar의 의견에서 부분적으로 해석 됨)

소프트웨어에서 Joel 읽기 시작 (Joel Spolsky / Stack Exchange 설립자) ...

내가 할 첫번째 일은 Joel 테스트를 수행하는 것 입니다.

이를 통해 "개발자로서 개선 할 수있는 방법을 찾고 있었지만 개발 환경에 대한 12 가지 질문 테스트를 우연히 볼 수 있었기 때문에 재미있게 작업 할 수있는 곳에 대해 답변했습니다." ... 이것은 차례로 당신의 코드가 아닌 당신이 개인적으로가 아니라는 것을 설명하는 제 3자를 만듭니다.

Pragmatic Practices 에 대해 자세히 읽으면 스스로 개선하고 빨강 / 녹색 / 리 팩터와 같은 것들을 구현하게되며이를 통해 코드 기반을 정리하여 유지 관리가 가능해집니다. (시간이 지남에 따라)

희망이 도움이됩니다! 프로그래밍에 오신 것을 환영합니다 (어제 코드는 일반적으로 짜증납니다) ;-)

빠른 팁 : 코드를 다르게 작성 해야하는 이유 목록과 함께 관리를 제안하는 경우 "프로그래머의 사기 / 근로 조건 개선"이라는 주장을 포함 시키십시오.

기술 팀이 현재의 혼란보다 더 많은 콘텐츠를 작성하고 깨끗한 코드를 유지하는 것이 분명하며, 이는 작업에 대한 태도를 확실히 향상시킬 수 있습니다. 유용한 주장이 될 수 있습니다.

• 경영진이 실제로 설계를 지시합니까? 대부분의 팀이 배후에 있다면 무엇을 막고 있습니까? 능동적으로 행동하고 그룹으로 결정하십시오. 점진적으로 구현할 계획을 세우십시오 . 그럼 해
• 경영진이 사용하는 개발 도구를 지시합니까? 공구 관리를 교체하는 데 시간이 걸리지 않는 한 일반적으로 중요하지 않습니다. 적극적으로 행동하고 그룹으로 사용하려는 개발 도구를 결정하십시오. 관리 부서에서 구매해야하는 경우 마이그레이션 계획 및 비용 편익 분석 을 보여주십시오 . 그럼 해
• 경영진이 사용하는 언어를 결정합니까? VBScript 대신 사용할 것을 사전에 결정하고 그룹으로 결정하십시오. 점진적으로 구현할 계획을 세우십시오. 경영진 구매가 필요한 경우 계획을 보여주십시오. 그럼 해
• 사양에 대한 정보가 없습니다. 그것은 일반적으로 직장에서 사람과 프로세스에 크게 의존합니다. 파손 된 부분을 식별하고 프로세스를 수정하는 데 필요한 최소한의 변경 사항은 현재 작동하는 방식과 작동 방식에 대한 시간, 분석 및 이해가 필요합니다. 계획을 세우고 경영진을 설득하고 설득 할 수 있다는 것을 알고 있다면.

비즈니스 가치가 없는 (또는 부드러운) 비즈니스 시간이없는 많은 전용 시간이 필요없는 변경 방법을 제안하면 더 많은 변화와 존경을받을 수 있습니다 .

경험에서 말하기 : 쉽지 않습니다. 거의 불가능합니다. 경영진은 코드가 빨라지고 문제가 발생했을 때 완전히 무지하거나 및 / 또는 단서가 없다는 것을 신경 쓰지 않습니다. 코드를 작성하는 이유와 목록을 작성하여 리팩토링 / 재 작성할 때 실제 비즈니스 가치를 입증하는 이유에 대한 추론을 작성하는 것이 최선의 방법 입니다.

예를 들어 "코드를 유지 관리 할 수 ​​없습니다"일 수 있습니다.

X , Y 및 Z 때문에 현재 코드를 유지 관리 할 수 ​​없습니다 (유지할 수없는 이유를 나열하십시오). X , Y , Z (변경이 어려운 이유) 때문에 변경 요청과 새로운 기능을 수행하기가 매우 어렵 습니다. 변경이 어렵 기 때문에 개발 팀은 버그 수정 및 개선에 쉽게 대응할 수 없습니다.

당신의 유일한 희망은 상사와 경영진이 코드에 어떤 영향을 미쳤는지 이해하기에는 너무 어리석지 않고 문제를 해결하기 위해 새로운 기능 요청이 나오기를 기꺼이하지 않을 것입니다. 그렇지 않으면 노력이 헛된 것입니다 . 과거의 경험에 비추어 볼 때, 코드에 문제가 있거나 동료가 너무 걱정하지 않아 경영진에게 우려를 표할 가능성이 큽니다.

행운을 빕니다. 당신이 필요합니다.

"나는 대학을 신선하게 시작했다"-당신의 질문에 대답해야합니다.

관리자는 아마도 코드가 차선책이라는 것을 알고있을 것입니다. 대부분의 코드는 Ray Gosling, Guido Van Rossum 또는 다른 사람이 그것을 작성하는 데 정말로 좋고 비싸지 않은 한 고용하지 않는 한입니다.

경영진은 또한 회사에 적용되는 "작업"에 대한 정의 (충돌, 판매, 보고서 제공 등)를 사용하여 작동한다는 것을 알고 있습니다.

최소한의 비용으로 코드를 "작동"상태로 유지하기를 원합니다. 그들은 값 비싼 프로젝트가 모든 것을 다시 쓰는 제안을 원하지 않습니다.

결과물이 우아한 코드가 아닌 작동하는 소프트웨어 (이미 가지고있는 소프트웨어)이기 때문에 비즈니스 사례를 만드는 것은 거의 불가능합니다.

소프트웨어에서 기능을 먼저 시장에 출시하는 데 큰 기회 비용이 있다는 사실을 추가하십시오. 당신이 정말로 그것에 대해 생각한다면, 시간 투자에 대한 장기 투자 회수가 보장되지 않습니다.

즉, 관리 가능한 물린 방식으로 작은 것들 (예 : 좋은 VSS를 얻는 것)을 리팩토링하고 수정하는 것이 여전히 좋은 계획입니다. 궁극적으로 이것은 관리 문제가 아닌 기술 문제입니다. 약속 한 것을 계속 이행하면서해야 할 일만하면 괜찮을 것입니다. 강력한 사례를 만들어도 경영진은 코드 품질에 대한 중요한 세부 사항에 관심이 없을 것입니다.

가능한 한 빨리 떠나십시오 (직업 호퍼처럼 보이고 싶지 않으면 너무 빨리 떠나지 않을 수도 있습니다). 코드가 엉망이고 사람들이 거기에 머물고 있다는 사실은 가난한 개발자와 함께 일하고 있음을 의미합니다. 자신의 작업에 관심이있는 괜찮은 개발자는 그런 쓰레기를 오랫동안 연구하지 않을 것입니다.

재 작성의 가능성은 매우 $$ 현명한 투자 가치가 있음을 명확하게 보여주지 않는 한 상당히 낮습니다.

관리는 코드에 신경 쓰지 않습니다. 그들은 판매 할 제품을 갖는 것을 걱정합니다.

레거시 시스템이 실제로 매우 나쁘고 팀의 대다수를 위해 어리석은 양의 오버 헤드를 추가하는 경우 (나는 항상 큰 덩어리를 코딩하거나 그 전체를 코딩하는 사람이 있기 때문에 대다수를 말합니다) 그의 손을) 그들에게 다가 가서 개발 시간에 비즈니스 비용이 든다고 말하면 고객 만족에 영향을 줄 것입니다.

그러나 다시 한 번, 그들은 여전히 ​​코드에 신경 쓰지 않고 제품에 관심을 갖기 때문에 "응답 할 수 있습니다"라는 대답이 나오더라도 관리자의 허락없이 코드를 정리할 수 있습니다. 배에 가지 말고, 팀과 먼저 이야기하고, 아무도 와서 좋아하지 않고 3 개월이 걸리는 기능을 사용해보십시오. 해킹 당했기 때문에 작동하지 않는 것처럼 보입니다.

코드를 크게 변경할 때의 예산 영향과 변경하지 않은 경우의 예산 영향을 이해하는 방식으로 관리에 접근하십시오. 나는 Emilio의 문구를 좋아했다.

"오래된"코드는 항상 끔찍하지만 명심해야합니다. 이것은 우리 모두 개발자로서 끊임없이 성장한다는 것을 의미합니다. 우리는 좋은 코드를 작성했다가 나중에 더 나은 코드를 작성하는 법을 배우고 이전의 "좋은"코드는 끔찍한 것 같습니다. 너무 많은 개발자들이 지속적으로 더 나은 결과를 얻고 장기적으로 더 많은 돈을 낭비하려고 노력하고 있습니다. 균형을 잡는 행위입니다. 즉, 갈수록 나아질 수 있다면 항상 좋습니다. 그 거대한 기능을 수정하려고 할 때 분할하십시오! 결국 당신은 어딘가에 도착할 것입니다.

하지마

어쨌든 큰 프로젝트를 처음부터 다시 작성하는 것은 큰 실수입니다.

관리자, 특히 프로젝트 관리자에게 잘못된 코드 및 리팩토링에 대해 말하기가 쉽지 않다고 생각한 적이 있습니다. 첫째, 그들은 당신이 수석 사람이더라도 여전히 신뢰할 수있는 시간이 필요하더라도 당신을 신뢰해야합니다. 둘째, 그들은 단순히 문제가 얼마나 나쁜지 이해하지 못합니다. 오늘이 마지막 날인 경우 새 빌드를 릴리스하면 빌드가 실패합니다. 그들은 그것이 얼마나 심각한 지 알지만 나쁜 코드, 부적절한 테스트 등과 같은 많은 문제로 인해 빌드가 실패한 것을 결코 알지 못합니다.

웹 프로젝트에서 구성 및 배포 작업을 마쳤습니다. 새 빌드를 배포 할 때마다 예기치 않은 문제를 해결하는 데 종종 많은 시간이 걸립니다. 대부분의 문제는 보안 및 통합이었습니다 (여러 웹 / Windows 응용 프로그램 간). 우리의 코드는 짜증나고, 다른 사람들의 코드는 짜증나고, 그들은 완전히 스파게티 코드입니다.

우리는 새 버전을 계획하고 있었고 리팩토링을 강력히 요청했습니다. 버그가 자주 발생하는 로그인 / 인증 코드에 세부 로그를 추가하십시오. 관리자들은 동의했지만, 그것은 멋진 목록에 포함되었으며 이미 큰 기능 목록과 시간이 촉박했기 때문에 완료 될지 모르겠습니다.

두 가지 종류의 관리자가 있습니다 : 당신이하는 일을 이해하는 척하는 사람과 그렇지 않은 사람들. 소프트웨어를 이해하는 척하는 사람은 적대적입니다. 그렇지 않은 사람들은 단순히 당신에 의해 짜증납니다.

어쨌든 관리자는 모두 거짓말 쟁이이므로 다른 모든 사람을 강요하는 경향이 있습니다.

내 요점은 소프트웨어가 오래되었다고 말하면 변명으로 간주 할 것입니다. 그들은 상관하지 않습니다.