Chứng minh mã xấu cho khách hàng?

Một khách hàng đã yêu cầu tôi thiết kế lại trang web của họ, một ứng dụng ASP.NET Webforms được phát triển bởi một nhà tư vấn khác. Nó có vẻ như là một công việc tương đối đơn giản, nhưng sau khi xem mã, rõ ràng đó không phải là trường hợp.

Ứng dụng này đã không được viết tốt. Ở tất cả. Nó rất dễ bị tấn công SQL SQL, logic kinh doanh được lan truyền trong toàn bộ ứng dụng, có rất nhiều sự trùng lặp và mã kết thúc không có gì. Trên hết, nó tiếp tục ném các ngoại lệ đang bị làm mờ đi, vì vậy trang web dường như chạy trơn tru.

Công việc của tôi chỉ đơn giản là cập nhật HTML và CSS, nhưng phần lớn HTML đang được tạo ra theo logic nghiệp vụ và sẽ là một cơn ác mộng khi sắp xếp. Ước tính của tôi về thiết kế lại dài hơn so với khách hàng đã nhắm đến. Họ đang hỏi tại sao quá lâu.

Làm thế nào tôi có thể giải thích cho khách hàng của tôi chỉ là mã này xấu như thế nào? Trong tâm trí của họ, ứng dụng đang chạy rất tốt và thiết kế lại nên nhanh chóng. Đó là lời của tôi chống lại nhà tư vấn trước đó. Làm thế nào tôi có thể đưa ra các ví dụ đơn giản, cụ thể mà một khách hàng không có kỹ thuật sẽ hiểu?

Cập nhật

Cảm ơn vì tất cả những phản hồi. Trình diễn tấn công tiêm SQL có ý nghĩa và tôi sẽ demo nó trong môi trường thử nghiệm. Đó chỉ là một phần của nhiều vấn đề trong ứng dụng này. Tôi đang tìm cách giải thích tại sao các phần khác (chẳng hạn như html được tạo trong lớp dữ liệu) sẽ cần phải được thay thế bằng các thực tiễn tốt hơn để cập nhật html và css. Có nhiều gợi ý hay ở đây mà tôi sẽ ghép lại khi nói chuyện với khách hàng của mình.

Những người không chuyên về công nghệ không phải là những kẻ ngốc (đối với hầu hết các phần). Họ có thể hiểu một đối số kỹ thuật nếu bạn giữ nó đủ cao. Chọn một nhiệm vụ mà bạn nghĩ nên đơn giản và hướng dẫn họ thực hiện tại sao không.

Tôi dự kiến ​​sự thay đổi này là một từ trong một tệp. Nơi có khả năng nhất để thay đổi nó dường như là ở đây, nhưng khi tôi thay đổi nó ở đó, nó chỉ hoạt động ở một nơi, và nó đã phá vỡ 7 nơi khác. Khi tôi sửa một cái, nó bị vỡ thêm hai chỗ nữa, gây ra hiệu ứng domino, vì vậy một sự thay đổi mà tôi nghĩ nên mất 10 phút đã kết thúc sau 2 giờ. Đó chỉ là một ví dụ. Có rất nhiều nhiệm vụ 2 giờ bất ngờ trong đó.

Cấu trúc mã, kiểu dáng, nợ kỹ thuật là một điều mà - ít nhất là ban đầu, cho đến khi khách hàng tin tưởng bạn - bạn sẽ cần phải sống cùng.

Lỗ hổng bảo mật là một vấn đề khác.

Cá nhân, tôi sẽ làm một ước tính dựa trên công việc cần thiết bằng cách sử dụng cấu trúc và kiểu dáng hiện có trong khi làm rõ rằng có những vấn đề quan trọng với cơ sở mã. Tôi muốn nâng cao ý nghĩa bảo mật một cách riêng biệt: thực hiện một cuộc tấn công vào cơ sở dữ liệu để lái xe về nhà trong một cuộc họp.

Tôi đã rất vui khi làm điều này với một khách hàng trước đây với hệ thống thẻ quà tặng khách hàng thân thiết khi tôi đặt 5000 bảng vào thẻ "của tôi" và nhờ anh ấy kiểm tra thẻ cho đến khi.

Một số gợi ý tuyệt vời ở đây về cách truyền đạt và truyền đạt điều này đến khách hàng. Hy vọng họ sẽ trả hết cho bạn.

Cờ đỏ lớn đây!

Nếu khách hàng yêu cầu bạn không thực hiện bất kỳ thay đổi nào ngoài những gì bạn đã đồng ý (HTML và CSS) tôi sẽ chuyển qua dự án này và rút giá thầu của tôi.

Ngay cả với một tổng quan bằng văn bản và được truyền đạt tốt về tất cả các lỗi và vấn đề bảo mật, trách nhiệm pháp lý là quá lớn để tôi có thể thoải mái. Ngay cả khi khách hàng không bao giờ thực hiện bất kỳ hành động pháp lý hoặc yêu cầu sửa chữa sau khi hack hoặc vi phạm; tên và danh tiếng của bạn vẫn còn gắn liền với công việc!

Bạn cũng có thể mất nhiều hơn nhiều so với bạn đứng để đạt được.

Giải thích và có thể chứng minh lỗ hổng
Khi lời nói của bạn chống lại anh ta, mọi điều bạn nói chỉ có thể là không khí nóng như họ quan tâm. Khi bạn chỉ cho họ cách ứng dụng của họ có thể bị lạm dụng thông qua SQL tiêm, thì đột nhiên bạn là người đáng tin cậy. Bạn sẽ cần sự tín nhiệm để đàm phán lại. Và điều này là đủ của một người thay đổi trò chơi để cung cấp cho bạn.

Có lòng từ thiện đối với người tiền nhiệm
Điều đó không có nghĩa là giả vờ những sai lầm không có ở đó, nhưng nếu bạn gặp phải sự hạ thấp thì bạn sẽ mất uy tín. Đừng nói một lời nào về lập trình viên ngoại trừ có thể mang lại cho anh ta lợi ích của sự nghi ngờ. Tập trung vào mã, không phải là lập trình viên. Làm cho họ cảm thấy như bạn là "người tốt" sẽ giúp bạn mất nhiều thời gian hơn trong các cuộc đàm phán. Và "những người tốt" không bao giờ nói những điều có ý nghĩa. Khi giải thích các lỗi bảo mật hiện có (như lỗ hổng SQL tiêm) cho máy khách, tôi thích nói điều gì đó như sau:

Bảo mật ứng dụng web là một lĩnh vực phát triển nhanh chóng. Nhiều công cụ và kỹ thuật phát triển mà mọi người học được ngay cả ngày nay đã phát triển trước khi hầu hết các khai thác này được hiểu rõ. Để đi trước các phát triển bảo mật, bạn phải theo dõi lĩnh vực rất chặt chẽ và đôi khi thậm chí thay đổi toàn bộ phong cách phát triển của bạn. Hầu hết các lập trình viên không làm điều này.

Chúng tôi đi đây. Không một lời ác nói về nhà phát triển; anh ấy chỉ là "hầu hết các lập trình viên", có nghĩa là anh ấy ở công ty khá tốt. Và bây giờ bạn đã chứng minh rằng bạn không phải là "hầu hết các lập trình viên", điều đó mang lại cho bạn sự tin cậy hơn một chút và có lẽ là lý do để họ trả cho bạn nhiều tiền hơn.

Đàm phán một sự sắp xếp mới
Một khi khách hàng hiểu rằng ứng dụng của anh ta bị công chúng lạm dụng, anh ta sẽ muốn nó được sửa chữa. Bạn có thể là người anh ấy sẽ yêu cầu sửa nó. Bạn có thể hoặc không muốn công việc đó, vì vậy hãy suy nghĩ kỹ trước khi nói chuyện với họ.

Ít nhất, bạn muốn có thêm thời gian để hoàn thành công việc họ đã giao cho bạn. Bạn đã đặt chúng đủ cảnh giác với những thứ dễ bị tổn thương mà chúng có thể sẽ không giữ bạn theo ước tính ban đầu của bạn. Nhưng hãy chắc chắn rằng khách hàng biết bạn là ai và sẽ không sửa chữa như là một phần của sự sắp xếp này.

Thông thường, nhà phát triển (bạn) muốn làm lại toàn bộ từ đầu. Và trong những trường hợp như thế này, đó thậm chí có thể là một lựa chọn. Nhưng ngay cả khi đó, khách hàng sẽ muốn một cái gì đó có thể duy trì hoạt động kinh doanh của mình cho đến khi ứng dụng mới được xây dựng. Điều này có nghĩa là ngay cả khi bạn bắt đầu lại, có lẽ bạn vẫn sẽ phải cập nhật ứng dụng cũ một chút.

Tôi đã bắt đầu điều này như một bình luận, bởi vì lúc đầu tôi nghĩ nó là một bên, nhưng có lẽ nó thực sự không.

Tôi sẽ ghi lại đầy đủ mọi thứ mà bạn cảm thấy nên được thiết kế lại, và tại sao (điều gì xảy ra nếu họ không thực hiện thay đổi) và ước tính về việc khắc phục sự cố. Tôi sẽ đặc biệt tỉ mỉ với bất cứ điều gì bạn cho là rủi ro bảo mật.

Tôi sẽ làm điều này trước khi chạm vào bất kỳ mã nào và đảm bảo rằng khách hàng của bạn có một bản sao của báo cáo này, tốt nhất là với một loại dấu thời gian. Nó có thể mất một chút thời gian, nhưng nó cũng sẽ bảo vệ bạn nếu một trong những rủi ro bảo mật này trở thành hiện thực. Thậm chí tốt hơn nếu bạn có thể nhận được một cái gì đó đã ký mà nói rằng họ đã nhận được tài liệu.

Chắc chắn, bạn có thể chỉ ra kiểm soát nguồn của mã gốc mà bạn đã thừa kế nếu nó xảy ra, nhưng sẽ dễ dàng hơn để chỉ vào tài liệu này và nói, theo cách chuyên nghiệp hơn, "Thấy không? Tôi đã nói với bạn như vậy."

Tài liệu này có thể là điểm khởi đầu của các cuộc thảo luận tiếp theo và thậm chí khách hàng của bạn có thể sử dụng nó để có được "đúng người" để cho phép thực hiện một số hoặc tất cả các thay đổi.

Điều đó đang được nói, một khi khách hàng tháo gỡ rủi ro, hãy cười và chịu đựng nếu họ nói sẽ thực hiện công việc bằng mọi cách, hoặc bỏ đi.

Hãy nhớ rằng khách hàng sẽ nhờ bạn giúp đỡ trong việc duy trì ứng dụng của họ. Công việc của bạn là một chuyên gia để chỉ ra bất kỳ vấn đề nào bạn tìm thấy với ứng dụng của họ. Khách hàng có thể không biết những vấn đề này tồn tại và họ nên được biết về chúng. Giải thích những vấn đề này theo cách mà họ có thể hiểu và để họ quyết định cách họ muốn tiến hành.

Sử dụng các ví dụ trong thế giới thực để minh họa các vấn đề này, chẳng hạn như xe bị hỏng hoặc máy giặt cần sửa chữa. Để chỉ là sử dụng các ví dụ họ đã quen thuộc. Để giải thích về việc tiêm SQL, tôi chỉ đơn giản là chứng minh đó là gì và tại sao nó lại là một vấn đề.

Cuối cùng, bạn muốn truyền đạt rằng bạn quan tâm đến sự thành công của ứng dụng mà bạn đang được yêu cầu làm việc.

Tôi thích sử dụng các chất tương tự khách hàng có thể liên quan đến. Số lượng công việc tôi đặt trước để giành được công việc sẽ phụ thuộc vào số tiền khách hàng dự định chi tiêu (100 đô la khác xa so với 20.000 đô la). Thông báo tôi đã nói "dự định". Ước tính cá nhân của bạn về giá trị liên quan không có ý nghĩa nhiều nếu bạn không nhận được những gì bạn yêu cầu.

Trong tình huống của bạn - một lần nữa tùy thuộc vào tiền - tôi có thể vẽ một hộp với một dòng đi ra từ mỗi bên và nói với khách hàng "Đây là cách bạn hình dung phần mềm ngay bây giờ. Tất cả dữ liệu đi vào một đầu trông đẹp và sạch sẽ và đơn giản ". "Đây là những gì bạn nghĩ phần mềm trông giống như bên trong" và sau đó vẽ một dòng thứ ba kết nối hai dòng bên trong hộp.

Sau đó, tôi sẽ vẽ một hộp khác giống như hộp đầu tiên với các dòng đầu vào và đầu ra ở bên ngoài, ngoại trừ lần này tôi sẽ nói "Đây là phần mềm thực sự trông như thế nào bên trong hộp ngay bây giờ." và sau đó để kết nối hai dòng lần này, tôi sẽ vẽ một đống mỳ spaghetti ngẫu nhiên, có thể bằng các ngắt và nối và viết nguệch ngoạc.

Cuối cùng tôi sẽ nói, "Bây giờ những gì bạn yêu cầu tôi làm là ..." và vẽ một hình đơn giản bên trong hộp đầu tiên có lẽ là một nửa vòng tròn nhỏ chạm vào dòng và sau đó nói "nhưng để làm điều đó, tôi ' tôi phải làm điều này ... "và vẽ một cơn lốc xoáy có hình dạng xoắn ốc xung quanh đường dây và tiếp tục ..." để có được tất cả những điều này ..... "và chỉ vào spaghetti trong hộp khác.

Tôi nghĩ rằng sẽ lái xe về nhà trong khoảng 2 phút. Nếu họ cứ khăng khăng bạn làm điều đó thì hãy ghi lại như những người khác đã đề cập ở trên.

Làm thế nào tôi có thể giải thích cho khách hàng của tôi chỉ là mã này xấu như thế nào?

Có lẽ bạn có thể sử dụng một sự tương tự như hệ thống ống nước trong một ngôi nhà mà theo thời gian, sau khi sửa chữa và sửa sang lại, trở nên gượng gạo và kết hợp với nhau khi sửa chữa một thứ, ảnh hưởng và có thể phá vỡ một thứ khác mà sau đó cần sửa chữa và không có cách nào để bạn biết tất cả những nơi mà điều này sẽ xảy ra.

Đó là lời của tôi chống lại nhà tư vấn trước đây, vậy làm thế nào tôi thực sự có thể đưa ra những ví dụ đơn giản, cụ thể mà một khách hàng không có kỹ thuật sẽ hiểu?

Bạn nói đúng, đó là từ chống lại bất cứ hình ảnh nào mà nhà tư vấn trước đó đã tạo ra trong đầu họ. Đề nghị của tôi là chỉ làm những gì bạn yêu cầu, đưa ra những ví dụ đơn giản, cụ thể. Vì đây là thiết kế lại, hãy hiển thị cách một đoạn HTML được xác định trong mã được biên dịch được hiển thị với phần còn lại của trang HTML và cách thay đổi ảnh hưởng đến hoặc không, phần còn lại của trang. Có lẽ cùng một mã được biên dịch biểu hiện đánh dấu sau khi áp dụng một số quy tắc "kinh doanh". Cho thấy sự khác biệt.

Đây là một vấn đề phổ biến và RẤT phổ biến. Chúc may mắn với điều đó.

Hãy trung thực và trực tiếp.

Nhưng quan trọng nhất là không đảm nhận một công việc không đáp ứng mong đợi của bạn. Hầu hết mọi người không nhận ra rằng một nhà thầu có thể sa thải khách hàng, họ có thể và nên làm nếu công việc gặp nhiều rắc rối hơn giá trị.

Đây là một sự tương tự tôi đã sử dụng (mặc dù tôi không chứng minh tính hiệu quả của nó): Hãy tưởng tượng trang web của họ là một máy vật lý, giống như một máy in cơ học bằng cách nào đó chấp nhận đầu vào.

Họ có thể nghĩ rằng máy có thành phần X và một máy khác có Y. Trong thực tế, đó là 20 hoặc gần như các máy tương tự. Một số người trong số họ không còn làm bất cứ điều gì, tất cả trong số họ cố gắng tạo ra các chức năng mà những người khác đã làm và không ai ngoài nhà tư vấn trước đó đã từng thấy bất cứ điều gì giống như họ trước đây.

"Xem gizmo này ở đây để phân tích các biến bài và sau đó gửi thành phần này xuống một lỗ thỏ của if-elses? Không chỉ có một trong số này, có một trong số này trong mỗi trang (hoặc bất cứ điều gì), một số trong số chúng vệ sinh đầu vào và một số không (hoặc tất cả không) và không đọc toàn bộ điều tôi không thể biết. "

Một điểm chưa thực sự được đề cập là bạn có thể chỉ đơn giản là đang vượt qua những gì khách hàng thực sự muốn từ bạn trong trường hợp này. Quá sức là tuyệt vời và có thể cung cấp cho bạn rất nhiều sự hài lòng trong công việc. Nhưng nếu khách hàng đơn giản là không quan tâm, nghĩ rằng hiệu suất hiện tại là "đủ tốt" và chỉ muốn một số cập nhật nhỏ, có thể không thể thuyết phục họ đầu tư lớn vào bạn để đại tu cơ sở mã.

Vào thời điểm đó, có lẽ bạn sẽ cần phải quyết định xem có nên tuân thủ các nguyên tắc và từ chối nhận một công việc buộc bạn phải gắn tên tốt của mình vào một mớ hỗn độn mã hay bạn có thể giữ mũi, vào trong, hoàn thành công việc với một số băng keo, và nhận được với thanh toán của bạn.

Nếu bạn quyết định đi trước với công việc băng keo, hãy đảm bảo tài liệu, tài liệu, tài liệu và càng minh bạch càng tốt. Điều cuối cùng bạn muốn là bị đổ lỗi cho một sự cố xảy ra trong tương lai, đó là kết quả của một lỗ hổng ứng dụng mà bạn đã cảnh báo khách hàng về việc đó nhưng khách hàng quyết định không đủ quan trọng để giải quyết vào lúc đó.

Theo như các rủi ro tiêm SQL, như những người khác đã nói, bạn sẽ có thể chứng minh cho các mối nguy hiểm đó theo cách cho thấy các rủi ro mà không thực sự làm bất cứ điều gì phá hoại trong sản xuất. Nhưng một lần nữa, nếu họ thấy nó và không quan tâm đủ để trả tiền cho bạn để sửa nó, bạn đã thực hiện sự siêng năng thiện chí của mình trong trường hợp này.

Đó là sốt Noob để đi vào một dự án và đề nghị một điều viết lại đầu tiên, thực hiện một số nhóm nhỏ của những sửa đổi và sử dụng những để minh họa cho bao nhiêu đơn giản hơn và rẻ hơn nó có thể có được. Sau đó, bạn có một trường hợp rõ ràng về lý do tại sao chi phí phát triển sạch hơn sẽ dẫn đến chi phí bảo trì thấp hơn và phát triển nhanh hơn trong thời gian dài với một ít chi phí bên phông chữ.

Đừng bao giờ quên rằng về cơ bản, bạn đang yêu cầu họ trả tiền cho bạn để làm cho cuộc sống của bạn dễ dàng hơn, trong tâm trí họ chỉ cần tìm "anh chàng" có thể làm nổi bật chi phí Y và phóng đại sự phức tạp của dự án của bạn có thể loại bỏ cơ hội cho bạn. Đó là một con đường khó khăn khi bạn viết lại một tháng và bạn chỉ gặp nhà phát triển ban đầu để nhận ra toàn bộ ứng dụng được viết trong một cửa sổ cực kỳ hợp đồng bởi một nhà phát triển, người hiểu đầy đủ tất cả các thỏa hiệp đã được thực hiện. Nếu ứng dụng bên trong trông khủng khiếp nhưng bên ngoài hoạt động tốt, như bạn nói, rất có khả năng đây sẽ là trường hợp. Thông thường, nợ kỹ thuật trong một cơ sở mã là một sản phẩm của các hạn chế tài nguyên mà mã được phát triển và nếu họ không xây dựng một nhóm và thay vào đó là ký kết hợp đồng ...

Tôi chỉ đang nói'

Tôi sẽ chơi trò bênh vực của quỷ ở đây (phần nào đó giống như những gì @khrome đang nói: "bạn không trả tiền cho khách hàng để làm cho cuộc sống của bạn dễ dàng hơn"). Tôi thậm chí sẽ đi xa hơn khi nói rằng trường hợp bạn trình bày là quá một chiều vì bạn đã mô tả trường hợp một cách chung chung. Hầu hết các chuyên gia tư vấn đến dự án mới sẽ chiếu ánh sáng xấu đến dự án trước đó ... Tôi không nói đó là những gì bạn đang làm ở đây, nhưng cho đến khi chúng tôi thấy các ví dụ, tôi không thể đơn giản nhận lời của bạn cho nó.

Điều đó nói rằng, tôi sẽ cố gắng giải quyết các vấn đề cho bạn từng điểm:

• Tiêm SQL . OK, vì vậy tôi đoán rằng lập trình viên đã sử dụng nối chuỗi thay vì truy vấn tham số và / hoặc thủ tục được lưu trữ. Điều này rất dễ khắc phục, đặc biệt là trong ADO.NET ... Cá nhân tôi sẽ đề cập đến nó cho khách hàng nhưng không thực hiện quá nhiều vấn đề lớn từ nó.
• HTML đang được tạo ra trong logic kinh doanh và sẽ là một cơn ác mộng sắp xếp . OK, anh bạn, đây là một trong những nơi mà bạn cho tôi biết thêm chi tiết. Trừ khi bạn đang sử dụng MVC, đây là một xu hướng xảy ra ... nhưng nó không hẳn là điều xấu ... đó là một trong những điều mà hầu hết các lập trình viên sẽ nói " goto là xấu, không bao giờ sử dụng nó" nhưng bạn biết gì không? Tôi đã sử dụng goto khi nó có ý nghĩa! Vì vậy, bạn có chắc chắn rằng họ không sử dụng các lớp trợ giúp tình cờ chia sẻ cùng một không gian tên như mã DLL kinh doanh? Một lần nữa, nó không khó để cô lập.
• logic kinh doanh được lan truyền trong toàn bộ ứng dụng, có rất nhiều sự trùng lặp và mã kết thúc không có gì. . Và? Khách hàng chỉ yêu cầu bạn thay đổi HTML / CSS. Tại sao bạn lại quan tâm đến những vấn đề này?
• nó tiếp tục ném các ngoại lệ đang bị làm mờ đi, vì vậy trang web dường như chạy trơn tru . Một lần nữa, rất mơ hồ. Các ngoại lệ là bình thường trong bất kỳ ứng dụng nào, đó là lý do tại sao chúng tôi có các mệnh đề thử / bắt trong mã của chúng tôi. Trừ khi chúng nổi bong bóng trong UI và làm hỏng trải nghiệm người dùng (như hiển thị HTTP 500 một cách không cần thiết), tôi cũng không nghĩ đây là điều mà bạn nên quan tâm, hoặc ..

Vì vậy, trong ngắn hạn, tôi sẽ khuyên bạn nên đi đường cao tốc. Nếu bạn nghĩ rằng nó không xứng đáng với thời gian của bạn và bạn muốn viết lại nó với chi phí của khách hàng, thì hãy bỏ công việc đi. Nghiêm túc mà nói, cuối cùng, khách hàng trả tiền cho thời gian của bạn để làm cho toàn bộ hoạt động với số tiền $$$ ít nhất.

Trong nhiều năm kinh nghiệm trong lĩnh vực này, tôi luôn nói rằng những lập trình viên giỏi nhất mà tôi gặp là những người có thể làm cho hệ thống ổn định bằng cách viết ít mã nhất , không phải bằng cách viết lại toàn bộ .

Chỉnh sửa: Tôi đã thấy rằng câu trả lời của tôi không phải là câu trả lời phổ biến nhất (tôi đã mong đợi điều này) nhưng tôi đứng trước phản ứng của mình. Tôi chỉnh sửa nó để làm cho nó bớt ngớ ngẩn. ;-)

Chắc chắn các cuộc tấn công SQL SQL và các lỗi chức năng khác trong ứng dụng được ưu tiên, nhưng bạn cũng có thể "chứng minh" các thực tiễn và chất lượng mã xấu. Với các công cụ đo lường mã, bạn có thể chứng minh rõ ràng mức độ xấu của mã và cho anh ta biết số tiền này sẽ tăng thêm bao nhiêu cho bất kỳ thay đổi nào trong tương lai và sửa lỗi. Tôi không quen thuộc với môi trường .net nhưng tôi chắc chắn có một vài thứ để chọn.