고객에게 잘못된 코드를 보여줄까요?

클라이언트가 다른 컨설턴트가 개발 한 ASP.NET Webforms 응용 프로그램 인 웹 사이트를 다시 디자인하도록 요청했습니다. 비교적 간단한 작업처럼 보였지만 코드를 살펴본 후에는 그렇지 않습니다.

이 응용 프로그램은 잘 작성되지 않았습니다. 조금도. SQL 인젝션 공격에 매우 취약하고, 비즈니스 로직이 전체 애플리케이션에 퍼져 있으며, 중복이 많으며, 아무 것도하지 않는 막 다른 코드가 있습니다. 게다가 질식되는 예외가 계속 발생하므로 사이트가 원활하게 실행되는 것으로 보입니다.

내 임무는 단순히 HTML과 CSS를 업데이트하는 것이지만 대부분의 HTML은 비즈니스 로직에서 생성되며 정렬하기에는 악몽이 될 것입니다. 재 설계에 대한 나의 예상은 고객이 목표했던 것보다 길다. 그들은 왜 그렇게 오래 묻고 있습니다.

이 코드가 얼마나 나쁜지 고객에게 어떻게 설명 할 수 있습니까? 그들의 마음에, 응용 프로그램은 훌륭하게 실행되고 재 설계는 빠른 일회성이어야합니다. 전 컨설턴트에 대한 나의 말입니다. 비 기술적 고객이 이해할 수있는 간단하고 구체적인 예를 어떻게 제시 할 수 있습니까?

최신 정보

모든 답변에 감사드립니다. SQL 주입 공격 데모는 의미가 있으며 테스트 환경에서 데모를 시연 할 것입니다. 그것은이 응용 프로그램에서 많은 문제의 일부일뿐입니다. html 및 CSS 업데이트를 수행하기 위해 다른 부분 (예 : 데이터 영역에서 생성되는 html)을 더 나은 방법으로 대체해야하는 이유를 설명하는 방법을 찾고있었습니다. 고객과 대화 할 때 함께 제안 할 좋은 제안이 많이 있습니다.

비 기술자들은 바보가 아닙니다 (대부분). 그들은 당신이 그것을 충분히 높은 수준으로 유지하면 기술적 인 논쟁을 이해할 수 있습니다. 간단하다고 생각되는 과제를 고르고 왜 그렇지 않은지 살펴보십시오.

이 변경 사항이 하나의 파일에서 한 단어가 될 것으로 예상했습니다. 그것을 바꿀 가능성이 가장 높은 곳은 여기에있는 것처럼 보였지만 내가 그곳을 갈아 입었을 때 한 곳에서만 일했고 다른 7 곳이 고장났습니다. 하나를 고치면 두 곳이 더 떨어져 도미노 효과를 일으켜 10 분이 걸리면 2 시간이 걸렸다 고 생각했습니다. 한 가지 예일뿐입니다. 거기에는 훨씬 더 예기치 않은 2 시간 작업이 있습니다.

코드 구조, 스타일, 기술적 부채는 적어도 처음에는 고객이 당신을 믿을 때까지 살아남 아야 할 것 중 하나입니다.

보안 취약점은 또 다른 문제입니다.

개인적으로 기존 구조와 스타일을 사용하여 필요한 작업을 기반으로 견적을 작성하는 동시에 코드베이스에 중대한 문제가 있음을 분명히했습니다. 보안에 대한 시사점을 별도로 제기했습니다. 회의 중에 데이터베이스를 해킹하여 포인트를 집으로 가져옵니다.

"내"카드에 £ 5000를 넣고 그에게 카드를 확인하게했을 때 충성도 기프트 카드 시스템을 갖춘 이전 고객과 함께이 일을하는 것은 매우 기뻤습니다.

이를 고객에게 전달하고 전달하는 방법에 대한 몇 가지 훌륭한 제안이 있습니다. 잘만되면 그들은 당신을 위해 돈을 지불합니다.

주요 적기!

고객이 동의하지 않은 내용 (HTML 및 CSS)을 변경하지 말라고 요청하면이 프로젝트를 통과하고 입찰을 철회합니다.

모든 결함과 보안 문제에 대한 서면 및 의사 소통 개요를 가지고 있어도 잠재적 책임은 너무 커서 편안하지 않습니다. 고객이 해킹이나 위반 후에 법적인 조치를 취하거나 수정을 요구하지 않더라도; 당신의 이름과 명성은 여전히 ​​작품에 붙어 있습니다!

얻는 것보다 훨씬 더 많이 잃을 수도 있습니다.

결함을 설명하고 설명 할 수 있음
자신에 대한 당신의 말이 다가 오면, 당신이 말하는 모든 것은 그들이 생각하는 한 열기가 될 수 있습니다. SQL 인젝션을 통해 앱을 악용하는 방법을 보여 주면 갑자기 신뢰할 수있는 사람입니다. 재협상하려면 신뢰가 필요합니다. 그리고 이것은 당신에게 그것을 줄 수있는 게임 체인저로 충분합니다.

전임자와 관련하여 자선을 베푸십시오
. 실수가 없다는 것을 의미하지는 않습니다. 그러나 당신이 대결을 겪으면 신뢰를 잃게됩니다. 아마도 그에게 의심의 이익을주는 것 외에는 프로그래머에 대해 한마디도하지 마십시오. 코더가 아닌 코드에 중점을 둡니다. 그들이 당신이 "좋은 사람"인 것처럼 느끼게 만드는 것은 협상에 훨씬 더 많은 여지를 줄 것입니다. 그리고 "좋은 사람들"은 결코 의미하는 말을하지 않습니다. 클라이언트에 기존 보안 실수 (예 : SQL 주입 취약점)를 설명 할 때 다음과 같이 말하고 싶습니다.

웹 애플리케이션 보안은 빠르게 발전하는 분야입니다. 오늘날에도 사람들이 배우는 많은 개발 도구와 기술은 이러한 악용 대부분이 잘 이해되기 전에 진화했습니다. 보안 개발을 앞서 가려면 필드를 매우 밀접하게 따라야하며 때로는 전체 개발 스타일을 변경해야합니다. 대부분의 프로그래머는 이것을하지 않습니다.

우리는 거기에 갈. 개발자에 대해 말하는 악의의 말이 아닙니다. 그는 단지 "가장 많은 프로그래머"일 뿐인데, 이는 꽤 좋은 회사에 있다는 것을 의미합니다. 그리고 지금 당신은 당신이 "더 많은 신뢰도" 가 아니라는 것을 보여주었습니다 .

새로운 계약 협상
고객이 자신의 앱이 공개적으로 악용 될 수 있음을 이해하면 수정을 원할 것입니다. 당신은 아마 그가 고치려고 할 사람 일 것입니다. 당신은 그 직업을 원하거나 원하지 않을 수 있으므로, 그들과 대화하기 전에 신중하게 생각하십시오.

최소한, 그들은 이미 당신에게 주어진 일을 끝내기 위해 더 많은 시간을 원합니다. 당신은 아마도 그들이 당신을 원래의 추정치에 맞지 않을 수있는 취약점으로 충분히 경계를 설정했습니다. 그러나 고객이이 계약의 일부로 자신이 무엇을 알고 있고 고치지 않도록해야합니다.

일반적으로 개발자는 모든 것을 처음부터 다시 실행하는 것을 선호합니다. 그리고 이런 경우에는 옵션 일 수도 있습니다. 그럼에도 불구하고 클라이언트는 새로운 앱이 구축 될 때까지 비즈니스를 계속 운영 할 수있는 무언가를 원할 것입니다. 다시 시작하더라도 여전히 이전 앱을 약간 업데이트해야 할 것입니다.

나는 이것을 주석으로 시작했습니다. 왜냐하면 처음에는 그것이 옆으로 생각했지만 실제로는 그렇지 않습니다.

나는 당신이 느끼는 모든 것을 다시 디자인하고 왜 ( 변경 하지 않으면 어떻게되는지 ), 문제를 해결하기위한 추정치를 완전히 문서화 할 것입니다 . 나는 당신이 보안 위험으로 인식하는 모든 것에 특히 세심한 것입니다.

나는 만지기 전에이 작업을 수행 할 어떤 코드를, 그리고 클라이언트가 바람직 타임 스탬프의 일종으로,이 보고서의 사본을 가지고 있는지 확인하십시오. 시간이 다소 걸릴 수 있지만 이러한 보안 위험 중 하나가 실현되는 경우에도 귀하를 보호합니다. 그들이 문서를 받았다고 서명 한 것을 얻을 수 있다면 더욱 좋습니다.

물론, 상속 된 원본 코드의 소스 제어를 가리킬 수는 있지만이 문서를보다 전문적인 방법으로보다 쉽게 ​​언급 할 수 있습니다.

이 문서는 추가 토론의 ​​시작점이 될 수 있으며 고객이 "적절한 사람들"에게 일부 또는 모든 변경 권한을 부여하는 데 사용할 수도 있습니다.

즉, 일단 고객이 위험을 이해하지 못하면, 어쨌든 일을하라고 말하거나 멀리 나갈 때 위험을 감수해야합니다.

응용 프로그램을 유지 관리하는 데 도움을주기 위해 고객이 방문한다는 것을 기억하십시오. 응용 프로그램에서 발견 한 모든 문제를 지적하는 것은 전문가의 임무입니다. 고객은 이러한 문제가 존재한다는 사실을 모를 것이므로이를 알고 있어야합니다. 이러한 문제를 이해하고 진행 방법을 결정할 수 있도록 이러한 문제를 설명하십시오.

자동차 고장 또는 수리가 필요한 세탁기와 같은 이러한 문제를 설명하기 위해 실제 사례를 사용하십시오. 중요한 것은 이미 익숙한 예제를 사용하는 것입니다. SQL 인젝션을 설명하기 위해 그게 무엇이고 왜 문제인지 간단히 설명하겠습니다.

결국 당신은 당신이 작업하도록 요청받은 응용 프로그램의 성공에 관심을 가지고 있음을 전달하고자합니다.

나는 고객이 관련시킬 수있는 유추를 사용하고 싶다. 내가 직장에서 이기기 위해 선불로 한 일의 양은 고객이 지출하고자하는 돈의 양에 달려 있습니다 (100 달러는 20,000 달러와 크게 다릅니다). 내가 "내 향적"이라고 말했다. 당신이 요구하는 것을 얻지 못한다면 관련된 가치에 대한 개인적인 추정은 그다지 의미가 없습니다.

상황에 따라-돈에 따라 다시 한 쪽에서 한 줄이 나오는 상자를 그려 고객에게 말할 수 있습니다. "이것은 소프트웨어를 시각화하는 방법입니다. 데이터는 한 쪽 끝에서 다른 쪽 끝으로 나옵니다. 멋지고 깨끗하고 단순 해 보입니다. " "이것은 소프트웨어가 내부에있는 것처럼 보인다"고 상자 안에 두 줄을 연결하는 세 번째 줄을 그립니다.

그런 다음 외부에 입력 및 출력 줄이있는 첫 번째 상자와 같은 다른 상자를 그립니다. 이번에는 "지금 상자 안에 소프트웨어가 실제로 보이는 모양이 있습니다." 이번에는 두 줄을 연결하기 위해 스파게티 엉망으로 된 임의의 더미를 그릴 것입니다.

마지막으로 "이제 당신이 요구하는 것은 이것입니다 ..."라고 말하고 첫 번째 상자 안에 작은 반원을 선에 닿아 서 간단한 모양을 그리고 "그렇게하려면 d ...이 작업을 수행해야합니다. "선 주위에 토네이도처럼 보이는 나선형 모양을 그리고 계속"...이 모든 것을 돌기 위해 ..... "다른 상자에있는 스파게티를 가리 킵니다.

나는 그것이 약 2 분 안에 포인트를 집으로 몰아 넣을 것이라고 생각합니다. 그들이 당신에게 어쨌든 그렇게 주장한다면, 다른 사람들이 위에서 언급 한 것처럼 그것을 문서화하십시오.

이 코드가 얼마나 나쁜지 고객에게 어떻게 설명 할 수 있습니까?

아마도 집안에서 배관과 같은 유추를 시간이 지남에 따라 수정하고 개조 한 후 변덕스럽고 결합되어 한 가지를 고칠 때 영향을 미치고 다른 것을 깨뜨려 고칠 필요가 있으며 알 수있는 방법이 없을 수도 있습니다. 이것이 일어날 모든 장소.

그것은 이전 컨설턴트에 대한 나의 말이므로, 비 기술적 고객이 이해할 수있는 간단하고 구체적인 예를 실제로 어떻게 제시 할 수 있습니까?

당신이 맞습니다, 그것은 이전 컨설턴트가 그들의 머리에서 만든 시각적 인 것에 반대하는 말입니다. 내 제안은 당신이 요구하는 것을하고 간단하고 구체적인 예를 제시하는 것입니다. 이것은 재 설계이므로 컴파일 된 코드에 정의 된 HTML 조각이 나머지 HTML 페이지와 함께 표시되는 방식과 변경 사항이 나머지 페이지에 영향을 미치거나 그렇지 않은 방식을 보여줍니다. 동일한 "컴파일"규칙을 적용한 후 동일한 컴파일 된 코드가 마크 업을 렌더링 할 수 있습니다. 차이점을 보여주십시오.

이것은 어렵고 매우 일반적인 문제입니다. 행운을 빕니다.

정직하고 직접하십시오.

그러나 가장 중요한 것은 기대에 미치지 못하는 직업을 갖지 않는 것입니다. 대부분의 사람들은 계약자가 고객을 해고 할 수 있다는 것을 인식하지 못합니다.

여기에 내가 사용한 비유가 있습니다 (효과를 보증하지는 않지만). 그들의 웹 사이트가 기계적인 인쇄기처럼 입력을 받아들이는 물리적 인 기계라고 상상해보십시오.

그들은 아마도 기계가 X와 Y를 수행하는 구성 요소를 가지고 있다고 생각할 것입니다. 실제로, 그것은 거의 20 대 정도의 비슷한 기계입니다. 그들 중 일부는 더 이상 아무것도하지 않고, 모두는 다른 사람들이 이미 수행 한 기능을 수행하려고 시도하며, 이전 컨설턴트 외에는 이전과 똑같은 것을 본 적이 없습니다.

"포스트 변수를 구문 분석 한 다음이 구성 요소를 if-elses의 토끼 구멍으로 보내는이 기즈모를 참조하십시오.이 중 하나만있는 것이 아니라 모든 페이지 (또는 기타)에 이들 중 하나가 있습니다. 입력을 소독하고 일부는 그렇지 않은 (또는 모두는 그렇지 않은) 모든 것을 읽지 않으면 어느 것이인지 알 수 없습니다. "

아직 언급하지 않은 한 가지 점은이 경우 고객이 실제로 원하는 것을 지나치게 넘어 설 수 있다는 것입니다. 초과 달성은 훌륭하고 많은 직업 만족도를 줄 수 있습니다. 그러나 클라이언트가 단순히 신경 쓰지 않고 현재 성능이 "충분히 좋다"고 생각하고 약간의 업데이트 만 원한다면 코드베이스를 정밀 검사하기 위해 많은 투자를하도록 설득하는 것이 불가능할 수 있습니다.

그 시점에서 아마도 원칙을 세우고 부끄러운 코드 혼란에 좋은 이름을 붙일 수있는 직업을 거부하거나 코를 잡고 들어 와서 일을 마칠 수 있는지 결정해야 할 것입니다 덕트 테이프로 지불하고 지불하십시오.

덕트 테이프 작업을 계속하기로 결정한 경우 가능한 한 문서화, 문서화, 문서화 및 투명성을 유지해야합니다. 마지막으로 당신이 원하는 것은 응용 프로그램 결함으로 인해 고객에게 경고했지만 응용 프로그램 결함이 당시에 다루기에 충분하지 않다고 결정한 미래의 잘못된 일에 대해 비난받는 것입니다.

SQL 인젝션 위험에 관한 한, 다른 사람들이 말했듯이 실제로 프로덕션 환경에서 파괴적인 일을하지 않고 위험을 보여주는 방식으로 위험을 보여줄 수 있어야한다고 말했습니다. 그러나 다시 말하지만, 그들이보고 그것을 고치기 위해 돈을 지불 할만큼 신경 쓰지 않는다면,이 경우에 선의의 부지런한 일을 한 것입니다.

이 프로젝트에 와서 재 작성 먼저 제안, 수정의 몇 가지 작은 부분 집합을 수행하고 얼마나 간단하고 저렴 설명하기 위해 사람들을 사용하는 멍청한 놈 소스입니다 수 있었다. 그러면 더 깔끔한 개발 비용으로 인해 유지 관리 비용이 절감되고 글꼴 측면 비용이 적게 들면서 장기적으로 개발 속도가 빨라지는 이유를 분명히 알 수 있습니다.

근본적으로 당신은 그들이 당신의 삶을 더 쉽게 만들기 위해 당신에게 돈을 지불하도록 요구하고 있음을 잊지 마십시오. 그들의 마음에는 Y 비용으로 X 기능을 제공하고 프로젝트의 복잡성을 확대 할 수있는 '남자'를 찾아야 만 기회가 사라질 수 있습니다. 당신을 위해. 한 달에 다시 작성하고 원래 개발자와 만났을 때 모든 타협을 완전히 이해 한 개발자가 전체 응용 프로그램이 계약을 맺은 창으로 작성되었다는 사실을 깨닫기 란 쉽지 않습니다. 당신이 말하는 것처럼 앱이 내부적으로 끔찍하지만 외부 적으로 잘 작동한다면, 아마도 그럴 것입니다. 종종 코드베이스 내의 기술 부채는 코드가 개발 된 자원 제약의 결과이며 팀을 구성하지 않고 대신 계약을 맺고 있다면 ...

난 그냥 말하는거야

나는 여기서 악마의 옹호자를 할 것입니다 (@khrome의 말에 따라 : "당신은 당신의 삶을 편하게 하기 위해 고객에게 돈을 지불하지 않습니다 "). 귀하가 제시 한 사건이 일반적인 방식으로 설명 되었기 때문에 귀하가 제시 한 사건이 너무 일방적이라고 진술하기까지합니다. 새 프로젝트에 들어오는 대부분의 컨설턴트는 이전 프로젝트에 대해 나쁜 빛을 비출 것입니다 ... 나는 그것이 당신이하고있는 일이 아니라, 우리가 예제를 볼 때까지 단순히 당신의 말을 받아 들일 수는 없습니다.

즉, 문제를 단계별로 해결하려고합니다.

• SQL 주입 . 그래, 프로그래머가 매개 변수가있는 쿼리 및 / 또는 저장 프로 시저 대신 문자열 연결을 사용하고 있다고 생각합니다. 이것은 특히 ADO.NET에서 수정하기가 매우 쉽습니다 ... 개인적으로 클라이언트에게 언급하지만 너무 많은 것을하지는 않습니다.
• HTML은 비즈니스 로직에서 생성되고 있으며 분류하기에는 악몽이 될 것 입니다. 좋아, 친구, 이것은 당신이 나에게 더 자세한 정보를 제공하는 사람들 중 하나입니다. MVC를 사용하지 않는 한, 이런 경향이 있습니다. 그러나 반드시 나쁜 것은 아닙니다 ... 대부분의 프로그래머가 " 고토 가 나쁘다; 절대 사용하지 마십시오 "라고 말하는 것 중 하나 이지만, 그 사실을 알고 있습니까? 나는 의미가있는 곳에서 goto를 사용 했습니다! 비즈니스 코드 DLL과 동일한 네임 스페이스를 공유하는 헬퍼 클래스를 사용하지 않습니까? 다시 말하지만 격리하기가 어렵지 않습니다.
• 비즈니스 로직은 전체 애플리케이션에 퍼져 있으며 많은 중복이 있으며 아무 것도하지 않는 막 다른 코드가 있습니다. . 과? 고객이 방금 HTML / CSS를 변경하도록 요청하고 있습니다. 왜 이러한 문제에 관심이 있습니까?
• 그것은 질식되는 예외를 계속 던지므로 사이트가 원활하게 실행되는 것처럼 보입니다 . 다시 모호합니다. 모든 응용 프로그램에서 예외는 일반적이므로 코드에 try / catch 절이 있습니다. 그들이 UI에서 버블 링하고 사용자 경험을 망치지 않는 한 (HTTP 500을 불필요하게 표시하는 것과 같이), 이것이 당신이 신경 써야 할 것이라고 생각하지 않습니다.

간단히 말해서, 나는 당신에게 높은 길을 타라고 조언 할 것입니다. 시간이 가치가 없다고 생각하고 고객을 희생하여 재 작성하고 싶다면 직장을 떠나십시오. 진지하게, 클라이언트는 모든 것을 최소한의 $$$로 작동시키기 위해 시간을 지불합니다.

필자는이 분야에서 수년간 쌓아온 경험에서 항상 최고의 프로그래머 는 전체 를 다시 쓰지 않고 최소한의 코드 를 작성하여 시스템을 안정적으로 만들 수 있다고 말합니다 .

편집 : 나는 내 대답이 가장 인기있는 답변이 아니라는 것을 이미 알고 있지만 응답을 기다립니다. 나는 덜 까다 롭도록 이것을 편집했습니다. ;-)

확실히 응용 프로그램의 SQL 주입 공격 및 기타 기능적 결함이 우선했지만, 잘못된 코드 품질 및 관행을 "시연"할 수도 있습니다. 코드 메트릭 도구를 사용하면 코드가 얼마나 나쁜지 명확하게 보여주고 향후 변경 및 버그 수정에 얼마나 많은 비용이 드는지 보여줄 수 있습니다. .net 환경에 익숙하지 않지만 선택할 수있는 것이 몇 가지 있습니다.