Tôi bị buộc phải viết mã xấu. Làm thế nào để tôi giữ thể diện? [đóng cửa]

Tôi chỉ là một nhà phát triển cơ sở nhưng công việc của tôi buộc tôi phải làm việc với mã PHP thực sự khủng khiếp (nghĩ về mã PHP tồi tệ nhất bạn đã thấy; sau đó nghĩ về mã xấu gấp đôi). Tôi thường cố gắng sửa lỗi và chiến đấu với codebase để thêm các tính năng mới. Đôi khi, tôi được yêu cầu làm cho mọi thứ hoạt động càng sớm càng tốt, không liên quan đến những vụ hack bẩn thỉu.

Sản phẩm này trước đây là nguồn mở và tôi lo ngại rằng nó có thể trở thành nguồn mở trong tương lai. Tôi sẽ xấu hổ nếu ai đó (đặc biệt là các nhà tuyển dụng tiềm năng) có thể tìm thấy tên của tôi bên cạnh một số thay đổi. Tôi có thể làm gì để bảo vệ tên tốt của mình?

Tôi không chắc điều này có liên quan hay không nhưng tôi sẽ nói thêm rằng cả sếp và đồng nghiệp của tôi đều không muốn thừa nhận rằng mã này là xấu, nhưng tôi không chắc là tôi có thể đổ lỗi cho họ vì điều đó - đối với nhiều người trong số họ đây là nghề nghiệp đầu tiên.

Rome đã không được xây dựng trong một ngày, nhưng bạn có thể là một 'Hướng đạo sinh' giỏi. Mỗi khi bạn chạm vào mã, hãy để nó tốt hơn so với trước đây. Sẽ không mất nhiều thời gian để sử dụng tên hàm hợp lý, tiêu chuẩn mã hóa tốt và đưa ra nhận xét đàng hoàng khi bạn làm việc.

Tôi nghĩ rằng nguy hiểm là suy nghĩ tất cả hoặc không có gì. Chỉ vì bạn không thể dành thời gian bạn muốn viết mã thanh lịch, không có nghĩa là bạn phải hoàn toàn từ bỏ và viết rác.

Đồng ý với S.Lott từ các bình luận * (lần đầu tiên :) Không ai bắt bạn phải viết mã xấu. Có điều là, đàn em dev. thông thường (trang web này cũng đáng trách vì điều đó) bị lạc trong các thực tiễn tốt nhất, "mã đẹp", ... bất cứ điều gì bạn muốn gọi nó ... và họ không làm được gì nhiều; hoặc họ hoàn thành nó nhưng lãng phí rất nhiều thời gian. Bằng cách bảo họ viết mã xấu (đó là mã cũng hoạt động), nó sẽ nhận được "thông qua đó", chỉ khiến họ cung cấp một cái gì đó. Khi thời gian trôi qua, kết quả là một (bây giờ không còn nữa) nhà phát triển cơ sở rất nhanh chóng đưa ra giải pháp nhanh & bẩn, nhưng dành phần còn lại của thời gian để cải thiện nó. Và khi thời gian trôi qua, bạn tìm hiểu thêm và đến một lúc nào đó, bạn bắt đầu cung cấp các giải pháp nhanh & bẩn thực sự là mã tốt.

Nhưng, nếu bạn đã đi theo con đường của mình và cố gắng viết mã hoàn hảo ngay từ đầu, rất có thể bạn đã dành rất nhiều thời gian và gần như không làm gì cả.

Vì vậy, ... viết mã xấu, ... rất nhiều mã ... mã hầu như không hoạt động, và sau đó TUYỆT VỜI. Mỗi lần lặp lại tốt hơn một chút!

Không ai viết giải pháp hoàn hảo ngay lần đầu tiên.

* cái này, nó ngắn hơn sẽ là một bình luận.

Mã nhận xét là bạn của bạn ở đây.

Bất cứ khi nào bạn cảm thấy phải viết một số bản hack giá rẻ vì áp lực, chỉ cần nói một câu đại loại như: "Mã này làm X vì hạn chế về thời gian. Lý tưởng nhất là tôi sẽ làm Y thay thế. - Xấu hổ, ngày 5 tháng 7 năm 2011"

Sau đó, nếu nhà tuyển dụng tiềm năng nhìn thấy nó, họ sẽ nhận ra bạn thích viết mã tốt, nhưng bạn cũng sẵn sàng điều chỉnh phong cách mã hóa của mình theo nhu cầu kinh doanh. Hầu hết các nhà tuyển dụng sẽ xem cả hai điều đó là những điều tốt.

Nó phụ thuộc vào cách họ buộc bạn.

Theo kinh nghiệm của tôi, có hai khả năng:

Bạn cảm thấy bị ép buộc bởi một lịch trình chặt chẽ, mã di sản, vv

Trong trường hợp này, như hầu hết các câu trả lời khác đã nói, tùy thuộc vào bạn để 'tối ưu hóa cho mát mẻ'. Bạn có thể không có thời gian để viết lại codebase thành MVC, nhưng như bước đầu tiên, chẳng hạn, bạn có thể dừng việc dán SQL của mình bằng tay và thay vào đó là viết một cái hay execute_sql($query, $params), tạo nền tảng cho trừu tượng như fetch_customer($filter_params), v.v. Hãy nhớ, tất cả là tốt nhất Thực tế cuối cùng là sếp của bạn có được một sản phẩm sớm hơn, vì vậy chỉ có mâu thuẫn trong việc đầu tư bao nhiêu thời gian vào tương lai so với hiện tại.

Khi bạn đặt đúng ngữ cảnh ('trong vòng 6 tháng, mà không cần thêm thời gian, tôi đã cấu trúc lại mã nguyên khối thành MVC'), bạn nên để tên của mình trên mã và cố gắng tự hào như một nhà trị liệu, dạy cho một nạn nhân đột quỵ nói lại từ đơn

Bạn được yêu cầu rõ ràng để thực hiện nó theo cách bạn cho là không phù hợp

Cố gắng tách biệt chế độ xem khỏi mô hình không tồn tại trong đánh giá, vì 'nó quá phức tạp, tại sao bạn không thực hiện các truy vấn sql đơn giản?'. Bạn execute_sqlbị đóng hộp vì 'một lập trình viên có kỷ luật không cần điều đó'.

Trường hợp này hút xấu. Theo kinh nghiệm của tôi, nó thường đi kèm với quản lý vi mô và các đồng đội đã được thăng chức ở đó vì lý do chính trị, không phải vì thành công của họ. Vấn đề thực sự là, bạn phải chịu trách nhiệm về một cái gì đó (mã) mà bạn không thể kiểm soát (bạn phải làm theo cách của họ). Giải pháp tốt nhất sẽ là giải quyết nguyên nhân gốc rễ (nghĩa là bạn bị đối xử như một người lẩm cẩm). Giải pháp tốt nhất thứ hai (và theo kinh nghiệm của tôi, thông thường) là bỏ thuốc lá.

Ưu điểm là, trong kịch bản này, tên của bạn không có khả năng được xuất bản bằng mọi cách, bởi vì trưởng nhóm lấy tín dụng cho tất cả thành công.

Tôi khá tự tin rằng sếp của bạn yêu cầu bạn cung cấp một cái gì đó nhanh chóng, nhưng không phải là bạn phải nỗ lực thêm để làm cho nó cố tình xấu. Điều đó có nghĩa là bất cứ khi nào bạn có lựa chọn giữa mã thực sự xấu và mã kém hơn một chút và cả hai tùy chọn sẽ khiến bạn mất nhiều thời gian để thực hiện, bạn sẽ chọn tùy chọn kém hơn một chút. Đó là giải pháp ngắn hạn và không cần nỗ lực gì cả.

Về lâu dài, hãy nói chuyện với sếp của bạn. Giải thích cách đầu tư 15 phút ở đây có thể tiết kiệm hàng giờ ở đó. Hãy chắc chắn rằng bạn có những ví dụ thuyết phục - không phải kiểu "nếu tôi đã làm điều này và ở đây, hy vọng của tôi là tôi sẽ có thể làm điều này vào năm tới", nhưng thay vào đó, "hãy nhìn, ở đây tôi đã làm điều này, và bởi vì về điều đó, tôi đã mất ba giờ để tìm ra vấn đề ở đó, nếu tôi đã làm nó theo cách này và bằng cách đó, lỗi sẽ rõ ràng ngay lập tức ". Một cảnh báo ở đây: mặc dù mã thanh lịch và có thể bảo trì cảm thấy tốt hơn và hiệu quả hơn, đôi khi không. Có những tình huống mà một sửa chữa nhanh chóng cẩu thả là hoàn toàn hợp lý: đôi khi bạn đang viết mã sử dụng một lần, đôi khi bạn đang giữ một mẩu rác đã lỗi thời, chờ đợi điều thực sự; đôi khi, lợi ích của một giải pháp thích hợp không '

Nếu vẫn thất bại, hãy đi tìm một công việc khác.

Không ai ép bạn viết mã xấu. Bạn có thể xoay chuyển tình huống này và làm cho nó tích cực. Thay đổi tiên phong cho các chính sách và thủ tục. Và bạn cũng không thể luôn là người đàn ông / phụ nữ "có". Nếu họ nói rằng họ cần chức năng x trước khi kết thúc ngày, hãy nói với họ rằng điều đó là không khả thi, nhưng hãy đưa ra lời biện minh tại sao thực sự không phải vậy. Trường hợp có một vấn đề, cung cấp giải pháp. Không chỉ là một con mắt mù, hoặc tệ hơn ... thêm vào nó.

Cửa hàng dev của bạn không phải là người đầu tiên có thời hạn nghiêm ngặt, trong khi vẫn muốn duy trì mã được thiết kế tốt.

Bất kỳ công ty nào cũng cần tìm sự cân bằng giữa việc viết mã xuất sắc, với các tài liệu và kiểm tra đơn vị rộng rãi và đưa sản phẩm ra thị trường trong một ngân sách hợp lý và không gian thời gian.

Mã tốt nhất trên thế giới không quan trọng nếu nó lỗi thời trước khi nó được phát hành.

Thực dụng là cố gắng tìm sự cân bằng đó. Việc sửa các tính năng nhanh chóng có thể rất cần thiết về mặt thương mại tại thời điểm này, điều đó không có nghĩa là nó sẽ luôn như vậy.

Phải mất rất nhiều kinh nghiệm (Nhiều hơn hầu hết các lập trình viên từng có), để có được sự cân bằng này ngay. Nó rất dễ dàng để đi cho một trong hai cực đoan. Tìm một cách trung gian là khó khăn hơn.

Tôi không nói rằng ông chủ của bạn là đúng. Là một lập trình viên, có một sự cám dỗ để cố gắng liên tục tạo ra mã đẹp mà không thể thương mại hóa được. Lưu tâm đến sự cám dỗ này có thể giúp bạn nhận ra rằng một số hack này không quá tệ.

Hầu hết các mã sau khi đủ thời gian sẽ chứa các bản hack cho các tình huống cụ thể quá tốn kém để tái cấu trúc thành một khung chung.

Tôi muốn nói thêm rằng bạn không nên tiếp tục như bạn đang làm điều đó bây giờ, không nói gì và chỉ hack và hack.

Bạn cần đứng lên và chỉ vào mã cụ thể và nói với họ những gì tệ về nó. Hãy cụ thể và sử dụng số liệu mã để sao lưu khiếu nại của bạn. Không có gì đáng xấu hổ hơn việc yêu cầu một mã là xấu khi thực tế không phải vậy, bạn chỉ không hiểu những gì đã được thực hiện.

Tôi chắc chắn có nhiều công cụ có sẵn miễn phí để sử dụng để phân tích mã php http://en.wikipedia.org/wiki/Code_analysis

Ngoài ra, tất nhiên điều này http://en.wikipedia.org/wiki/Code_smell

Đọc nó, tổng hợp những gì bạn có thể tìm thấy trong ứng dụng của bạn, và tất nhiên liệt kê các lựa chọn thay thế . Thực tế tồi tệ của nó là chỉ đứng lên và hét lên "Tôi không thích cách này được thực hiện" mà không trình bày một cách khác (tốt nhất) tốt hơn để làm điều đó.

Hack nhanh chóng tốn tiền. Và đừng xem nó là hoàn toàn tiêu cực - Bạn có thể học được rất nhiều từ công việc này ngay bây giờ và có thể kiếm lợi từ những kinh nghiệm bạn làm trong lần tiếp theo.

thứ

Trước bất cứ điều gì khác, bạn KHÔNG sử dụng kiểm soát nguồn của một số loại, phải không? Nếu không, bắt đầu từ đó. Nó sẽ giúp bạn đầu tiên và được phần còn lại của nhóm chấp nhận một cách nhanh chóng.

Nếu bạn có quyền kiểm soát nguồn, bạn không nên đặt tên của mình vào mã, chỉ cần đặt tên của công ty bạn. Thông thường trong mã xấu là đặt lịch sử sửa đổi trong các nhận xét ở đầu tệp, điều này được ủy quyền tốt hơn cho kiểm soát nguồn.

Bây giờ, liên quan đến chất lượng mã, bạn sẽ không thể thay đổi nó như một cách tiếp cận lớn. Dần dần, từng người một, thêm các cách tiếp cận mới cho các vấn đề khác nhau. Nếu bạn làm đúng, nó sẽ TIẾT KIỆM một thời gian và bạn sẽ sử dụng nó để làm cho chất lượng tổng thể tốt hơn.

Để cho bạn một ví dụ về tôi, tôi đã từng đến giữa một dự án với ứng dụng Perl / CGI trong đó tất cả HTML đều nằm trong mã. Toàn bộ ứng dụng nằm trong một tệp duy nhất không có cấu trúc rõ ràng. Không có gì được phiên bản. Tôi đã bắt đầu bằng cách định cấu hình repo CVS (không có sẵn SVN tại thời điểm đó), đặt giao diện web cho nó cho khách hàng. Lúc đầu, tôi đã tự mình xử lý các cam kết từ các đồng nghiệp của mình. Sau đó, tôi chia tất cả các phương thức trong các mô-đun (tệp) khác nhau. Tại thời điểm đó, các đồng nghiệp bắt đầu áp dụng CVS. Sau đó, tôi chuyển HTML ra khỏi mã. Sau đó, mỗi lần tôi phải thực hiện một thay đổi trong một phần của mã, tôi đã dành một chút thời gian để cấu trúc lại một số mã. Cuối cùng, tốc độ phát triển đã tăng lên rất nhiều khiến khách hàng vô cùng hạnh phúc. Họ sẽ yêu cầu thay đổi mỹ phẩm và thay vì chúng tôi nói với họ "sẽ mất 2 ngày",

Tuy nhiên, cách tiếp cận này sẽ chỉ hoạt động nếu bạn nắm vững mã tổng thể đủ tốt. Nếu bạn không hiểu bức tranh lớn, nếu một số phần của ứng dụng không thể hiểu được, nó sẽ làm cho công việc của bạn thực sự khó khăn.

Một điều cuối cùng, viết lại hoàn toàn đôi khi là giải pháp duy nhất nhưng thường rất khó để biện minh cho chi phí của nó cho quản lý.

Vì bạn là một nhà phát triển cơ sở, đây thực sự là một điều tốt. Bị ném vào giữa một mớ hỗn độn mã lớn sẽ dạy cho bạn nhiều hơn về những điều không nên làm hơn là chỉ làm việc với mã 'sạch' hoàn hảo. Tận dụng tình huống và tìm hiểu cách cấu trúc lại mã xấu và từ từ chuyển đổi nó thành thứ gì đó dễ quản lý hơn. Và đừng phàn nàn về việc nó phải càng sớm càng tốt. Đó là điểm - học cách cấu trúc lại và dọn sạch mã trong khi thực hiện mọi thứ theo một thời hạn chặt chẽ. Rốt cuộc, bất cứ ai cũng có thể viết mã hoàn hảo nếu họ có thời gian vô tận.