Dự án gần hoàn thành, nhưng mã spaghetti thủ tục. Tôi có viết lại hay chỉ tiếp tục cố gắng gửi nó? [đóng cửa]


242

Tôi là một nhà phát triển web mới bắt đầu (một năm kinh nghiệm).

Một vài tuần sau khi tốt nghiệp, tôi đã nhận được một công việc để xây dựng một ứng dụng web cho một công ty có chủ sở hữu không phải là một anh chàng công nghệ. Anh ấy đã tuyển dụng tôi để tránh bị đánh cắp ý tưởng của anh ấy, chi phí phát triển cao do một công ty dịch vụ tính phí và để có một người trẻ mà anh ấy có thể tin tưởng để duy trì dự án trong thời gian dài (tôi đã tự mình đi đến những kết luận này sau khi được thuê ).

Khi tôi quay lại, với bằng tốt nghiệp về khoa học máy tính, tôi đã chấp nhận lời đề nghị với suy nghĩ tôi có thể xây dựng bất cứ thứ gì.

Tôi đã gọi các mũi tiêm. Sau một số nghiên cứu, tôi đã giải quyết trên PHP và bắt đầu với PHP đơn giản, không có đối tượng, chỉ là mã thủ tục xấu xí. Hai tháng sau, mọi thứ trở nên lộn xộn, và thật khó để đạt được bất kỳ tiến triển nào. Các ứng dụng web là rất lớn. Vì vậy, tôi quyết định kiểm tra một khung MVC sẽ giúp cuộc sống của tôi dễ dàng hơn. Đó là nơi tôi tình cờ gặp một đứa trẻ tuyệt vời trong cộng đồng PHP: Laravel. Tôi thích nó, nó dễ học và tôi bắt đầu viết mã ngay lập tức. Mã của tôi trông sạch sẽ hơn, ngăn nắp hơn. Nó trông rất tốt.

Nhưng một lần nữa ứng dụng web là rất lớn. Công ty đang gây áp lực buộc tôi phải cung cấp phiên bản đầu tiên mà họ muốn triển khai, rõ ràng và bắt đầu tìm kiếm khách hàng.

Bởi vì Laravel rất vui khi làm việc cùng, nó khiến tôi nhớ tại sao tôi lại chọn ngành này ngay từ đầu - điều mà tôi đã quên khi bị mắc kẹt trong hệ thống giáo dục tồi tệ.

Vì vậy, tôi bắt đầu làm việc trên các dự án nhỏ vào ban đêm, đọc về phương pháp luận và thực hành tốt nhất. Tôi đã xem lại OOP, chuyển sang thiết kế và phân tích hướng đối tượng và đọc cuốn sách Clean Code của chú Bob .

Điều này giúp tôi nhận ra rằng tôi thực sự không biết gì. Tôi không biết cách xây dựng phần mềm CÁCH QUYỀN. Nhưng tại thời điểm này thì đã quá muộn và giờ tôi đã gần xong. Mã của tôi hoàn toàn không sạch, chỉ là mã spaghetti, một nỗi đau thực sự để sửa lỗi, tất cả logic nằm trong bộ điều khiển và có rất ít thiết kế hướng đối tượng.

Tôi có suy nghĩ dai dẳng rằng tôi phải viết lại toàn bộ dự án. Tuy nhiên, tôi không thể làm điều đó ... Họ cứ hỏi khi nào nó sẽ hoàn thành.

Tôi không thể tưởng tượng mã này được triển khai trên một máy chủ. Ngoài ra, tôi vẫn không biết gì về hiệu quả mã và hiệu suất của ứng dụng web.

Một mặt, công ty đang chờ sản phẩm và không thể chờ thêm được nữa. Mặt khác, tôi không thể thấy bản thân mình tiến xa hơn với mã thực tế. Tôi có thể hoàn thành, bọc lại và triển khai, nhưng chúa chỉ biết những gì có thể xảy ra khi mọi người bắt đầu sử dụng nó.

Tôi có viết lại không, hay cứ tiếp tục vận chuyển, hoặc có lựa chọn nào khác mà tôi đã bỏ lỡ không?


142
Hoàn thành nó theo cách bạn đã bắt đầu và xóa sạch nợ kỹ thuật trong phiên bản tiếp theo (nếu có). Sếp của bạn sẽ không biết sự khác biệt. Hãy chắc chắn rằng bạn kiểm tra nó tốt.
Robert Harvey

45
"Nhưng chúa chỉ biết những gì có thể xảy ra khi mọi người bắt đầu sử dụng nó". Đó là niềm vui của việc phát triển phần mềm. Tốt hơn để làm quen với nó;)
linac

144
Đây sẽ là mỗi hệ thống duy nhất bạn từng xây dựng.
Sa thải

57
Phần mềm không bao giờ kết thúc và một khi bạn đến gần, bạn sẽ luôn có cái nhìn sâu sắc khiến bạn muốn ném toàn bộ cơ sở mã ra khỏi cửa sổ. Đừng. Cung cấp một sản phẩm làm việc và sau đó làm chủ nghệ thuật tái cấu trúc. Đó sẽ là một bài học quý giá.
Pieter B

14
Cha tôi thường nói với tôi "Đôi khi bạn phải bắn các kỹ sư và tàu."
corsiKa

Câu trả lời:


253

Bạn đã vấp ngã trên gót chân của hầu hết các nền giáo dục CS: ​​họ dạy cho bạn các công cụ và kỹ thuật, nhưng không phải là thương mại. Xây dựng phần mềm là một nghề thủ công, một công việc mà bạn chỉ có được qua nhiều năm thực hành và kinh nghiệm sử dụng phần mềm của bạn (người dùng chỉ trích gay gắt hơn nhiều so với giáo viên). Xây dựng phần mềm cũng thường là một doanh nghiệp, một trong đó các mục tiêu kinh doanh có thể ghi đè lên tham vọng kỹ thuật.

Trước hết, tàu. Nếu bạn chỉ cho chủ doanh nghiệp phần mềm và họ cảm thấy nó đã sẵn sàng để giao hàng, thì hãy giao hàng. Nếu nó không đến điểm đó, nhưng đóng lại, kết thúc nó. Phần mềm duy nhất quan trọng là phần mềm thực sự được sử dụng. Doanh nghiệp phần mềm duy nhất kiếm được tiền là một doanh nghiệp có sản phẩm.

Thứ hai, bạn đã học được rất nhiều điều có giá trị, vì vậy bạn nên đánh giá cao kinh nghiệm cho những gì nó đã dạy bạn :

  1. Mã treo mà không có kế hoạch hoặc kiến ​​trúc là một công thức cho thảm họa
  2. Có nhiều thứ để lập trình hơn là viết mã
  3. Các chủ doanh nghiệp phi kỹ thuật thường không hiểu tác động của các quyết định kỹ thuật (như ai sẽ thuê) và các nhà phát triển phải giải thích mọi thứ cho họ.
  4. Hầu hết các vấn đề đã được giải quyết tốt hơn nhiều so với bạn sẽ giải quyết chúng, trong các khung hiện có. Nó trả tiền để biết các khung tồn tại và khi nào sử dụng chúng.
  5. Những người mới ra trường được giao cho một dự án lớn với ít hướng dẫn có xu hướng sản xuất một bát mã spaghetti. Điều này là bình thường.

Dưới đây là một số lời khuyên cho bạn về cách tiến hành:

  1. Giao tiếp, giao tiếp, giao tiếp. Bạn phải rất cởi mở và thẳng thắn về tình trạng của dự án và ý tưởng của bạn về cách tiến hành, ngay cả khi bạn không chắc chắn và nhìn thấy nhiều đường dẫn. Điều này khiến cho chủ doanh nghiệp lựa chọn phải làm gì. Nếu bạn giữ kiến ​​thức cho chính mình, bạn sẽ tước đi những lựa chọn của họ.
  2. Chống lại sự cám dỗ của viết lại đầy đủ. Trong khi bạn đang viết lại, doanh nghiệp không có sản phẩm. Ngoài ra, viết lại hiếm khi tốt như bạn tưởng tượng nó. Thay vào đó chọn một kiến ​​trúc và di chuyển codebase đến nó dần dần. Ngay cả một codebase khủng khiếp cũng có thể được cứu vãn theo cách này. Đọc sách về tái cấu trúc để giúp bạn cùng.
  3. Tìm hiểu về kiểm tra tự động / kiểm tra đơn vị . Bạn phải xây dựng sự tự tin về mã, và cách để làm điều đó là che nó bằng các bài kiểm tra tự động. Điều này đi đôi với tái cấu trúc. Miễn là bạn không có các bài kiểm tra, hãy kiểm tra thủ công và toàn diện (cố gắng phá mã của bạn, vì người dùng của bạn sẽ làm như vậy). Ghi nhật ký tất cả các lỗi bạn tìm thấy để bạn có thể ưu tiên và sửa chúng (bạn sẽ không có thời gian để sửa tất cả các lỗi, không có phần mềm nào không có lỗi trong thế giới thực).
  4. Tìm hiểu về cách triển khai một ứng dụng web và giữ cho nó chạy. Cuốn sách Hoạt động trên web: Giữ dữ liệu đúng giờ là một khởi đầu tốt.

4
Những người kinh doanh phi kỹ thuật có những điều họ quan tâm và dù sao cũng sẽ không hiểu những điều kỹ thuật. Các nhà phát triển phải cung cấp cho họ các tùy chọn khả thi về mặt kỹ thuật với chi phí và lợi ích (liên quan đến những thứ cực kỳ khó ghét và phổ biến như học để ước tính thời gian thực hiện các nhiệm vụ).
Jan Hudec

1
Đây là một tình huống trong đó việc viết lại đầy đủ có thể phù hợp - nếu về cơ bản, anh ta đã sử dụng phiên bản đầu tiên làm công cụ đào tạo, thì phiên bản thứ 2 sẽ là "bản mà anh ta nên viết". Tôi nghĩ rằng trong tất cả các trường hợp khác, viết lại là lời khuyên tồi, nhưng không phải ở đây. Không cho một người đã viết mã không thực sự biết những gì anh ta đang làm. Tâm trí bạn, sửa chữa nó nên là một cơ hội đào tạo tuyệt vời!
gbjbaanb

2
Tôi có một lý thuyết làm việc rằng "mỗi đoạn mã sản xuất được viết lại ít nhất một lần." Cho đến nay theo kinh nghiệm chuyên môn của tôi, nó khá đúng ở cả cấp độ vĩ mô (kiến trúc) và vi mô (phương pháp). Bí quyết là học khi những nhà tái cấu trúc này phù hợp.
zourtney

11
+1 cho điểm đầu tiên một mình. Hãy nhớ tất cả mọi người, vận chuyển là một tính năng quá .
thegrinner

5
Nếu boos của bạn thích trang web, nó đã được thực hiện. Sếp của bạn đã giảm giá và thuê một sinh viên tốt nghiệp đại học mới. Anh ta hoặc biết những gì anh ta sẽ nhận được hoặc xứng đáng được giáo dục. Phần mềm của bạn có lỗi. Sống với nó. Tất cả chúng ta làm. Bạn thông minh hơn bạn một năm trước. Yêu cầu tăng lương, hoặc tìm một công việc mới (hoặc là tốt). Nếu bạn tìm kiếm một công việc mới, hãy chắc chắn chọn một nhà tuyển dụng với một nhóm mà bạn có thể học những thói quen tốt.
SeattleCplusplus

114

Điều này có vẻ như mọi hệ thống khác đã được ném vào tôi để sửa chữa.

Hãy thư giãn, điều này xảy ra với rất nhiều người. Một thiếu niên bị ném vào tận cùng không có kinh nghiệm, không có sự giúp đỡ, không có sự hỗ trợ và không có hướng dẫn không chính xác là một công thức để thành công. Thuê và mong đợi một lập trình viên cơ sở xây dựng một hệ thống hoàn toàn mới từ đầu hoạt động tốt, hoạt động tốt và có thể bảo trì là không thực tế. Thật may mắn nếu tất cả những điều đó xảy ra với một lập trình viên cao cấp.

Theo ý kiến ​​của tôi bạn phải đến sạch. Điều này sẽ không vui Nói với họ rằng bạn đã cố gắng hết sức, nó hoạt động (chủ yếu), nhưng bạn lo lắng rằng nó có thể hoạt động không tốt và sẽ có rất nhiều lỗi ( luôn có lỗi). Nó cần được xem xét bởi một lập trình viên cao cấp và họ có thể khắc phục mọi vấn đề về hiệu năng / bảo mật rõ ràng một cách nhanh chóng. Hoặc họ có thể triển khai nó và vượt qua các ngón tay của họ. Nó sẽ ổn thôi, hoặc bốc khói. Có lẽ bạn có thể khắc phục vấn đề khi chúng xuất hiện. Nếu bạn có một cơ sở người dùng lớn có thể không.

Hoặc bạn có thể làm những gì hầu hết mọi người làm trong tình huống này: lấy tiền, biến mất và để họ sắp xếp nó ra. Tôi sẽ để nó cho bạn biết lựa chọn đạo đức là gì.

Chỉnh sửa (vì câu hỏi này có rất nhiều phiếu tôi cũng có thể thêm một số nội dung)

Một phần niềm vui của việc trở thành một lập trình viên là những người phi kỹ thuật (có thể là người quản lý của bạn, chắc chắn là phần còn lại của doanh nghiệp) không biết bạn làm gì. Điều này là tốt và xấu. Một phần của điều xấu là bạn phải liên tục giải thích cách các dự án phát triển phần mềm hoạt động. Lập kế hoạch, yêu cầu, đánh giá mã, thử nghiệm, triển khai và sửa lỗi. Công việc của bạn là giải thích tầm quan trọng của kiểm tra và dành thời gian để kiểm tra. Bạn phải đứng trên mặt đất của bạn ở đây. Mọi người sẽ không hiểu tầm quan trọng ( "chúng ta có thể bắt đầu sử dụng nó không?") nhưng một khi họ bắt đầu thử nghiệm (không phải trong môi trường sống!) họ sẽ nhanh chóng hiểu được lợi ích. Một trong những lý do tại sao họ thuê bạn là vì họ không biết gì về phát triển phần mềm, do đó, tùy thuộc vào bạn để giáo dục họ. Bạn cần nhấn mạnh tầm quan trọng của việc kiểm tra và sửa lỗi ở đây - hãy nhớ rằng, họ không phải là lập trình viên, họ không biết sự khác biệt giữa cách chia cho 0 và thẻ html bị hỏng.

Thường thì rất nhiều vấn đề nảy sinh không phải là lỗi. Chúng sẽ là các vấn đề về khả năng sử dụng, các yêu cầu bị bỏ lỡ, các yêu cầu đã thay đổi, kỳ vọng của người dùng (tại sao tôi không thể sử dụng điều này trên điện thoại di động của mình?) Và sau đó là các lỗi thực tế thực tế. Bạn cần phải giải quyết những vấn đề này trước khi phát hành trực tuyến - thường thì rất nhiều lỗi có thể được khắc phục hoặc sửa vài ngày sau đó. Nếu mọi người mong đợi một hệ thống hoàn hảo, họ sẽ phải chịu nhiều đau đớn. Nếu họ đang mong đợi lỗi, cuộc sống của bạn sẽ dễ dàng hơn trong vài tuần tới.

Ồ và đừng nhầm lẫn giữa kiểm tra người dùng với kiểm tra đơn vị cũng như kiểm tra hệ thống.

  • Kiểm thử đơn vị - chức năng mã của tôi có trả về đúng giá trị không
  • Kiểm tra hệ thống - nó có báo lỗi khi tôi nhấp vào X không
  • Kiểm tra chấp nhận người dùng (UAT) - chương trình có phù hợp với yêu cầu không? Liệu nó làm những gì họ yêu cầu bạn làm cho nó làm? Nó có thể đi trực tiếp không?

Nếu bạn không viết ra những yêu cầu của những gì họ yêu cầu bạn làm, UAT sẽ khó khăn hơn nhiều. Đây là nơi rất nhiều người ngã xuống. Có những gì họ muốn hệ thống viết ra giấy sẽ giúp cuộc sống của bạn dễ dàng hơn rất nhiều. Họ sẽ nói "Tại sao nó không làm X?" và bạn có thể nói "Bạn đã bảo tôi làm nó Y". Nếu chương trình sai, sửa nó. Nếu các yêu cầu sai, sửa tài liệu, yêu cầu thêm một hoặc hai ngày (không, nhấn mạnh vào nó), thực hiện thay đổi, cập nhật tài liệu và kiểm tra lại.

Khi bạn đã trải qua quá trình này một vài lần, bạn có thể bắt đầu tìm hiểu về Agile .. nhưng đó là một thế giới khác :)

TL; Kiểm tra DR là tốt


7
Đúng và điển hình. Tôi sẽ nói rằng việc rời đi thậm chí rõ ràng là đạo đức, đó không phải là vấn đề của những người mới đến để quản lý lực lượng lao động trong dự án, vì vậy tôi hoàn toàn hiểu nếu ai đó rời đi vì điều đó.
CsBalazsHungary

1
+1 khi thừa nhận rằng hầu hết mọi người sẽ lấy tiền và biến mất. Loại điều này là những gì giữ cho các chuyên gia tư vấn trong công việc.
James_pic

Định nghĩa thử nghiệm không tốt ở đây. Kiểm thử đơn vị xác minh thông số kỹ thuật của đơn vị, kiểm thử tích hợp xác minh thông số kỹ thuật của hệ thống đầu cuối, thử nghiệm chấp nhận (có hoặc không có "người dùng") xác minh thông số kỹ thuật kinh doanh của sản phẩm. "Kiểm tra hệ thống" có thể có nghĩa là hầu hết mọi thứ ngoài kiểm thử đơn vị. Xác minh giá trị trả về không phải lúc nào cũng cần thiết hoặc hữu ích trong kiểm tra đơn vị và hiếm khi kiểm tra giao diện người dùng tự động tốt chỉ thất bại nếu hệ thống "ném lỗi".
Aaronaught

"Công việc của bạn là giải thích tầm quan trọng của kiểm tra và dành thời gian để kiểm tra." Tôi không phải là một lập trình viên 'thực sự', nhưng cách tốt nhất tôi có thể giải thích là nếu một người vận hành máy tiện không có một bộ calip quay số trong máy của anh ta. Cách duy nhất anh ta biết là anh ta đã làm điều gì đó tồi tệ là khi QC kiểm tra và nói với anh ta rằng nó sai. Nếu bạn không có QC và không có thử nghiệm đơn vị, thì giống như gia công một cách mù quáng một phần và gửi nó ra khỏi cửa. Cũng giống như bất kỳ ngành công nghiệp nào khác - Nếu bạn không có cách nào để kiểm tra sản phẩm của mình, không có cách nào để biết liệu những gì bạn vận chuyển thậm chí sẽ hoạt động.
dùng2785724

@ user2785724 - nếu bạn đang viết mã, bạn là một lập trình viên thực thụ. Có thể bạn có ít kinh nghiệm hơn, nhưng điều đó không khiến bạn trở thành một lập trình viên.
Rocklan

61

Bất cứ khi nào bạn bắt đầu từ đầu, gần như chắc chắn bạn sẽ mắc cùng một số lỗi hoặc nhiều hơn do Hệ thống thứ hai Syndromme . Những sai lầm mới của bạn sẽ khác, nhưng lượng thời gian cần thiết để gỡ lỗi sẽ tương tự và do đó sẽ tuyệt vọng về cách nó không phù hợp. Nó cũng sẽ trì hoãn việc triển khai vào sản xuất hoặc triển khai các tính năng mới nếu phiên bản đầu tiên được triển khai, điều này sẽ gây rắc rối nghiêm trọng cho công ty. Joel Spolsky gọi đó là "sai lầm chiến lược tồi tệ nhất" mà bất kỳ công ty hoặc nhà phát triển nào cũng có thể mắc phải.

Cách tiếp cận được đề xuất là thay vì dọn dẹp từng mớ hỗn độn ban đầu trong quá trình bảo trì. Và thậm chí đừng cố gắng cấu trúc lại nó chỉ vì lợi ích của nó. Bên cạnh đó, các nhà quản lý thường xem đó là sự lãng phí tiền bạc (thường là như vậy) và nó mang lại rủi ro không cần thiết khi đưa ra các lỗi mới. Một khi bạn gỡ lỗi mã một cách đau đớn, nó có thể không đẹp, nhưng nó sẽ hoạt động. Vì vậy, hãy để nó cho đến khi bạn cần chạm vào nó vì những lý do khác (có thể là sửa lỗi, tính năng mới hoặc chỉ là một thay đổi theo yêu cầu của tiếp thị). Sau đó làm sạch các bộ phận khó điều chỉnh nhất. Điều này thường được gọi là Quy tắc Hướng đạo Boy .

Và tại thời điểm đó, bạn không cần phải tranh luận với người quản lý. Chỉ cần bao gồm tái cấu trúc mong muốn tối thiểu trong ước tính cho yêu cầu. Bạn sẽ học hỏi kinh nghiệm khi bạn có thể đủ khả năng để mang lại một chút bởi vì công ty thực sự đang ở trong tình trạng khắc phục và khi bạn không muốn tạo ra vấn đề trong tương lai và chỉ không thừa nhận bất kỳ khả năng nào sẽ nhanh chóng hack nó.

Cuối cùng, thêm một chút về cách đọc khuyến nghị: Big Ball of Mud .


1
+ long.MaxValue cho c2.com/cgi/wiki Tôi thích trang web đó, mặc dù có vẻ như đã chết.
Người dùng khác

4
Tôi chưa bao giờ nghe nói về Joel Spolsky, nhưng tôi chỉ dành một giờ đồng hồ để đọc một số bài đăng trên blog của anh ấy. Anh ấy hoàn toàn vui nhộn và rõ ràng là rất hiểu biết.
Adam Johns

9
@AdamJohns: Nhưng bạn đang sử dụng phần mềm của anh ấy. Ngay bây giờ. Anh ấy là người chính đằng sau trang web này.
Jan Hudec

1
@JanHudec Anh và Atwood.
jpmc26

5
Cuối cùng, một người khác chưa bao giờ nghe nói về Spolsky trước khi truy cập trang web này. Từ đọc đến đây bạn sẽ nghĩ anh ấy là người đến thứ hai.
MDMoore313

29

Tôi quên nơi tôi đọc nó lần đầu tiên, nhưng tôi chỉ muốn lặp lại, mạnh mẽ hơn một chút, những gì người khác đã nói:

Vận chuyển là một tính năng.

Không có gì tệ hơn là một anh chàng luôn "dọn dẹp" mã hiện có (có thể là hack, xấu, bẩn) hoạt động hoàn hảo , giới thiệu các lỗi mới, v.v. Điều quan trọng trong thế giới thực là hoàn thành công việc của bạn. Bạn đã làm điều đó. Tàu. Đừng để bị lạc trong thiết kế lại của một dự án hoạt động hoàn toàn tốt, ngay cả khi nó xấu xí dưới mui xe. Khi bạn sửa nó, hãy tăng dần và tạo cho mình một bộ kiểm tra tốt để bạn có ít hồi quy nhất có thể.


Không chắc đây có phải là bản gốc thực sự hay không, nhưng bài viết này xuất hiện dưới dạng Google đầu tiên. Tất nhiên là bởi Joel (anh ấy đã viết khá nhiều về chủ đề này và đã viết nó khá tốt).
Jan Hudec

24

Mỗi dự án để lại cho bạn thông minh hơn bạn trước đây. Sau mỗi dự án, bạn sẽ tích lũy được nhiều kinh nghiệm hơn, điều này sẽ rất tiện lợi khi bạn có nó từ đầu. Tôi biết rằng thật khó để không xem lại tất cả mọi thứ và áp dụng những gì bạn đã học. Nhưng hãy nhớ:

Hoàn hảo là kẻ thù của tốt.

Đối với khách hàng, tốt hơn hết là có một phần mềm tốt hơn là một phần mềm hoàn hảo sẽ không bao giờ được phát hành.

Đây chỉ là dự án đầu tiên của bạn. Sẽ có nhiều dự án nữa trong tương lai nơi bạn có thể áp dụng mọi thứ bạn đã học được từ đầu.


15

Tôi [...] đọc mã sạch Bob của Bác.

Tôi có suy nghĩ dai dẳng rằng tôi phải viết lại toàn bộ dự án.

Cuốn sách này có một phần được đặt tên, rất thích hợp, "The Grand Redesign in the Sky".

Đừng cố viết lại tất cả mọi thứ bởi vì, trong trường hợp không chắc là bạn có thời gian để thực hiện nó, dù sao bạn cũng sẽ phải đối mặt với những vấn đề tương tự. Khi bạn hoàn thành thiết kế lại, bạn sẽ học được những điều mới và sẽ nhận ra rằng những phần đầu tiên của nó rất không chuyên nghiệp, vì vậy bạn sẽ muốn viết lại nó một lần nữa.

Thiết kế lại và viết lại là tốt, nhưng chỉ khi chúng được thực hiện tăng dần trên một hệ thống làm việc. Như một người dùng khác đã chỉ ra, hãy tuân thủ Quy tắc Hướng đạo nam, tái cấu trúc mã của bạn từng chút một khi bạn làm việc với nó.


6
Hơi đúng. Tôi đã lặp đi lặp lại thiết kế của cùng một codebase trong một thập kỷ, và tôi vẫn nghĩ kiến ​​trúc của những gì tôi đã làm năm ngoái là tào lao. Bạn không bao giờ ngừng học hỏi.
Joeri Sebrechts

1
Và chỉ cần làm rõ, điều làm cho các cải tiến gia tăng trở nên khả thi là bạn có một loạt các thử nghiệm để giúp bạn tự tin rằng bạn không phá vỡ chức năng hiện có. Nếu bạn thấy mình đang nghĩ "Tôi không thể thay đổi điều đó" thì bạn đã xác định được một nơi nào đó cần bảo hiểm kiểm tra.
PhilDin

9

Bạn đang làm tốt đấy.

Bạn nói rằng mã của bạn hoạt động, và nó gần như đã sẵn sàng để giao hàng, phải không? Và bạn nhận thấy rằng mã của bạn có thể được cải thiện rất nhiều. Tốt

Tình huống khó xử của bạn khiến tôi nhớ nhiều về trải nghiệm đầu tiên của tôi với nghề tự do (được tuyển dụng khi đang học năm thứ 2 tại uni để tạo ra một hệ thống POS đa ngôn ngữ). Tôi đã trải qua những câu hỏi bất tận vì tôi không bao giờ hài lòng với mã, muốn có khả năng mở rộng, muốn phát minh lại bánh xe tốt hơn ... Nhưng tôi chỉ trì hoãn dự án (như, khoảng 12 tháng) và ... gì? Khi bạn triển khai điều đó, nó vẫn cần rất nhiều bằng chứng, thử nghiệm, vá lỗi, v.v ...

Bạn có kinh nghiệm làm việc với các cơ sở mã chuyên nghiệp? Nhiều cơ sở mã có đầy đủ các mã kỳ quặc, khó duy trì. Một cách khác để khám phá sự phức tạp của phần mềm bằng cách tự mình xây dựng một chương trình lớn sẽ duy trì / mở rộng mã lộn xộn không kém do người khác viết.

Các trường hợp duy nhất mà tôi thấy viết lại hoàn thành rất tốt là khi nhóm đồng thời áp dụng một công cụ / khung công cụ mới.

Nếu logic cơ bản (những gì chương trình làm, không phải cách nó được trình bày như các hàm, các lớp và vv ...) là âm thanh, thì nó sẽ hoạt động tốt như vậy, vì vậy, bạn nghĩ rằng mã spaghetti không có nghĩa là nó không nên được triển khai.

Bạn cần để cho khách hàng của bạn có một cái gì đó mà họ có thể sử dụng. Sau đó, khi họ yêu cầu bạn cải thiện chức năng / thêm chức năng, bạn sẽ quyết định xem có cần tái cấu trúc hay không và có thể cho khách hàng của bạn biết rằng "một số công việc kỹ thuật là cần thiết để tích hợp tính năng mới". Qua đó họ sẽ hiểu rằng điều đó sẽ khiến họ tốn nhiều tiền hơn, và họ sẽ phải chờ lâu hơn. Và họ sẽ hiểu (hoặc bạn có thể rút ra).

Thời điểm tốt hơn để viết lại mọi thứ sẽ là khi một khách hàng khác yêu cầu bạn tạo ra một cái gì đó tương tự.

Nói tóm lại, trừ khi bạn có thể chứng minh rằng toàn bộ sự việc sẽ thổi vào mặt mọi người nếu nó được triển khai, việc trì hoãn triển khai sẽ không chuyên nghiệp và sẽ không có lợi cho bạn hoặc khách hàng của bạn. Học cách làm các bộ tái cấu trúc nhỏ trong khi sửa lỗi hoặc thêm các tính năng mới, đó sẽ là kinh nghiệm quý giá cho bạn.


7

Hầu hết những gì tôi sẽ nói để trả lời câu hỏi của bạn đã được nói bởi những người khác. Đọc "Những điều bạn không bao giờ nên làm, Phần I" của Joel Spolsky (cùng với một số bài viết khác của ông về "các phi hành gia kiến ​​trúc"). Hãy nhớ rằng "sự hoàn hảo là kẻ thù của điều tốt". Học cách tái cấu trúc tăng dần. Vận chuyển là quan trọng, vv

Điều tôi muốn nói thêm là đây: bạn đã được giao nhiệm vụ với một thứ được coi là có thể thực hiện được bởi một sinh viên mới tốt nghiệp làm việc với ngân sách / khung thời gian khởi động nhỏ. Bạn không cần bất cứ điều gì phức tạp hơn nhiều so với lập trình thủ tục, có cấu trúc, tốt. (Và, FYI, "lập trình thủ tục" không phải là một từ xấu. Nó là một điều cần thiết ở một số cấp độ trong hầu hết các trường hợp, và nó hoàn toàn phù hợp cho nhiều dự án.)

Chỉ cần chắc chắn rằng bạn thực sự làm cấu trúc, lập trình thủ tục. Sự lặp lại trong mã của bạn không nhất thiết là một dấu hiệu cho thấy bạn cần các cấu trúc đa hình lớn. Nó đơn giản có thể là một dấu hiệu cho thấy bạn cần lấy mã lặp lại và đưa nó vào chương trình con. Dòng chảy kiểm soát "Spaghetti" có thể chỉ đơn giản là một cơ hội để thoát khỏi toàn cầu.

Nếu có những khía cạnh của dự án gọi một cách hợp pháp cho tính đa hình, kế thừa triển khai, v.v., tôi sẽ đề nghị rằng có thể quy mô của dự án đã bị đánh giá thấp.


4
Tôi sẽ thêm rằng mã spaghetti không giới hạn ở mã thủ tục. Việc sử dụng đa hình và thừa kế không chính xác có thể dẫn đến tình trạng lộn xộn khó hiểu hơn nhiều so với nhiều phần thủ tục phức tạp. Việc luồng điều khiển nhảy khắp nơi không quan trọng bằng cách sử dụng các thủ tục được xác định sai hoặc kế thừa trong hệ thống phân cấp lớp phức tạp; nó vẫn nhảy khắp nơi và khó theo dõi.
Jan Hudec

4

Nếu bạn thực sự quan tâm đến tình huống khó xử mà bạn có, bạn cũng nên đọc "Khởi nghiệp tinh gọn". Rất nhiều lời khuyên mà bạn đang được đưa ra ở đây sẽ cộng hưởng với bạn nhiều hơn nếu bạn đọc cuốn sách đó. Về cơ bản, tỷ lệ đốt tài nguyên là kẻ thù tồi tệ nhất của bạn và không có gì có giá trị hơn đối với bạn và tổ chức của bạn so với phản hồi của người dùng cuối / khách hàng. Vì vậy, hãy đưa sản phẩm của bạn đến trạng thái khả thi (Sản phẩm khả thi tối thiểu - hoặc MVP) và sau đó gửi sản phẩm ra khỏi cửa (bất kể mã thực sự trông như thế nào). Hãy để khách hàng của bạn ra lệnh cho các thay đổi và phiên bản trong tương lai của bạn chứ không phải theo cách khác. Nếu bạn tập trung vào cách tiếp cận đó, cả bạn và sếp của bạn sẽ hạnh phúc hơn về lâu dài.


4

Vì những lý do mà những người khác đã giải thích cặn kẽ, đã đến lúc kết thúc dự án và vận chuyển nó, thật đau đớn vì điều đó có thể xảy ra.

Tôi chỉ muốn nhấn mạnh rằng việc thử nghiệm ứng dụng cũng là một phần của việc "hoàn thiện" nó. Nếu các phần quan trọng của chức năng chưa được thực hiện triệt để và xác nhận kết quả chính xác, thì bạn có lý khi lo ngại rằng mọi người sẽ gặp rắc rối với ứng dụng này khi ứng dụng được triển khai.

Kiểm tra đơn vị và kiểm tra cấp cao tự động là tuyệt vời và là những thứ bạn nên có nhiều nhất có thể trước khi bạn cố gắng cấu trúc lại (hoặc viết lại) ứng dụng này. Nhưng ngay bây giờ bạn chủ yếu cần kiểm tra nó, ngay cả khi bạn phải chạy mọi bài kiểm tra "bằng tay" và xác nhận hoạt động chính xác "bằng mắt". Nếu bạn có thể tìm ra cách tự động hóa các thử nghiệm đó sau, điều đó sẽ giúp ích khi đến lúc bắt đầu làm việc trên phiên bản tiếp theo của sản phẩm.

Một số người có sở trường là ngồi xuống trước một dự án phần mềm mới với tư cách là người dùng thử nghiệm alpha và khiến mọi thứ trở nên sai lầm. Đó là, họ giỏi phá vỡ mọi thứ. Nếu bạn đủ may mắn để có một người tài năng như vậy làm việc với bạn, hãy để họ dùng thử ứng dụng trước để bạn có cơ hội khắc phục sớm mọi lỗi rõ ràng. Nếu bạn phải tự thực hiện nhiệm vụ này, thì:

  • Hãy có phương pháp.
  • Hãy thử mọi tính năng.
  • Giả sử bạn là người dùng thiếu kinh nghiệm với ứng dụng của bạn. Phạm sai lầm ngu ngốc và xem cách phần mềm xử lý chúng.
  • Viết ra những gì bạn đang làm để bạn có thể thử lại sau khi bạn nghĩ rằng bạn đã khắc phục vấn đề.

Tôi hoàn toàn đồng ý với điều này. Đừng quên kiểm tra thủ công trong sản xuất quá. Cho dù bạn đã thực hiện bao nhiêu thử nghiệm trong môi trường phát triển, bạn luôn cần kiểm tra độ tỉnh táo trong môi trường trực tiếp sau mỗi lần triển khai. Bạn có thể yêu cầu đồng nghiệp của bạn giúp đỡ với điều này.
Will Sheppard

1

Câu hỏi của bạn nói: "Bắt đầu sai, tôi có nên bắt đầu lại không" trong khi văn bản bổ sung thực sự nói "Dự án đã hoàn thành, nhưng đã làm sai, tôi nên bắt đầu lại". Đối với tiêu đề câu hỏi một mình: Nếu số lượng công việc lập trình mà bạn đã thực hiện là nhỏ so với tổng số công việc cần thiết, thì bắt đầu lại tất cả sẽ có ý nghĩa. Điều đó xảy ra rất nhiều khi vấn đề phức tạp và hiểu sai, và khá nhiều thời gian được dành để tìm ra vấn đề thực sự là gì. Không có điểm nào tiếp tục với một khởi đầu tồi tệ, nếu vứt nó đi và bắt đầu lại, lần này với sự hiểu biết tốt về vấn đề, có nghĩa là bạn sẽ thực sự kết thúc nhanh hơn.


0

Đây là những gì tôi sẽ làm cá nhân:

  1. Hãy từ bỏ, kiếm cớ và từ bỏ (thậm chí bạn có thể trả lại một phần tiền lương của mình để bạn trông không tệ)
  2. Làm sạch mã của bạn càng nhiều càng tốt
  3. Làm tài liệu về tất cả các phần tốt của công việc của bạn như thiết kế tốt, ý tưởng tốt, v.v ...

Tại sao tôi đề nghị tất cả những điều này cho bạn?

Vì nghĩ về tương lai. Sẽ có thời gian trong tương lai khi một số người nhất định sẽ nắm giữ mã này. Họ sẽ đưa ra tất cả các loại giả định và đánh giá về bạn và khả năng của bạn. Họ không quan tâm khi bạn viết nó, họ không quan tâm đến hoàn cảnh. Họ chỉ muốn nhìn thấy trong đó những gì họ muốn thấy để xác nhận bất cứ điều gì họ muốn xác nhận.

Bạn sẽ bị gắn mác là bất cứ tên xấu nào, thuật ngữ họ có thể đưa ra để tác động tiêu cực đến bạn. Và mặc dù bạn trong tương lai rất có thể hoàn toàn khác nhau về khả năng kỹ thuật, kỹ năng, kiến ​​thức, phong cách và tình huống sẽ rất khác nhau, mã này sẽ được sử dụng để chống lại bạn theo mọi cách có thể. Nó giống như một tòa án nơi họ có thể nói tất cả những điều xấu về bạn và mã và thiết kế của bạn và bạn thậm chí không nhận thức được điều đó để bạn có thể giải thích và tự bào chữa. (và bạn có thể học rất thường xuyên rằng họ sai lầm sâu sắc, lặp đi lặp lại) Vì vậy, đừng làm điều đó. Bỏ cuộc.

Tin tôi đi, có những người đưa ra nhiều giả định về bạn vì bạn đã làm gì đó cho bất cứ mục đích gì vào bất cứ lúc nào. Đối với họ, nếu bạn đã làm điều này trong tình huống A, bạn sẽ làm điều đó trong tình huống B. Họ nghĩ rất đơn giản.


0

Thêm hai gợi ý nữa, tôi sẽ đặt cược ít nhất một trong số những điều bạn chưa thực hiện.

1) Đặt một trình theo dõi lỗi tại chỗ và dạy sếp của bạn sử dụng nó. Đây có thể là một phần của cuộc trò chuyện về cách bạn làm hỏng, đã học tốt hơn và sẽ sửa nó theo cách có kế hoạch

2) Bắt đầu sử dụng kiểm soát phiên bản, mặc dù hy vọng bạn đã làm như vậy.

Có rất nhiều hệ thống được lưu trữ ngoài đó cung cấp miễn phí cả hai tài khoản trên cho các tài khoản nhỏ. Tôi đặc biệt thích FogBugz, một hệ thống hoàn thành nhiệm vụ và ước tính tuyệt vời sẽ giúp sếp của bạn chắc chắn hơn nữa rằng bạn đang giải quyết mọi thứ một cách được quản lý tốt.

biên tập

Ồ, có ai đó thực sự không thích điều này - một downvote VÀ một cờ xóa? Tại sao?

Tôi đã phát triển phần mềm trong hơn ba mươi năm bao gồm rất nhiều công việc tư vấn và kế thừa mã của người khác. Một số lượng lớn các hệ thống sự cố mà tôi đã thấy là nơi mọi người đào hố và không có ghi chú chi tiết về cách họ đến đó và họ cũng không kiểm soát phiên bản.


-2

Để trả lời câu hỏi của bạn: như rất nhiều người khác đã nói, không. Vận chuyển và dọn dẹp từng chút một trong quá trình sửa lỗi.

Ngoài ra, trong khi sách / StackExchange / webforums là tài nguyên học tập tốt, bạn có thể thấy rằng không có gì có thể phù hợp với việc học bạn sẽ nhận được khi làm việc (hoặc thậm chí chỉ thảo luận về công việc) với các lập trình viên khác. Tìm kiếm và tham dự một nhóm địa phương cho một công nghệ bạn đang sử dụng hoặc muốn học là một sự đầu tư tuyệt vời cho thời gian của bạn. Bên cạnh kiến ​​thức kỹ thuật cần có, đây là một cách dễ dàng để kết nối mạng vô giá khi bạn mong đợi các hợp đồng biểu diễn trong tương lai.


-2

Sếp của bạn đã nhận thức được mức độ kinh nghiệm của bạn khi anh ta thuê bạn. Chỉ cần bày tỏ mối quan tâm của bạn, và cho anh ấy biết bạn đang lo lắng về nó. Đồng thời cho anh ấy biết bạn đã học được bao nhiêu và bạn có thể làm tốt hơn bao nhiêu cho dự án tiếp theo.


-2

Bạn là một nhà phát triển web mới bắt đầu, không có nhà phát triển giỏi nào để tư vấn cho bạn, ông chủ của bạn đã thuê bạn biết điều này hoàn toàn tốt. Tôi nghĩ rằng bạn đang làm tốt như bất cứ ai có thể mong đợi bạn làm. Trên thực tế, thực tế là bạn có cái nhìn sâu sắc rằng công việc có thể tốt hơn, và bạn thực sự đã học được những điều cho phép bạn làm nó tốt hơn, có nghĩa là bạn đang làm tốt hơn hầu hết. Hãy nhớ cho sự tỉnh táo của bạn rằng phiên bản của bạn đã bắt đầu công việc không thể làm nó tốt hơn. Ai đó có nhiều kinh nghiệm hơn (và do đó được trả lương cao hơn), hoặc bạn với một dự án có giá trị kinh nghiệm, có thể đã làm điều đó tốt hơn.

Phải làm gì bây giờ : Hãy vui vì bạn là một nhà phát triển tốt hơn so với một năm trước. Dự án tiếp theo bạn sẽ làm tốt hơn (và cuối cùng, bạn sẽ có nhiều kinh nghiệm trở lại và không hài lòng với những gì bạn đã làm; điều đó là bình thường). Thay đổi hoặc viết lại dự án cuối cùng sẽ mang lại cho doanh nghiệp rất ít lợi ích cho chi phí. Những gì bạn có thể làm là thay thế mã xấu bằng mã tốt khi bạn cần thay đổi; điều đó có ý nghĩa bởi vì sửa đổi mã bảo trì kém có thể khó hơn thay thế bằng mã tốt. Và nếu bạn nhận được một nhà phát triển có kinh nghiệm mới để giúp đỡ, nói với họ rằng này mã không phải là một ví dụ rằng họ nên sao chép.

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.