Làm thế nào để đối phó với các sản phẩm tuyệt vời được viết bằng mã crappy?

Question

Tôi được yêu cầu cải thiện và duy trì một ứng dụng Web nội bộ được sử dụng và được chấp thuận bởi một cộng đồng người dùng quan trọng. Điều này bao gồm cải tiến hiệu suất và thêm tính năng.

Thật không may, mã bị cồng kềnh, đôi khi rất kém được viết và khó đọc và thay đổi. Điều này làm cho những thay đổi khó thực hiện hơn nhiều.

Mặc dù tất cả điều này, ứng dụng là đẹp, hữu ích và người dùng thích nó và muốn thay đổi.

Đó là lý do tại sao tôi cảm thấy mình đã bị lừa. Có thực sự tốt hơn để viết mã crappy cho kết quả tuyệt vời nhanh hơn và vinh quang, sau đó để lại cho các dự án mới tuyệt vời để lại một số lượng vấn đề phía sau?

Tôi đã đọc rất nhiều về chủ đề này vào ngày Coding Horror rồi, nhưng tôi muốn đọc thêm từ những người ở đây đang trải nghiệm thực tế đáng buồn này và cách họ đối phó với nó. Có lẽ tôi cũng cần phải có chút dũng cảm;)

Vì ngôn ngữ chính của tôi không phải là tiếng Anh, vui lòng viết lại câu hỏi này bằng ngữ pháp tốt hơn.

Answer 1

Điều này sẽ xảy ra với hầu hết các lập trình viên. Sự thôi thúc đầu tiên là viết lại nó. Cách tiếp cận tốt hơn là chỉ làm những gì bạn đang được yêu cầu làm. Nếu bạn đi vào viết lại lớn, bạn rất có khả năng phá vỡ nó.

Nếu các thay đổi cần rất đơn giản, bạn nên thực hiện chúng với càng ít thay đổi khi một có thể, trong phong cách mà nó đã được viết bằng.

Nếu những thay đổi phức tạp hơn, sau đó cố gắng áp dụng các thay đổi trong càng ít chỗ càng tốt. Nếu kế hoạch của bạn là dọn sạch mã theo thời gian thì đây là nơi bắt đầu. Hãy cẩn thận với những thay đổi bạn thực hiện, bởi vì bạn có thể dễ dàng phá vỡ các phụ thuộc mà bạn không hiểu. Đó là kinh nghiệm cá nhân của tôi mà tôi thường có thể thêm các tính năng mới hoặc thực hiện các thay đổi bằng cách thực sự loại bỏ mã và viết lại những gì còn lại trong bất kỳ thói quen hoặc phương pháp nhất định nào.

Chống lại sự cám dỗ của bạn để viết lại mọi thứ. Nhìn vào nó như là phân loại. Ưu tiên các thay đổi bạn muốn xem và triển khai chúng khi bạn triển khai các thay đổi đang được yêu cầu. Tránh ảnh hưởng đến mã mà bạn không bị yêu cầu thay đổi. Đừng ép buộc người dùng của bạn giải quyết các vấn đề từ những thay đổi bạn đang thực hiện chỉ vì tính thẩm mỹ.

Answer 2

Viết bộ thử nghiệm cho sản phẩm để bạn có thể tự tin hơn khi không phá vỡ bất kỳ thứ gì.

Sau đó refactor các bit tồi tệ nhất của mã, hoặc các bit bạn cần phải thay đổi anyway.

Nhưng: xem xét "nếu nó không bị hỏng, không khắc phục được", Nếu khu vực đang hoạt động và bạn không cần thay đổi, hãy cân nhắc xem rủi ro khi đưa ra vấn đề vượt quá lợi ích từ việc nó "đẹp"

Và tìm các nhà phát triển ban đầu và cám dỗ họ vào một số con hẻm tối tăm :) Hoặc tốt hơn, làm cho họ làm những thay đổi

Answer 3

Vâng, một số chương trình nặng bằng văn bản được phổ biến. Nhược điểm là các ứng dụng như vậy có xu hướng khó khăn hơn để cải thiện theo thời gian (ví dụ về mặt mở rộng quy mô, thêm các tính năng mới, sửa lỗi vv).

Nhưng không, không tốt để viết mã rác. Bạn nên xác định những gì người dùng muốn và cung cấp cho họ giao diện tốt, v.v. và làm cho mã dễ bảo trì. Đôi khi điều đó có thể có nghĩa là người dùng sẽ phải đợi lâu hơn một chút cho các tính năng mới, đặc biệt là sớm - nhưng bạn sẽ có thể hoàn thành nhiều hơn trong thời gian dài.

Trong trường hợp của bạn, tôi khuyên bạn nên cố gắng cải thiện từng chút một. Nếu bạn có thể, khắc ra một khu vực và "sửa chữa" đó, và chắc chắn rằng nó không bao giờ quay trở lại những "ngày cũ xấu". Sau đó, khắc ra các khu vực tiếp theo, vv Cuối cùng bạn sẽ có một ứng dụng độc đáo bằng văn bản. Cũng có thể mất nhiều thời gian hơn là viết lại từ đầu, nhưng bạn sẽ có thể cung cấp cho người dùng những cải tiến khi bạn đi, và bạn sẽ tự tin hơn khi nó là một hệ thống làm việc tại bất kỳ thời điểm nào.

Answer 4

Hầu như mọi nhà phát triển, ở mọi nơi, khi được giới thiệu với một số mã họ không viết, muốn viết lại nó để sửa các bit crappy.

Chống thôi thúc viết lại mọi thứ, sửa các bit bị hỏng. Đối phó với các bit không thể duy trì được khi bạn phải duy trì chúng!

Answer 5

Mã lỗi là technical debt; nó có thể ít tốn kém để viết, nhưng trở nên đắt hơn nhiều để duy trì (trừ khi bạn trả nợ bằng cách tái cấu trúc hoặc viết lại).

Bạn có thể nhận được kết quả nhanh hơn và vinh quang, nhưng khi người dùng muốn thay đổi, bạn sẽ phải dành nhiều nỗ lực hơn để thực hiện chúng (hoặc sửa lỗi không thể tránh khỏi).

Answer 6

Tôi đã viết mã crappy cho một số dự án. Tuy nhiên mã 'xấu' hợp lý. Mã lộn xộn có thể được gây ra bởi nhiều lý do, không chỉ là kỹ năng của người đó (tốt, phần lớn thời gian là do kỹ năng)

Các lập trình viên có thể viết mã rất tốt nếu bạn có đủ thời gian và không có áp lực từ kinh doanh. Tuy nhiên những người kinh doanh không đánh giá cao mã hóa tốt nhưng chức năng và ngoại hình. Tôi cho rằng coder 'crappy' là một người thông minh trong kinh doanh. Đơn giản là ông đã phát triển mô hình giải pháp, làm cho phần mềm hoạt động trong một thời gian ngắn và cũng làm cho người sử dụng lao động hạnh phúc tôi đoán !! Nếu để người viết mã viết lại, họ có thể làm tốt hơn nhiều.

Trước hết là, bạn cần thuyết phục bản thân đánh giá cao số lượng công cụ lập trình ban đầu đã trải qua, đây là một trong những điểm cần xem xét nếu bạn là nhà phát triển trưởng thành hay không. MOST của những người khiếu nại và thậm chí cười vào các phiên bản hiện tại bởi vì họ biết họ có thể làm tốt hơn. Nó giống như vẽ trên một tờ giấy trắng với trí tưởng tượng của bạn, hoặc tạo một bản sao của bức tranh hiện có. Cái nào khó hơn?

Thứ hai, nhìn vào mã tổng thể và tìm ra nơi nó có thể được cải thiện, bạn có thể tìm thấy điều gì đó bạn hiểu lầm.

Thứ ba, đường bản đồ nâng cao, nó có thể chứa Todos gần đây và trong tương lai

Cuối cùng, bắt đầu lên kế hoạch làm thế nào nó có thể được cải thiện nếu bạn thiết kế nó từ đầu, kiến ​​trúc mới vv, và trình bày nó cho ban quản lý khi nó đã sẵn sàng và toàn diện.

Mọi phần mềm đều có chỗ để cải thiện, đó là lý do bạn được thuê để cải thiện nó.

Answer 7

Đảm bảo quản lý và người dùng của bạn biết rằng mã không có đủ chất lượng từ quan điểm thay đổi. Khi ước tính lượng thời gian bạn cần để triển khai các tính năng mới, hãy luôn nêu rõ thời gian bạn cần để xóa mã bị ảnh hưởng.

Answer 8

"Mặc dù vậy, việc áp dụng là đẹp trai, hữu ích, và người dùng thích nó và muốn thay đổi"

Ứng dụng này rõ ràng cho khách hàng những gì họ muốn, nhưng có vẻ như nó đã đạt đến giai đoạn unmaintainable.

Tôi nghĩ rằng không có gì khác cho nó, nhưng để tái cấu trúc không ngừng. Điều này có thể sẽ dễ dàng hơn và ít đau đớn hơn nếu bạn chống lại áp lực để thêm bất kỳ chức năng không tầm thường nào cùng một lúc. Bởi tất cả các phương tiện nói với các nhà quản lý rằng mặc dù phần mềm là tốt, nó có nguy cơ biến thành một đống lớn của crud unmaintainable.

Thực hiện cải tiến mã thường giới thiệu một hoặc hai lỗi của riêng chúng, nhưng sẽ giúp bạn tiết kiệm rất nhiều tổn thương não trong thời gian dài. Nhận được càng nhiều nhãn cầu bổ sung khi bạn có thể giúp kiểm tra và gỡ lỗi, và bám chặt vào việc thực hiện các bit thực sự xấu trước tiên.

Hãy xem xét giới thiệu các bài kiểm tra đơn vị nếu đương nhiệm trước đó chưa làm như vậy, để bạn tự tin hơn rằng việc tái cấu trúc không bị hỏng. Tôi không ủng hộ 'nếu nó aint đã phá vỡ ...'triết lý như thế này sẽ giữ cho bạn trên cùng một merry-go-round không đạt yêu cầu.

Đừng lo lắng về tiếng Anh của bạn, nó hoàn toàn hợp lý với tôi và tình trạng khó khăn của bạn là phổ biến.

Answer 9

Thỉnh thoảng khi một lập trình viên chọn dự án cũ lần đầu tiên và thấy tất cả các lớp, giao diện, mô-đun mã, v.v. ngay lập tức nghĩ rằng nó "cồng kềnh". Trong thực tế, nó có thể chỉ có một kiến ​​trúc rất sâu, có thể được áp đảo lúc đầu. Nếu không có tài liệu nào với dự án (ví dụ: Sơ đồ lớp), hãy dành chút thời gian để phác thảo. Nó sẽ không chỉ giúp bạn hiểu dự án hoạt động như thế nào, mà còn giúp mọi người theo sau bạn.

Điều đó cũng xảy ra với các câu như "khó đọc". Nếu bạn biết ngôn ngữ lập trình, thì không khó đọc bất kỳ ứng dụng nào khác. Phong cách của lập trình viên ban đầu có thể khác với phong cách của bạn nhưng nếu ứng dụng hoạt động, thì họ không làm bất cứ điều gì mà ngôn ngữ sẽ không cho phép họ làm. Dòng chảy có thể khó theo dõi, nhưng điều đó có thể được khắc phục bằng cách phác thảo quá trình (ví dụ: Biểu đồ luồng). Hầu hết các nhà quản lý sẽ cho phép thời gian cho một đường cong học tập để làm quen với ứng dụng trước khi thực hiện thay đổi. Hãy dành thời gian đó để phác thảo một số sơ đồ, bạn (và lập trình viên theo bạn) sẽ rất vui vì bạn đã làm.

Theo như "mã crappy" đi, đó là rất chủ quan. Nó thực sự là mã (việc thực hiện) đó là "crappy" hay thiết kế? Có thiếu các mẫu thiết kế không? Việc sử dụng quá mức hoặc triển khai không đúng các mẫu thiết kế? Hay họ thực sự thực hiện các mẫu thiết kế chắc chắn nhưng bạn không quen với họ đủ để nhận ra chúng? Điều quan trọng là, nó có thể áp đảo khi đưa một dự án mới để duy trì và dễ đổ lỗi cho lập trình viên ban đầu cho "bloat", "mã crappy", "khó đọc và thay đổi", v.v. Đôi khi thực sự là đúng, nhưng nhiều lần nó có thể là do người lập trình không hiểu thiết kế và kiến ​​trúc của ứng dụng, hoặc hiểu tại sao một số thứ nhất định được thực hiện theo cách của chúng.