응용 프로그램이 잘못된 코드베이스에 구축되어 있음을 증명하는 방법은 무엇입니까?

나는 현재 내 직장에서 일했던 일부 개발자가 만든 시스템을 검토하고 있습니다. 이 시스템은 사용자의 관점에서 잘 작동하지만 코드 검토를 할 때는 완전히 엉망입니다. 응용 프로그램이 구축되는 방식은 사용량이 크게 증가하지는 않지만 향후 업데이트를 보류하지 않을 것이라고 확신합니다.

문제는 그것이 얼마나 나쁜지 알지만 상사에게는 그렇지 않다는 것입니다. 관리자에게 실제로 문제를 확인하고 현재 코드베이스에서 최소한의 심사를 수행하도록 확신 할 수 있고 가까운 시일 내에 다음 버전의 애플리케이션을위한 새로운 개발 라인을 시작하도록 확신을 줄 수있는 방법은 무엇입니까?

'그러나 지금 작동합니다'는 소프트웨어 엔지니어의 합법적 인 좌절에 대한 표준 관리 대응입니다. 내가 할 첫 번째 일은 문서 (있는 경우)를 컴파일하고 코드와 문서 사이의 모순을 설명하는 데 사용하는 것입니다.

가능하면 포괄적 인 단위 테스트 모음을 구성하십시오. 기존 코드베이스에서 비난받을 수있는 회귀를 문서화 할 수 있도록 변경 될 때마다이를 실행하십시오.

마지막으로, 신뢰하는 다른 부서의 개발자를 끌어들일 수 있다면 코드를 다시 한 번 살펴보십시오. '이것은 허물이다'고 말하는 한 개발자는 한참 동안 일했던 선임 개발자가 그에게 보증하고 '아니요, Jim이 맞습니다. 이것은 크래커 크래커입니다. '

물론 환경, 회사 ​​규모 등에 따라 다릅니다.

나는 Pragmatic Programmer 를 보지 않았다면 항상 살펴 보는 것이 좋습니다 . 모든 소프트웨어 전문가에게 읽어야 할뿐만 아니라 소프트웨어 엔지니어링을 공예로 보지 않는 경영진, 동료, 사용자 등을 다루는 좋은 제안이 있습니다.

경영진의 관점에서 볼 때 시스템에는 아무런 문제가 없으며 단지 시스템을 다시 작성하고 싶거나 이전 엔지니어가 수행 한 작업을 이해하지 못하고 작업을 쉽게하기를 원하기 때문에 불만이 있습니다. 약간의 짚맨이지만, 정상에있는 누군가가 지금 일이 잘되고 있음을 알면, 당신이 처한 위기를 보지 못하게됩니다 (어딘가에 기후 변화에 우화가 있다고 확신합니다 ...) .

어느 정도, 그들은 요점을 가지고 있습니다. 경영진은 릴리스가 원래 예상치를 훨씬 넘어 설 때 문제가 발생하는 것으로 나타났습니다. "기존 코드 기반으로는 불가능합니다", QA 이후에 버그가 많이 발생하는 것으로 예상되는 작업에 대한 추정치가 너무 높아 보입니다. 일이 잘 따라 가고 있다면, 결론을 내리는 데 영향을 미치지 않기 때문에 머리를 가볍게 두드리고 최선을 다하도록 지시하기 쉽습니다.

수행 할 작업은 조직과 소프트웨어 자체에 따라 다릅니다. 그러나 기본적으로 잘못된 레거시 코드의 결과로 발생하는 모든 문제를 문서화하는 것이 좋습니다. 작업을 추정 할 때 이전 코드 기반의 어떤 측면이 이러한 추가 비용을 추가하는지에 대한 자세한 설명과 함께 왜 오래 걸리는지 생각하는지 경영진에게 명확하게 설명하십시오. 버그 코드에 도입되는 경우, 이유 등 이유는 이 버그에 미끄러 수 있었던 방법과 기존의 코드베이스에 문제가 책임이 있습니다.

소프트웨어가 원래 디자인을 넘어서고 계속 향상 시키기에는 문제가 있음을 시사하는 방식으로 이해 관계자에게 귀하의 우려를 표명하는 것이 좋습니다.

코드 범위 및 코드 검토를 수행 할 수있는 다양한 도구가 있습니다. 귀하의 기술에 적합한 Google 도구는 일반적으로 업계 표준 도구입니다. 이러한 도구를 사용하고 코드 품질 보고서를 작성하여 Manager에 제시하는 것이 좋습니다. 당신의 비판이 구성적이고 비 정치적이어야합니다.

관리가 단순한 변경 요청이라고 생각하는 위치를 이해하기 쉬운 예를 선택하십시오. 그러나 기존 설계로 인해 훨씬 ​​더 어렵습니다.

당신은 그들이 특정 요청에 머무르기를 원하지 않지만, 이것이 변경 요청이 어떤 것인지 알려줍니다. 아무도 구석에 응용 프로그램으로 칠하기를 원하지 않습니다. 개발자는 YAGNI를 믿지만 경영진은 CYA를 믿습니다.

부하 테스트에 대한 제안은 좋은 접근 방법이 될 수 있지만 사용량 증가에 대한 우려가 실제 성장 잠재력에 부합한다고 확신 할 수는 없습니다 (1 년 안에 두 배로 증가하지는 않을 것입니다).

모든 것이 상대적입니다. 그들은 더 중요한 프로젝트를 계획 할 때이 프로젝트에 리소스를 넣고 싶지 않을 수도 있습니다. 큰 그림이 보이지 않는다고 표시되지 마십시오.

당신이 무언가를 증명하는 것에 대해 이야기 할 때, 모든 과학적 방법이 작용하고, 그 의미의 일부는 당신이 진실한 것을 결정하는 객관적인 표준을 받아들이려면, 조사 할 때 성가신 사실을 받아 들여야한다는 것입니다. 당신 편이 아니어야합니다.

귀하의 경우, 입증해야 할 두 가지가 있다고 생각합니다.

첫째, 현재 코드베이스가 "나쁜"것입니다. 당신이 아마 증명할 수있는 것은 "이 코드를 검사하는 거의 모든 개발자들의 전문적인 의견은 그것이 나쁘다는 것"입니다.

둘째, 회사는 코드베이스를 다시 작성하는 것이 좋습니다. 첫 번째 포인트가 맞더라도 두 번째 포인트가 맞지 않을 수 있기 때문에 문제가됩니다. 또한이 결정을 내릴만큼 충분하지 않습니다. 이것은 경영진의 직무이며, 첫 번째 요점에 대한 전문적인 판단을 존중하려면 두 번째 점에 대한 평가를 존중해야합니다.

그러나 정보를 제공하지 않으면 두 번째 요점을 결정할 수 없습니다. 코드의 문제가 비즈니스에 미치는 영향과 재 작성이 비즈니스에 미치는 영향에 대해 알고있는 사항을 전달해야합니다. 둘 다 불확실성이 많은 미래를 예측하기 때문에 어렵습니다.

그러나 비즈니스 용어로 문제를 설명하려고 할 수 있습니다. 변경 및 회귀에 추가 시간이 얼마나 걸립니까? 재 작성 비용은 얼마입니까? 다시 쓰지 않으면 시간이 지남에 따라 현재 시스템의 비용이 얼마나 빨리 증가합니까? 사용량이 증가하면 현재 코드가 유지되면 재난이 발생할 가능성은 무엇입니까? 당신은 이것을 전혀 알 수 없지만 다른 사람보다 더 나은 추측을 할 수 있습니다. 이러한 것들을 예측할 수 있다고 생각하는 범위 또는 의사 소통 할 내용을 제시하십시오.

대부분의 개발자는 성가신 코드를 유지하는 것을 좋아하지 않습니다. 그렇기 때문에 개발자 관점에서 다시 작성해야 할 코드가 비즈니스 관점에서 다시 작성할 가치가없는 것은 불행한 이유입니다.

예를 들어, 재 작성이 수익성을 갖더라도 회사의 다른 곳에서 돈을 소비하는 기회 비용보다 가치가 떨어질 수 있습니다. 또는 잘못된 코드베이스는 변경하는 데 시간이 오래 걸리고 더 많은 회귀가 있지만 재 작성을 수익성있게 만들기에는 충분하지 않습니다. 그들은 앞으로 몇 개월 안에 매입 될 것으로 보이며 재 작성에 돈을 쓰면 책에 표시되지만 버그가있는 소프트웨어는 그렇지 않습니다.

비즈니스 관점에서 그것에 대해 생각하고 원하는 것을 얻기 위해 숫자를 요리하지 마십시오. 큰 재 작성은 비즈니스 관점에서 볼 때 결코 쉬운 일이 아닙니다. 직접적으로 증명할 수없는 것을 증명하려면, 그것을 반증하기 위해 최선을 다하십시오. 처음부터 다시 쓰지 않는 방법 을 찾기 위해 최선을 다 했지만 아무 의미가 없다면 , 처음부터 다시 쓰려고 할 때입니다. 그리고 그러한 노력을 기울이면 경영진은 자신이 아닌 회사의 이익을 대변하는 것이 진지하다는 것을 보여줄 것입니다 (귀하가 아닌 회사의 이익을 대표하는 것입니까?).

코드베이스에 무엇이 나쁜지에 달려 있다고 생각합니다. "내가하는 방식이 아님"이 나쁜 코드 기반이라는 의미는 아닙니다.

실제로 나쁜 코드 기반을 만드는 것 :

• 보안 구멍

  서버, 응용 프로그램 및 / 또는 데이터를 취약하게 만드는 문제 특히 민감한 회사, 고객 또는 고객 데이터를 위험에 빠뜨리는 모든 것. 이것들은 문서화하기 쉬워야합니다.

• 고장난

  데이터를 마사지하고 응용 프로그램을 거의 지속적으로 유지 관리하여 데이터를 유지하기 때문에 작동합니다. 당신이 떠나고 아무도 슬랙을 취하지 않으면 더 이상 작동하지 않을 것입니다. -시간을 얼마나 쓰는지 문서화하십시오. 그리고 얼마나 절약 할 수 있는지 기록하십시오. 종종 이러한 프로세스는 사용자에게 비효율적이며이를 문서화 할 수도 있습니다.

• 실제로 작동하지 않습니다

  작동하는 것 같지만 결과가 올바르지 않습니다. 이는 일반적으로 일치하지 않는 숫자, 결함률 등의 문제를 일으 킵니다.

나쁜 코드베이스가 아닌 것 (좋지 않은 것) :

• 쓸모없는 지원되지 않는 기술로 작성되었습니다. (VB6, COBOL, .net1.1 등)

새로운 기술로 마이그레이션 할 때의 이점에 유의하십시오. 위험을 최소화하고 사용자 및 관리 신뢰를 구축 할 수 있도록 조각을 한 번에 이동하는 마이그레이션 경로를 찾으십시오. 논리가 기본적으로 원본과 동일하게 작동하는지 확인하십시오.

• 문서화되지 않거나 형식이 잘못된 코드

일반적으로 코드에 실제로 영향을주지 않으면 서 주석을 추가하고 서식을 수정할 수 있기 때문에이 방법을 사용하는 것이 가장 쉽습니다. 그러나 다시 쓰지 않아도됩니다. 이것이 다른 문제와 결합되어 있다고 생각되면 가장 먼저해야 할 일은 코드의 생존 가능성을 더 잘 평가할 수 있도록 수정하는 것입니다.

당신은 어떤 방식으로 자신의 질문에 대답했습니다.

그들이 시스템에 돈을 쓰도록 설득하는 방법은 사용자에게 제대로 작동하지 않을 때까지 기다리는 것입니다. 규모가 커지지 않을 것이라고 생각되면, 그것이 일어날 때까지 기다리거나 그것을 입증하기 위해 부하 테스트를 수행하십시오.

그런 다음이 크기를 조정하여 청소하는 것은 X 시간의 간단한 제안입니다.

이것은 사용자의 관점에서 모든 것이 현재 수용 가능하고 안정적인 시점에 있기 때문에 어려운 상황입니다. 기본적으로 비 기술적 인 관리자에게는 걱정할 것이 없지만 코드베이스를 다시 작성하라는 것은 엄청나게 큰 결정이며, 특히 한 사람의 의견과 노력에 대해 가볍게 결정해서는 안됩니다. .

따라서 당신은 압도적 인 기술적 부채 (귀하의 견해가 없으며 그에 대한 예가 없어야 함)와 어려운 장소에 있기 때문에 다시 쓰기를 요구하는 어려운 위치에 있습니다. 이 시스템에 기능을 유지하고 추가하는 데 어려움이 있습니다.

새로운 기능에 대한 귀하의 추정치가 높을 것입니다. 사실로 이러한 높은 수치를 정당화하여 실제로 많은 시간이 소요될 것임을 증명하십시오. 이를 제대로 전달하지 않으면 관리자가 무능하다고 가정 할 수 있으며 확실히 원하지 않을 수도 있습니다. 그가 높은 추정치에 의문을 제기 할 때 축적 된 기술 부채가 현재 소프트웨어에 빠르고 저렴하게 기능을 추가하는 기능을 방해한다고 느끼는 이유를 설명하십시오. 관리자가 두 개의 뇌 세포를 문지르면 매우 빨리 이해하기 시작할 것입니다.

요점은 관리자를 설득하려고하지 말고 재 작성이 허용되는 과정 임을 확신 할 수있는 적절하고 신중하게 선택된 정보로 관리자를 안내해야한다는 것 입니다. 관리자가 자신의 아이디어라고 생각해야합니다.

먼저 코드베이스에 축적 된 기술 부채를 결정하십시오. 그런 다음 이 질문과 답변을 살펴보고 , 계속 진행하기 전에 경영진이 기술 부채를 상환하도록 설득하는 방법을 설명합니다.

모든 성숙한 소프트웨어가 엉망인 것처럼 보이는 이유가 있습니다 .

1. 모든 혼란은 비즈니스가 의존하는 중요한 논리를 인코딩하는 것입니다. 그것 없이는 아무것도 작동하지 않습니다. 사용자 문제를 해결하기 위해서는 모든 것이 필요했습니다.
2. 약간 오래된 기술을 사용하고 있습니다. 현재 프로그래머는 템플릿 매직을 사용하지 않으면 엉망이라고 생각합니다. 보기가 깨졌습니다. 더 큰 프로젝트에 늦게 도착하는 사람은이 단계를 거치면서 모든 세부 사항을 배우게됩니다.
3. 얼마 전에 중요했던 요구 사항은 더 이상 중요하지 않습니다. 소프트웨어가 이미 이러한 문제를 해결했기 때문입니다. 프로젝트가 늦어지면 소프트웨어는 아무 이유없이 복잡해 보일 수 있습니다. 문제는 더 이상 존재하지 않지만 코드의 복잡성은 여전히 ​​존재합니다.