Tôi không thể lập trình vì mã tôi đang sử dụng sử dụng các kiểu mã hóa cũ. Đây có phải là bình thường cho các lập trình viên?

29

Tôi có công việc thực sự đầu tiên là lập trình viên, nhưng tôi không thể giải quyết bất kỳ vấn đề nào do phong cách mã hóa được sử dụng. Mã ở đây:

Không có ý kiến
Không có chức năng (50, 100, 200, 300 hoặc nhiều dòng được thực hiện theo trình tự)
Sử dụng rất nhiều ifcâu lệnh với rất nhiều đường dẫn
Có các biến mà làm cho không có ý nghĩa (Eg .: cf_cfop, CF_Natop, lnom, r_procod)
Sử dụng một ngôn ngữ cũ (Visual FoxPro 8 từ 2002), nhưng có những bản phát hành mới từ năm 2007.

Tôi cảm thấy như mình đã quay trở lại năm 1970. Có phải bình thường khi một lập trình viên quen thuộc với OOP, mã sạch, các mẫu thiết kế, v.v ... gặp rắc rối với mã hóa theo cách thức cũ này không?

EDIT : Tất cả các câu trả lời là rất tốt. Đối với hy vọng (un) của tôi, dường như có rất nhiều loại cơ sở mã này trên khắp thế giới. Một điểm được đề cập đến tất cả các câu trả lời là cấu trúc lại mã. Vâng, tôi thực sự thích làm điều đó. Trong dự án cá nhân của tôi, tôi luôn làm điều này, nhưng ... tôi không thể cấu trúc lại mã. Lập trình viên chỉ được phép thay đổi các tệp trong tác vụ mà chúng được thiết kế.

Mọi thay đổi trong mã cũ phải được nhận xét trong mã (ngay cả với Subversion là kiểm soát phiên bản), cộng với thông tin meta (ngày, lập trình viên, tác vụ) liên quan đến thay đổi đó (điều này đã trở thành một mớ hỗn độn, có mã với 3 dòng được sử dụng và 50 dòng cũ nhận xét). Tôi nghĩ rằng đó không chỉ là vấn đề về mã, mà còn là quản lý vấn đề phát triển phần mềm.

coding-style

— Renato Dinhani
nguồn

43

Vâng tất nhiên đó là bình thường. Bạn đã được đào tạo để làm việc theo một cách nhất định và hầu hết việc đào tạo của bạn là vô ích khi đối mặt với một cơ sở mã được thực hiện theo một cách hoàn toàn khác. Điều đó nói rằng các nguyên tắc cốt lõi đã không thay đổi nhiều như vậy, và sau cú sốc ban đầu, bạn sẽ bắt đầu điều chỉnh ...

— yannis

12

Bạn không thiếu nhiều bằng cách không sử dụng ý kiến. Nếu bất cứ điều gì mọi người lạm dụng chúng.

— JohnFx

22

@JohnFx Không đồng ý với bạn, nhưng đã phải đối mặt với nhiều hơn những lời lẽ tào lao vô nghĩa, tôi nói rằng tôi thích những bình luận thừa / lỗi thời hơn là không có bình luận nào cả.

— yannis

25

Điều này có vẻ xấu - nhưng tôi rất vui vì bạn đang cảm thấy loại đau này sớm trong sự nghiệp của mình, vì nó sẽ là một động lực lớn để không viết mã như loại bạn đang duy trì.

— Bork Blatt

19

Một trong những kỹ năng quan trọng nhất bạn có thể phát triển với tư cách là một lập trình viên là có thể hiểu và cấu trúc lại mã của người khác. Nếu bạn không thành thạo nó, bạn sẽ không bao giờ là một lập trình viên giỏi. Bạn may mắn khi có cơ hội học kỹ năng này.

— Paul Tomblin

0

Ok, tôi sẽ cùn. Đó là một nơi tồi tệ để làm việc ... Tôi đã ở trong những tình huống như vậy, và thường thì nó kết thúc với việc bạn bị mã này nuốt chửng. Sau một năm hoặc lâu hơn, bạn sẽ quen với nó và bạn sẽ không biết cách sử dụng các lựa chọn thay thế hiện đại để đạt được cùng một nhiệm vụ dễ dàng hơn, theo cách dễ bảo trì hơn và cũng nhanh hơn trong thời gian chạy hầu hết các trường hợp.

Tôi đã rời khỏi một nơi làm việc như thế, bởi vì, chỉ sau một tháng, tôi cảm thấy mình bị kéo vào một mã skool cũ. Tôi đã cố gắng để cho nó đi, nhưng quyết định không. Tôi không thể sử dụng mã sạch và bắt đầu mất các kỹ năng vì thiếu thực hành hàng ngày. Bất kỳ cách tiếp cận hiện đại nào cũng phải được sự chấp thuận của 3 lớp nhà phát triển, điều không bao giờ xảy ra, bởi vì ý tưởng là mọi thứ có thể bị phá vỡ khi sử dụng các phương pháp hiện đại. Và bản chất dễ vỡ của mã xuất hiện khi bạn không sử dụng các phương pháp hiện đại là khá đáng sợ.

Đừng hiểu sai ý tôi, có những trường hợp người ta quá kỹ thuật và tôi chống lại điều đó. Nhưng việc bị kéo vào '80 quy ước và phong cách mã hóa trong khoảng thời gian dài sẽ ngăn cản bước tiến của bạn, và, tôi nghĩ, cơ hội nghề nghiệp.

Sau đó, một lần nữa, bạn phải kiếm tiền, vì vậy đôi khi bạn phải làm những gì bạn không chính xác. Theo dõi các triệu chứng kiệt sức và biến mã hóa thành một nhiệm vụ trần tục trong những trường hợp đó.

— Mã hóa
nguồn

1

Làm thế nào bạn có thể nói nó là một nơi tồi tệ để làm việc? Không có gì sai với mã nội tuyến kế thừa. Mã kế thừa có một vị trí trong thế giới này mà không có mã kế thừa, chúng ta sẽ có những khai thác mới trong các ứng dụng chúng ta sử dụng hàng ngày.

— Ramhound

1

@Ramhound: Bởi vì tôi có kinh nghiệm đầu tay ở những nơi như vậy. Bạn sẽ không được phép sử dụng các container hiệu quả, bạn sẽ không thể sử dụng các cấu trúc an toàn, bạn sẽ không có đầu vào nào về kiến trúc. Sự sợ hãi của sự thay đổi là lý do chính. Và nếu bạn ở lại nơi đó hơn một năm, bạn sẽ bị kéo vào đó. Mã hiện đại làm cho thiết kế của bạn đơn giản hơn, nhanh hơn và TIẾT KIỆM! Tôi khá chắc chắn rằng nơi này có đầy bộ nhớ thô, khi xây dựng truy vấn SQL, rất có thể thậm chí không được tham số hóa, v.v.

— Coder

1

@Ramhound Mã di sản là ok. Viết mã kế thừa hôm nay không ổn.

— Renato Dinhani

@Coder, đây là một mô tả hoàn hảo về công việc, và giống như bạn, tôi đã rời bỏ công việc sau một tháng và một vài ngày. Điều tốt nhất tôi đã làm, và bây giờ, trong thời gian rảnh, tôi đang học được rất nhiều điều hữu ích.

— Renato Dinhani

Cập nhật sau 6 năm: Tôi rời công ty đó vài ngày sau khi đăng câu hỏi này và nhìn lại, đó là quyết định tốt nhất tôi đưa ra. Tôi đã có cơ hội làm việc trong nhiều dự án khác ở các công ty khác và không ai trong số họ có những thực tiễn tồi tệ hoặc thiếu chất lượng mà tôi tìm thấy trong công việc đầu tiên đó. Ở nhà học hỏi tình trạng hiện tại của thị trường việc làm cho phép tôi làm việc trong các dự án thú vị hơn và các công ty tốt hơn.

— Renato Dinhani

35

Phong cách mã hóa này (nếu bạn thậm chí muốn gọi nó là bất kỳ loại phong cách nào) là phong cách mã hóa xấu .

Người ta có thể viết các hàm ngắn với các tên biến mô tả và điều khiển luồng lành mạnh trong hầu hết các ngôn ngữ hiện đại (Visual FoxPro là hiện đại, vâng).

Các vấn đề bạn đang gặp phải là với một cơ sở mã xấu , không hơn, không kém.

Các cơ sở mã như vậy tồn tại và rất nhiều - thực tế là bạn đang gặp vấn đề với họ chứng thực họ có thể xấu đến mức nào (và bạn có được đào tạo tốt).

Những gì bạn có thể thử và làm là cải thiện những thứ bạn có thể - đổi tên các biến, trích xuất các điểm chung và chia các hàm lớn thành các hàm nhỏ hơn, v.v ... Nhận bản sao Hoạt động hiệu quả với Mã kế thừa ...

Tôi đang ở trong một dự án C # với cấu trúc rất tệ, không phải là những gì bạn mô tả. Chỉ cần kết hợp 12 chức năng riêng biệt (sao chép-dán rõ ràng) thành một chức năng có một tham số duy nhất .

— Oded
nguồn

33

Lập trình viên giỏi có thể xử lý bất kỳ loại câu chuyện kinh dị. Sẽ không vui chút nào, nhưng đó là lý do tại sao họ trả tiền cho bạn để làm điều đó. Công việc không phải là niềm vui và trò chơi.

— tp1

9

@ tp1 - Đúng, nhưng bạn phải thừa nhận rằng cơ sở mã đầu tiên mà bạn gặp phải có thể gây sốc cho hệ thống.

— Oded

10

@Renato: tất cả các lập trình viên làm việc về việc duy trì mã nhiều hơn là viết / thiết kế mã mới. Và tất cả các mã liên tục được sửa đổi sẽ trở nên tồi tệ hơn theo thời gian trừ khi bạn dành nhiều nỗ lực để ngăn chặn nó. Các lập trình viên giỏi cũng giỏi hơn trong việc xử lý các cơ sở mã xấu, dù họ có thích hay không, vì vậy các nhà quản lý sẽ thường giao cho họ những nhiệm vụ như vậy, và rất ít người có thể tránh hoàn toàn các nhiệm vụ đó. Tôi thực sự sẽ lập luận rằng một lập trình viên không thể tuyên bố là thực sự tốt trừ khi anh ta có một số kinh nghiệm xử lý mã xấu (cũng có thể là mã của anh ta).

— Michael Borgwardt

13

@ RenatoDinhaniConceição, tôi sẽ không bao giờ xem xét việc thuê một nhà phát triển để thiết kế ban đầu, người đã không dành thời gian bảo trì, bạn CANNNOT là một nhà thiết kế giỏi mà không có kinh nghiệm này (thất bại là một trong những nguyên nhân hàng đầu của các thiết kế xấu kinh nghiệm của tôi). Bạn không thể là một lập trình viên giỏi và kém trong việc bảo trì. Bạn có thể không thích nó, nhưng cần phải hiểu làm thế nào để thiết kế tốt. Và khả năng làm công việc kiên trì chăm chỉ cũng là một đặc điểm của một lập trình viên giỏi. Nếu dễ thì họ sẽ không cần chúng tôi.

— HLGEM

8

@ tp1 Công việc được cho là thú vị và trò chơi, nếu không, bạn đang làm sai.

— Kevin McCormick

18

Điều đó không thực sự "lỗi thời" ngoại trừ trong đó (hiện tại) các thực hành thiết kế tốt không phải lúc nào cũng phổ biến. Đó chỉ là mã xấu. Mã xấu làm chậm bất cứ ai. Cuối cùng bạn đã quen với nó, nhưng đó chỉ là vì bạn đã quen với những điều kỳ quặc cụ thể trong hệ thống cụ thể của bạn. Đưa ra một dự án mới, bạn có thể tìm thấy những cách hoàn toàn mới để viết mã xấu. Điều tốt là bạn biết làm thế nào để xác định những mã này có mùi.

Điều lớn nhất bạn có thể làm là không truyền bá vấn đề . Đừng coi những thực hành xấu này như một quy ước trừ khi nhóm của bạn là. Giữ mã mới sạch theo cách không bắt buộc người tái cấu trúc. Nếu nó tệ và bạn có thời gian, hãy xem xét một công cụ tái cấu trúc lớn ... nhưng trong thực tế, bạn hiếm khi có được sự xa xỉ đó.

Xem xét thêm ý kiến khi bạn tìm ra mọi thứ, và thay đổi các bit và phần nhỏ là thực tế. Trừ khi bạn đang viết mã độc, bạn cần phải làm việc này với nhóm của bạn; nếu không có quy ước nào, bạn nên dành chút thời gian để đưa ra chúng và có thể cam kết từ từ cải thiện cơ sở mã nếu bạn vẫn thường xuyên duy trì nó.

Nếu bạn tìm thấy một hàm hoàn toàn bị cô lập với các tên biến xấu và dù sao bạn cũng đang sửa nó, bạn cũng có thể làm cho các tên biến đó trở nên hữu ích, hãy cấu trúc lại các if. Đừng thay đổi các tính năng phổ biến trừ khi bạn sẽ cấu trúc lại một phần lớn của nó.

— Ben Brocka
nguồn

4

"Thực hành thiết kế tốt không phải lúc nào cũng phổ biến" Không nhất thiết là về sự phổ biến. Những gì được coi là thiết kế tốt hoặc thực hành tốt nhất phát triển theo thời gian. Đó là điều cần lưu ý khi xem mã cũ.

— Burhan Ali

@BurhanAli, abosiol hoàn toàn, một thực tiễn tốt vào năm 2000 khi ứng dụng của chúng tôi được thiết kế theo phương pháp không nhất thiết phải là một thực tiễn tốt bây giờ. Các nhà phát triển trẻ thường không biết rằng những gì họ được dạy là những thực tiễn tốt nhất có thể không tồn tại vào thời điểm mã được viết hoặc có thể không hoạt động với ngôn ngữ cũ mà phần mềm sử dụng.

— HLGEM

2

Tôi không nghĩ các hàm 500 dòng từng được coi là "tốt" ... cuốn sách chính tôi học được từ thời những năm 80 đã đề cập rằng bạn có thể nên chia mọi thứ thành chương trình con khi chúng bắt đầu quá lớn để phân nhánh từ cuối trở lại để bắt đầu Điều đó xảy ra ở đâu đó giữa 40-120 dòng trên bộ xử lý đó (6502).

— mjfgates

11

không có ý kiến - sửa nó khi bạn học nó
không có chức năng (50, 100, 200, 300 hoặc nhiều dòng được thực hiện theo trình tự)

Điều này có thể bắt nguồn từ một lần lặp trước của mã. Tại thời điểm này, tôi sẽ cẩn thận với sự khác biệt tinh tế giữa các khối mã có vẻ tương tự đã trở thành "tính năng". Nhưng bất kể ý tưởng kiểu cấu trúc này tệ đến mức nào, nó khá đơn giản để hiểu ... vì vậy tôi không chắc bạn sẽ gặp rắc rối với nó ở đâu.

sử dụng rất nhiều câu lệnh if có nhiều đường dẫn - tôi thực sự không chắc ý của bạn ở đây là gì
có các biến không có ý nghĩa (ví dụ: cf_cfop, CF_Natop, lnom, r_procod) -

Tôi sẽ nhấn mạnh sự thận trọng với bit 'đổi tên'. Có một cơ hội công bằng mà bạn chỉ đơn giản là không hiểu về biệt ngữ và các tên biến sẽ có ý nghĩa hơn nhiều sau khi bạn ở đó một thời gian. Không nói rằng cũng không thể có tên biến có vấn đề, nhưng ví dụ của bạn trông giống như có logic với chúng, nếu bạn biết các từ viết tắt phổ biến tại trang web của bạn là gì. Điều này rõ ràng không quan trọng bằng nếu bạn là nhóm 1.

sử dụng ngôn ngữ mà tôi không quen thuộc (Visual FoxPro 8 từ 2002) - Đây là vấn đề của bạn, không phải mã

— jkerian
nguồn

7

1: Đây là vấn đề của bạn, chứ không phải :) của mã

— aleroot

Điểm cuối cùng của ông là sai ngữ pháp; Tôi không thể hiểu ý nghĩa ban đầu của anh ấy. Tôi đoán, và tôi có thể đã đoán sai, vì vậy anh ta có thể không có nghĩa là anh ta không quen thuộc với Visual FoxPro.

— Myrddin Emrys

Về FoxPro, câu hỏi của tôi đã được chỉnh sửa. Tôi đã nói rằng đó là một ngôn ngữ dài dòng và đối với tôi, điều này không tốt, nhưng đó là ý kiến cá nhân. Tôi hiểu nó, nhưng tôi không thích, và điểm chính là thời đại của ngôn ngữ. Nó không được cập nhật trong công ty của tôi, nhưng có những bản phát hành mới (Visual FoxPro 9 từ 2007).

— Renato Dinhani

3

@ RenatoDinhaniConceição, thông thường không nâng cấp sản phẩm cơ sở dữ liệu vì việc nâng cấp phá vỡ những thứ hiện đang hoạt động và không có tiền hoặc thời gian để thay đổi nếu bạn không duy trì phiên bản cũ hơn. Đây là một sự lựa chọn kinh doanh.

— HLGEM

1

@renato, hầu hết các ứng dụng cơ sở dữ liệu không dễ tương thích ngược.

— HLGEM

11

Điều này nghe với tôi như một cơ hội .

Rõ ràng là bạn đã có thể thấy rất nhiều vấn đề trong cách mọi thứ được thực hiện và quản lý. Bạn có thể phàn nàn rằng đó là tất cả rác rưởi và bạn không thể làm bất cứ điều gì, HOẶC bạn có thể sử dụng điều này như một cơ hội vàng để thực sự cho thấy chủ nhân của bạn giá trị của bạn.

Bây giờ, nó sẽ không giúp bạn nếu bạn hành quân đến chủ nhân của mình và nói với anh ta rằng mọi thứ cần phải thay đổi. Vì vậy, mẹo là chơi cùng một lúc, hỏi RẤT NHIỀU câu hỏi và khi bạn được yêu cầu viết mã, bạn sẽ cần chơi theo luật của họ với tất cả các nhận xét, v.v., vì bạn sẽ cần phải giữ các nhà phát triển khác thông báo bằng cách sử dụng bất kỳ hệ thống nào mà họ hiện đang thích, đồng thời bạn có thể giới thiệu các phép tái cấu trúc hợp lý sẽ không gây rủi ro cho bạn bất cứ điều gì. Bạn có thể trích xuất một vài phương thức và nếu ngôn ngữ của bạn hỗ trợ nó, hãy giới thiệu một vài bài kiểm tra đơn vị. Khi được hỏi tại sao bạn lại làm theo cách này hoặc nếu được bảo là bạn đang làm gì đó "sai", hãy tránh phòng thủ hoặc tranh luận trong khi trình bày âm thanh về vị trí của bạn cho phong cách mã hóa ưa thích của bạn. Ví dụ, bạn có thể tham khảo các cuốn sách như Clean Code của Bob Martin hoặc bạn có thể tham khảo các cuốn sách, bài viết khác, hoặc thậm chí các câu hỏi và câu trả lời mà bạn đã gặp trên Lập trình viên. Bất cứ điều gì bạn có thể thấy hữu ích để hỗ trợ vị trí của bạn với những sự thật có thể vượt quá kinh nghiệm của bạn trong mắt những người bạn đang làm việc cùng.

Liên quan đến việc bình luận quá mức, một số điều này có thể bị xóa nếu bạn thêm một vài tên mô tả cho các biến và phương thức, nhưng bạn cũng có thể tạo ra một trường hợp cho một hệ thống kiểm soát phiên bản tốt và sử dụng điều đó để lưu bản ghi các thay đổi và ngày, v.v. và để sử dụng một công cụ để so sánh các phiên bản khác nhau của các tệp nguồn của bạn nếu chúng không đi kèm với VCS đã chọn của bạn.

Như tôi đã nói, đây là một cơ hội để đóng góp cho sự cải thiện của một nhóm phát triển nghe có vẻ như bị lạc đường. Bạn có cơ hội để nổi bật như là người có kỹ năng và hiểu biết, và như một người có thể dẫn dắt bằng ví dụ. Đây là tất cả những điều tốt để giúp bạn sau này khi sự nghiệp của bạn tiến triển.

— S.Robin
nguồn

2

Đầu tiên, tất cả các câu trả lời ở đây là tốt và giúp tôi. Câu trả lời này không được bình chọn hay bình luận cao, nhưng tôi thực sự thích nó. Tôi nghĩ rằng việc hỏi rất nhiều câu hỏi và không phòng thủ là rất quan trọng. Tôi đã nói chuyện với sếp của tôi về một số điểm tôi đã đề cập ở đây và như dự đoán, tôi không có sức mạnh để thực hiện những thay đổi lớn, nhưng tôi cảm thấy rằng một chút sẽ được thay đổi để tốt hơn sau đó. Cảm ơn bạn, S. Robbins và những người khác vì những lời khôn ngoan.

— Renato Dinhani

1

Vâng, tôi đã làm điều đó một lần, và thành công với nó. Thật là mệt mỏi. Tôi sẽ không bao giờ làm điều đó một lần nữa. Điều này thực sự khó khăn: bạn không thể bỏ qua TRƯỚC KHI tái cấu trúc, mã yếu nên có khả năng phát nổ trên khuôn mặt của bạn bất cứ lúc nào và bạn sẽ phải đối mặt với một sự kháng cự rất quan trọng do thói quen làm việc của mọi người (trong số các vấn đề khác). Tôi biết công việc chỉ dành cho những người quan tâm đến chất lượng mã.

— deadalnix

1

@deadalnix Công việc đầu tiên hiếm khi cung cấp cơ hội để chọn những người bạn làm việc cùng. Thường thì bạn sẽ không biết mọi người thực sự quan tâm đến chất lượng mã như thế nào cho đến khi bạn làm việc với họ một thời gian. Câu trả lời của tôi giúp OP hiểu điều này. Tuyên bố của bạn về việc không thể kiểm tra đơn vị trước khi tái cấu trúc là hoàn toàn sai. Cố gắng tái cấu trúc trước khi kiểm tra đơn vị làm tăng rủi ro tổng thể. Đuổi theo lỗi mà không kiểm tra là không hiệu quả và mệt mỏi. Những người quan tâm đến chất lượng mã tập trung rất nhiều vào các bài kiểm tra và kỹ thuật mã hóa sạch. Tôi không nhận được sự phản đối ngầm của bạn, rất vui khi trò chuyện về điều này ngoại tuyến :-)

— S.Robins

@ S.Robins Đuổi lỗi mà không kiểm tra là không hiệu quả và kiệt sức và tái cấu trúc mà không đáng tin cậy là rất rủi ro (và cả hai kết hợp độc đáo). Đây chính xác là lý do tại sao một tình huống như vậy là một cơn ác mộng. Cơ sở mã di sản khổng lồ thường không đáng tin cậy (đầy đủ các trạng thái toàn cầu, phụ thuộc mã hóa cứng vào hệ thống sản xuất hoặc trên các hệ thống khác, không có sự phân tách mối quan tâm, lặp lại mã lớn, v.v.). Bạn sẽ phải ném một thẻ tái cấu trúc đầu tiên để làm cho mã không thể nhận được. Tôi nghĩ rằng cả hai chúng tôi đồng ý về khía cạnh mã hóa của vấn đề, nhưng hiểu lầm lẫn nhau.

— deadalnix

1

Đây cũng là cơ hội để thu thập nội dung cho thed Dailywtf.com

— Arkh

8

Chào mừng đến với rừng rậm!

Thật không may, thường bắt đầu làm việc trong một công ty có nghĩa là bắt đầu đối mặt với những tình huống như vậy, trừ khi bạn làm việc cho một công ty có cấu trúc và được tổ chức tốt, tình huống này là khá bình thường ...

Lời khuyên của tôi là :

Bắt đầu học và làm quen với: ngôn ngữ lập trình được sử dụng (Clipper / dBase) và môi trường (Visual FoxPro)
Đọc và phân tích cơ sở mã và bắt đầu bình luận nó
tổ chức / tái cấu trúc mã (giải quyết vấn đề có quá nhiều dòng được thực hiện theo trình tự)

Gặp vấn đề đối với một cơ sở mã tương tự là điều bình thường, nhưng có thể trở thành một thách thức lớn khi cố gắng cải thiện chất lượng mã và đưa "liên lạc của bạn" vào chương trình cải thiện cơ sở mã và có thể làm cho chương trình tốt hơn ...

— xe ngựa
nguồn

7

Để trả lời câu hỏi của bạn: Có, mọi người / công ty ở mọi nơi sử dụng cơ sở hạ tầng có thể được xây dựng dựa trên mã tào lao. Khi hòa nhập bản thân vào những tình huống như vậy, có thể rất khó để giải quyết.

Mùa hè năm ngoái, tôi đã làm việc như một thực tập sinh phát triển một ứng dụng được sử dụng bởi nhóm QA gắn liền với một bộ phận cụ thể. Nhóm QA đã sử dụng rất nhiều tập lệnh độc lập (VBScript, Perl, Bash) để chạy thử nghiệm trên cơ sở dữ liệu và họ muốn đưa tất cả chúng vào cùng một ứng dụng. Tuy nhiên, vấn đề với điều này là các tập lệnh đã được sử dụng ở nơi khác trong công ty (do đó, chức năng cốt lõi / tên biến không thể thay đổi) và mã được "thêm vào" trong gần 10 năm; rất nhiều chuyện tào lao đã được xây dựng

Đây là những gì bạn có thể làm về nó, mặc dù:

Yêu cầu giúp đỡ: đồng nghiệp của bạn, những người đã phải xem mặc dù mã này có thể quen thuộc với các đặc điểm riêng của nó. Những gì khó hiểu và khó hiểu với bạn là hoàn toàn tốt cho họ. Vì vậy, yêu cầu giúp đỡ!
Tái cấu trúc bất cứ khi nào có thể: nếu bạn phải xem / duy trì mã này trong một khoảng thời gian dài, hãy cấu trúc lại bất cứ khi nào bạn có thể. Ngay cả khi bạn đang chạy một tìm và thay thế trên một tên biến, mỗi một chút đều có ích. Công ty mà tôi đã thực tập vào mùa hè năm ngoái có một vấn đề tương tự là sử dụng tên biến crappy. Mọi cơ hội tôi có thể chạy mã của họ thông qua một chiếc lược tốt, thay đổi tên biến, tối ưu hóa logic (nhóm các chức năng khác nhau thành 1, chẳng hạn), v.v. Hãy làm tương tự bất cứ khi nào bạn có cơ hội!

Như trường hợp ở khắp mọi nơi, miễn là các tính năng bên ngoài của mã hoạt động chính xác, sẽ không có vấn đề gì về cách thức hoạt động bên trong.

— Zach Dziura
nguồn

+1 cho "yêu cầu trợ giúp". Làm việc trong một nhóm thêm chi phí nhưng cũng mang lại lợi ích.

7

Tôi sẽ đưa ra một số ý kiến khác với nhiều người trả lời ở đây. Nhiều ý kiến của tôi có thể rõ ràng với bạn, nhưng dù sao cũng cần phải nói.

Hãy thận trọng với việc thay đổi mã mà bạn không hiểu, cho đến khi bạn hiểu nó.
Nếu bạn đang làm việc trong môi trường nhóm, với mã mà đồng đội của bạn làm việc, hãy thảo luận về những thay đổi của bạn với họ trước khi thực hiện các thay đổi. Không ai thích một "tay súng đơn độc" đến và thay đổi mã mà mọi người khác đều quen thuộc. Điều này không có nghĩa là những thay đổi của bạn không được bảo hành hoặc là điều "đúng" phải làm.
Có được sự chấp nhận cho ý tưởng của bạn. Đưa mọi người lên tàu với ý tưởng của bạn, sau đó bạn có thể sử dụng các kỹ năng của nhóm để tái cấu trúc, thay vì gánh nặng cho mình với toàn bộ khối lượng công việc.
Mua quản lý mua. Họ có thể phân bổ tiền cho bạn để đi và tính lại mã.
Nói chuyện với quản lý theo cách họ hiểu về lợi ích của việc bao thanh toán lại cơ sở mã của họ. Mã duy trì nhiều hơn có nghĩa là ít thời gian hơn để giải quyết các lỗi, thêm các tính năng, vv Điều đó có nghĩa là phát triển hiệu quả về chi phí. Thời gian quay vòng nhanh hơn, vv

Thật dễ dàng để thêm mã hóa thuần túy, đề xuất thực tiễn tốt nhất mà không cần hiểu chính trị của môi trường của bạn. Những người bạn làm việc cùng có thể không muốn thay đổi hoặc phân bổ thời gian để thay đổi cơ sở mã của bạn, nhưng hãy cố gắng bán ý tưởng cho mọi người trước khi nhảy vào và thay đổi mọi thứ (có rủi ro cố hữu)

Hi vọng điêu nay co ich.

— phòng tangkymush
nguồn

1

Ngoài ra: Kiểm tra, tạo bản sao lưu, sử dụng kiểm soát phiên bản. Nếu bạn là người mới, có những điều đang diễn ra trong nguồn mà bạn không hiểu và những gì có vẻ như là một thay đổi vô hại có thể gây ra sự cố mà bạn không lường trước được.

— Scott C Wilson

Tôi sẽ thêm. Đừng thay đổi bất cứ điều gì cho đến khi bạn có một bài kiểm tra thất bại đòi hỏi phải hành động . Bắt đầu viết bài kiểm tra. Khi bạn có một bài kiểm tra thất bại, hãy chắc chắn rằng nó quan trọng. Sau đó, bạn có một nhiệm vụ mạnh mẽ để thay đổi. Thậm chí sau đó chờ cho đến khi hệ thống bão hòa với các bài kiểm tra. Luôn cố gắng rời khỏi hệ thống là tốt hoặc tốt hơn (không bao giờ tệ hơn) bạn đã tìm thấy nó.

— emory

5

Một trong những điều nổi bật là nhận xét đã chỉnh sửa của bạn

Mọi thay đổi trong mã cũ phải được giữ bình luận trong mã, cộng với thông tin meta (ngày, lập trình viên, tác vụ) liên quan đến thay đổi đó (điều này đã trở thành một mớ hỗn độn, có mã với 3 dòng được sử dụng và 50 dòng cũ được nhận xét). Tôi nghĩ rằng đó không chỉ là vấn đề về mã, mà còn là quản lý vấn đề phát triển phần mềm.

Tôi cũng có một dự án nơi tôi được thừa hưởng một cơ sở mã FoxPro kế thừa với nhiều vấn đề mà bạn mô tả. Một trong những điều đầu tiên tôi giới thiệu cho dự án là một kho lưu trữ mã nguồn tốt. FoxPro có thể tích hợp với SourceSafe, nhưng sản phẩm đó rất khó sử dụng.

Tôi đã lấy một bản sao của công cụ scx của Paul McNett http://paulmcnett.com/scX.php và tích hợp nó vào chu kỳ phát triển của tôi. Nó thực hiện công việc khá tốt là trích xuất mã FoxPro nhị phân sang định dạng văn bản mà sau đó có thể được đưa vào kho lưu trữ nguồn, như Subversion, Mercurial hoặc thậm chí là git. (Bạn có thể thấy dự án SubFox tại http://vfpx.codeplex.com hữu ích.

Các công cụ này cung cấp Lịch sử và cho phép các lập trình viên tiếp tục với công việc duy trì mã. Chắc chắn phải mất một thời gian để học cách sử dụng các công cụ này, nhưng vì tất cả chúng đều miễn phí, nên thực sự không có ý nghĩa gì khi không đầu tư một chút thời gian vào chúng. (ngay cả khi bạn không thể thực hiện các dự án công việc theo cách đó).

— scott-pascoe
nguồn

4

Tôi sẽ hoàn toàn đồng ý với câu trả lời của funkymushroom. Nếu bạn là một môi trường nhóm, hãy chắc chắn rằng những người khác biết bạn đang cấu trúc lại hoặc sắp xếp lại mã, nếu bạn có kế hoạch để nhận bất kỳ nhiệm vụ tốt nào trong tương lai.

Từ kinh nghiệm cá nhân tôi biết, mặc dù không phải là phong cách mã hóa của bạn, nếu bạn đang duy trì mã, cái nào khác cũng sửa đổi và duy trì, hãy giữ nguyên kiểu mã hiện có. Thêm ý kiến và làm rõ là tốt, nhưng bố cục và quy ước cơ bản nên vẫn còn. Các bậc thầy / súng cũ trong dự án hy vọng mã này tương tự như những gì họ đã thấy trong nhiều năm.

Khi một khách hàng la hét về một lỗi, quản lý của bạn sẽ tìm đến những khẩu súng cũ để khắc phục sự cố nhanh nhất có thể. Nếu những khẩu súng cũ này, khi bị áp lực, hãy tìm bạn, đã dọn sạch mã Mã và vì vậy bây giờ chúng phải dành thời gian để tìm ra nơi bạn di chuyển hoặc đổi tên một biến mà chúng biết cần điều chỉnh, tên của bạn trong công ty sẽ được đổi thành. bùn bùn.

Một khi khủng hoảng kết thúc, đầu tiên khẩu súng cũ sẽ đổ lỗi cho bạn từ từ xuống bản cập nhật quan trọng. Tiếp theo, bạn sẽ thấy rằng bạn phải duy trì mã đã được dọn sạch miễn là bạn ở công ty. Cuối cùng, khi các dự án thú vị mới có sẵn, các nhà quản lý của bạn sẽ hỏi các chuyên gia về người nên thực hiện dự án và nếu bạn đã bắt vít chúng một lần, bạn sẽ không bao giờ thực hiện dự án mới, cho đến khi thức ăn của bạn bị ném vào cuối để đáp ứng một thời hạn.

Nếu bạn đã học ở trường đại học, cách mã hóa đúng hướng của bạn, và bây giờ bạn đang ở trong lực lượng lao động, hãy quên đi cách thức đúng hướng đó. Đây không phải là bài tập đại học, những dự án này không chỉ kéo dài một học kỳ, chúng có thể sống trong nhiều năm và sẽ phải được duy trì bởi một nhóm người có trình độ chuyên môn khác nhau và mức độ quan tâm khác nhau trong xu hướng CS mới nhất. Bạn phải là một người chơi nhóm.

Bạn có thể là người lập trình hot nhất trong trường, nhưng tại nơi làm việc, công việc đầu tiên của bạn, bạn là người mới với tín dụng đường phố bằng không. Những người đã lập trình trong nhiều năm không nói dối về trường học hoặc điểm số của bạn, đó là cách bạn chơi với người khác tốt như thế nào và bạn gây ra bao nhiêu sự gián đoạn cho cuộc sống của họ.

Trong 20 năm của tôi, tôi dường như đã có nhiều lập trình viên ace bị sa thải, chủ yếu là vì họ yêu cầu thực hiện mọi thứ theo cách đúng đắn của họ. Trừ khi bạn mang lại một cái gì đó rất, rất, rất độc đáo cho công việc, bạn mới có thể thay thế. Bạn có thể đã đứng đầu lớp, nhưng năm tới, một người khác sẽ đứng đầu lớp và tìm kiếm việc làm.

Tôi xem nó như công việc chính của bạn, là giữ công việc của bạn, cho đến khi bạn quyết định thay đổi công việc. Để giữ công việc của bạn có nghĩa là bạn phải chơi đẹp trong sân chơi do người khác xây dựng và trả tiền.

Tôi biết tôi nghe có vẻ tiêu cực, nhưng luôn có hy vọng. Khi bạn có được kinh nghiệm, có được thành công, bạn sẽ có được ảnh hưởng và có thể chuyển mọi thứ sang một cách tốt hơn. Khi viết mã mới hoặc trên một dự án mới, hãy thúc đẩy những thay đổi bạn tìm kiếm. Nếu đó là mã mới, những khẩu súng cũ không hy vọng nó sẽ là cách họ rời bỏ nó và khi họ thấy những lợi thế họ có thể học và thích nghi theo cách mới.

Hệ thống cũ có thể thay đổi, nhưng cần có thời gian. Thay đổi một cái gì đó giới thiệu rủi ro, và kinh doanh ghét rủi ro, và bạn phải dành thời gian và công việc để làm cho công ty thoải mái với sự thay đổi.

— Scott S
nguồn