Câu trả lời:
Luôn luôn có một cách tốt hơn để viết mã của bạn.
Cho dù bạn tìm thấy mã bạn viết xuất sắc đến đâu, bạn sẽ ngạc nhiên về mức độ tệ của nó nếu bạn xem lại nó trong một vài năm. Chỉ vì một vài năm trước, bạn không biết về một số mẫu bạn biết ngày nay hoặc một số tính năng ngôn ngữ bạn đã học trong khi đó, v.v.
Hãy suy nghĩ trước khi bạn bắt đầu viết mã.
Không có gì lâu dài hơn các giải pháp tạm thời :)
Nếu rất khó để giải quyết vấn đề, rất có thể chính vấn đề đó đã được đặt ra ngay từ đầu.
Phần mềm của bạn sẽ sống lâu hơn đáng kể so với bạn nghĩ tại thời điểm bạn viết nó.
Tôi bắt đầu sự nghiệp của mình vào những năm 80. Tôi bắt đầu sử dụng phần mềm có nguồn gốc từ những năm 70 và vẫn đang được sử dụng vào những năm 90 (có thể lâu hơn, tôi không biết chắc chắn về số phận của nó). Một số mã nguồn mở của riêng tôi là một nửa trong thập kỷ thứ hai của nó.
Làm việc tốt với những người khác là rất quan trọng.
"Cho tôi xem 'Đi tới chàng' của bạn và tôi sẽ cho bạn thấy vấn đề của bạn"
Slapdash Hero Coders - những người chỉ viết mã mà không liên quan đến quy ước, khả năng đọc hoặc bất cứ ai khác đang làm việc - có thể gây hại nhiều hơn lợi.
Không nói rằng những người có thể viết hàng tấn mã chất lượng tốt là điều xấu. Chỉ là hiếm.
Học ngôn ngữ mới là một phần của công việc
Tôi đã học về bốn ngôn ngữ lập trình ở trường vào những năm 80 nhưng đã sử dụng một trong số chúng trong công việc. Tôi đã có bốn công việc mà tôi thậm chí không biết ngôn ngữ mà tôi được thuê để sử dụng.
Nhìn chung, tôi đã học và sử dụng một cách chuyên nghiệp có lẽ cả tá ngôn ngữ trong sự nghiệp của mình, bao gồm FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript, và a vài DSL nhỏ. Làm một bài toán nhỏ, tôi dường như trung bình một ngôn ngữ mới cứ sau vài năm, mặc dù có rất nhiều sự trùng lặp.
Nếu bất cứ điều gì là một hằng số trong sự nghiệp của tôi, thì đó là sự thay đổi.
Hãy tiếp tục học mỗi ngày. Kiến thức của ngày hôm nay đã lỗi thời vào ngày mai.
Trớ trêu thay câu trả lời này cũng sẽ bị lỗi thời vào ngày mai. Nhưng thực sự, hãy học tập một hoặc hai thứ và được chứng nhận nếu có thể, là Thần của những thứ đó (có thể là ngôn ngữ lập trình hoặc quản trị hệ thống / mạng / cơ sở dữ liệu) và luôn để mắt đến những thứ nhỏ nhặt khác, như các ngôn ngữ khác mà không quan trọng bạn.
Ý tôi là, ví dụ, là một chuyên gia tuyệt vời về quản trị Java và Oracle DB, nhưng nghiên cứu một chút về Python, PHP, C ++, HTML5, Javascript, mặc dù không đến mức chứng nhận. Nghiên cứu từng web hoặc khung ngôn ngữ tồn tại. Nghiên cứu hoặc cố gắng có một số kinh nghiệm (cơ bản) với từng cơ sở dữ liệu tồn tại, như SQL Server, MySQL, Cassandra, HBase, PostgreQuery và toàn bộ thế giới No-SQL như MongoDB và CouchDB. Cố gắng có một số kinh nghiệm với quản trị và ảo hóa linux.
Đó là bài học lớn nhất mà tôi học được từ 16 năm kinh nghiệm của mình. Tôi đã có gần 10 năm là một lập trình viên ngôn ngữ đơn, sử dụng Pascal trong thời đại của nó và Visual Basic 6 vào đầu thiên niên kỷ, và là một nhà phát triển PHP từ 9 năm trước. Nhưng từ đó tôi học được rằng các nhà phát triển cần biết ít nhất một chút về mọi thứ.
Tôi đã học được rằng nguyên tắc thiết kế tốt nhất là KISS (Giữ cho nó đơn giản, Ngốc!) .
Tôi đã học được rằng giữ cho mã của bạn đơn giản và sạch sẽ là mối quan tâm chính và mỗi thành viên trong nhóm nên hiểu những gì bạn có mã. The KISS principlenói rằng hầu hết các hệ thống hoạt động tốt nhất nếu chúng được giữ đơn giản thay vì phức tạp, do đó, đơn giản nên là mục tiêu chính trong thiết kế và nên tránh sự phức tạp không cần thiết.
Không có thử
Hãy nói rằng bạn có một nhiệm vụ hoặc một loạt các nhiệm vụ ước tính mất 4 ngày. Sau đó, sếp hoặc người quản lý dự án của bạn hỏi liệu bạn có thể cố gắng hoàn thành nó trong hai ngày vì một số lý do quan trọng. Muốn trở thành một nhân viên tốt, linh hoạt, bạn có thể muốn nói: chắc chắn, bạn có thể thử. Nhiều khả năng kết quả từ việc này là bạn sẽ bỏ lỡ thời hạn, hoặc bạn sẽ thực hiện hack nửa vời để hoàn thành nó. Và đó không phải là lỗi của sếp khi yêu cầu bạn làm điều đó, đó là công việc của anh ấy. Đó là lỗi của bạn vì đã không nói không, đó là công việc của bạn.
Bạn không thể mặc cả với thời gian. Bạn có thể mặc cả với phạm vi. Hãy chuyên nghiệp và đừng bán mình quá ngắn.
"Điều đó sẽ không bao giờ xảy ra" thực sự có nghĩa là "Điều đó sẽ không bao giờ xảy ra cho đến ngày đầu tiên sản xuất"
Viết mã rất dễ. Đọc mã rất khó. Ngay cả khi mã là của bạn. Vì vậy, bất cứ khi nào có thể, đi cho phương pháp dễ đọc.
Bạn không thông minh hơn người khác. Đừng bao giờ nghĩ rằng cách tiếp cận của bạn là tốt nhất chỉ vì nó là của bạn.
Hãy chú ý đến những gì được nói, không phải bởi những gì nó được nói. Ý tưởng tuyệt vời có thể đến cho các nguồn bất ngờ nhất.
Đừng lười biếng. Hãy dành thời gian của bạn để viết mã đẹp. Bạn sẽ phải sửa nó bằng mọi giá với chi phí cao hơn.
Đừng sử dụng các tính năng OOP ưa thích chỉ vì bạn có thể! - YAGNI (Bạn sẽ không cần nó)
Use fancy OOP featuresbởi vì chúng có lợi ích cụ thể, rõ ràng cho vấn đề bạn đang cố gắng giải quyết . Bạn cười, nhưng tôi thấy điều này mọi lúc. Hầu hết các lập trình viên không bao giờ gặp một đối tượng mà họ không thích. Tôi nghĩ rằng nó phải là cách khác: những kỹ thuật này có tội cho đến khi được chứng minh vô tội trong tòa án của KISS .