Phân tích các lỗi phổ biến của các lập trình viên mới làm quen, pt. 1

Chào thế giới! Khi bạn đã học mọi thứ bạn cần biết và cuối cùng được làm việc với tư cách là một thực tập sinh hoặc nhà phát triển cơ sở, bạn có thể thư giãn, phải không? Không. Mọi thứ đối với bạn chỉ mới bắt đầu... Xung quanh bạn là rất nhiều điều mới mẻ và khó hiểu. Làm thế nào để bạn không vặn nó ngay khi ra khỏi cổng? Đó là những gì chúng ta sẽ nói về ngày hôm nay. Trong bài viết này, tôi muốn phân tích những sai lầm phổ biến của tân binh và đưa ra một số lời khuyên, dựa trên kinh nghiệm của bản thân, về cách tránh chúng. Vì vậy, hãy bắt đầu mà không cần phải quảng cáo thêm:

1. Sợ tìm kiếm sự giúp đỡ từ những đồng nghiệp có kinh nghiệm hơn

Tất cả chúng ta đều là con người. Tất cả chúng ta đều sợ mình trông thật ngu ngốc, đặc biệt là trong mắt những đồng nghiệp mới, giàu kinh nghiệm hơn. Khi các nhà phát triển nhận công việc đầu tiên của họ, họ thường bị hướng dẫn bởi nỗi sợ hãi này và, với một tiếng nói nặng nề, họ thu mình lại, cố gắng tự mình tìm ra mọi thứ. Ngoài ra, xung quanh một người nào đó có thể là những đồng nghiệp giàu kinh nghiệm hơn, những người này có thể chỉ cho người đó hướng đi hứa hẹn nhất, giúp tránh được nhiều sai lầm hơn và những "cú va chạm" không cần thiết. Vì vậy, hãy nhớ: đừng ngại đặt câu hỏi. Bạn là người mới bắt đầu và mọi người đều hiểu điều này một cách hoàn hảo. Khi bạn yêu cầu, không ai sẽ đánh bạn bằng gậy. Có lẽ điều ngược lại sẽ xảy ra: bạn sẽ kết bạn với đồng nghiệp nhanh hơn và bắt đầu thích giao tiếp tích cực hơn với họ. TÔI' Tôi sẽ nói nhiều hơn nữa: bạn càng hỏi và thảo luận nhiều vấn đề kỹ thuật khác nhau, bạn càng có thể nhanh chóng lột bỏ lớp vỏ non nớt và trở thành một chuyên gia trong lĩnh vực của mình. Và một lời khuyên nữa. Đừng xa lạ vớiStackOverflow . Tôi đang nói cụ thể về việc đặt câu hỏi về tài nguyên này. Một mặt, phải mất một thời gian để có câu trả lời cho câu hỏi của bạn. Nhưng mặt khác, bạn có thể nhanh chóng học được nhiều cách tiếp cận để giải quyết vấn đề của mình và nhìn nó từ một góc độ hơi khác. Tôi cũng muốn lưu ý rằng có những lợi ích thiết thực khi viết nhận xét/câu trả lời và viết câu hỏi làm rõ về các câu hỏi của StackOverflow từ các nhà phát triển khác: bạn có cơ hội tranh luận và tìm hiểu sâu hơn về các vấn đề, chưa kể đến việc tăng nghiệp.

2. Không tự mình tìm kiếm thông tin

Sai lầm này có thể được coi là mặt trái của sai lầm trước đó.Ý tôi ở đây là khi bạn bắt đầu làm phiền đồng nghiệp và người quen của mình về mọi vấn đề hoặc trục trặc mà bạn gặp phải. Đặt câu hỏi là tốt, nhưng đừng đặt quá nhiều câu hỏi. Nếu không, mọi người có thể chỉ thấy bạn phiền phức. Nếu bạn bối rối về điều gì đó, điều đầu tiên cần làm là rèn luyện kỹ năng tìm kiếm của bạn trong công cụ tìm kiếm tốt nhất - Google. Một số người khác đã gặp phải phần lớn các lỗi khó hiểu và các vấn đề khác. Và bạn sẽ khá ngạc nhiên nếu bạn google câu hỏi của mình và thấy số lượng người quen thuộc với một vấn đề tương tự và những người đã nhận được câu trả lời thấu đáo mà bạn có thể áp dụng trong công việc của mình. Đó là lý do tại sao bạn sẽ thường nghe đồng nghiệp của mình trả lời bằng "Google it". Giảng viên đại học' Đừng cảm thấy khó chịu với câu trả lời này - đồng nghiệp của bạn không phải là giáo viên riêng của bạn, người phải truyền đạt tất cả những điều tinh tế trong lĩnh vực công việc của bạn. Sự mở rộng vô tận của Internet sẽ là người cố vấn của bạn. Đôi khi các lập trình viên còn được gọi lànhững người có đai đen trong tìm kiếm Google . Vì vậy, nếu chúng tôi có một "trục trặc", trước tiên chúng tôi google vấn đề. Nếu không thể tìm ra giải pháp (điều này hiếm khi xảy ra), chỉ khi đó chúng tôi mới bắt đầu hỏi đồng nghiệp. Các câu hỏi ngay lập tức là để nhận được lời khuyên về cách tiếp cận bạn nên chọn để giải quyết vấn đề hơn là những gì bạn sẽ làm khi gặp va chạm tốc độ hoặc thông báo lỗi khó hiểu. Rốt cuộc, họ có thể nhìn xa hơn cách tiếp cận ưa thích của bạn và ngay lập tức dự đoán bất kỳ cách tiếp cận nào sẽ dẫn đến đâu trong thời gian dài.

3. Sao chép và dán một cách mù quáng

Nhưng các vấn đề tìm kiếm trên Google và các giải pháp của chúng đều có những cạm bẫy của nó. Ví dụ: sao chép và dán một cách mù quáng các tệp .Điều này thường xảy ra khi bạn tìm thấy một vấn đề tương tự (nhưng có lẽ không hoàn toàn giống vấn đề) và một giải pháp liên quan, chẳng hạn như trên StackOverflow. Bạn lấy giải pháp này và sao chép và dán nó mà không đi sâu vào chi tiết. Và sau đó bạn hoặc đồng nghiệp của bạn phát hiện ra một số lỗi lạ hoặc hành vi không chính xác trong mã của bạn. Và không ai có thể đoán ngay chúng đến từ đâu. Tất nhiên, cuối cùng, vị trí có mã được sao chép sẽ được tìm thấy và bạn chắc chắn sẽ không được khen ngợi về giải pháp của mình. Do đó, khi bạn tìm thấy một giải pháp có sẵn trên StackOverflow (hoặc bất kỳ nơi nào khác), trước tiên bạn phải hiểu kỹ về cái gì, cách thức và lý do. Có lẽ google các chức năng có liên quan và đọc tài liệu cho nó. Và chỉ sau khi hoàn thành, bạn mới nên thêm nó vào dự án của mình.

4. Chọn sai giải pháp

Khi viết một giải pháp, đôi khi bạn sẽ thấy rằng nó liên tục trở nên phức tạp hơn, cuối cùng đi đến ngõ cụt. Và sau đó bạn cố gắng làm cho giải pháp phức tạp hơn nữa để bằng cách nào đó làm cho nó hoạt động thay vì tìm kiếm một giải pháp thay thế khác phù hợp hơn. Có thể bạn cảm thấy mình đã đầu tư rất nhiều thời gian và công sức nên quyết định rằng, dù thế nào đi chăng nữa, bạn sẽ không bỏ cuộc và sẽ giải quyết vấn đề bằng cách tiếp cận hiện tại của mình. Đây không phải là một thái độ đúng đắn. Ít nhất là trong lập trình. Bạn càng sớm thử một cách tiếp cận khác, thì cuối cùng bạn sẽ càng tiết kiệm được nhiều thời gian. Vì vậy, đừng ngại thử nghiệm và thử các cách tiếp cận khác, bất kể bạn đã đầu tư bao nhiêu thời gian vào cách tiếp cận hiện tại. Hơn nữa, bằng cách thử nhiều cách tiếp cận và tìm hiểu sâu hơn về chủ đề, bạn'

5. Sợ đặt câu hỏi về công việc hiện tại của bạn

Làm việc trong một dự án phát triển phần mềm thường tập trung vào việc thực hiện các nhiệm vụ cụ thể. Ví dụ, ở Jira. Những nhiệm vụ này không phải lúc nào cũng được vạch ra một cách rõ ràng và chi tiết. Mô tả nhiệm vụ thường được viết bởi các trưởng nhóm, những người cũng chỉ là người phàm. Họ có thể quên thêm một cái gì đó hoặc không tính đến thực tế là bạn không quen với chức năng này hoặc chức năng kia. Hoặc có lẽ bạn không có bất kỳ quyền truy cập nào vào dự án (ví dụ: quyền truy cập vào cơ sở dữ liệu, máy chủ nhật ký, v.v.). Và bây giờ, bạn đã nhận được nhiệm vụ, nghiên cứu nó hơn một vài giờ, nhưng bạn vẫn ngồi đó, nhìn chằm chằm vào màn hình với sự hoang mang. Thay vì tiếp tục cố gắng hiểu điều này mà không thành công, bạn nên bắt đầu yêu cầu làm rõ hoặc hướng dẫn từ người tạo ra nhiệm vụ. Ví dụ: trong ứng dụng mà nhóm của bạn sử dụng để liên lạc (ví dụ: Microsoft Teams), bạn có thể đặt câu hỏi hoặc đưa ra nhận xét trực tiếp về nhiệm vụ. Mặt khác, nếu bạn viết câu hỏi của mình trong một tin nhắn cá nhân, bạn có thể sẽ nhận được câu trả lời nhanh hơn vì người đó sẽ nhìn thấy câu hỏi của bạn ngay lập tức. Mặt khác, bằng cách đặt câu hỏi trong Jira, bạn thiết lập bằng chứng rằng bạn đang làm điều gì đó, cụ thể là phân tích vấn đề. Có một cách để đẩy nhanh quá trình này: đặt câu hỏi của bạn trong một bình luận trong Jira và sau đó trong DM, thả một liên kết đến bình luận của bạn và yêu cầu xem qua.

6. Đặt kỳ vọng cao phi thực tế vào trưởng nhóm

Một lần nữa, đây là mặt trái của điểm trước đó. Trưởng nhóm là người đứng đầu một nhóm phát triển. Theo quy định, trưởng nhóm của bạn dành phần lớn thời gian của mình cho các hình thức giao tiếp khác nhau. Tuy nhiên, anh ấy hoặc cô ấy cũng viết mã để không quên mọi thứ về lập trình. Như bạn có thể hiểu, cuộc sống của trưởng nhóm rất bận rộn. Rõ ràng là không dễ chịu gì khi kéo tay áo của trưởng nhóm mỗi khi bạn cần hắt hơi. Hãy tưởng tượng mọi thành viên trong nhóm dồn dập dẫn đầu với hàng loạt câu hỏi. Điều đó có thể khiến bất cứ ai phát điên, phải không? Và nếu bạn đặt nhiều câu hỏi, thì trưởng nhóm của bạn sẽ phải dành nhiều thời gian để trả lời bạn. Có thể làm gì để giảm số lượng câu hỏi hướng đến trưởng nhóm:

• Khám phá tài liệu dự án sâu hơn để giảm số điểm mù.
• Hướng câu hỏi của bạn đến các thành viên khác trong nhóm của bạn. Họ có thể quen thuộc với chức năng này giống như khách hàng tiềm năng, hoặc thậm chí có thể hơn thế nữa, vì chức năng này rất có thể được viết bởi một trong số họ.

Ngoài ra, bạn có thể xem các chú thích trong IDE cho ai và khi mã trong một dòng cụ thể được thay đổi lần cuối. Đó chính xác là cách bạn có thể tìm ra ai là người thích hợp nhất để đặt câu hỏi cho bạn. Như bạn có thể đã nhận ra, khi đặt câu hỏi cho trưởng nhóm, cũng như đặt câu hỏi cho đồng nghiệp, bạn cần cố gắng tìm một phương tiện vui vẻ — đừng ngại đặt câu hỏi, nhưng cũng đừng hỏi quá nhiều của họ.

7. Sợ đánh giá mã

Đánh giá mãlà một giai đoạn xảy ra trước khi bạn gửi mã của mình tới một ứng dụng chung (đến một nhánh dùng chung, ví dụ: chính hoặc nhà phát triển). Việc kiểm tra này được thực hiện bởi một nhà phát triển không tham gia vào nhiệm vụ, người có đôi mắt tinh tường có thể phát hiện ra các lỗi, điểm không chính xác hoặc sai sót trong kiểu mã của bạn mà không được chú ý khi bạn viết mã lần đầu. Nếu có những lời chỉ trích, chúng sẽ được để lại dưới dạng nhận xét về một số phần của mã. Trong trường hợp này, nhà phát triển đã viết mã phải sửa các lỗi được xác định trong quá trình đánh giá (hoặc thảo luận về các quyết định của anh ta với người đánh giá, có thể thuyết phục họ rằng họ đúng). Sau đó, mã được gửi đi xem xét lại cho đến khi người đánh giá không còn nhận xét nào nữa. Người đánh giá hoạt động như một "cổng" trước khi mã được cam kết. Thách thức là nhiều lập trình viên mới làm quen coi việc xem lại mã là những lời chỉ trích và lên án. Họ không đánh giá cao các bài đánh giá mã và sợ chúng. Họ không nên. Đánh giá mã chính xác là những gì cho phép chúng tôi cải thiện mã của mình. Rốt cuộc, chúng tôi nhận được thông tin quan trọng về những gì chúng tôi đang làm sai và những gì đáng chú ý. Bạn nên coi mỗi lần xem lại mã là một phần của lộ trình học tập, điều gì đó có thể giúp bạn tiến bộ hơn. Khi ai đó nhận xét về mã của bạn, họ đang chia sẻ kinh nghiệm và các phương pháp hay nhất với bạn. Cá nhân tôi không tin rằng bạn có thể trở thành một lập trình viên giỏi mà không nhận được đánh giá mã. Bởi vì bạn thậm chí không biết về chất lượng mã của mình và liệu một người bên ngoài có kinh nghiệm có chỉ ra lỗi hay không. không đánh giá cao các đánh giá mã và sợ chúng. Họ không nên. Đánh giá mã chính xác là những gì cho phép chúng tôi cải thiện mã của mình. Rốt cuộc, chúng tôi nhận được thông tin quan trọng về những gì chúng tôi đang làm sai và những gì đáng chú ý. Bạn nên coi mỗi lần xem lại mã là một phần của lộ trình học tập, điều gì đó có thể giúp bạn tiến bộ hơn. Khi ai đó nhận xét về mã của bạn, họ đang chia sẻ kinh nghiệm và các phương pháp hay nhất với bạn. Cá nhân tôi không tin rằng bạn có thể trở thành một lập trình viên giỏi mà không nhận được đánh giá mã. Bởi vì bạn thậm chí không biết về chất lượng mã của mình và liệu một người bên ngoài có kinh nghiệm có chỉ ra lỗi hay không. không đánh giá cao các đánh giá mã và sợ chúng. Họ không nên. Đánh giá mã chính xác là những gì cho phép chúng tôi cải thiện mã của mình. Rốt cuộc, chúng tôi nhận được thông tin quan trọng về những gì chúng tôi đang làm sai và những gì đáng chú ý. Bạn nên coi mỗi lần xem lại mã là một phần của lộ trình học tập, điều gì đó có thể giúp bạn tiến bộ hơn. Khi ai đó nhận xét về mã của bạn, họ đang chia sẻ kinh nghiệm và các phương pháp hay nhất với bạn. Cá nhân tôi không tin rằng bạn có thể trở thành một lập trình viên giỏi mà không nhận được đánh giá mã. Bởi vì bạn thậm chí không biết về chất lượng mã của mình và liệu một người bên ngoài có kinh nghiệm có chỉ ra lỗi hay không. đang làm sai và điều gì đáng chú ý. Bạn nên coi mỗi lần xem lại mã là một phần của lộ trình học tập, điều gì đó có thể giúp bạn tiến bộ hơn. Khi ai đó nhận xét về mã của bạn, họ đang chia sẻ kinh nghiệm và các phương pháp hay nhất với bạn. Cá nhân tôi không tin rằng bạn có thể trở thành một lập trình viên giỏi mà không nhận được đánh giá mã. Bởi vì bạn thậm chí không biết về chất lượng mã của mình và liệu một người bên ngoài có kinh nghiệm có chỉ ra lỗi hay không. đang làm sai và điều gì đáng chú ý. Bạn nên coi mỗi lần xem lại mã là một phần của lộ trình học tập, điều gì đó có thể giúp bạn tiến bộ hơn. Khi ai đó nhận xét về mã của bạn, họ đang chia sẻ kinh nghiệm và các phương pháp hay nhất với bạn. Cá nhân tôi không tin rằng bạn có thể trở thành một lập trình viên giỏi mà không nhận được đánh giá mã. Bởi vì bạn thậm chí không biết về chất lượng mã của mình và liệu một người bên ngoài có kinh nghiệm có chỉ ra lỗi hay không.

8. Xu hướng đưa ra những quyết định phức tạp

Các nhiệm vụ/vấn đề khác nhau thường có thể có một số giải pháp khác nhau. Và trong số tất cả các giải pháp có sẵn, những người mới bắt đầu có xu hướng sử dụng những giải pháp phức tạp và phức tạp nhất. Và điều đó có ý nghĩa: các lập trình viên mới vào ngày hôm qua đã học được rất nhiều thuật toán, mẫu và cấu trúc dữ liệu khác nhau, vì vậy họ rất muốn thực hiện một số trong số chúng. Tin tôi đi, tôi đã từng như vậy, vì vậy tôi biết mình đang nói về điều gì :) Tôi gặp phải tình huống là tôi đã triển khai một số chức năng trong một thời gian dài. Nó hóa ra là rất, rất phức tạp. Sau đó, nhà phát triển cấp cao đã viết lại mã của tôi. Tất nhiên, tôi rất muốn xem anh ấy đã thay đổi những gì và như thế nào. Tôi đã xem xét cách thực hiện của anh ấy và ngạc nhiên về mức độ đơn giản của nó. Và có ít mã hơn ba lần. Và thật đáng kinh ngạc, các bài kiểm tra tự động cho chức năng này không bị xóa hoặc thay đổi! Nói cách khác, logic chung vẫn giữ nguyên. Từ đó, tôi đi đến kết luận rằngcác giải pháp khéo léo nhất luôn đơn giản . Sau khi nhận ra điều này, việc viết mã trở nên dễ dàng hơn nhiều và chất lượng mã của tôi đã tăng lên một mức cao hơn đáng kể. Sau đó, bạn hỏi khi nào thì đáng để áp dụng các mẫu thiết kế và thuật toán ưa thích? Khi áp dụng chúng sẽ là giải pháp đơn giản và nhỏ gọn nhất.

9. Phát minh lại bánh xe

Bánh xe là một giải pháp lâu bền đã được phát minh từ lâu. Trong mô hình chống đối này, nhà phát triển triển khai giải pháp độc quyền của riêng mình cho một vấn đề đã được giải quyết. Đôi khi những giải pháp hiện có này tốt hơn những gì lập trình viên đưa ra. Theo quy luật, việc phát minh lại bánh xe sẽ dẫn đến mất thời gian và giảm năng suất, bởi vì giải pháp bạn tìm thấy có thể không phải là giải pháp tốt nhất, hoặc, bạn có thể không tìm thấy giải pháp nào cả. Điều đó nói rằng, chúng tôi không thể loại trừ khả năng tạo ra giải pháp độc lập của riêng mình: nếu chúng tôi làm như vậy, thì tất cả những gì còn lại là lập trình sao chép và dán. Lập trình viên nên được hướng dẫn đúng cách bởi các nhiệm vụ lập trình cụ thể phát sinh để giải quyết chúng một cách thành thạo và nhanh chóng, cho dù bằng cách sử dụng các giải pháp làm sẵn hoặc bằng cách tạo các giải pháp tùy chỉnh. Một mặt, tại các trường đại học và trong các khóa học trực tuyến, chúng ta bị tấn công bởi nhiều loại nhiệm vụ khác nhau dường như được thiết kế để giúp chúng ta phát minh lại bánh xe. Nhưng chỉ ở cái nhìn đầu tiên: Mục đích thực sự ở đây là phát triển tư duy thuật toán và nắm vững sâu hơn về cú pháp ngôn ngữ. Những nhiệm vụ như vậy cũng giúp bạn hiểu rõ hơn về các thuật toán và cấu trúc dữ liệu, đồng thời cung cấp cho bạn các kỹ năng để triển khai các đối tác tinh vi hơn, nếu cần (điều này đôi khi cần thiết, nhưng cực kỳ hiếm). Trong cuộc sống thực, bạn không cần phải phát minh ra bánh xe của riêng mình trong phần lớn các trường hợp, vì bánh xe đáp ứng nhu cầu của bạn đã có từ lâu. Có lẽ sự thiếu kinh nghiệm của bạn khiến bạn không biết về sự tồn tại của việc triển khai các chức năng mà bạn cần. Đây là lúc bạn cần thực hiện lời khuyên được đưa ra trong điểm đầu tiên của bài viết này, cụ thể là, nhờ các đồng nghiệp có kinh nghiệm hơn giúp đỡ. Họ sẽ có thể hướng dẫn bạn (ví dụ: chỉ cho bạn đi đúng hướng trong tìm kiếm của Google) hoặc đề xuất một triển khai cụ thể (ví dụ: một số thư viện).

10. Không viết bài kiểm tra

Tất cả những người mới không thích viết bài kiểm tra. Nhưng tại sao chúng ta nên chọn những người mới ở đây? Các nhà phát triển dày dạn kinh nghiệm hơn cũng không thích viết các bài kiểm tra, nhưng họ hiểu rõ hơn tại sao các bài kiểm tra lại cần thiết. Khi bạn hoàn toàn xanh, bạn tự hỏi tại sao bạn nên viết chúng. Mọi thứ đều hoạt động, vì vậy không thể có bất kỳ sai sót nào. Nhưng làm thế nào để bạn đảm bảo rằng những thay đổi của bạn sẽ không phá vỡ thứ gì đó ở nơi khác trong hệ thống? Đồng nghiệp của bạn sẽ không đánh giá cao nếu bạn thúc đẩy những thay đổi gây hại nhiều hơn lợi. Đây là nơi các bài kiểm tra đến để giải cứu chúng tôi. Mã của ứng dụng càng được bao phủ bởi các bài kiểm tra thì càng tốt (điều này được gọi là mức độ bao phủ của mã hoặc mức độ bao phủ của bài kiểm tra). Nếu ứng dụng có phạm vi kiểm tra tốt, thì bạn có thể chạy tất cả các kiểm tra để tìm những nơi mã của bạn sẽ bị hỏng. Và như tôi đã nói trong ví dụ trên, khi nhà phát triển cấp cao tái cấu trúc mã, các thử nghiệm đã không bị lỗi. Điều này là do logic chung không thay đổi. Chúng tôi sử dụng các thử nghiệm để chứng minh liệu logic của chức năng nhất định có thay đổi hay không. Vì vậy, ngay cả khi bạn không thích các bài kiểm tra viết, chúng chắc chắn hữu ích và xứng đáng với thời gian dành cho chúng.

11. Bình luận thái quá

Nhiều nhà phát triển mắc phải chủ nghĩa hoàn hảo và người mới cũng không ngoại lệ. Đôi khi họ chỉ thể hiện một khía cạnh của xu hướng này khi họ bắt đầu bình luận về mọi người và mọi thứ. Ngay cả việc đưa ra những bình luận không cần thiết, bởi vì mã quá rõ ràng:

Cat cat = new Cat(); // Cat object

Không phải tất cả các lập trình viên mới làm quen ngay lập tức nhận ra rằng mã bình luận không phải lúc nào cũng tốt, bởi vì các bình luận thừa làm lộn xộn mã và khiến nó khó đọc. Và nếu mã thay đổi, nhưng các bình luận cũ không được cập nhật thì sao? Sau đó, họ sẽ chỉ đánh lừa và làm chúng tôi bối rối. Vậy thì tại sao lại đưa ra nhận xét như vậy? Thông thường, mã được viết tốt không cần phải bình luận , vì mọi thứ trong đó đã rõ ràng và có thể đọc được. Nếu bạn cần viết bình luận, thì bạn đã làm hỏng khả năng đọc của mã và đang cố gắng khắc phục tình trạng này bằng cách nào đó. Cách tiếp cận tốt nhất là viết mã có thể đọc được ngay từ đầu, tức là mã không cần bình luận. Tôi cũng không thể không đề cập đến sự cần thiết phải tuân theo các quy ước đặt tên chính xác cho các phương thức, biến và lớp. Đây là quy tắc của tôi: Nhận xét tốt nhất là không có nhận xét nào hoặc đặt tên chính xác mô tả rõ ràng chức năng trong ứng dụng của bạn.

12. Đặt tên xấu

Những người mới chơi rất nhanh và lỏng lẻo trong việc đặt tên cho các lớp, biến, phương thức, v.v. Ví dụ: bằng cách tạo một lớp có tên hoàn toàn không mô tả mục đích của nó. Hoặc họ khai báo một biến có tên ngắn, đại loại như x . Họ khi có thêm hai biến tên n và yđược tạo ra, việc ghi nhớ những gì x chịu trách nhiệm trở nên rất khó khăn. Đối mặt với tình huống này, bạn phải suy nghĩ cẩn thận về mã, phân tích mã dưới kính hiển vi (có thể sử dụng trình gỡ lỗi), nghiên cứu chức năng để hiểu đơn giản điều gì đang xảy ra. Đây là nơi các quy ước đặt tên chính xác mà tôi đã đề cập ở trên hỗ trợ chúng ta. Tên chính xác cải thiện khả năng đọc mã, do đó giảm thời gian cần thiết để bạn làm quen với mã, bởi vì việc sử dụng một phương thức sẽ dễ dàng hơn nhiều khi tên của nó mô tả gần đúng chức năng của nó. Mọi thứ trong mã bao gồm tên (biến, phương thức, lớp, đối tượng, tệp, v.v.), vì vậy điểm này trở nên rất quan trọng khi tạo mã chính xác, rõ ràng. Bạn nên nhớ rằng tên phải truyền đạt ý nghĩa, ví dụ, tại sao biến tồn tại, nó làm gì, và nó được sử dụng như thế nào. Tôi sẽ lưu ý nhiều lần rằng nhận xét tốt nhất cho một biến là đặt cho nó một cái tên hay. Để nghiên cứu sâu hơn về các nhận xét và đặt tên chính xác, tôi khuyên bạn nên đọc các tác phẩm kinh điển vượt thời gian:"Clean Code: A Handbook of Agile Software Craftsmanship" của Robert Martin . Trên lưu ý đó, phần đầu tiên của bài viết này (những suy nghĩ của tôi) đã kết thúc. Còn tiếp...