Hút ít hơn mỗi năm? [đóng cửa]

Hút ít hơn mỗi năm -Jeff Atwood

Tôi đã xem qua bài viết sâu sắc này. Trích dẫn trực tiếp từ bài viết

Tôi thường nghĩ rằng hút ít hơn mỗi năm là cách các lập trình viên khiêm tốn cải thiện. Bạn sẽ không hài lòng với mã bạn đã viết một năm trước. Nếu bạn không, điều đó có nghĩa là A) bạn đã không học được gì trong một năm, B) mã của bạn không thể được cải thiện hoặc C) bạn không bao giờ xem lại mã cũ. Tất cả những điều này là nụ hôn chết chóc cho các nhà phát triển phần mềm.

1. Làm thế nào thường xuyên xảy ra hoặc không xảy ra với bạn?
2. Bao lâu trước khi bạn thấy một sự cải thiện thực sự trong mã hóa của bạn? năm tháng?
3. Bạn có bao giờ xem lại mã cũ của bạn ?
4. Làm thế nào thường xuyên mã cũ của bạn làm bạn khó chịu? hoặc mức độ thường xuyên bạn phải xử lý nợ kỹ thuật của bạn.

Chắc chắn rất khó để sửa các lỗi cũ và mã bẩn mà chúng tôi có thể đã thực hiện để nhanh chóng đáp ứng thời hạn và các sửa lỗi nhanh đó, một số trường hợp chúng tôi có thể phải viết lại hầu hết các ứng dụng / mã. Không có tranh luận về điều đó.

Một số nhà phát triển mà tôi đã gặp đã lập luận rằng họ đã ở giai đoạn phát triển , nơi mã hóa của họ không cần cải thiện hoặc không thể cải thiện được nữa.

• Điều này có xảy ra không?
• Nếu vậy, bao nhiêu năm để mã hóa trên một ngôn ngữ cụ thể thì người ta mong đợi điều này xảy ra?

Liên quan:

Bao giờ nhìn lại một số mã cũ của bạn và nhăn nhó trong đau đớn?

Khoảnh khắc Star Wars trong Code "Luke! Tôi là mã của bạn!" "Không! Không thể! Không thể nào!"

  > Sucking Less Every Year ?

Không nhưng Sucking khác nhau mỗi năm :-)

Sau những đánh giá đầu tiên của tôi nhiều năm trước, tôi đã phải chịu đựng những quy ước đặt tên.

Sau đó, tôi chịu đựng rằng mã hóa của tôi là (không cần thiết) được triển khai để chung chung nhất có thể nhưng điều đó làm cho mã trở nên khó hiểu và duy trì.

Sau đó, tôi đã phát triển testdriven, InversionOfControl, những gì chấm chung chung ở đâu và nhiều hơn nữa.

phần kết luận

nỗi khổ của những thói quen xấu cũ đã được giải quyết nhưng đã được bù đắp bằng những đau khổ mới mà tôi có được vì tôi đã học được nhiều hơn.

Thật thú vị, tất cả các lập trình viên "rockstar" mà tôi từng làm việc đều cực kỳ khiêm tốn, ham học hỏi và sẵn sàng thừa nhận rằng họ không biết tất cả mọi thứ. Heck, nhiều người thực sự hoàn toàn tự ti, ít nhất là trong những khoảnh khắc nhẹ nhàng.

Tôi không nghĩ rằng tôi đã từng gặp một nhà phát triển nghĩ rằng mã hóa của họ "không thể được cải thiện", nhưng một cái gì đó cho tôi biết những người này sẽ ở cách xa ngôi sao nhạc rock như bạn có thể nhận được - nói một cách nhẹ nhàng.

Các điểm sau đây không phải là lời khuyên mà là nhật ký cá nhân:

• sử dụng ít biến toàn cục hơn
• không sử dụng viết tắt cho các biến hoặc tên hàm
• viết [một số] mã kiểm tra
• không đánh giá mã là chậm (hoặc nhanh) mà không có điểm chuẩn
• tìm hiểu cách tải thử nghiệm một ứng dụng
• đừng sửa nó, nếu nó không bị hỏng
• sử dụng công cụ quản lý mã nguồn (git / hg)
• tái cấu trúc là tuyệt vời, đừng đánh giá thấp chi phí thử nghiệm mà nó mang lại
• bảo mật là khó khăn, vì vậy hãy cẩn thận với điều này càng sớm càng tốt
• vá một số lỗi dự án nguồn mở
• blog một cái gì đó mới
• khả năng sử dụng có thể không phải là một yêu cầu tính năng nhưng nó quan trọng

Tôi đã không học được tất cả trong vòng một năm, mọi thứ đều cần có thời gian ...

Mọi người thường nghĩ rằng mã tốt chỉ đột nhiên xảy ra nhưng đối với hầu hết chúng ta chỉ là mã tốt phát triển trong cơ sở mã của chúng tôi. Ý tôi là, rất khó để viết phần mềm hoàn hảo ngay từ đầu vì các yêu cầu luôn thay đổi và chúng tôi không phải là lập trình viên hoàn hảo, vì vậy những quyết định ngu ngốc được đưa ra liên tục từ các nhà quản lý và lập trình viên. Sau đó, tôi thấy mỗi yêu cầu thay đổi một cơ hội tốt để cấu trúc lại một số mã cũ thành mã tốt hơn (và được trả tiền cho nó!) Và trả một chút nợ kỹ thuật. Như họ nói: "rời khỏi kho lưu trữ mã tốt hơn một chút mỗi khi bạn cam kết mã". Sau đó, hệ thống của bạn sẽ phát triển thành một hệ thống gần với lý tưởng hơn.

Tôi biết hoàn toàn không có lập trình viên nào tự hào về phần mềm của mình nhưng điều đó là tốt. Hơn có nghĩa là các lập trình viên đã học được trong quá trình.

Ngoài ra nếu bạn đọc cuốn sách "Clean Code" thì bạn sẽ tăng mã "hút yếu tố" của riêng mình lên nhiều lần. : D

Tôi thực sự có cả hai mặt của đồng tiền cho việc này.

Một mặt, bạn nhìn vào mã cũ và bạn thấy nó đầy lỗi và cách làm phức tạp chỉ đơn giản là hoàn thành bằng cách tận dụng các kỹ thuật và tính năng ngôn ngữ mà bạn không biết trước đó.

Mặt khác, bạn phát hiện ra một giải pháp đặc biệt tao nhã cho một vấn đề và bạn không thể giúp giải phóng nụ cười tự mãn khi bạn trở nên thông minh như thế nào.

Và sau đó bạn cuộn xuống một vài dòng và nhăn mặt kinh hoàng với thực tế là bạn đã sử dụng GOTO trong C.

Hmm ... Tôi thường khá ngạc nhiên khi thấy rất nhiều mã cũ của tôi tốt như thế nào.

Nếu tôi đang làm nó ngày hôm nay, tôi thường viết nó khác đi, nhưng nếu tôi phải sống với những hạn chế của thời gian, tôi không chắc mình sẽ làm thế. Khi bạn có thể tin tưởng vào một máy thông thường có ít nhất một vài hợp đồng RAM, bạn có thể (và thường nên) viết mã của mình một chút khác so với khi một ổ cứng lớn là 100 megabyte.

1. Làm thế nào thường xuyên xảy ra hoặc không xảy ra với bạn?

2. Bao lâu trước khi bạn thấy một sự cải thiện thực sự trong mã hóa của bạn? năm tháng?

3. Bạn có bao giờ xem lại mã cũ của bạn?

4. Làm thế nào thường xuyên mã cũ của bạn làm bạn khó chịu? hoặc mức độ thường xuyên bạn phải xử lý nợ kỹ thuật của bạn.

1. Mỗi khi tôi học được điều gì mới, hy vọng đó là chuyện hàng ngày.

2. Nếu tôi có thể thực hiện những gì tôi đã học, thì ngay lập tức khi tôi thực hiện nó.

3. Có, chỉ dành cho (1) Các tính năng mới, (2) Sửa lỗi, (3) Hoài niệm, (4) Xem cách tôi giải quyết một cái gì đó, có thể hữu ích.

4. Liên quan đến 1., khi tôi học cách làm điều gì đó tốt hơn, tôi biết rằng một số dự án cũ "có thể" đã được thực hiện tốt hơn. Tôi để họ được. Chỉ cần chắc chắn rằng dự án tiếp theo được thực hiện theo cách tốt hơn. Tôi không lo lắng trừ khi đó là một lỗi thực tế.

Trong một câu hỏi khác , chủ đề là về các cách để đánh giá chất lượng mã của riêng bạn. Một trong những gợi ý của tôi là xem xét nó trong vài năm, khi kinh nghiệm của bạn cao hơn nhiều so với khi viết mã. Một câu trả lời của tôi cho câu hỏi này liên quan trực tiếp đến câu hỏi của bạn:

"trong trường hợp của tôi, tuổi thọ là một năm: điều đó có nghĩa là tôi có thể sửa đổi mã mà tôi đã viết sáu tháng trước, nhưng nếu mã được viết cách đây hai năm, nó có khả năng bị ném mạnh, sau đó viết lại hoàn toàn, kể từ đó nó chỉ hút quá nhiều. "

Vì vậy, trong thực tế, mọi đoạn mã tôi đã viết trở nên không thể chịu đựng được theo quan điểm của tôi trong một năm. Và tôi không nói về mã vứt đi, mà còn về mã tôi đã viết với chất lượng, khả năng bảo trì và khả năng đọc. Hiện tại, không có ngoại lệ.

Để trả lời câu hỏi thứ hai của bạn về tuổi thọ, nó thay đổi rất nhiều. Một đoạn mã vứt đi có tuổi thọ bằng 0 giây : nó chỉ hút sau khi bạn viết nó, nhưng nó không thành vấn đề. Một số đoạn mã tôi đã viết có thể chịu được sau hai năm , nhưng cần một số thay đổi về mỹ phẩm: một chút tái cấu trúc, thực thi các quy tắc StyleCop, v.v. Trung bình, trong trường hợp chính xác của tôi, tuổi thọ thay đổi từ tám tháng đến một năm trong C # và giữa hai sáu tháng cho PHP.

Tôi có xem lại mã cũ của mình không? Vâng, tất nhiên, như mọi nhà phát triển, trừ khi bạn không quan tâm đến DRY và phát minh lại bánh xe của chính mình nhiều lần. Cũng có cơ hội để xem xét và cải thiện mã rất thường xuyên nếu bạn có một cơ sở mã chung mà bạn sử dụng trong nhiều dự án . Một điểm khác là nếu bạn làm việc trong các dự án lớn, một số có thể mất nhiều năm , vì vậy bạn sẽ phải xem lại mã cũ.

Một số nhà phát triển mà tôi đã gặp đã lập luận rằng họ đã ở giai đoạn phát triển, nơi mã hóa của họ không cần cải thiện hoặc không thể cải thiện được nữa.

Khi một người nói rằng cô ấy hoàn hảo đến mức cô ấy không cần phải học bất cứ điều gì, điều đó có nghĩa là cô ấy thậm chí không có khả năng hiểu cô ấy hoàn toàn ngu ngốc như thế nào.

Ngay cả khi bạn có hai mươi năm kinh nghiệm về máy tính / lập trình, mọi thứ thay đổi quá nhanh, do đó, luôn có những điều mới để học và các kỹ thuật mới để cải thiện mã. Ví dụ: mã C # được viết khi không có .NET Framework 3.0 rất có thể dễ đọc hơn và tốt hơn với những thứ mới mà chúng ta có ngày nay (bao gồm Linq, hợp đồng mã, v.v.), và ngay cả khi mã cũ được viết bởi nhà phát triển thông minh nhất.

Nó xảy ra khá thường xuyên khi tôi đang xem mã và tự hỏi, "Tôi đã nghĩ gì khi tôi viết bài này?"

Thường có những cải tiến mọi lúc vì đôi khi một ý tưởng mới để tổ chức mã, tạo kiểu mã hoặc một cái gì đó khác sẽ đến với tôi và trong khi nó có thể không phải là một cải tiến tuyệt vời, mọi điều nhỏ nhặt đều có thể giúp ích.

Tùy thuộc vào môi trường làm việc, tôi có thể thấy mã từ vài năm trước khi tôi tiếp tục làm việc trong cùng một cơ sở mã và khá quen thuộc với những gì trong đó và là thứ cần quản lý.

Mã cũ hầu như luôn làm tôi khó chịu vì thông thường tôi sẽ thay đổi một hệ thống hiện có hoặc thay thế hệ thống. Trong cả hai trường hợp, tôi phải biết các yêu cầu của hệ thống hiện có để đảm bảo chúng ở đó trong hệ thống mới.

Mặc dù tôi chắc chắn rằng có những người như Jon Skeet có thể nghĩ ra mã hoàn hảo, nhưng hầu hết những người khác nói rằng mã của họ không thể được cải thiện đang nói rằng từ điểm bản ngã có thể không hấp dẫn. Đồng thời, về mặt tìm kiếm một sự cải thiện lớn mỗi lần không phải lúc nào cũng xảy ra.

1. Làm thế nào thường xảy ra hoặc không xảy ra với bạn?

Làm thế nào thường xuyên tôi không hài lòng với mã cũ của tôi? Gần như luôn luôn. Có những trường hợp ngoại lệ hiếm hoi mà tôi có mã mà tôi thực sự tự hào ... nhưng một lần nữa, chúng rất hiếm. Tôi đã được thông báo rằng mã mà tôi đã viết vài năm trước là tốt ... Tôi co rúm người lại và nghĩ rằng "bạn là người nghèo đáng thương vì đã nhìn thấy tồi tệ hơn rác mà tôi đã viết."

2. Bao lâu trước khi bạn thấy một sự cải thiện thực sự trong mã hóa của bạn? năm tháng?

Nó thường ở trong các giai đoạn ... Tôi thực sự say mê một phong cách hoặc phương pháp (ví dụ như giao diện lưu loát ... vì đó là phong cách cuối cùng mà tôi có một kiểu ướt lớn) và bán thịt mọi thứ tôi viết trong một hoặc bốn tháng . Sau đó, nó bắt đầu nhìn tốt hơn.

3. Bạn có bao giờ xem lại mã cũ của mình không?

Không thường xuyên như tôi muốn. Hầu hết các mã cũ của tôi, được sở hữu bởi các nhà tuyển dụng trước đó. Mã cá nhân bị rửa trắng quá thường xuyên.

4. Làm thế nào thường xuyên mã cũ của bạn làm bạn khó chịu? hoặc mức độ thường xuyên bạn phải xử lý nợ kỹ thuật của bạn.

Do các nhà tuyển dụng trước đó có hầu hết các mã cũ của tôi và tôi rửa sạch hầu hết các mã cá nhân của mình ... không thường xuyên lắm.