Làm thế nào để bạn ngăn chặn các giải pháp tạm thời kéo dài mãi mãi?

Giả sử có hai giải pháp khả thi cho một vấn đề: cách thứ nhất là nhanh chóng nhưng khó hiểu; thứ hai là thích hợp hơn nhưng sẽ mất nhiều thời gian hơn để thực hiện. Bạn cần giải quyết vấn đề nhanh chóng, vì vậy bạn quyết định xử lý bản hack nhanh nhất có thể, lên kế hoạch bắt đầu công việc tìm giải pháp tốt hơn sau đó. Vấn đề là, ngay sau khi vấn đề được giải quyết, nó sẽ giảm mạnh danh sách việc cần làm. Bạn vẫn đang có kế hoạch đưa ra giải pháp tốt hơn vào một thời điểm nào đó, nhưng thật khó để biện minh cho việc thực hiện nó ngay bây giờ. Đột nhiên bạn thấy mình đã mất 5 năm để sử dụng giải pháp kém hoàn hảo, đồng thời chửi rủa nó.

Điều này nghe có vẻ quen thuộc? Tôi biết nó đã xảy ra nhiều hơn một lần ở nơi tôi làm việc. Một đồng nghiệp mô tả việc cố tình tạo ra một GUI không tốt để nó không vô tình được sử dụng lâu dài. Bạn có một chiến lược tốt hơn?

Viết một trường hợp thử nghiệm mà bản hack không thành công.

Nếu bạn không thể viết một bài kiểm tra mà bản hack không thành công, thì sau cùng thì không có gì sai với bản hack, hoặc nếu không thì khung thử nghiệm của bạn không đủ. Nếu trước đó, hãy chạy đi nhanh chóng trước khi bạn lãng phí cuộc sống của mình vào việc tối ưu hóa không cần thiết. Nếu sau này, hãy tìm cách tiếp cận khác (để gắn cờ hack hoặc thử nghiệm ...)

Chiến lược 1 (hầu như không bao giờ được chọn): Không thực hiện kluge. Thậm chí đừng để mọi người biết đó là một khả năng. Chỉ cần làm đúng cách ngay lần đầu tiên. Như tôi đã nói, cái này hầu như không bao giờ được chọn, do thời gian hạn chế.

Chiến lược 2 (không trung thực): Nói dối và lừa dối. Nói với ban quản lý rằng có lỗi trong vụ hack và chúng có thể gây ra các vấn đề lớn sau này. Thật không may, hầu hết thời gian, những người quản lý chỉ nói rằng hãy đợi cho đến khi lỗi trở thành vấn đề, sau đó sửa lỗi.

Chiến lược 2a: Tương tự như chiến lược 2, ngoại trừ thực sự có lỗi. Tuy nhiên, cùng một vấn đề.

Chiến lược 3 (và yêu thích của cá nhân tôi): Thiết kế giải pháp bất cứ khi nào bạn có thể, và thực hiện nó đủ tốt để một sinh viên thực tập hoặc khỉ mã có thể làm được. Bạn sẽ dễ dàng biện minh cho việc tiêu một số tiền nhỏ bằng mã khỉ hơn là biện minh cho đồng lương của mình, vì vậy mọi việc có thể sẽ hoàn thành.

Chiến lược 4: Chờ viết lại. Tiếp tục chờ. Sớm hay muộn (có thể là sau này), ai đó sẽ phải viết lại điều đó. Cũng có thể làm điều đó ngay lúc đó.

Đây là một bài viết liên quan tuyệt vời về nợ kỹ thuật .

Về cơ bản, nó là sự tương tự của nợ với tất cả các quyết định kỹ thuật mà bạn đưa ra. Có nợ tốt và nợ xấu ... và bạn phải chọn khoản nợ sẽ đạt được mục tiêu bạn muốn với chi phí dài hạn ít nhất.

Loại nợ tồi tệ nhất là các lối tắt tích lũy nhỏ tương tự như nợ thẻ tín dụng ... mỗi khoản không ảnh hưởng gì, nhưng chẳng mấy chốc bạn sẽ ở trong ngôi nhà nghèo.

Đây là một vấn đề lớn khi thực hiện công việc theo thời hạn. Tôi thấy rằng việc thêm các nhận xét rất chi tiết về lý do tại sao cách này được chọn và một số gợi ý về cách nó nên được mã hóa trợ giúp. Bằng cách này, mọi người nhìn vào mã sẽ thấy nó và giữ cho nó luôn mới.

Một tùy chọn khác sẽ hoạt động là thêm bug.feature vào khung theo dõi của bạn (bạn có một cái đúng không?). Bằng cách đó, nó có thể hiển thị và có thể buộc sự cố vào một số thời điểm.

Lần duy nhất bạn có thể biện minh cho việc sửa những thứ này (vì chúng không thực sự bị hỏng, chỉ là xấu xí) là khi bạn có một tính năng hoặc bản sửa lỗi khác chạm vào cùng một phần mã và bạn cũng có thể viết lại nó.

Bạn phải tính toán chi phí thời gian của một nhà phát triển. Nếu các yêu cầu phần mềm đang được đáp ứng và điều sai duy nhất là mã đang bị che khuất, thì nó không thực sự đáng để sửa.

Toàn bộ các công ty có thể ngừng hoạt động kinh doanh vì các kỹ sư quá sốt sắng yêu cầu phải tái kiến ​​trúc hàng năm hoặc lâu hơn khi họ gặp khó khăn.

Nếu nó không có lỗi và đáp ứng các yêu cầu, nó đã hoàn tất. Gửi nó đi. Tiến lên.

[Biên tập]

Tất nhiên, tôi không ủng hộ việc mọi thứ luôn bị hack. Bạn phải thiết kế và viết mã một cách cẩn thận trong quá trình bình thường của quá trình phát triển. Nhưng khi bạn kết thúc với các vụ hack mà chỉ cần thực hiện nhanh chóng, bạn phải thực hiện phân tích chi phí - lợi ích để xem liệu có đáng để xóa mã hay không. Nếu trong suốt thời gian tồn tại của ứng dụng, bạn sẽ dành nhiều thời gian hơn để viết mã cho một vụ hack lộn xộn hơn là sửa nó, thì tất nhiên hãy sửa nó. Nhưng nếu không, sẽ quá tốn kém và rủi ro khi viết mã lại một ứng dụng đang hoạt động, không có lỗi chỉ vì nhìn vào nguồn sẽ khiến bạn bị ốm.

BẠN KHÔNG LÀM GIẢI PHÁP INTERIM.

Đôi khi tôi nghĩ rằng các lập trình viên chỉ cần được nói điều này.

Xin lỗi về điều đó, nhưng nghiêm túc - một giải pháp hack là vô giá trị và ngay cả trong lần lặp đầu tiên có thể mất nhiều thời gian hơn so với việc thực hiện chính xác một phần của giải pháp.

Vui lòng ngừng để lại cho tôi mã tào lao của bạn để duy trì. Chỉ cần LUÔN LUÔN MÃ ĐÚNG. Không cần biết nó mất bao lâu và ai la mắng bạn.

Khi bạn ngồi đó xoay ngón tay cái sau khi giao hàng sớm trong khi mọi người khác đang gỡ lỗi những trò hack ngu ngốc của họ, bạn sẽ cảm ơn tôi.

Ngay cả khi bạn không nghĩ mình là một lập trình viên giỏi, hãy luôn cố gắng làm tốt nhất có thể, đừng bao giờ đi đường tắt - bạn sẽ không mất BẤT CỨ thời gian nào để làm đúng. Tôi có thể biện minh cho câu nói này nếu bạn không tin tôi.

Đột nhiên bạn thấy mình đã mất 5 năm để sử dụng giải pháp kém hoàn hảo, đồng thời chửi rủa nó.

Nếu bạn đang nguyền rủa nó, tại sao nó lại ở cuối danh sách VIỆC CẦN LÀM?

• Nếu nó không ảnh hưởng đến bạn, tại sao bạn lại nguyền rủa nó?
• Nếu nó đang ảnh hưởng đến bạn, thì đó là một vấn đề cần được khắc phục NGAY BÂY GIỜ.

• Tôi đảm bảo rằng tôi đang lên tiếng về mức độ ưu tiên của sửa chữa dài hạn, ĐẶC BIỆT sau khi sửa chữa ngắn hạn đã hoàn thành.
• Tôi nêu chi tiết lý do tại sao đó là một cuộc tấn công và không phải là một giải pháp lâu dài và sử dụng những lý do đó để yêu cầu các bên liên quan (người quản lý, khách hàng, v.v.) hiểu tại sao nó cần được sửa
• Tùy thuộc vào từng trường hợp, tôi thậm chí có thể tiêm một chút sợ trường hợp xấu nhất vào đó. "Nếu đường này bị đứt một cách an toàn, cả cây cầu có thể sụp đổ!"
• Tôi nhận trách nhiệm đưa ra một giải pháp lâu dài và đảm bảo rằng nó được triển khai

Đó là một cuộc gọi khó. Cá nhân tôi đã thực hiện các vụ hack gây ra, đôi khi bạn PHẢI đưa sản phẩm đó ra khỏi cửa và đến tay khách hàng. Tuy nhiên, cách mà tôi chăm sóc nó là cứ làm.

Nói với trưởng dự án hoặc sếp của bạn, hoặc khách hàng: Có một số điểm cần được dọn dẹp và viết mã tốt hơn. Tôi cần một tuần để làm việc đó và sẽ tốn ít chi phí hơn để làm điều đó ngay bây giờ, sau đó sẽ là 6 tháng kể từ bây giờ, khi chúng tôi cần triển khai một tiện ích mở rộng trên hệ thống con.

Thông thường những vấn đề như thế này phát sinh do giao tiếp không tốt với quản lý hoặc khách hàng. Nếu giải pháp phù hợp với khách hàng thì họ không có lý do gì để yêu cầu thay đổi giải pháp đó. Vì vậy, họ cần được thông báo trước về những đánh đổi mà bạn đã thực hiện để họ có thể lên kế hoạch thêm thời gian để khắc phục sự cố sau khi bạn thực hiện giải pháp nhanh chóng.

Làm thế nào để giải quyết nó phụ thuộc một chút vào lý do tại sao nó là một giải pháp tồi. Nếu giải pháp của bạn không tốt vì khó thay đổi hoặc bảo trì thì lần đầu tiên bạn phải bảo trì và có nhiều thời gian hơn thì đó là thời điểm thích hợp để nâng cấp lên giải pháp tốt hơn. Trong trường hợp này, sẽ hữu ích nếu bạn nói với khách hàng hoặc sếp rằng bạn đã đi đường tắt ngay từ đầu. Bằng cách đó, họ biết rằng họ không thể mong đợi một giải pháp nhanh chóng vào lần tới. Chỉnh sửa giao diện người dùng có thể là một cách hay để đảm bảo khách hàng quay lại để sửa mọi thứ.

Nếu giải pháp không tốt vì nó rủi ro hoặc không ổn định thì bạn thực sự cần nói chuyện với người lập kế hoạch và có kế hoạch thời gian để khắc phục vấn đề càng sớm càng tốt.

Chúc may mắn. Theo kinh nghiệm của tôi, điều này gần như không thể đạt được.

Một khi bạn đi xuống con dốc trơn trượt của việc thực hiện hack vì bạn đang phải chịu áp lực thì bạn cũng có thể quen với việc sống chung với nó mọi lúc. Hầu như KHÔNG BAO GIỜ có đủ thời gian để làm lại một thứ gì đó đã hoạt động, cho dù nó được triển khai nội bộ tồi tệ đến mức nào. Điều gì khiến bạn nghĩ rằng kỳ diệu sẽ có nhiều thời gian hơn "vào một ngày nào đó" để sửa lỗi?

Ngoại lệ duy nhất mà tôi có thể nghĩ ra đối với quy tắc này là nếu vụ hack hoàn toàn ngăn cản bạn triển khai một phần chức năng khác mà khách hàng cần. Sau đó, bạn không có lựa chọn nào khác ngoài việc làm lại công việc.

Tôi cố gắng xây dựng giải pháp hacky để nó có thể được chuyển sang một cách lâu dài nhất có thể. Giả sử bạn có một anh chàng đang xây dựng cơ sở dữ liệu trong SQL Server vì đó là DB mạnh nhất của anh ta, nhưng tiêu chuẩn công ty của bạn là Oracle. Xây dựng db với càng ít tính năng không thể chuyển nhượng (như kiểu dữ liệu Bit) càng tốt. Trong ví dụ này, không khó để tránh các loại bit, nhưng nó làm cho quá trình chuyển đổi sau này trở nên dễ dàng hơn.

Giáo dục cho bất kỳ ai chịu trách nhiệm đưa ra quyết định cuối cùng tại sao cách làm việc khó hiểu về lâu dài là xấu.

• Mô tả vấn đề bằng các thuật ngữ mà chúng có thể liên quan.
• Bao gồm biểu đồ đường cong chi phí, năng suất và doanh thu.
• Dạy họ về nợ kỹ thuật .
• Thường xuyên tái cấu trúc nếu bạn bị đẩy về phía trước.
• Đừng bao giờ gọi nó là "tái cấu trúc" hoặc "quay lại và dọn dẹp" trước mặt những người không rành về kỹ thuật. Thay vào đó, hãy gọi nó là "điều chỉnh" hệ thống để xử lý "các tính năng mới".

Về cơ bản, những người không hiểu phần mềm không có khái niệm về việc xem lại những thứ đã hoạt động. Theo cách họ nhìn nhận về nó, các nhà phát triển giống như những người thợ máy muốn tiếp tục tháo rời và lắp ráp lại toàn bộ chiếc xe mỗi khi ai đó muốn thêm một tính năng, điều này nghe có vẻ điên rồ đối với họ.

Nó giúp tạo ra sự tương tự với những thứ hàng ngày. Giải thích cho họ về cách khi bạn đưa ra giải pháp tạm thời, bạn đã đưa ra các lựa chọn phù hợp để xây dựng nó một cách nhanh chóng, thay vì ổn định, có thể bảo trì, v.v. Nó giống như việc chọn xây dựng bằng gỗ thay vì thép vì gỗ dễ cắt hơn, và do đó, bạn có thể xây dựng giải pháp tạm thời nhanh hơn. Tuy nhiên, gỗ đơn giản không thể hỗ trợ nền móng của một tòa nhà 20 tầng.

Chúng tôi sử dụng Java và Hudson để tích hợp liên tục. 'Các giải pháp tạm thời' phải được nhận xét bằng:

// TODO: Better solution required.

Mỗi khi Hudson chạy một bản dựng, nó cung cấp một báo cáo về từng mục CẦN LÀM để chúng tôi có một bản ghi cập nhật, dễ thấy về bất kỳ mục nào còn tồn tại cần được cải thiện.

Câu hỏi tuyệt vời. Điều này cũng làm phiền tôi rất nhiều - và hầu hết thời gian tôi là người duy nhất chịu trách nhiệm ưu tiên các vấn đề trong các dự án của riêng tôi (vâng, doanh nghiệp nhỏ).

Tôi phát hiện ra rằng vấn đề cần được khắc phục thường chỉ là một tập hợp con của vấn đề. IOW, khách hàng cần sửa chữa khẩn cấp không cần toàn bộ vấn đề được giải quyết, chỉ là một phần của nó - nhỏ hơn hoặc lớn hơn. Điều đó đôi khi cho phép tôi tạo ra một cách giải quyết không phải là giải pháp cho toàn bộ vấn đề mà chỉ cho tập hợp con của khách hàng và điều đó cho phép tôi để ngỏ vấn đề lớn hơn trong trình theo dõi vấn đề.

Tất nhiên điều đó có thể không áp dụng cho môi trường làm việc của bạn :(

Điều này làm tôi nhớ đến câu chuyện "CTool". Ban đầu CTool được đưa ra bởi một trong những nhà phát triển của chúng tôi, tôi sẽ gọi anh ấy là Don, như một cách khả thi để giải quyết vấn đề mà chúng tôi đang gặp phải. Là một người làm việc chăm chỉ nghiêm túc, Don đã cắm đầu và cung cấp một nguyên mẫu hoạt động. Bạn biết tôi sẽ đi đâu với điều này. Chỉ qua một đêm, CTool đã trở thành một phần của quy trình làm việc của công ty với toàn bộ bộ phận phụ thuộc vào nó. Đến ngày thứ hai hoặc thứ ba, những lời phàn nàn gay gắt bắt đầu lan truyền về những thiếu sót của CTool. Người dùng đặt câu hỏi về năng lực, sự cam kết và chỉ số IQ của Don. Don phản đối rằng đây không bao giờ được cho là một ứng dụng sản xuất đã rơi vào tai điếc. Điều này đã diễn ra trong nhiều năm. Cuối cùng, một người nào đó đã xung quanh để viết lại ứng dụng, ngay sau khi Don khởi hành. Vào thời điểm này, rất nhiều sự ghê tởm đã gắn liền với cái tên CTool nên việc đặt tên cho nó là CTool phiên bản 2 là điều không cần bàn cãi. Thậm chí còn có một đám tang chính thức cho CTool, phần nào gợi nhớ đến cảnh hành quyết máy photocopy (hay là một máy in?) Trong Office Space .

Một số người có thể nói Don xứng đáng với những mũi tên và cáp treo vì đã không làm cho nó đi đúng hướng để sửa CTool. Điểm duy nhất của tôi là nói rằng bạn không bao giờ nên tìm ra giải pháp có lẽ là không chính đáng trong Thế giới thực. Nhưng nếu bạn là người làm điều đó, hãy thận trọng bước đi.

• Nhận nó bằng văn bản (email). Vì vậy, khi nó trở thành một vấn đề, quản lý sau này không "quên" rằng nó được cho là tạm thời.

• Làm cho nó hiển thị cho người dùng. Càng dễ thấy thì mọi người càng ít có khả năng quên quay trở lại và làm đúng cách khi khủng hoảng kết thúc.

• Thương lượng trước khi có giải pháp tạm thời cho một dự án, tài nguyên và dòng thời gian để có được bản sửa lỗi thực sự. Công việc cho giải pháp thực sự có thể nên bắt đầu ngay sau khi giải pháp tạm thời kết thúc.

Bạn gửi một lỗi mô tả thứ hai dựa trên "bản sửa lỗi" của riêng bạn và đưa ra nhận xét việc cần làm ngay trong các khu vực bị ảnh hưởng với nội dung "Khu vực này cần rất nhiều công việc. Hãy xem lỗi # 555" (tất nhiên là sử dụng đúng số) . Những người nói "đừng hack" dường như không hiểu câu hỏi. Giả sử bạn có một hệ thống cần được thiết lập và chạy ngay bây giờ, giải pháp không hack của bạn là 8 ngày làm việc, hack của bạn là 38 phút làm việc, việc hack ở đó để bạn có thời gian thực hiện công việc và không bị mất tiền trong khi bạn đang làm điều đó.

Bây giờ bạn vẫn phải yêu cầu khách hàng hoặc ban quản lý của mình đồng ý lên lịch N * 100 phút thời gian cần thiết để thực hiện sửa chữa thực sự ngoài N phút cần thiết hiện tại để khắc phục. Nếu bạn phải từ chối thực hiện hack cho đến khi bạn đạt được thỏa thuận như vậy, thì có lẽ đó là điều bạn phải làm, nhưng tôi đã làm việc với một số người hiểu biết về vấn đề đó.

Giá thực sự của việc giới thiệu bản sửa lỗi nhanh là khi người khác cần giới thiệu bản sửa lỗi nhanh thứ 2, họ sẽ giới thiệu bản sửa lỗi nhanh đó dựa trên bản sửa lỗi nhanh của chính bạn. Vì vậy, việc sửa chữa nhanh được đặt ra càng lâu thì nó sẽ càng trở nên cố thủ hơn. Thông thường, một vụ hack chỉ mất nhiều thời gian hơn một chút so với việc thực hiện đúng, cho đến khi bạn gặp phải lần hack thứ hai được xây dựng trên lần đầu tiên.

Vì vậy, rõ ràng là (hoặc dường như) đôi khi cần thiết để đưa ra một bản sửa lỗi nhanh chóng.

Một giải pháp khả thi, giả sử kiểm soát phiên bản của bạn hỗ trợ nó, là giới thiệu một nhánh rẽ từ nguồn bất cứ khi nào bạn thực hiện một vụ hack như vậy. Nếu mọi người được khuyến khích tránh mã hóa các tính năng mới trong các fork đặc biệt "làm cho xong việc" này, thì việc tích hợp các tính năng mới với fork sẽ tốn nhiều công sức hơn là để thoát khỏi vụ hack. Tuy nhiên, nhiều khả năng là fork "tốt" sẽ bị loại bỏ. Và nếu bạn còn đủ xa để phát hành rằng việc thực hiện một đợt fork như vậy sẽ không thực tế (vì nó không đáng thực hiện tích hợp kép được đề cập ở trên), thì có lẽ bạn thậm chí không nên sử dụng hack.

Một cách tiếp cận rất duy tâm.

Một giải pháp thực tế hơn là giữ cho chương trình của bạn được phân đoạn thành nhiều thành phần trực giao nhất có thể và thỉnh thoảng viết lại hoàn chỉnh một số thành phần.

Một câu hỏi hay hơn là tại sao giải pháp hacky lại tệ. Nếu nó xấu vì nó làm giảm tính linh hoạt, hãy bỏ qua nó cho đến khi bạn cần sự linh hoạt. Nếu nó xấu vì nó ảnh hưởng đến hành vi của chương trình, hãy bỏ qua nó và cuối cùng nó sẽ trở thành một bản sửa lỗi và SẼ được giải quyết. Nếu nó xấu vì nó trông xấu xí, hãy bỏ qua nó, miễn là bản hack được bản địa hóa.

Một số giải pháp tôi đã thấy trong quá khứ:

• Đánh dấu nó bằng một nhận xét HACKtrong mã (hoặc lược đồ tương tự như XXX)
• Có một báo cáo tự động chạy và được gửi qua email hàng tuần cho những người quan tâm đến việc đếm số lần HACKnhận xét xuất hiện
• Thêm một mục mới vào hệ thống theo dõi lỗi của bạn với số dòng và mô tả về giải pháp phù hợp (để kiến ​​thức thu được từ nghiên cứu trước khi viết bản hack không bị mất)
• viết một trường hợp thử nghiệm chứng minh cách hack không thành công (nếu có thể) và kiểm tra nó vào bộ thử nghiệm thích hợp (tức là để nó ném ra các lỗi mà cuối cùng ai đó sẽ muốn dọn dẹp)
• khi hack được cài đặt và áp suất tắt, hãy bắt đầu ngay giải pháp phù hợp

Đây là một câu hỏi tuyệt vời. Một điều tôi nhận thấy khi tôi có thêm kinh nghiệm: hack sẽ khiến bạn mất một khoảng thời gian rất ngắn và thường khiến bạn phải trả một số tiền lớn hơn. Có liên quan mật thiết là 'sửa chữa nhanh' giải quyết những gì bạn nghĩ là vấn đề - chỉ để phát hiện ra khi nó nổ tung rằng đó không phải là vấn đề.

Tạm gác cuộc tranh luận về việc bạn có nên làm hay không, hãy giả sử rằng bạn phải làm. Mẹo bây giờ là làm theo cách giảm thiểu ảnh hưởng tầm xa, sau này dễ bị bung ra và tự gây phiền toái nên bạn nhớ khắc phục nhé.

Phần phiền toái rất dễ dàng: làm cho nó đưa ra cảnh báo mỗi khi bạn thực hiện k bùn.

Phần tách ra có thể dễ dàng: Tôi thích làm điều này là đặt k bùn phía sau tên chương trình con. Điều đó giúp bạn cập nhật dễ dàng hơn vì bạn phân chia kích thước mã. Khi bạn nhận được giải pháp vĩnh viễn của mình, chương trình con của bạn có thể triển khai nó hoặc là không. Đôi khi một lớp con cũng có thể hoạt động tốt cho việc này. Tuy nhiên, đừng để người khác phụ thuộc vào bất cứ cách sửa chữa nhanh chóng của bạn. Thật khó để đề xuất bất kỳ kỹ thuật cụ thể nào mà không nhìn thấy tình hình.

Giảm thiểu các hiệu ứng tầm xa sẽ dễ dàng nếu phần còn lại của mã tốt. Luôn đi qua giao diện đã xuất bản, v.v.

Cố gắng làm cho chi phí của vụ hack rõ ràng với những người kinh doanh. Sau đó, họ có thể đưa ra quyết định sáng suốt theo một trong hai cách.

Bạn có thể cố ý viết nó theo cách quá hạn chế và có chủ đích và sẽ yêu cầu viết lại để sửa đổi.

Chúng tôi phải làm điều này một lần - tạo một phiên bản demo ngắn hạn mà chúng tôi biết rằng chúng tôi không muốn giữ lại. Khách hàng muốn nó trên hộp winTel, vì vậy chúng tôi đã phát triển nguyên mẫu trong SGI / XWindows. (Chúng tôi đã thông thạo cả hai, vì vậy nó không phải là một vấn đề).

Lời thú tội:

Tôi đã sử dụng '#define private public' trong C ++ để đọc dữ liệu từ một số lớp mã khác. Nó đã bị hack nhưng hoạt động tốt và việc sửa chữa nó chưa bao giờ trở thành ưu tiên. Bây giờ là 3 năm sau ...

Một trong những lý do chính khiến các bản hack không bị loại bỏ là nguy cơ người ta đưa ra các lỗi mới trong khi sửa lỗi. (Đặc biệt là khi xử lý các cơ sở mã trước TDD.)

Câu trả lời của tôi hơi khác so với những người khác. Kinh nghiệm của tôi là các phương pháp sau giúp bạn duy trì sự nhanh nhẹn và chuyển từ các giải pháp lặp lại / alpha đầu tiên của hackey sang phiên bản beta / sẵn sàng sản xuất:

1. Hướng phát triển thử nghiệm

2. Các đơn vị tái cấu trúc nhỏ

3. Tích hợp liên tục
4. Quản lý cấu hình tốt
5. Kỹ thuật cơ sở dữ liệu nhanh / tái cấu trúc cơ sở dữ liệu

Và không nên nói rằng bạn phải có sự hỗ trợ của các bên liên quan để thực hiện bất kỳ điều nào trong số này một cách chính xác. Nhưng với những sản phẩm này, bạn có các công cụ và quy trình phù hợp để nhanh chóng thay đổi sản phẩm theo những cách chính một cách tự tin. Đôi khi khả năng thay đổi của bạn là khả năng quản lý rủi ro của những thay đổi và từ quan điểm phát triển, những công cụ / kỹ thuật này mang lại cho bạn chỗ đứng vững chắc hơn.