Hàng ngàn lỗi!


30

Tôi đã được giao cho một dự án mới gần đây. Vâng, một dự án cũ thực sự, được viết bằng ASP cổ điển. Bây giờ một phiên bản mới của ứng dụng đang được viết trong ASP.NET mới nhất, nhưng nó không được mong đợi là RTM trong một thời gian (ngày phát hành dự kiến ​​là tháng 1 năm 2017) vì vậy tôi phải thực hiện một số bảo trì trên ứng dụng cũ cho đến khi có thể bỏ đi.
Ngoài ra, tôi có cảm giác rằng không phải tất cả khách hàng sẽ chuyển sang chương trình mới ngay lập tức, vì vậy phiên bản này có thể sẽ xuất hiện trong một thời gian.

Và vấn đề là, nó đầy lỗi. Các phần của nó có từ thế kỷ trước, khi không có tiêu chuẩn web và tôi không thực sự bận tâm về chế độ Quirks widthheightcác thuộc tính thay vì CSS, các bảng được sử dụng cho bố cục, bộ khung, v.v., nhưng ồ, tất cả đều là những lỗi đó! width="20px"ở khắp mọi nơi, onchange="javascript:..."và ở những nơi họ sử dụng css, style="width:20"style="width=20px"là phổ biến. Không đề cập đến nhiều dòng trong đó có mâu thuẫn widthstylethuộc tính. V.v ...
Kết quả là, ứng dụng web chỉ chạy trong IE và chỉ ở chế độ tương thích. Rõ ràng là các nhà phát triển không bao giờ nhìn vào tính hợp lệ của mã, chỉ khi những gì xuất hiện trông giống như những gì họ nghĩ trong đầu thì nó sẽ trông như thế.

Và tôi không biết làm thế nào để xử lý việc đó. Tôi thấy không thể nhắm mắt trước những lỗi đó trong khi tìm mã cho các lỗi khác.
Tất nhiên tôi có thể thực hiện tìm kiếm và thay thế toàn cầu để giải quyết hầu hết các vấn đề, nhưng điều đó có nghĩa là cam kết đầu tiên của tôi sẽ bao gồm hàng ngàn tệp .asp đã thay đổi. Tôi có thể làm điều đó?


21
"lỗi" bạn có nghĩa là phong cách mã hóa mà bạn không thích?
Ewan

9
Một mẹo mà tôi đã nghe: Đi đến một nơi mà sinh viên âm nhạc thực hành. Cố gắng để có được mười lăm phút trong một căn phòng cách âm. SCREAM trong mười lăm phút. Bây giờ bạn cảm thấy tốt hơn, đi và sửa lỗi! Nghiêm túc, kiểm tra với quản lý mục tiêu là gì. Nếu phần mềm này là cần thiết, nó có thể sẽ sớm ngăn họ nâng cấp máy tính và gây ra sự cố thay thế các máy tính cũ bị hỏng.
gnasher729

24
Câu hỏi này nghe giống như một câu nói. Tại sao bạn lại phàn nàn về một phần mềm sẽ bị xử lý trong một vài tháng?
Doc Brown

5
Không phải là "lỗi" mà mã được viết bằng "ASP cổ điển" tuân theo các tiêu chuẩn (như chúng là) của ASP cổ điển, điều này khác với thời trang mới nhất trong mã hóa web - và thời trang mới nhất có thể sẽ bị "loại bỏ" của ngày "vào năm tới trong mọi trường hợp. "Rõ ràng là các nhà phát triển không bao giờ xem tính hợp lệ của mã" - nếu OP nghĩ rằng anh ta / cô ta có thể viết mã vẫn "trông có hiệu lực" trong 15 năm trở lên trong tương lai, thời gian sẽ trả lời nếu niềm tin đó chỉ là sự lạc quan tự nhiên ( hoặc vô minh) của tuổi trẻ.
alephzero

19
"Tôi phải thực hiện một số bảo trì trên ứng dụng cũ cho đến khi nó có thể bị loại bỏ." Bảo trì gì? Hãy cụ thể. Nếu bạn được giao nhiệm vụ duy trì cơ sở mã này và không có gì khác được nói, thì đừng thay đổi một điều duy nhất. Duy trì nó ngụ ý rằng bạn tiếp tục làm cho nó hoạt động, không sửa chữa những thứ không được coi là bị hỏng ngay từ đầu.
Stephan Branchot

Câu trả lời:


99

Có vẻ như bạn đang nhầm lẫn một số điều trong thuật ngữ "lỗi"

  • thuộc tính html kế thừa
  • phong cách mã hóa
  • lỗi mã hóa không gây ra lỗi
  • lỗi không báo cáo
  • những sai lầm hiện đang là tính năng
  • báo cáo lỗi
  • báo cáo lỗi bạn đã được chỉ định để sửa

Trên một ứng dụng cũ sẽ chỉ được thay thế một trong những loại lỗi này sẽ khiến bạn lo lắng. Cái cuối cùng.

Tôi có thể nói rằng bạn thậm chí không nên cấu trúc lại những thứ khác trên một tính năng mà bạn đang sửa lỗi, chủ yếu là do:

  • những sai lầm hiện đang là tính năng

Bạn có thể thấy từ mã có thể hoạt động như thế nào nhưng không bao giờ thực hiện được, nhưng tất cả người dùng đã hòa hợp với yếu tố có chiều rộng không xác định trong 10 năm qua và họ sẽ không cảm ơn bạn vì đã sửa nó.

Về mặt tích cực, nếu bạn đặt đầu JFDI hoài nghi của mình lên, bạn sẽ có thể ghi mặc dù các lỗi siêu nhanh và nhóm phiên bản mới sẽ không thể theo kịp các tính năng của phiên bản cũ.

Điều này sẽ mang lại cho bạn nụ cười hả hê của niềm vui mỉa mai khi bạn giới thiệu trình giả lập plugin chrome6 cho khách hàng để họ có thể tiếp tục sử dụng 'tính năng' marquee mà họ yêu thích


28
"Những sai lầm hiện đang có tính năng " - ồ, niềm vui ...
FP

36
Thực sự rất thận trọng trong những gì bạn chạm vào, Điều này ngay lập tức xuất hiện trong tâm trí: xkcd.com/1172
Dennis Jaheruddin

3
Vui lòng làm rõ... JFDI ...
GER

5
@GER "Chỉ cần [khám phá] Làm điều đó" có nghĩa là tránh các tiêu chuẩn và thử nghiệm thông thường và những thứ khác và chỉ cần sửa chữa mà không quan tâm liệu nó có được thực hiện theo cách có thể duy trì và có thể đọc được hay không.
Nzall

3
thích aglie nhưng hơn thế nữa
Ewan

40

Những gì bạn hỏi không phải là một câu hỏi kỹ thuật, và không ai ở đây có thể trả lời nó.

Bạn đang làm việc trên một phần mềm trong chế độ bảo trì và bạn quan sát công nghệ lỗi thời và một số lượng lớn các điểm không hoàn hảo và không nhất quán. Bạn hỏi phải làm gì. Ví dụ, bạn có nên mở rộng nỗ lực để làm cho nó tương thích với trình duyệt không? Bạn có nên mang nó phù hợp với tiêu chuẩn hiện đại? Bạn có nên sửa lỗi không thống nhất về cú pháp trên ứng dụng không? Vấn đề là, đây là những quyết định kinh doanh . Bạn nên hỏi người quản lý hoặc chủ sở hữu sản phẩm về những vấn đề họ muốn bạn giải quyết và ưu tiên của họ là gì. Vì đã có một dự án đang được tiến hành để viết lại ứng dụng, nên rất có thể ban lãnh đạo đã nhận thức được các vấn đề bạn quan sát được.

Nếu ứng dụng sẽ được thay thế hoàn toàn trong vài tháng, có khả năng họ chỉ muốn bạn khắc phục các sự cố nghiêm trọng cụ thể và để phần còn lại của mớ hỗn độn. Nhưng chúng tôi không biết.

Bạn hỏi liệu bạn có thể thực hiện quét tìm kiếm và thay thế hoạt động trên cơ sở mã, thay đổi hàng ngàn tệp. Tất nhiên bạn có thể. Câu hỏi là nếu bạn nên . Những thay đổi sâu rộng như vậy có thể sẽ yêu cầu thử nghiệm rộng rãi để đảm bảo không có gì bị phá vỡ. Một lần nữa, đó là một quyết định kinh doanh nếu lợi ích vượt xa chi phí về thời gian và rủi ro.


1
Đó là một quyết định kinh doanh nhưng thật rõ ràng để trả lời rằng anh ta không cần phải hỏi người quản lý. Anh ta không nên dọn dẹp mớ hỗn độn nếu không cần thiết. (+1)
usr

14

Khi ứng dụng sẽ được thay thế sau 18 đến 24 tuần (thêm sự chậm trễ dự kiến ​​vào 6 đến 8 tuần ước tính được trình bày ở trên), bạn thực sự cần phải tự hỏi mình giá trị nào bạn thêm vào doanh nghiệp bằng cách vẫn đầu tư số lượng công việc đáng kể vào phiên bản cũ.

Chắc chắn, khi bạn sẽ bị mắc kẹt với việc hỗ trợ ứng dụng trong vài năm tới, thì việc loại bỏ các khoản nợ kỹ thuật có thể có giá trị trong thời gian dài. Nhưng dù sao tất cả sẽ bị đổ, vậy thì tại sao phải bận tâm? Chỉ cần thêm một bản sửa lỗi hackish khác lên trên tất cả các bản sửa lỗi hackish khác để sửa bất kỳ vấn đề nào chỉ đơn giản là không thể đợi cho đến khi phát hành phiên bản mới và gọi nó là một ngày.

Bạn cũng có thể tự hỏi những gì bạn có thể làm cho ứng dụng trong suốt cuộc đời nhỏ bé mà nó vẫn còn. Khi bạn thực sự buồn chán ngay bây giờ và đơn giản là không có gì tốt hơn với thời gian của mình, bạn có thể sửa chữa lớn và loại bỏ tất cả các vấn đề về phong cách mà bạn đã đề cập, nhưng rất có thể điều này trước tiên sẽ phá vỡ nhiều thứ hơn là nó sẽ khắc phục . Bạn có thể có thể thoát khỏi những vấn đề mới này cuối cùng cũng có đủ thời gian, nhưng bạn không có thời gian đó.


11
s/weeks/years/
CodeInChaos

9
Năm ngoái, tôi đã sửa một lỗi hiệu năng về cơ bản lên tới một bảng nên lưu trữ một số giá trị gần đây thực sự giữ tất cả lịch sử và phát triển không giới hạn. Ở vị trí thích hợp trong mã, có một bình luận nói rằng về cơ bản "điều này sẽ được xóa theo định kỳ, nhưng không thành vấn đề khi chúng tôi dự định loại bỏ hệ thống vào cuối năm 2007". Không có gì sống lâu hơn các giải pháp tạm thời.
Peteris

@Peteris Vâng, thuế tạm thời. Nhưng vâng.
Jay

Lần trước tôi làm việc trên một ứng dụng như thế này, nó cũng chỉ là tạm thời. Phần cứng mà nó được thiết kế để kiểm soát đã bị loại bỏ và một phần thay thế được xây dựng, và phần mềm mới sẽ được phát triển để kiểm soát sự thay thế., Sẽ có trong 6 tháng. Thật không may, phần cứng thay thế đã bị lỗi và tất cả ngân sách đã bỏ ra để sửa lỗi, vì vậy không còn gì cho hệ thống kiểm soát thay thế. Sau một vài năm, toàn bộ dự án đã bị hủy bỏ. AFAIK, toàn bộ hệ thống vẫn chạy trên cả phần cứng và phần mềm cũ, 5 năm sau.
Jules

May mắn thay, tôi đã nhận được giải phóng mặt bằng để khắc phục các sự cố tồi tệ nhất (các cuộc tấn công SQL SQL, các bảng SQL có hàng triệu hàng nhưng không có chỉ mục , các trang mà nhà phát triển ban đầu đã quên kiểm tra ủy quyền ...).
Jules

3

Lý do KHÔNG thực hiện thay đổi lớn:

Một: Mã sẽ biến mất trong một vài tháng. Nó có thực sự xứng đáng với thời gian của công ty để bạn dành 5 tháng để sửa chữa một hệ thống mà sau đó sẽ bị vứt đi 1 tháng sau đó không? Hãy cẩn thận: Các hệ thống hiếm khi biến mất khi chúng có lịch trình đi xa. Hệ thống thay thế hầu như luôn luôn trễ, có những người dùng không thể nâng cấp vì bất kỳ lý do gì, v.v ... Nhưng đây là một vấn đề phức tạp.

Hai: Nếu bạn thực hiện nhiều thay đổi, đặc biệt là tìm kiếm và thay thế hàng loạt, bạn sẽ giới thiệu các lỗi. Không phải bạn có thể giới thiệu lỗi: bạn sẽ. Giả sử bạn đã thực hiện S & R và thay đổi "width = 200" thành "width: 200px". Có mã C # hoặc VB trên các bảng ASP của bạn không? Bởi vì nếu bạn có một biến có tên là "chiều rộng" mà bạn đã đặt thành 200, bạn chỉ cần phá vỡ nó. . "? Bây giờ nó nói "width: 200pxmm". Được rồi, giả sử bạn nghĩ về những điều đó. Điều gì xảy ra nếu có nơi nào đó có thông số chiều rộng không hợp lệ, tất nhiên bị bỏ qua và hiện đang được bố trí khá độc đáo. Bạn "sửa" chiều rộng và hiện tại có độ phân giải 200px ... và màn hình bị vặn lên, vì thực tế 200px là chiều rộng sai để cung cấp và nó chỉ hoạt động vì giá trị đó bị bỏ qua? Mass S & R rất nguy hiểm, vì bạn gần như chắc chắn không nghiên cứu mọi nơi bạn thay đổi. Bạn có thể thậm chí không chắc chắn những gì để kiểm tra.

Ba: Mã "rõ ràng" sai trong thực tế có thể là những gì người dùng muốn. Tôi đã thấy rất nhiều thông số kỹ thuật yêu cầu hành vi rõ ràng là sai và điên rồ ... và sau đó tôi quay lại với người dùng và hỏi họ thực sự muốn gì, và hóa ra họ thực sự muốn hành vi điên rồ này, bởi vì đó là làm thế nào kinh doanh của họ hoạt động hoặc quy định của chính phủ yêu cầu nó hoặc bất cứ điều gì.

Ngay cả khi hành vi thực sự sai, có thể người dùng đã mong đợi nó và họ thường xuyên làm việc xung quanh nó và bằng cách sửa nó, bạn sẽ phá vỡ cách giải quyết của họ. Ví dụ: Tôi làm việc trên một hệ thống nơi chúng tôi có một nơi mà bạn chỉ định từ đó và qua các ngày mà việc bán hàng có sẵn cho công chúng. Cả hai ngày thực sự là nửa đêm bắt đầu từ ngày đó, vì vậy nếu bạn nói "đến hết ngày 30 tháng 7" thì có nghĩa là kết thúc vào cuối ngày 29 tháng 7, tức là một phút trước 12:01 sáng 30 tháng 7, không phải là hết ngày 30 tháng 7 Tại một thời điểm tôi đã sửa lỗi này, nhưng tôi chỉ có thể làm điều đó vì có ít hơn nửa tá người có thẩm quyền sử dụng màn hình đó và tôi chỉ có thể nói với họ tất cả những gì tôi đã sửa nó. Nếu có hàng trăm người dùng và bây giờ tất cả họ đã nhận ra rằng bạn thực sự phải đưa ra ngày này qua ngày khác, thì việc "sửa chữa" của tôi


0

Tất nhiên tôi có thể thực hiện tìm kiếm và thay thế toàn cầu để giải quyết hầu hết các vấn đề, nhưng điều đó có nghĩa là cam kết đầu tiên của tôi sẽ bao gồm hàng ngàn tệp .asp đã thay đổi. Tôi có thể làm điều đó?

Tôi không thấy lý do tại sao không. Một cam kết nên khái niệm một điều, nhưng tôi thấy không có lý do tại sao một phát toàn cầu và thay thế từ style="width=20"đến style="width: 20px"sẽ không được tính là "một điều", nói về mặt khái niệm. Và nếu nó sẽ giúp bạn ngủ ngon hơn, giúp bạn không bị phân tâm khi bạn sửa chữa những thứ khác, và không làm hỏng bất cứ điều gì , tại sao không?


12
Tại sao không? Bởi vì một tìm kiếm và thay thế sâu rộng trên một cơ sở mã di sản lớn đòi hỏi phải thử nghiệm rộng rãi sau đó để đảm bảo không có gì bị hỏng.
JacquesB

-2

Vấn đề của bạn là đặt ưu tiên : Vấn đề nào là showstoppers (trong sản xuất)? Đó là đánh dấu thời gian? Và cái nào có thể để lâu hơn (vì nó hoạt động và đã làm như vậy trong nhiều năm nay, thậm chí là loại)?

Những gì tôi sẽ làm trong tình huống của bạn là lập danh sách các lớp vấn đề mà tôi muốn xem xét. Ví dụ, thay thế style="width=(\d+)"với style="width: \1px"(mà có lẽ có thể được sửa chữa với một phát toàn cầu / thay thế sử dụng regexp - xin lỗi nếu tôi không phải là 100%) sẽ là một lớp học, và nếu chỉ có một lần xuất hiện, như vậy đi. Đối với mỗi danh mục danh sách một ưu tiên (mức độ khẩn cấp để thực hiện việc này) và ước tính công việc (sẽ mất bao lâu để thực hiện danh mục này).

Nhiệm vụ bảo trì của bạn cũng sẽ có trong danh sách này. Bây giờ bạn đang bắt đầu áp dụng một số quản lý, ngay cả khi chỉ cho chính mình và bạn có một công cụ để sử dụng khi bạn có thời gian và không có gì để làm, hoặc khi bạn cần thương lượng với người quản lý về công việc phải làm (hoặc yêu cầu thời gian để được phân bổ cho một cái gì đó mà anh ta có thể không nhận thức được). (Kiểu chủ động này có thể giúp bạn được chú ý cho các chương trình khuyến mãi, nếu được thực hiện đúng.)

Tôi đoán bạn thích lập trình bởi vì bạn có một tính cách cầu toàn ở một mức độ nào đó. NHƯNG trong một môi trường thương mại, bạn cần bắt đầu nhận ra rằng hoàn hảo là kẻ thù của sự tốt lành (và điều tốt mang lại tiền, sự hoàn hảo có thể không nhất thiết mang lại nhiều hơn đáng kể cho toàn bộ công việc nhiều hơn). Đầu tiên làm những gì cần thiết, sau đó làm những gì tốt đẹp để có. Vâng, điều này có thể đi ngược lại hạt của bạn không có kết thúc. Chỉ cần cười và chịu đựng nó, và có lẽ có một sở thích để thực hiện sự hoàn hảo của bạn và giữ cho bạn lành mạnh ;-)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.