Lời nói đầu của người dịch: Sau khi đọc bài viết này, bạn có thể ngạc nhiên hoặc thậm chí tức giận. Vâng, chúng tôi cũng rất ngạc nhiên: tác giả được cho là chưa bao giờ nghe nói về hệ thống phân cấp trong nhóm, về việc đặt nhiệm vụ với trạng thái “làm nhanh chóng và không cần lý luận”. Vâng, đúng vậy, đây là một văn bản hơi lạ. Thật vậy, tác giả gợi ý rằng lập trình viên nên đảm nhận vai trò của một kiến trúc sư hệ thống - vậy tại sao bạn lại cần một kiến trúc sư? Nhưng tất cả những phản đối này sẽ không làm bạn mù quáng trước vấn đề chính - tại sao chúng tôi vẫn lấy và dịch văn bản này. Anh ấy không nói về vai trò. Văn bản này nói về cách tiếp cận và nhận thức chuyên nghiệp. Sự thật là chỉ cần bạn “làm những gì được bảo” mà không suy nghĩ về ý nghĩa của hành động của mình, bạn sẽ không bao giờ trở thành một lập trình viên giỏi.
Nói không với mã không cần thiết. Tất cả những gì bạn phải làm là ghép ba chữ cái lại với nhau và nói từ đó. Chúng ta hãy cùng nhau thử làm điều này: "Không!"
Nhưng chờ đã. Tại sao chúng ta lại làm việc này? Suy cho cùng, nhiệm vụ chính của một lập trình viên là viết mã. Nhưng bạn có cần viết bất kỳ mã nào được yêu cầu không? KHÔNG! “Hiểu khi nào không nên viết mã có lẽ là kỹ năng quan trọng nhất đối với một lập trình viên.” .
Chúng tôi nhắc nhở: cho tất cả độc giả của "Habr" - giảm giá 10 rúp khi đăng ký bất kỳ khóa học Skillbox nào bằng mã khuyến mại "Habr".
Hộp kỹ năng khuyến nghị: khóa học thực hành .
Lập trình là nghệ thuật giải quyết vấn đề. Và bạn là bậc thầy của nghệ thuật này.
Đôi khi, trong nỗ lực bắt đầu công việc nhanh nhất có thể, chúng ta không nghĩ gì khác ngoài việc hoàn thành nhiệm vụ trước mắt. Và điều này có thể gây ra những vấn đề thậm chí còn nghiêm trọng hơn.
Lập trình viên nhắm mắt làm ngơ điều gì?
Tất cả mã bạn viết phải dễ hiểu đối với các nhà phát triển khác và phải được kiểm tra và sửa lỗi.
Nhưng có một vấn đề: bất cứ điều gì bạn viết, nó sẽ làm phức tạp phần mềm của bạn và có thể gây ra lỗi trong tương lai.
Theo Rich Skrent, . Đây là những gì anh ấy viết:
“Mã này không tốt vì nó bắt đầu hỏng và cần được bảo trì liên tục. Việc thêm các tính năng mới thường yêu cầu sửa đổi mã cũ. Càng lớn thì khả năng xảy ra lỗi càng cao và càng mất nhiều thời gian để biên dịch. Phải mất một nhà phát triển khác nhiều thời gian hơn để tìm ra nó. Và nếu cần tái cấu trúc thì chắc chắn sẽ có những đoạn đáng để thay đổi. Mã lớn thường có nghĩa là giảm tính linh hoạt và chức năng của dự án. Một giải pháp đơn giản và tinh tế sẽ nhanh hơn mã phức tạp.”
Làm thế nào để bạn biết khi nào không nên viết mã?
Vấn đề là các lập trình viên thường phóng đại số lượng tính năng mà ứng dụng của họ cần. Kết quả là nhiều đoạn mã vẫn chưa hoàn thiện hoặc không ai sử dụng mà còn làm phức tạp ứng dụng.
Bạn phải hiểu rõ ràng dự án của bạn cần gì và không có gì.
Một ví dụ là một ứng dụng chỉ giải quyết được một nhiệm vụ - quản lý email. Với mục đích này, hai chức năng đã được giới thiệu - gửi và nhận thư. Bạn không nên mong đợi người quản lý thư đồng thời trở thành người quản lý tác vụ.
Bạn cần kiên quyết nói “không” với những đề xuất bổ sung những tính năng không liên quan đến nhiệm vụ chính của ứng dụng. Đây chính xác là thời điểm rõ ràng rằng không cần thêm mã.
Không bao giờ mất trọng tâm của ứng dụng của bạn.
Hãy luôn tự hỏi:
— Chức năng nào nên được thực hiện bây giờ?
- Tôi nên viết mã gì?
Đặt câu hỏi về những ý tưởng nảy ra trong đầu và đánh giá những đề xuất đến từ bên ngoài. Nếu không, mã bổ sung có thể giết chết dự án.
Biết khi nào không thêm những thứ không cần thiết sẽ giúp bạn kiểm soát chặt chẽ cơ sở mã của mình.
Khi bắt đầu đường dẫn, lập trình viên chỉ có hai hoặc ba tệp nguồn. Nó đơn giản. Biên dịch và khởi chạy ứng dụng đòi hỏi thời gian tối thiểu; Luôn luôn rõ ràng ở đâu và những gì cần tìm kiếm.
Khi ứng dụng mở rộng, ngày càng có nhiều tệp mã xuất hiện. Họ điền vào danh mục, mỗi danh mục có hàng trăm dòng. Để tổ chức tất cả những điều này một cách chính xác, bạn sẽ phải tạo các thư mục bổ sung. Đồng thời, việc ghi nhớ chức năng nào chịu trách nhiệm về cái gì và hành động nào gây ra chúng ngày càng trở nên khó khăn; bắt bọ cũng mất nhiều thời gian hơn. Việc quản lý dự án cũng ngày càng trở nên phức tạp hơn; không phải một mà nhiều nhà phát triển được yêu cầu phải theo dõi mọi thứ. Theo đó, chi phí, cả tiền bạc và thời gian, đều tăng lên và quá trình phát triển bị chậm lại.
Dự án cuối cùng sẽ trở nên khổng lồ và việc thêm từng tính năng mới ngày càng tốn nhiều công sức hơn. Ngay cả đối với một việc gì đó rất nhỏ nhặt, bạn cũng phải mất vài giờ. Việc sửa các lỗi hiện có dẫn đến sự xuất hiện của các lỗi mới và thời hạn phát hành ứng dụng bị trễ.
Bây giờ chúng ta phải chiến đấu vì sự sống của dự án. Tại sao?
Thực tế là bạn không hiểu khi nào thì không nên thêm mã bổ sung và trả lời “có” cho mọi đề xuất và ý tưởng. Bạn đã mù quáng, mong muốn tạo ra những điều mới mẻ đã khiến bạn bỏ qua những sự thật quan trọng.
Nghe giống kịch bản phim kinh dị nhỉ?
Đây chính xác là điều sẽ xảy ra nếu bạn tiếp tục nói đồng ý. Cố gắng hiểu khi nào không nên thêm mã. Loại bỏ những thứ không cần thiết khỏi dự án - điều này sẽ giúp cuộc sống của bạn dễ dàng hơn rất nhiều và kéo dài tuổi thọ của ứng dụng.
“Một trong những ngày làm việc hiệu quả nhất của tôi là khi tôi xóa 1000 dòng mã.”
—Ken Thompson.
Học khi nào không viết mã là khó. Nhưng nó là cần thiết.
Vâng, tôi biết rằng bạn mới bước chân vào con đường lập trình viên và muốn viết code. Tốt thôi, đừng đánh mất ấn tượng đầu tiên đó, nhưng cũng đừng đánh mất những yếu tố quan trọng vì nhiệt tình. Chúng tôi nhận ra mọi thứ thông qua thử nghiệm và sai sót. Bạn cũng sẽ phạm sai lầm và học hỏi từ chúng. Nhưng nếu bạn có thể học hỏi từ những điều trên thì công việc của bạn sẽ trở nên có ý thức hơn.
Hãy tiếp tục sáng tạo nhưng hãy biết khi nào nên nói không.
Hộp kỹ năng khuyến nghị:
- Khóa học trực tuyến được áp dụng .
- Khóa học trực tuyến .
- Khóa học năm thực tế .
Nguồn: www.habr.com