Một phần lớn mã của tôi có một lỗi thiết kế lớn. Hoàn thành nó hoặc sửa chữa nó bây giờ? [đóng cửa]


186

Tôi là một học sinh trung học làm việc trong một dự án C # với một người bạn của tôi có trình độ kỹ năng tương tự như tôi. Cho đến nay, chúng tôi đã viết khoảng 3.000 dòng mã và 250 dòng mã thử nghiệm trong khoảng 100 lần xác nhận. Do đi học, tôi đã hoãn dự án trong vài tháng và gần đây tôi đã có thể chọn lại nó.

Vào thời điểm tôi nhặt nó lên, tôi hiểu rằng mã tôi đã viết được thiết kế kém, chẳng hạn như bao gồm các luồng quá mức trong trình kết xuất, ngăn chặn các điều kiện chạy đua trong tương tác giữa CPU, GPU và hộp mực trò chơi giả lập , cũng như mã chỉ đơn giản là dư thừa và khó hiểu.

Vấn đề là tôi chưa hoàn thành ngay cả chức năng chính của chương trình của mình, vì vậy tôi không thể thực sự tái cấu trúc và tôi cảm thấy nản lòng khi tiếp tục nhận thức hoàn hảo rằng thiết kế mã của tôi bị lỗi. Đồng thời, tôi không muốn từ bỏ dự án; một số lượng đáng kể tiến độ đã được thực hiện và công việc không được lãng phí.

Tôi cảm thấy như thể tôi có một vài lựa chọn: chỉ đơn giản là hoàn thành chức năng bằng cách làm việc xung quanh thiết kế kém và sau đó tái cấu trúc một khi mọi thứ đang hoạt động, tạm dừng mọi thứ và làm việc để gỡ rối mọi thứ trước khi phần còn lại của chức năng có thể kết thúc, bắt đầu dự án tất cả để nó tươi mới trong tâm trí tôi một lần nữa, hoặc hoàn toàn từ bỏ dự án do kích thước quá lớn của nó (về cơ bản là "trở lại bảng vẽ").

Dựa trên kinh nghiệm của những người khác trong các dự án như vậy, đâu là cách để tôi trở lại đúng hướng? Từ các câu trả lời trên trang web này, sự đồng thuận chung là việc viết lại nói chung là không cần thiết nhưng là một tùy chọn có sẵn nếu mã không thể được duy trì mà không có chi phí quá cao. Tôi thực sự muốn theo đuổi dự án này, nhưng vì hiện tại, mã của tôi không được thiết kế đủ tốt để tôi tiếp tục và cảm giác tuyệt vọng khiến tôi không thể tiếp tục.


13
Nghiêm túc: Có một lỗ hổng thiết kế lớn trong các sản phẩm của mình không bao giờ ngăn cản được Ell Ellison. Tại sao lại để nó làm phiền bạn?
Pieter Geerkens

54
Công việc đã không lãng phí. Nó đã làm cho bạn một lập trình viên tốt hơn.
sampathsris

10
Điều này có thể không áp dụng cho bạn vào lúc này, nhưng trong tương lai nếu bạn viết một cái gì đó mà bạn dự định duy trì một cách chuyên nghiệp, đừng bao giờ viết lại một lượng lớn .
gcampbell

8
@JoeBlow "100% phần mềm nhanh chóng trở nên hoàn toàn vô dụng và phải được làm lại từ đầu". Tuyên bố này không có ý nghĩa logic. Bạn đang nói với tôi phần mềm tôi sử dụng hàng ngày ... hoàn toàn vô dụng và phải làm lại từ đầu?
oldmud0

10
"Vâng - vâng, tất nhiên. Không ai đang sử dụng OS9 hoặc Windows3. Phần mềm tạm thời là đáng kể." Bạn, như thường lệ, nhầm lẫn mặc dù sự tự tin của bạn! Hạt nhân Windows NT, được giới thiệu trong NT 3.1, là cốt lõi của ngay cả Windows 10. Windows đã không "viết lại hoàn toàn" trong khoảng 20 năm.
Các cuộc đua nhẹ nhàng trong quỹ đạo

Câu trả lời:


273

Nếu tôi ở trong đôi giày của bạn, có lẽ tôi sẽ thử nó theo cách này:

  • đầu tiên, hoàn thành dự án hiện tại - ít nhất là một phần - càng sớm càng tốt, nhưng trong trạng thái làm việc . Có lẽ bạn cần giảm các mục tiêu ban đầu của mình, suy nghĩ về chức năng tối thiểu bạn thực sự cần thấy trong "phiên bản 1.0".

  • sau đó và chỉ sau đó nghĩ về việc viết lại từ đầu (hãy gọi đây là "phiên bản 2.0"). Có lẽ bạn có thể sử dụng lại một số mã từ V1.0. Có thể sau khi ngủ lại tình huống bạn đi đến quyết định, bạn có thể cấu trúc lại V1.0 và lưu hầu hết nó. Nhưng đừng đưa ra quyết định này trước khi bạn không có "bằng chứng về khái niệm V1.0".

Một chương trình làm việc "1.0" là thứ bạn có thể hiển thị cho người khác, ngay cả khi mã không tốt (điều mà không ai khác sẽ bận tâm, ngoại trừ chính bạn). Nếu ở giữa việc tạo V2.0 mà bạn nhận ra mình sắp hết thời gian, bạn vẫn có V1.0 là một phần thành công, điều này sẽ tốt hơn nhiều cho tinh thần của bạn. Tuy nhiên, nếu bạn không hoàn thành V1.0 trước, có một cơ hội lớn bạn sẽ không bao giờ hoàn thành V2.0 bởi vì khi bạn đi được nửa đường, sẽ có một điểm mà bạn không hài lòng với thiết kế một lần nữa, sau đó? Bạn sẽ từ bỏ V2.0 một lần nữa và làm việc trên V3.0? Có nguy cơ cao chạy vào vòng tròn không bao giờ kết thúc này, không bao giờ kết thúc.

Tốt hơn nên coi đây là cơ hội để học cách đạt được các mục tiêu trung gian, thay vì cơ hội học cách để các dự án ở trạng thái chưa hoàn thành phía sau.


71
Người ta cũng có thể xem phiên bản làm việc 1.0 là cơ hội để tìm hiểu về quy trình tái cấu trúc.
jpmc26

20
Điều này. Tôi thường tìm thấy nhiều hơn một loạt các lỗi thiết kế / ràng buộc thiết kế / cập nhật yêu cầu khi tôi tiến triển từ không có gì sang nguyên mẫu làm việc đầu tiên. Đạt đến một trạng thái làm việc thực tế là quan trọng.
Eugene Ryabtsev

14
Theo kinh nghiệm của tôi, các quyết định thiết kế và / hoặc phát triển tồi tệ thường xuất hiện khi dự án phát triển. Như câu trả lời cho thấy, tốt nhất là nên có phiên bản 1.0 hoạt động thay vì khởi động lại từ đầu. Sau đó, bạn có thể sử dụng phiên bản 1.0 này làm đường cơ sở cho phiên bản tiếp theo.
Keale

9
Kết thúc một dự án sẽ cho phép bạn nhìn thấy những vấn đề tiềm ẩn mà bạn chưa gặp phải và thực sự có thể cho bạn thấy rằng một số điều mà bạn nghĩ là vấn đề có thể không lớn như bạn nghĩ. Giữ ghi chú tốt và bắt đầu thiết kế kế hoạch cho 2.0 trong khi bạn hoàn thành 1.0
CaffeineAddtions

9
Câu cuối cùng thật tuyệt vời:Better take this as an opportunity to learn how to achieve intermediate goals, instead of an opportunity to learn how to leave projects in an unfinished state behind.
Brandon

119

Các dự án CNTT đã hoàn thành, ngay cả những dự án bị lỗi, tốt hơn nhiều so với các dự án chưa hoàn thành.

Những người chưa hoàn thành có thể dạy cho bạn rất nhiều, nhưng không nhiều như những người đã hoàn thành.

Bạn có thể không nhìn thấy nó bây giờ, nhưng bạn nhận được một lượng giá trị khổng lồ làm việc với mã thậm chí bị lỗi.

Phiếu bầu của tôi sẽ được hoàn thiện và sau đó, có thể, tái cấu trúc - nếu cần. Khi bạn bắt đầu làm việc với nhiều dự án hơn, bạn sẽ thấy rằng phần đáng ngạc nhiên là phần "có nghĩa là được tái cấu trúc" vẫn không bị ảnh hưởng trong nhiều năm, trong khi các phần khác được mở rộng.

Từ quan điểm việc làm, trong hầu hết các trường hợp, bạn sẽ nhận được nhiều danh tiếng cho một dự án đã hoàn thành.


11
Thành thật mà nói, trong các dự án không tầm thường luôn có một vài lỗi. Liệt kê chúng và sửa chúng trong phiên bản tiếp theo. Đó là những gì ghi chú phát hành dành cho.
RedSonja

56

Tôi sẽ vui vẻ bắt đầu dự án hơn.

Bạn là sinh viên, và bạn vẫn đang học. Điều này đặt bạn vào một vị trí rất khác so với câu hỏi bạn liên kết đến.

  • Bạn không có trách nhiệm nghề nghiệp cho mã của bạn; nếu bạn xóa toàn bộ dự án ngay bây giờ và bỏ đi, bạn sẽ không phải chịu hậu quả gì. Đây là một lợi thế rất lớn cho một nhà phát triển. Trong câu hỏi mà bạn đã liên kết, những nhà phát triển đó đang cố gắng duy trì phần mềm mà mọi người đang trả tiền và thậm chí các lỗi nhỏ có thể gây ra vấn đề lớn với khách hàng, điều này gây nguy hiểm khi viết từ đầu. Bạn không có vấn đề đó.

  • Là một dự án cá nhân, đây là cơ hội hoàn hảo để thử những điều mới và học hỏi từ những sai lầm của bạn. Thật tuyệt khi bạn nhận ra mã cũ của mình có vấn đề, vì điều đó có nghĩa là bạn đã học được cách làm tốt hơn. Kinh nghiệm thông qua thử và sai có thể là vô giá đối với những lập trình viên mới bắt đầu.

  • Dự án của bạn tương đối nhỏ, và về cơ bản bạn không có bài kiểm tra nào. Có thể chỉ mất vài đêm để viết 3000 dòng từ đầu, đặc biệt là khi bạn đã có ý tưởng về những gì sẽ làm tốt hơn vào lần tới.

  • Làm việc trong một cơ sở mã bị hỏng sẽ làm hao tổn tinh thần của bạn lớn hơn nhiều so với việc viết lại.

Bên cạnh đó, đây có thể là một cơ hội tuyệt vời để thử viết một chương trình mô-đun hơn với các bài kiểm tra đơn vị. Làm như vậy sẽ giúp việc hiểu mã dễ dàng hơn nhiều nếu bạn quay lại mã đó sau một thời gian dài và giúp ngăn ngừa các lỗi bạn có thể vô tình giới thiệu do sự quên lãng.

Cuối cùng, đây là một ý kiến ​​về sự khôn ngoan của đôi khi thực hiện các bước lùi để tiến những bước lớn hơn về phía trước.


46
Viết lại từ Scrarch hiếm khi học hỏi từ những sai lầm và thường chỉ đơn giản là tạo ra những cái mới
tên là

28
Theo tôi, hoàn thành một dự án quan trọng hơn nhiều sau đó có dự án hoàn hảo. Mối đe dọa của một vòng lặp "nó không đủ tốt" là có thật.
Pieter B

9
Đôi khi khi bạn tự đào một cái hố, bạn cần ngừng đào; học bài học được trình bày và làm cho phiên bản thứ hai đơn giản hơn . Sai lầm hệ thống thứ hai mà mọi người mắc phải là xây dựng nó huyền ảo và phức tạp hơn.
Dale Johnson

15
Mọi người nên nhấn mạnh rằng OP đang làm việc trong một dự án đồ chơi . Tôi đã đọc bài luận của Joel về việc viết lại từ đầu , và không có điểm nào của anh ấy có thể áp dụng cho trường hợp này. OP không bán mã của họ cho thế giới thực, không có thời hạn, v.v. Dành gấp đôi thời gian lập trình có nghĩa là họ học được gấp đôi.
Kevin

6
@whatsisname Họ sẽ không mắc phải những sai lầm tương tự. Như bạn đã nói ở trên, họ sẽ tạo ra những cái mới, sẽ dạy họ những điều mới.
Kevin

34

Có lẽ bạn vẫn còn trong phần "học nhanh" trong quá trình phát triển của mình. Có một cơ hội tốt mà một vài tháng nữa, bạn sẽ thấy rằng thiết kế mới và tuyệt vời của bạn bị phá vỡ khủng khiếp theo những cách mà bạn thậm chí không nhận ra khi bạn bắt đầu.

Hoàn thành công việc - đây là điều quan trọng nhất bạn cần học. Tin tôi đi, tôi biết rất nhiều người (không chỉ lập trình viên) bị mắc kẹt trong vòng lặp "hãy bắt đầu lại từ đầu vì tôi đã học được rất nhiều trước khi tôi bắt đầu dự án này". Vấn đề là nó không bao giờ kết thúc - cho đến khi bạn ngừng học hỏi những điều mới, đó không phải là một nơi tốt đẹp để được :)

Nó cũng quan trọng để có thể thực sự hoàn thành bất cứ điều gì. Bắt đầu lại rất thú vị, tuyệt vời, thú vị ... nhưng nếu bạn chỉ học được điều đó, bạn sẽ không bao giờ có thể hoàn thành bất cứ điều gì. Một lần nữa, đó không phải là một khả năng rất hữu ích, và nó thực sự không cảm thấy tốt như làm một cái gì đó hữu ích (hoặc vui vẻ). Cuộc sống rất ngắn ngủi, thời gian có hạn và bạn không thể tiếp tục luyện tập mà không có kết quả rõ ràng - bạn sẽ phát điên vì điều đó. Nếu bạn thấy mình không thể bắt đầu làm việc vì bạn không thể quyết định nên tiếp cận phương pháp nào, bạn đã ở trong khu vực nguy hiểm.

Sẽ luôn có những xung động để bắt đầu lại. Ngay cả trong một môi trường học tập, những điều đó rất có thể là một ý tưởng tồi. Điều đó không có nghĩa là bạn cần mang mọi nguyên mẫu đơn đến một ứng dụng sẵn sàng sản xuất, cách xa nó. Nhưng ít nhất bạn cần phải đến giai đoạn nguyên mẫu hoạt động - rất có thể nó sẽ giúp ích cho tinh thần của bạn, và đó là một đặc điểm rất hữu ích cho bất kỳ nhà phát triển nào. Hoàn thành mọi việc . Và điều thú vị là, bạn sẽ nhanh chóng thấy rằng có hàng triệu điều thú vị hoặc hữu ích hơn bạn có thể làm với nguyên mẫu của mình thay vì "viết lại từ đầu" - và trong nhiều trường hợp, thậm chí tái cấu trúc nó. Mọi thứ bạn làm đều có chi phí - ít nhất, bạn có thể đã làm một việc khác trong lúc này.


25

Tôi tuân theo hệ tư tưởng "Làm cho nó hoạt động, làm cho đúng, làm cho nhanh" trong phát triển phần mềm.

  1. Làm cho nó hoạt động : Viết các chức năng cốt lõi, để dự án có thể sử dụng được. Làm những gì bạn phải làm để làm cho mọi thứ hoạt động, ngay cả khi nó có nghĩa là mã xấu xí.
  2. Làm cho đúng : Sửa lỗi và cấu trúc lại mã để dễ đọc, hiểu và bảo trì hơn.
  3. Làm cho nó nhanh : Tối ưu hóa chương trình, hướng tới sự cân bằng tốt giữa tốc độ, sử dụng tài nguyên và khả năng bảo trì.

Ngay bây giờ, bạn chưa hoàn thành bước 1. Làm cho nó hoạt động trước, và sau đó bạn có thể lo lắng về việc mã của bạn xấu đến mức nào. Trên thực tế, việc tạo ra một sản phẩm hoạt động là một trong những điều khó nhất đối với các nhà phát triển mới, bởi vì họ bị cuốn vào việc cố gắng làm cho mã của họ hoàn hảo ngay lần đầu tiên và vì vậy họ bị mắc kẹt trong Tối ưu hóa địa ngục và không bao giờ thực sự hoàn thành thực hiện tất cả các tính năng. Bạn phải học cách gạt bỏ mọi lo lắng về tái cấu trúc và tối ưu hóa để bạn có thể tập trung vào làm cho phần mềm hoạt động. Khi bạn có thêm một số kinh nghiệm, lần đầu tiên bạn sẽ làm được nhiều việc hơn, do đó việc tái cấu trúc ít hơn là cần thiết.

Hãy ghi nhớ: tối ưu hóa sớm là gốc rễ của mọi tội lỗi (xem câu hỏi lập trình viên xuất sắc này. Câu hỏi hay cho một cuộc thảo luận tốt). Nếu bạn dành quá nhiều thời gian suy nghĩ về cách làm cho mã của bạn tốt hơn, bạn sẽ bị kẹt trong tình trạng tê liệt phân tích . Điều này giết chết dự án. Tốt hơn hết là hãy hoàn thành dự án trước khi bạn bắt đầu cố gắng tối ưu hóa nó.

Để trích dẫn một diễn giả động lực tuyệt vời: chỉ cần làm điều đó .

Như mọi khi, có một xkcd có liên quan:

tối ưu hóa xkcd


1
Trong mã nguồn mở, bạn thậm chí có thể chèn bước 0, "chỉ cần làm cho nó". Ngay cả khi nó không hoạt động, nếu nó đủ thú vị, hãy giải phóng nó và có thể ai đó sẽ giúp bạn với bước 1.
Jörg W Mittag

1
Cá nhân, tôi thích mã đúng. Tôi thậm chí nghĩ rằng thiết kế đúng có thể hữu ích hơn mã có vấn đề. Bất kể thứ tự số 1 và số 2, tôi là +1 vì tôi thích thấy sự tách biệt được ghi chú. Nếu có các vấn đề triển khai chính như kiểm tra điều kiện chủng tộc, các vấn đề đó thường có thể được khắc phục mà không cần thiết kế lại API (chức năng gọi là gì), vì vậy bạn có thể sửa lỗi bằng cách tập trung vào chi tiết triển khai mà không cần phải tập trung quá nhiều vào các công cụ thiết kế cấp cao hơn chức năng. Vì vậy (có khả năng) có thể có giá trị khi có phiên bản mã (bán?) Hoạt động.
TUYỆT VỜI

Tôi không nghĩ rằng điều này áp dụng. OP rõ ràng đang nói về các vấn đề thiết kế cơ bản . Bạn không thể "vá" chúng một cách an toàn sau này.
Các cuộc đua nhẹ nhàng trong quỹ đạo

1
Đừng quên các bước 0,5, 1,5, 2,5 và 3,5: làm cho nó dễ đọc.
candied_orange

23

Viết lại nó. Mã không hoạt động có ít giá trị và ba nghìn dòng không phải là nhiều mã. Sẽ không mất nhiều thời gian để viết mã bạn hiện có, và nó sẽ tốt hơn nhiều. Tôi thường ném ra năm trăm hoặc một nghìn dòng mã kém, và thường thì việc viết lại dài bằng một phần năm.

Hầu hết các khái niệm xung quanh "không viết lại" liên quan đến các hệ thống lớn làm những việc quan trọng và trải qua những thay đổi liên tục để đáp ứng các yêu cầu phát triển. Viết lại các hệ thống phức tạp trong sử dụng hiếm khi thành công.

Tình huống của bạn là hoàn toàn ngược lại. Bạn có một ứng dụng nhỏ không có người dùng và yêu cầu duy nhất là những ứng dụng bạn chọn để thực hiện. Vì vậy, đi trước và viết lại nó.


7
Nếu bạn đang cố gắng theo một chu kỳ phát triển nhanh, ý tưởng là nếu bạn nhận ra mình đã đi sai lỗ thỏ, hãy ném nó đi và thử một hướng khác, tuy nhiên nếu bạn đang sử dụng điều khiển nguồn svn / git thì bạn nên có thể trở lại một cam kết ngay trước khi bạn đi sai đường để nó không phải là một thay đổi quá lớn - nếu không, hãy để đây là bài học để cam kết thường xuyên.
Theresa Forster

2
Với 3k dòng mã, có thể mất nhiều thời gian hơn để kiểm tra các cam kết sau đó chỉ cần viết lại toàn bộ.
Matthew Whited

Về repo git, chỉ cần xóa nó và bắt đầu lại. Mã hiện tại gần như chắc chắn hoàn toàn vô giá trị. Lý do gì để rời khỏi nó trên một số máy chủ? - không ai. Nhấn vào xóa.
Fattie

1
@JoeBlow: không có lý do để xóa repo git. Chỉ cần làm một chi nhánh mới. Bạn không bao giờ có thể biết khi nào bạn có thể muốn đề cập đến những thứ cũ.
kevin cline

19

Khởi động lại từ đầu thường là một động thái tồi tệ trong các dự án thực tế, chủ yếu là do các dự án thực tế tích lũy các bản sửa lỗi mà nhà phát triển mới không biết (ví dụ: xem Những điều bạn không nên làm , từ blog Joel trên Phần mềm .)

Không bao giờ, các dự án trường học không kế thừa lịch sử như vậy và thường bắt đầu bằng cách mã hóa và thiết kế cùng một lúc với kiến ​​thức một phần về điện toán và thiếu kinh nghiệm. Tôi sẽ xem xét phiên bản đầu tiên của bạn như là một nguyên mẫu, được sử dụng như một bằng chứng của khái niệm đó đã thất bại, và tôi sẽ rất vui nếu vứt nó đi (xem sự khác nhau giữa nguyên mẫu throwaway và tiến hóa là gì? Cho một cuộc thảo luận về throwaway vs mẫu tiến hóa.)

Thiết kế phù hợp đã trưởng thành trong đầu của bạn và không nên mất nhiều thời gian để viết nó ra bằng mã.


12

Tôi tôn trọng không đồng ý với các đề xuất rằng viết lại là một ý tưởng tồi.

Trong vương quốc của vòng đời phần mềm, người ta thường chấp nhận rằng thời gian và nỗ lực cần thiết để sửa lỗi tăng theo một bậc độ lớn mỗi lớp trong vòng đời. Nghĩa là, nếu mất 1 giờ để sửa lỗi ở mức yêu cầu, sẽ mất 10 giờ trong thiết kế, 100 giờ trong kiểm tra mã hóa và 1000 giờ để sửa lỗi. Những con số này nghe có vẻ thái quá, nhưng chúng được ngành công nghiệp chấp nhận là gần đúng. Rõ ràng, ít hơn trong một dự án nhỏ hơn, nhưng ý tưởng chung vẫn còn. Nếu dự án của bạn có một lỗi thiết kế cơ bản, thì sẽ phù hợp hơn nếu gọi đó là trải nghiệm học tập và quay lại, xem lại các yêu cầu ban đầu của bạn và thiết kế lại.

Tôi cũng sẽ khuyến khích xem xét mô hình Phát triển hướng thử nghiệm bằng cách sử dụng các thử nghiệm đơn vị có cấu trúc. Chúng là một nỗi đau và ban đầu có vẻ như lãng phí thời gian, nhưng khả năng phát hiện ra lỗi của chúng, đặc biệt là khi tích hợp với mã của người khác không thể được nêu rõ.


3
"Công nghiệp được chấp nhận" nghĩa là gì? Nguồn cho số là gì?
Christian

1
@Christian đây dường như là nguồn: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

1
TDD là con đường để đi!
2rs2ts

10

Bạn đã mất tôi ở câu này:

Vấn đề là tôi chưa hoàn thành ngay cả chức năng chính của chương trình của mình, vì vậy tôi không thể thực sự tái cấu trúc và tôi cảm thấy nản lòng khi tiếp tục nhận thức hoàn hảo rằng thiết kế mã của tôi bị lỗi.

Tôi tin vào nguyên tắc (nêu trong Systemantics ) rằng

  • Một hệ thống phức tạp hoạt động luôn được tìm thấy đã phát triển từ một hệ thống đơn giản hoạt động.
  • Một hệ thống phức tạp được thiết kế từ đầu không bao giờ hoạt động và không thể vá để làm cho nó hoạt động. Bạn phải bắt đầu lại, bắt đầu với một hệ thống đơn giản làm việc.

Vì vậy, viết một hệ thống phức tạp bao gồm

  • Viết một hệ thống đơn giản
  • Đảm bảo nó hoạt động

... tức là các bước sau:

  1. Viết một chút mã
  2. Kiểm tra nó để đảm bảo nó hoạt động
  3. Viết thêm một chút mã
  4. Kiểm tra lần nữa
  5. Vân vân.

Lưu ý rằng bước 3 có thể bao gồm:

  1. Viết thêm một chút mã
    1. Tái cấu trúc mã hiện có để chuẩn bị cho bổ sung mới
    2. Kiểm tra tái cấu trúc để đảm bảo nó vẫn hoạt động
    3. Thêm chức năng mới

Ngoài ra, Bước 2 "Kiểm tra nó để đảm bảo nó hoạt động" có thể liên quan đến việc viết lại nếu không.

Nếu tôi đang xây dựng trên một cơ sở mã thối, tôi sẽ không phù hợp để thêm chức năng. Vì vậy, tôi có xu hướng lên lịch một cái gì đó như "đơn giản hóa việc triển khai luồng hiện tại" như là công việc tiếp theo sẽ được thực hiện. Giả sử rằng bạn đã thử nghiệm khi bạn đi cùng, bạn nên có thể coi đây là một bài tập tái cấu trúc. Tiêu chí thành công / thoát cho giai đoạn làm việc này sẽ là:

  • Mã nguồn đơn giản hơn
  • Và không có lỗi mới nào được giới thiệu
  • (Và một số lỗi cũ đã được loại bỏ)

Ngẫu nhiên, "kiểm tra nó để đảm bảo nó hoạt động" không nhất thiết có nghĩa là "kiểm tra đơn vị" - khi cấu trúc nhóm đơn giản, bạn có thể kiểm tra hệ thống (đơn giản) bằng cách sử dụng kiểm tra hệ thống (đơn giản) (thay vì kiểm tra đơn vị) .


7

Một trong những vấn đề bạn đang gặp phải khi gặp phải một vấn đề như thế này, là bạn có cảm xúc gắn liền với mã bạn đã viết cho đến nay bằng cách này hay cách khác.

Một đồng nghiệp nói với tôi rằng anh ta đang viết một chương trình khi còn học đại học trong khi anh ta nhận được bài học từ một giáo sư nổi tiếng (tôi tin đó là Dijkstra). Ông yêu cầu giáo sư đã xem xét mã mà ông đã làm việc trong hơn một tháng. Giáo sư hỏi anh ta đã làm một bản sao lưu chưa, anh ta trả lời là không. Giáo sư sau đó đã xóa tất cả mã của mình và bảo anh ta viết lại.

Anh ta bực mình, nhưng 3 ngày sau anh ta đã hoàn thành chương trình, với mã sạch hơn và ít lỗi hơn và ít dòng mã hơn.

Cố gắng ước tính trung thực về lựa chọn nào là tốt nhất trong thời gian có sẵn cho dự án.

3 sự lựa chọn là

  • Xóa nó (hoàn toàn, không nhìn lại)
  • Tiếp tục làm việc trong thiết kế cũ
  • Mã tái cấu trúc trong khi bạn đi.

Tôi đã là một lập trình viên chuyên nghiệp trong hơn 10 năm và trong công việc của mình, tôi đã đi đến kết luận lựa chọn cuối cùng là hầu hết các lần được chọn, nhưng nó không phải luôn luôn là lựa chọn tốt nhất.


3
Tôi đã từng có một đoạn mã có lỗi. Tôi đã mất ba ngày để tìm lỗi khi bài kiểm tra của tôi bị xì hơi và tôi đã thành công trong việc xóa mã, không có bản sao lưu. Tôi viết lại toàn bộ cơ sở mã từ bộ nhớ trong tất cả các lỗi của tôi đã biến mất. Khoảng 3000 dòng cơ sở. Vì vậy, đôi khi nó lo lắng nó. Nhưng trong sản xuất điều này không bao giờ xảy ra.
joojaa

6

Có vẻ như kỹ năng của bạn đã phát triển đáng kể trong khoảng thời gian đó. Có lẽ làm việc trên dự án đó đã đóng góp cho nó. Thiết kế nó một lần nữa như một kinh nghiệm học tập có mục đích sẽ có kết quả.

Hãy nhớ rằng, đây không phải là thứ bạn cần cung cấp như một chương trình làm việc cho khách hàng. Nó được viết riêng cho việc thực hành. Vì vậy, trừ khi bạn muốn thực hành có vấn đề vận chuyển và giao hàng không hoàn hảo, tôi nghĩ bạn hiện đang trong giai đoạn phát triển, nơi làm việc "cơ bắp thiết kế" của bạn sẽ có kết quả.

Khi làm như vậy, hãy tập trung vào quy trình thiết kế và lập kế hoạch, và suy nghĩ về những thứ hiện có của bạn và suy nghĩ về những gì bạn hiểu rõ hơn.


6

Cấu trúc lại. Cấu trúc lại. Cấu trúc lại! CẤU TRÚC LẠI!!!!

Thành thật mà nói, dù bạn có kinh nghiệm đến đâu thì đây cũng là một vấn đề phổ biến. Bạn đã viết mã, bạn đã học được điều gì đó và bạn muốn sử dụng kiến ​​thức mới về mã cũ. Bạn muốn đo mã cũ so với kiến ​​thức mới.

Điều đó sẽ không làm việc. Nếu bạn làm điều đó, ứng dụng / trò chơi của bạn sẽ không bao giờ được hoàn thành. Thay vào đó, hãy cố gắng phân bổ thời gian của bạn cho dự án để một số "nhiệm vụ" của bạn là cấu trúc lại mã xấu. Ví dụ, giả sử bạn có một phương pháp cứu trò chơi khủng khiếp. Tiếp tục làm việc với trò chơi, nhưng tìm một chút thời gian để cấu trúc lại (thay thế) phương pháp kinh khủng đó. Cố gắng giữ cho các bộ tái cấu trúc nhỏ, và nó không phải là một vấn đề.

Khi bạn đến một phần chính của ứng dụng cần bộ tái cấu trúc thì bạn đang làm sai, nghiêm túc. Phá vỡ cấu trúc lại xuống các phần nhỏ hơn. Cố gắng dành bảy giờ để viết mã, và một giờ tái cấu trúc.

Khi bạn hoàn thành dự án và bạn nhấn tính năng đóng băng, thì bạn có thể dành thời gian tái cấu trúc lớn. Bây giờ, hãy hoàn thành trò chơi, nhưng vẫn cố gắng cấu trúc lại một số. Đó là điều tốt nhất bạn có thể làm.

Sẽ luôn có một cái gì đó để tái cấu trúc.


4

Tôi muốn nói rằng nó phụ thuộc một chút vào loại mã hiện tại của bạn và vấn đề chính xác nằm ở đâu. Tức là, nếu nền tảng của bạn là tốt (thiết kế lớp phù hợp trong hầu hết các phần, tách rời / gắn kết tốt, v.v., chỉ cần một vài lựa chọn tồi như các chủ đề bạn đã đề cập), thì bằng mọi cách, hãy lấy ra một bản gốc 1.0 và sau đó tái cấu trúc như không có ngày mai.

Mặt khác, nếu nó thực sự chỉ là một tập tin văn bản xấu xí được ghép vào nhau bằng cách nào đó vượt qua trình biên dịch, không có cấu trúc rõ ràng, v.v. (nói cách khác, một nguyên mẫu học tập công việc bằng chứng khái niệm), sau đó tôi muốn xóa nó và bắt đầu lại.

Trên phiên bản tiếp theo của bạn, hãy thực hiện một cách tiếp cận nhanh: đặt cho mình một mốc thời gian lặp lại cố định, như 2 tuần hoặc bất cứ điều gì phù hợp với lịch trình của bạn. Ở đầu mỗi đoạn (hãy gọi nó là chạy nước rút), hãy đặt cho mình những mục tiêu có thể đạt được trong 2 tuần. Đi trước và làm chúng, cố gắng hết sức để làm cho nó hoạt động. Đặt mục tiêu của bạn để sau mỗi 2 tuần bạn có thứ gì đó có thể hiển thị cho bạn bè, không chỉ là một số công việc nội bộ trừu tượng. Google "scrum" và "mục tiêu thông minh". Điều này rất dễ thực hiện, nếu bạn ở một mình, chỉ là một mảnh giấy với một vài gạch đầu dòng nhanh chóng được ghi lại.

Nếu bạn có thể làm điều đó, thì bắt đầu lại là tốt. Nếu bạn biết sâu bên trong rằng sau khi bắt đầu lại, bạn có thể sẽ kết thúc nơi bạn đang ở hiện tại, dù sao đi nữa, sau đó gắn bó với mã của bạn và làm cho nó hoạt động.


3

Bạn phải đặt mình vào vị trí của nhà tuyển dụng.

Đối với hầu hết các nhà tuyển dụng, bạn sẽ có giá trị nhất nếu bạn đi theo cách này: - Hoàn thành nó với 100% bài kiểm tra về mã mới bạn viết. - Thêm các thử nghiệm cho mã cũ (thiết kế xấu). - Tái cấu trúc nó để đạt được những gì bạn muốn như một thiết kế.

Làm tất cả điều đó với một quá trình phiên bản tốt, các chi nhánh và thẻ.

Viết lại thường là một ý tưởng gợi cảm, nhưng nó thường là một ý tưởng mà những người mới đến có nguy hiểm trong cuộc sống thực. Cho thấy rằng bạn sẵn sàng cải thiện chất lượng công việc bạn đã làm hơn là bắt đầu từ đầu là một dấu hiệu tốt cho thấy bạn là một người nghiêm túc.

Bạn rõ ràng có thể viết lại nó mặc dù, nhưng làm cho nó một dự án khác sau đó.


Chủ nhân nào? OP đang học trung học, làm một dự án thú cưng.
Các cuộc đua nhẹ nhàng trong quỹ đạo

Hành động chuyên nghiệp ngay từ đầu không thể quá tệ và trường trung học không quá xa so với cơ hội việc làm thực sự IMHO.
Steve Chamaillard

1
"Diễn xuất chuyên nghiệp" hoàn toàn không liên quan gì đến việc bạn có tái cấu trúc hay không.
Các cuộc đua nhẹ nhàng trong quỹ đạo

Nó có, trong một số cách. Hầu hết thời gian bắt đầu một dự án và mất rất nhiều công việc là không chuyên nghiệp, trong khi tái cấu trúc nó và do đó cải thiện nó cho thấy kết quả lâu dài tốt hơn (hầu hết các lần).
Steve Chamaillard

Và đây không phải là một trong những thời điểm đó.
Các cuộc đua nhẹ nhàng trong quỹ đạo

3

Chỉ cần thêm một số kinh nghiệm trong quá khứ của tôi vào hỗn hợp. Tôi đã làm việc cho một dự án phụ trong hơn một năm nay, bất cứ khi nào tôi có một vài phút rảnh rỗi. Dự án này đã đi từ một thử nghiệm đơn giản đến một lớp tĩnh đến một thiết kế lót mỏng hướng đối tượng hiện tại.

Trong tất cả các thay đổi này, tôi đã giữ nguyên chức năng của mã, không bao gồm sửa lỗi và lợi ích hiệu suất (cần phải nhanh nhất có thể). Cơ sở mã giống nhau mặc dù được tái cấu trúc vẫn giữ nguyên và do đó tôi đã cải thiện nó một cách ồ ạt mà không phải viết lại mã từ đầu và lãng phí thời gian.

Điều này có nghĩa là tôi đã có thể cải thiện mã với tốc độ nhanh hơn so với trước đây. Điều đó cũng có nghĩa là khi tôi đi sẽ dễ dàng hơn để nói những gì cần phải loại bỏ, tức là các lớp không cần thiết, và những gì có thể ở lại dễ dàng hơn là viết lại với ý tưởng cũ vẫn còn trong tâm trí tôi.

Do đó, lời khuyên của tôi sẽ là cấu trúc lại mã của bạn và tiếp tục cải thiện khi cần thiết. Mặc dù hãy nhớ nếu bạn quyết định viết lại từ đầu, bạn nên nắm bắt những ý tưởng hay của dự án cũ và xem xét kỹ chúng để xem chúng bị thiếu sót ở đâu. Tức là không chỉ sao chép mã cũ vào dự án mới.


3

Câu trả lời phụ thuộc vào thứ mà tôi muốn gọi là "trần phức tạp". Khi bạn thêm nhiều hơn và nhiều hơn vào một cơ sở mã, có xu hướng nó sẽ ngày càng phức tạp hơn và ngày càng ít tổ chức hơn. Tại một số điểm, bạn sẽ đạt đến "trần phức tạp", tại thời điểm đó, tiến trình trở nên rất khó khăn. Thay vì cố gắng tiếp tục di chuyển bằng vũ lực, tốt hơn là sao lưu, sắp xếp lại / viết lại, và sau đó tiếp tục tiến về phía trước.

Vì vậy, codebase của bạn tệ đến mức bạn đang ở gần một trần phức tạp? Nếu bạn cảm thấy rằng đó là, hãy dành một chút thời gian để dọn dẹp và đơn giản hóa trước khi tiếp tục. Nếu cách dễ nhất để dọn dẹp là viết lại một số phần, điều đó là tốt.


2

Cũng không? Cả hai?

Tiếp tục trở đi, dành một chút thời gian để sửa đổi thiết kế hiện có và một chút thời gian để thêm chức năng mới.

Nếu bạn có các tương tác không phù hợp, đó có thể là một nơi tốt để bắt đầu ("các luồng quá mức trong trình kết xuất" nghe có vẻ không hiệu quả, thay vì gây ra sự cố chính xác). Xem nếu bạn có thể tìm ra một cách chung để thoát khỏi các chủng tộc (và có thể là bế tắc), hoặc ít nhất là nhiều cách cụ thể để làm như vậy.

Tôi không biết mức độ nào những thứ như bế tắc và trình phát hiện chủng tộc có sẵn cho C #, nhưng nếu chúng tồn tại, chúng có thể hữu ích trong việc xác định những vấn đề đang xảy ra và xác minh rằng các bản sửa lỗi của bạn đang hoạt động.

Tôi thấy rằng, nói chung, tôi có động lực hơn để khắc phục các vấn đề với mã làm điều gì đó hữu ích, thay vì vứt nó đi và bắt đầu lại từ đầu. Có những trường hợp phát triển trường cháy xém (tương tự như trường xanh và trường nâu ...) thỏa mãn hơn, nhưng đó thường là đối với những điều mà cách tiếp cận hiện tại quá xa khỏi nơi mà nó không còn sai nữa.


2

Nếu mã của bạn là mô-đun thì bạn sẽ có thể hoàn thành phần còn lại của mã xung quanh các thành phần được viết xấu sau đó viết lại các thành phần được viết xấu mà không ảnh hưởng đến phần còn lại của mã.

Trong trường hợp đó, tùy thuộc vào bạn khi bạn viết lại các thành phần được viết xấu. Nếu các thành phần được viết kém được viết quá tệ đến mức mã hoàn thành sẽ không hoạt động với chúng, thì bạn sẽ cần phải viết lại chúng trước khi bạn có thể hoàn thành phần còn lại của mã.


2

Câu hỏi đầu tiên bạn nên tự hỏi mình là "lỗ hổng xấu đến mức nào?"

Chính xác thì bạn đã làm gì sai?

Nếu có điều gì đó tồi tệ đến mức bạn sẽ lãng phí hàng giờ để cố gắng xử lý sự cố, lộ dữ liệu nhạy cảm (mật khẩu / thẻ tín dụng) hoặc gây ra lỗ hổng xấu, thì có lẽ bạn nên chỉnh sửa nó, nhưng hầu hết thời gian bạn có thể lấy những gì bạn có, hoàn thành nó và khắc phục vấn đề sau.


Các lập trình viên thích cải thiện các ứng dụng của họ, muốn chúng là "tốt nhất có thể", nhưng đó không phải là phương pháp đúng.

NẾU bạn phát hành ứng dụng của mình càng sớm càng tốt, ngay cả khi nó không phải là 100%, lỗi vẫn là tất cả, thì bạn sẽ nhận được FEEDBACK từ những người khác, trong khi có thời gian để sửa lỗi và các thứ khác cho phiên bản 1.1. Những người khác sẽ có thể giúp bạn làm cho ứng dụng trở nên tốt hơn rất nhiều và bạn có thể đã lãng phí thời gian để làm điều gì đó mà mọi người có thể không thích.

Vì vậy, trong trường hợp của bạn, hãy đưa nó ra khỏi đó, nhận một số phản hồi và sau đó bạn có thể cấu trúc phiên bản 2.0 với tất cả các thay đổi và khắc phục lỗ hổng bạn có.


Một điều cần nhớ là chúng tôi không ngừng cải thiện. Có một câu nói rằng nếu bạn có thể xem mã của mình từ một năm trước và thấy rằng điều đó thật tệ, điều đó có nghĩa là bạn vẫn đang tiến bộ và đó là một điều tuyệt vời.


1

Nó phụ thuộc vào mức độ lộn xộn của mã của bạn.

  • Nếu bạn đã thực hiện các lỗi n00b thực sự khiến mã của bạn quá phức tạp hoặc dài dòng, thì tôi khuyên bạn nên viết lại các phần đó.

  • Nếu bạn nghĩ rằng bạn có lỗi nghiêm trọng mà bạn sẽ phải sửa, thì hãy viết một số bài kiểm tra đơn vị có thể kiểm tra xem bạn đã sửa lỗi chưa (... vì bạn chưa thể khởi chạy chương trình). Tốt hơn hết là sửa lỗi sớm và tốt hơn hết là sửa lỗi trong khi bạn vẫn nhớ mã làm gì.

  • Nếu bạn không thích những gì các phương thức được gọi, hoặc chúng thuộc về lớp nào, hoặc những thứ nhỏ như thế, thì chỉ cần sử dụng IDE. (Hãy nhớ rằng, đây là C #, không phải là một số javascript, python, perl, php, v.v.) sau đó cấu trúc lại nó nếu IDE của bạn làm cho nó không đau.

Nếu không, làm cho nó hoạt động và trau dồi kỹ năng của bạn trong dự án tiếp theo.


1

Như những người khác đã đề xuất, vì đây là một dự án cá nhân, chưa (chưa) là một dự án chuyên nghiệp, tôi sẽ nghiêm túc xem xét viết lại.

Tuy nhiên, bạn có thể tận dụng phương pháp khoa học ở đây, bằng cách thực hiện một thử nghiệm. Đầu tiên, hãy nghĩ ra một giả thuyết. Của tôi sẽ là, "có lẽ đã đến lúc viết lại." Để tiết kiệm thời gian, giảm chi phí thất bại và phần nào hạn chế sai lệch tiên nghiệm, trước khi bạn thực hiện bất kỳ chương trình nào nữa, hãy quyết định một khoảng thời gian ("hộp thời gian"). Tôi có thể đề nghị có lẽ 4 giờ đồng hồ treo tường. Cũng quyết định một phương pháp để đánh giá giả thuyết. Vì cổ phần thấp, tôi sẽ đề nghị như một phương pháp, chỉ cần tự hỏi: "tôi có vui vì tôi đã làm điều này không?" Bây giờ bắt đầu thí nghiệm. Sau hộp thời gian đã chọn của bạn, đánh giá của giả thuyết là gì? ví dụ Từ ví dụ của tôi, bạn có vui không khi bạn bắt đầu viết lại vì bạn đã dành 4 giờ để làm việc đó? Sau đó, nó có lẽ là sự lựa chọn đúng đắn.

Bạn có thể yêu cầu tất cả các lời khuyên trên thế giới, nhưng không có gì giống như thử nghiệm một giả thuyết theo kinh nghiệm.

Một vài lý do để xem xét lựa chọn viết lại như thử nghiệm của bạn:

  • Theo kinh nghiệm của tôi, nó thường vui hơn. Một lý do lớn viết lại thường không được lựa chọn trong các tình huống chuyên nghiệp là niềm vui khác xa với tiêu chí duy nhất. Nhưng bạn vẫn còn khá mới đối với tiền mã hóa, vì vậy, niềm vui có lẽ là một tiêu chí khá quan trọng và cũng là một chỉ số cho các yếu tố khác có thể vô hình đối với bạn ở giai đoạn đầu này (niềm vui cho thấy bạn sẽ tìm hiểu thêm, v.v.).
  • Kinh nghiệm của bạn và có lẽ là một cảm giác lương tâm dai dẳng dường như đang nói với bạn rằng viết lại là một điều đáng để xem xét. Nghe giọng nói đó, nếu có. Ngay cả khi bạn không làm theo lời khuyên, ít nhất hãy lắng nghe. Trong tương lai sẽ có nhiều tiếng nói bên ngoài hơn, và bạn cần thực hành lắng nghe ý thức tốt của riêng bạn.
  • Tôi nghi ngờ với việc viết lại, bạn có nhiều khả năng mô đun hóa mã của bạn nhiều hơn. Khi bạn tạo các mô-đun, bạn có các thành phần đáng tin cậy và có thể tái sử dụng nhiều hơn, bạn có thể tận dụng cho các dự án khác. Bạn thậm chí có thể thấy rằng cuối cùng, thứ dường như chỉ là một mô-đun của dự án chính của bạn hóa ra lại là đoạn mã thú vị và có giá trị nhất mà bạn viết.

Hoàn thiện một cái gì đó là một ý tưởng tốt, nhưng không phải trong chân không. Nếu bạn bắt đầu viết lại, thì bạn có thể chọn hoàn thành một cái gì đó bằng cách hoàn thành một mô-đun phụ cụ thể. Bạn có thể đặt mục tiêu đó làm mục tiêu đầu tiên, sau thử nghiệm trên. Hoàn thiện không có nghĩa là hoàn thành dự án chính ban đầu của bạn. Sau khi bạn hoàn thành một mô-đun, hoàn thành một mô-đun khác, vv, cho đến khi bạn hoàn thành việc viết lại toàn bộ phạm vi dự án ban đầu của bạn, nếu bạn muốn.

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.