수천 개의 오류!

최근에 새 프로젝트에 배정되었습니다. 사실 오래된 프로젝트는 고전적인 ASP로 작성되었습니다. 이제 최신 버전의 응용 프로그램이 최신 ASP.NET으로 작성되고 있지만 잠시 동안 RTM이 될 것으로 예상되지는 않지만 (예상 출시 날짜는 2017 년 1 월) 이전 응용 프로그램을 유지 관리해야 할 때까지 버렸다.
또한 모든 고객이 새로운 프로그램으로 즉시 전환하지는 않을 것이라는 생각이 들었습니다. 따라서이 버전은 아마도 잠시 동안있을 것입니다.

그리고 문제는 오류로 가득하다는 것입니다. 그것의 일부는 더 웹 표준 없었다 이전의 세기로 거슬러, 나는 정말 쿼크 모드에 대해 신경 쓰지 않고, width과 height, 모든 오류를 대신 CSS의 속성, 프레임 세트 등 레이아웃에 사용되는 테이블을하지만, 오! width="20px"사방에, onchange="javascript:..."그리고 그들이 CSS를 사용을 할, 그 장소에 style="width:20"와 style="width=20px"일상이다. 모순 width과 style속성 이있는 많은 줄은 말할 것도 없습니다 . 기타 등
결과적으로 웹 응용 프로그램은 IE에서만 실행되며 호환 모드에서만 실행됩니다. 개발자가 코드 유효성을 보지 않았다는 것이 분명합니다.

그리고 나는 그것을 처리하는 방법을 모른다. 다른 오류에 대한 코드를 보면서 해당 오류를 눈으로 감을 수는 없습니다.
물론 대부분의 문제를 해결하기 위해 전역 찾기 및 바꾸기를 수행 할 수는 있지만 첫 번째 커밋은 수천 개의 변경된 .asp 파일로 구성됩니다. 내가 할 수 있습니까?

"오류"라는 용어로 여러 가지를 혼동하는 것 같습니다.

• 기존 HTML 속성
• 코딩 스타일
• 버그를 발생시키지 않는 코딩 오류
• 보고되지 않은 버그
• 지금 특징 인 실수
• 보고 된 버그
• 해결하도록 지정된 버그보고

대체 될 레거시 앱에서는 이러한 유형의 오류 중 하나만 걱정해야합니다. 마지막 하나.

나는 주로 다음과 같은 이유로 버그 수정중인 기능에 대해 다른 것들을 리팩터링해서는 안된다고 말하고 싶습니다.

• 지금 특징 인 실수

코드에서 어떻게 작동했는지는 알 수 있지만 결코하지는 않았지만 모든 사용자는 지난 10 년 동안 불확실한 너비의 요소를 사용 해 왔으며 수정 해 주셔서 감사하지 않습니다.

한편, 냉소적 인 JFDI 헤드를 착용하면 버그가 매우 빠르지 만 화상을 입을 수 있으며 새 버전 팀은 이전 버전 기능을 유지할 수 없습니다.

이것은 고객에게 크롬 플러그인 ie6 에뮬레이터를 추천하여 그들이 좋아하는 '기능'을 계속 사용할 수 있도록 아이러니 글리의 미소를 지을 것입니다.

당신이 묻는 것은 기술적 인 질문이 아니며, 아무도 여기에 대답 할 수 없습니다.

유지 관리 모드에서 소프트웨어를 사용하고 있으며, 최신 기술과 많은 결함과 불일치가 관찰되었습니다. 무엇을해야하는지 묻습니다. 예를 들어 브라우저 간 호환이 가능하도록 노력을 확장해야합니까? 현대 표준에 맞게 가져와야합니까? 앱에서 구문 불일치를 수정해야합니까? 문제는 이것들이 비즈니스 결정 입니다. 관리자 나 제품 소유자에게 어떤 문제를 해결하고 우선 순위를 정해야하는지 문의해야합니다. 앱을 다시 작성하는 프로젝트가 이미 진행 중이므로 경영진은 관찰 한 문제를 이미 알고있을 것입니다.

응용 프로그램이 전체 개월 만에 교체 할 경우, 그것은이다 아마 그들은 단지 특정 중요한 문제를 해결하고 혼자 혼란의 나머지를 마칠. 그러나 우리는 모른다.

코드베이스에서 수천 개의 파일을 변경하여 검색 및 교체 작업을 스위핑 할 ​​수 있는지 묻습니다. 물론 당신은 할 수. 문제는 당신이 해야하는 경우 입니다. 이러한 변화는 아무것도 깨지지 않도록 광범위한 테스트가 필요할 것입니다. 이익이 시간과 위험에 소요되는 비용보다 큰 경우에도 비즈니스 결정입니다.

신청서가 18 주에서 24 주 안에 교체 될 때 (위에 제시된 6 주에서 8 주까지 예상되는 지연을 추가), 여전히 상당한 양의 작업에 투자하여 비즈니스에 어떤 가치를 더할 것인지 스스로에게 물어볼 필요가 있습니다. 이전 버전.

물론, 앞으로 몇 년 동안 응용 프로그램을 지원해야 할 때 기술 부채를 없애는 것이 장기적으로 가치가 있습니다. 그러나 어쨌든 모든 것이 버려 질 때 왜 귀찮게합니까? 다른 모든 해시 수정 프로그램 위에 다른 해시 수정 프로그램을 추가하여 새 버전이 출시 될 때까지 기다릴 수없는 문제를 하루 종일 고치십시오.

응용 프로그램이 아직 남은 짧은 수명 동안 수행 할 수있는 작업을 스스로에게 물어볼 수도 있습니다 . 지금 심심하고 시간과 관련이없는 경우에는 대대적 인 정밀 검사를 수행하고 언급 한 모든 스타일 문제를 제거 할 수 있지만 처음에는 더 많은 문제를 해결할 가능성이 높습니다. . 충분한 시간이 주어지면 이러한 새로운 문제를 제거 할 수는 있지만 그럴 시간이 없습니다.

크게 변경하지 않는 이유 :

하나 : 코드가 몇 개월 안에 사라질 것입니다. 1 개월 후에 버려 질 시스템을 5 개월 동안 사용하는 것이 회사의 시간 가치가 있습니까? 주의 사항 : 시스템이 예정된 시점에 사라지는 경우는 거의 없습니다. 교체 시스템은 거의 항상 늦습니다. 어떤 이유로 든 업그레이드 할 수없는 사용자가 있습니다. 그러나 이것은 복잡한 문제입니다.

둘째 : 대량 검색 및 교체를 많이 수행하면 버그가 발생합니다. 버그를 도입하지 않을 수도 있습니다. S & R을 수행하고 "width = 200"을 "width : 200px"로 변경했다고 가정하십시오. ASP 페이지에 C # 또는 VB 코드가 있습니까? "width"라는 변수가 200으로 설정되어 있으면 그 변수가 손상 되었기 때문입니다. (또는 그 문제로 인해 S & R을 ASP 페이지로 제한한다고 생각 했습니까?) 또는 "width : 200"을 "width : 200px"로 변경 한 경우 코드에 "width : 200mm"라고 표시된 곳이 있으면 어떻게됩니까? "? 이제 "width : 200pxmm"라고 표시됩니다. 자, 당신이 그것들을 생각했다고 가정 해 봅시다. 유효하지 않은 너비 사양을 가진 곳이 있다면 무시할 수있을 것입니다. 당신은 "수정" 너비와 200px로 배치됩니다 ... 200px는 실제로 잘못된 너비를 제공하기 때문에 그 값이 무시 되었기 때문에 작동합니까? 매스 S & R은 변화하는 모든 장소를 거의 연구하지 않기 때문에 매우 위험합니다. 무엇을 테스트해야할지 모를 수도 있습니다.

셋째, "분명히"잘못된 코드는 실제로 사용자가 원하는 것일 수 있습니다. 나는 분명히 잘못되고 미친 행동을 요구하는 많은 요구 사항 사양을 보았습니다 ... 그리고 나는 사용자에게 돌아가서 정말로 원하는 것을 묻습니다. 그들은 정말로이 미친 행동을 원한다는 것이 밝혀졌습니다. 사업 운영 방식이나 정부 규정에 따라

동작이 실제로 잘못된 경우에도 사용자가이를 예상하고 일상적으로 해결하고 해결하면 해결 방법이 중단됩니다. 예 : 나는 우리가 당신이 판매 할 수있는 날짜를 지정하는 장소가있는 시스템에서 일하고 있습니다. 두 날짜 모두 실제로 그 날 시작된 자정이므로 "7 월 30 일까지"라고 말하면 7 월 29 일의 끝으로, 즉 7 월 30 일 오전 12시 1 분 1 분 전에 끝나고 7 월 30 일이 아니라 어느 시점에서 나는 이것을 고쳤지만, 그 스크린을 사용할 권한이있는 사람이 6 명도 채되지 않아서 그 일을 할 수 있었으며, 내가 고친 모든 것을 간단하게 말할 수 있었다. 수백 명의 사용자가 있었지만 지금까지 하루 종일 실제로 제공해야한다는 사실을 알게 되었으면 내 "고정"

물론 대부분의 문제를 해결하기 위해 전역 찾기 및 바꾸기를 수행 할 수는 있지만 첫 번째 커밋은 수천 개의 변경된 .asp 파일로 구성됩니다. 내가 할 수 있습니까?

왜 그런지 모르겠습니다. A는해야한다 커밋 개념적으로 한 가지,하지만 난에서 글로벌 찾기 및 바꾸기 왜 아무 이유도 볼 style="width=20"로는 style="width: 20px""한 가지"로, 개념적으로 말하기에 포함되지 것입니다. 더 잘 자는데 도움이된다면, 다른 것들을 고칠 때주의를 산만하게하고 아무것도 뭉치지 말아라 .

당신의 문제는 우선 순위를 정하는 것입니다 : (제작 중) 쇼 토퍼 중 어떤 문제가 있습니까? 시한 폭탄은 어느 것입니까? 그리고 어느 것이 더 오래 남을 수 있습니까 (왜냐하면 작동하고 몇 년 동안 그렇게 해왔 기 때문에 심지어 일종의)?

내가 당신의 상황에서 내가하고 싶은 것은 내가보고 싶은 문제 클래스 목록을 만드는 것입니다. 예를 들면, 교체 style="width=(\d+)"로 style="width: \1px"(아마도 글로벌 발견과 수리 할 수있는 / 정규 표현식 사용하여 교체 - 광산이 100 %가 아닌 경우 죄송합니다) 하나 개의 클래스가 될 것이며, 단지 하나의 사건이 있다면, 그래서 그 것이다. 각 범주에 대해 우선 순위 (이 작업을 수행하는 것이 얼마나 긴급한가)와 작업 추정 (이 범주를 수행하는 데 걸리는 시간)이 있습니다.

유지 관리 작업도이 목록에 표시됩니다. 이제 당신은 자신에게도 일부 관리를 적용하기 시작했으며, 시간이없고 할 일이 없거나 할 일 (또는 요청)에 대해 관리자와 협상해야 할 때 사용할 도구가 있습니다. 그가 알지 못하는 것에 할당 될 시간). (이러한 종류의 사전 관리는 제대로 수행되면 프로모션에 대한 알림을받는 데 도움이 될 수 있습니다.)

나는 당신이 어느 정도의 완벽주의 성격을 가지고 있기 때문에 프로그래밍을 좋아한다고 생각합니다. 그러나 상업 환경에서는 완벽이 선의 적이라는 사실을 깨닫기 시작해야합니다 (그리고 선이 돈을 가져 오면 완벽이 훨씬 더 많은 일을 위해 눈에 띄게 더 많은 것을 가져올 수는 없습니다). 먼저 필요한 것을하고 나서 좋은 것을하십시오. 그렇습니다. 이것은 끝없이 당신의 곡물을 거칠 수 있습니다. 그냥 웃으면 서 참아, 아마도 완벽을 발휘하고 제정신을 유지하는 취미를 가질 수 있습니다. ;-)