Phân tích những lỗi điển hình của người mới lập trình: phần 1

Chào thế giới! Sau khi bạn đã học được mọi thứ mình cần và cuối cùng được thuê làm thực tập sinh hoặc cấp dưới, bạn có thể cảm thấy thư giãn phải không? Cho dù nó thế nào đi chăng nữa! Mọi thứ chỉ mới bắt đầu... Xung quanh bạn có rất nhiều điều mới mẻ và khó hiểu, và làm sao để không mắc sai lầm như thế này 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 xem xét những lỗi phổ biến mà người mới bắt đầu mắc phải và đưa ra một số lời khuyên từ 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 đắn đo thêm nữa:

1. Sợ nhờ những đồng nghiệp có kinh nghiệm hơn giúp đỡ

Tất cả chúng ta đều là con người và tất cả chúng ta đều sợ bị coi là ngu ngốc, đặc biệt là trong mắt những đồng nghiệp mới có nhiều kinh nghiệm hơn. Sau khi nhận được công việc đầu tiên, các nhà phát triển thường đầu hàng nỗi sợ hãi này và rút lui một cách khó chịu, cố gắng tự mình tìm ra mọi thứ. Đồng thời, một người có thể được bao quanh bởi những đồng nghiệp giàu kinh nghiệm hơn, những người này sẽ có thể hướng dẫn anh ta bước đầu đi theo con đường đúng đắn nhất, điều này sẽ giúp tránh được nhiều sai lầm và những “va chạm” không cần thiết. Do đó, 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 hỏi thì không ai đánh bạn bằng gậy. Có lẽ thậm chí còn ngược lại: bạn sẽ kết bạn với đồng nghiệp nhanh hơn và bắt đầu giao tiếp tích cực hơn với họ. Tôi sẽ nói nhiều hơn: bạn càng hỏi và thảo luận nhiều về các vấn đề kỹ thuật khác nhau, bạn càng có thể thoát khỏi vị trí của một người mới bắt đầu xanh và trở thành chuyên gia trong lĩnh vực của mình càng nhanh. Và một lời khuyên nữa. Đừng bỏ bê StackOverFlow . Trong bối cảnh này, ý tôi là đặ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 câu trả lời cho câu hỏi của bạn. Nhưng mặt khác, bạn có thể ngay lập tức tìm hiểu về một số cách tiếp cận để giải quyết vấn đề hiện tại và nhìn nó từ một góc độ hơi khác. Tôi cũng xin lưu ý rằng việc viết bình luận-trả lời, làm rõ câu hỏi trên StackOverFlow từ các nhà phát triển khác, ngoài điểm cộng về nghiệp chướng, còn có một lợi ích thiết thực: bạn có cơ hội thảo luận và hiểu sâu hơn về vấn đề này.

2. Đừng cố gắng tự mình tìm kiếm thông tin

Có lẽ lỗi này là mặt trái của lỗi trước. Ý tôi là khi bạn bắt đầu lôi kéo đồng nghiệp và người quen của mình bằng mọi vấn đề hoặc vấn đề. Hỏi là tốt, nhưng bạn không nên hỏi quá nhiều, nếu không bạn sẽ cảm thấy nhàm chán. Điều đầu tiên cần làm nếu có điểm khó hiểu nào đó xuất hiện là áp dụng kỹ năng tìm kiếm của bạn trên công cụ tìm kiếm tốt nhất - Google. Ai đó đã 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 tra Google và thấy số lượng người quen thuộc với vấn đề tương tự cũng như đã nhận được câu trả lời toàn diện phù hợp để sử dụng trong công việc của họ. Dựa trên điều này, bạn thường có thể nghe thấy đồng nghiệp trả lời một câu hỏi - “Google nó”. Bạn không nên cảm thấy bị xúc phạm bởi câu trả lời này, bởi vì xét cho cùng, đồng nghiệp của bạn không phải là một giáo viên cá nhân, người sẽ truyền đạt tất cả những điều phức tạp trong lĩnh vực công việc của bạn. Sự mở rộng vô tận của Internet sẽ giúp bạn trong việc tư vấn như vậy. Đôi khi lập trình viên còn được gọi là người có đai đen trong tìm kiếm Google . Do đó, khi chúng tôi gặp khó khăn, trước tiên chúng tôi sẽ tìm ra vấn đề trên Google và nếu không tìm thấy giải pháp nào (hiếm khi, nhưng nó xảy ra), thì chúng tôi bắt đầu hỏi đồng nghiệp của mình. Điều đáng để hỏi họ ngay lập tức, không phải khi có trục trặc hoặc lỗi khó hiểu nào đó, mà là khi chọn cách tiếp cận để giải quyết vấn đề. Rốt cuộc, họ có thể nhìn xa hơn tầm nhìn của bạn và ngay lập tức cho biết cách tiếp cận này hoặc cách tiếp cận kia có thể diễn ra về lâu dài như thế nào.

3. Sao chép-dán mù

Nhưng việc tra cứu vấn đề trên Google và theo đó, giải pháp của nó cũng có những cạm bẫy. Ví dụ: sao chép-dán mù . Đ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 nhau) và bên dưới vấn đề đó, chẳng hạn như trên StackOverFlow, có một giải pháp. Bạn lấy giải pháp này, tự mình sao chép và dán mà không đi sâu vào chi tiết. Và sau đó bạn hoặc đồng nghiệp trong dự án 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 chức năng của bạn. Và ngay lập tức không ai biết đôi chân đó đến từ đâu. Sau đó, tất nhiên, một nơi có mã này sẽ được tìm thấy và bạn chắc chắn sẽ không được khen ngợi vì quyết định này. Do đó, khi bạn tìm thấy một giải pháp làm sẵn trên StackOverFlow (hoặc ở nơi nào khác), trước hết bạn phải phân tích nó một cách chi tiết, nó là gì, như thế nào và tại sao. Có lẽ hãy google chức năng này và xem tài liệu về nó. Và chỉ sau đó mới triển khai nó vào dự án của bạn.

4. Đưa ra giải pháp sai

Khi viết một giải pháp, đôi khi xảy ra trường hợp nó ngày càng trở nên phức tạp và cuối cùng đi vào ngõ cụt. Và bạn đang cố gắng ngày càng phức tạp hóa nó để bằng cách nào đó giải quyết vấn đề này bằng cách sử dụng phương pháp này thay vì cố gắng tìm kiếm một giải pháp thay thế khả thi hơn. Có thể bạn chỉ đơn giản cảm thấy tiếc cho công sức và thời gian mình đã bỏ ra, và vì vậy bạn quyết định: dù thế nào đi chăng nữa, đừng bỏ cuộc mà hãy giải quyết vấn đề theo cách này. Đây không phải là cách tiếp cận hoàn toàn đú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ì bạn càng tiết kiệm được nhiều thời gian hơn. Vì vậy, đừng ngại thử nghiệm các phương pháp khác, bất chấp lượng thời gian bạn đã đầu tư vào phương pháp này. Hơn nữa, đây sẽ là điểm cho trải nghiệm của bạn, vì bạn sẽ thử một số cách tiếp cận và nghiên cứu lĩnh vực này tốt hơn.

5. Sợ đặt câu hỏi về nhiệm vụ hiện tại

Làm việc trong một dự án thường bao gồm việc hoàn thành một số nhiệm vụ (Nhiệm vụ). Ví dụ: ở Jira . Và những nhiệm vụ này không phải lúc nào cũng được mô tả chi tiết và rõ ràng. Chúng thường được viết bởi các trưởng nhóm và đây cũng là những con người, nếu điều đó xảy ra. Họ cũng có thể quên thêm thứ gì đó hoặc không tính đến việc bạn không rành lắm về chức năng này hay chức năng kia. Chà, hoặc 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ờ, khi nhận nhiệm vụ, nghiên cứu hơn mấy tiếng đồng hồ, bạn vẫn ngồi ngơ ngác nhìn vào màn hình. Và thay vì tiếp tục tìm hiểu vấn đề này mà không có kết quả, bạn nên bắt đầu đặt những câu hỏi dẫn dắt/làm rõ cho người thực hiện nhiệm vụ này. Giả sử, trong một ứng dụng mà bạn sử dụng để liên lạc trong nhóm (ví dụ: Microsoft Teams) hoặc trực tiếp dưới dạng nhận xét trong tác vụ này. Một mặt, nếu bạn viết câu hỏi trong tin nhắn cá nhân, rất có thể câu trả lời sẽ nhanh hơn vì người đó sẽ nhìn thấy câu hỏi ngay lập tức. Mặt khác, bằng cách đặt câu hỏi trong Jira, bạn có bằng chứng cho thấy bạn đang làm điều gì đó, cụ thể là phân tích vấn đề. Có một cách để tăng tốc quá trình này: đặt câu hỏi dưới dạng nhận xét trong Jira và gửi liên kết đến nhận xét này trong tin nhắn riêng kèm theo yêu cầu xem.

6. Kỳ vọng quá nhiều từ người lãnh đạo 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 nhóm phát triển. Theo quy định, phần lớn thời gian của một thành viên trong nhóm như vậy được dành cho nhiều loại hình liên lạc khác nhau. Và đồng thời, anh ấy cũng viết mã để không quên nó là gì. Vâng, như bạn hiểu, đây là một nhân vật rất bận rộn. Và việc co giật quá mức sau mỗi lần hắt hơi rõ ràng sẽ không khiến trẻ vui vẻ. Hãy tưởng tượng nếu mọi thành viên trong nhóm dồn dập anh ta bằng một loạt câu hỏi. Vì vậy, bạn có thể phát điên, phải không? Và sẽ không có gì đáng ngạc nhiên khi với nhiều câu hỏi từ phía bạn, anh ấy sẽ trả lời bạn rất lâu. Bạn có thể làm gì để giảm số lượng câu hỏi dành cho trưởng nhóm:

• Nghiên cứu tài liệu của dự án này sâu hơn để giảm số lượng điểm mù.
• Đặt câu hỏi cho các thành viên khác trong nhóm. Rất có thể họ đã quen thuộc với chức năng này như người dẫn đầu, hoặc thậm chí nhiều hơn, bởi vì rất có thể một trong số họ đã viết chức năng đó.

Ngoài ra, trong IDE, bạn có thể xem các chú thích: ai và khi nào đã thay đổi mã lần cuối trong một dòng nhất định. Bằng cách này, chúng ta sẽ tìm ra ai là người đúng nhất khi đặt câu hỏi này. Như bạn có thể đã hiểu, khi đặt câu hỏi cho trưởng nhóm, cũng như khi đặt câu hỏi cho đồng nghiệp, bạn cần cố gắng giữ nguyên tắc vàng - không ngại đặt câu hỏi nhưng cũng không làm phiền họ với số lượng quá nhiều.

7. Sợ xem xét mã

Đánh giá mã hoặc xem xét mã là giai đoạn trước khi tải mã lên một ứng dụng chung (đến một nhánh 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 liên quan đến nhiệm vụ này, người có thể, với giao diện mới mẻ, phát hiện ra các lỗi, điểm không chính xác hoặc thiếu sót trong kiểu mã không được chú ý trong giai đoạn phát triển ban đầu. Nếu có nhận xét, chúng sẽ được để lại dưới dạng nhận xét cho một số phần nhất định của mã. Trong trường hợp này, nhà phát triển thực hiện nhiệm vụ này phải sửa lỗi theo đánh giá (hoặc thảo luận về các quyết định của mình với người đánh giá, có thể thuyết phục anh ta về tính đúng đắn của quyết định của mình). Sau đó, gửi lại để xem xét, v.v. cho đến khi người đánh giá không có nhận xét gì. Người đánh giá đóng vai trò là “bộ lọc” trước khi tải mã lên. Vì vậy, nhiều lập trình viên mới vào nghề coi việc xem xét mã là sự chỉ trích và lên án. Họ không đánh giá cao cô ấy và sợ cô ấy, điều đó là sai. Chính việc xem xét mã cho phép chúng tôi cải thiện mã của mình. Rốt cuộc, chúng ta nhận được thông tin quan trọng về những gì chúng ta đang làm sai và những gì chúng ta nên chú ý. Cần phải xem mỗi lần đánh giá mã như một phần của quá trình học tập, điều gì đó có thể giúp bạn cải thiện. Khi một người để lại nhận xét về mã của bạn, anh ấy sẽ chia sẻ với bạn kinh nghiệm, những phương pháp hay nhất của anh ấy. Đối với tôi, bạn không thể trở thành một lập trình viên giỏi nếu không được đánh giá mã. Bởi vì bạn không biết mã của mình tốt như thế nào và liệu có lỗi nào ở đó theo quan điểm của một người có kinh nghiệm từ bên ngoài hay không.

8. Xu hướng giải pháp trừu tượng

Thông thường, các nhiệm vụ/vấn đề khác nhau có thể có nhiều giải pháp khác nhau. Và trong số tất cả các giải pháp có sẵn, người mới bắt đầu thường sử dụng những giải pháp phức tạp và “khó hiểu” nhất. Và đó là sự thật: nếu hôm qua một lập trình viên mới vào nghề đã nghiên cứu nhiều thuật toán, mẫu, cấu trúc dữ liệu khác nhau, thì anh ta sẽ rất muốn thực hiện một trong số chúng. Vâng, và có thể nói, tôi muốn tuyên bố về bản thân mình. Tin tôi đi, bản thân tôi cũng như vậy và 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 đã dành một thời gian dài để viết một chức năng mà hóa ra lại rất, rất phức tạp. Sau đó nó được viết lại bởi một nhà phát triển cấp Senior+. Tất nhiên, tôi rất muốn xem anh ấy đã thay đổi nó như thế nào và như thế nào. Tôi đã xem cách thực hiện của anh ấy và ngạc nhiên khi thấy nó trở nên đơn giản hơn nhiều. Và mã đã trở nên ít hơn ba lần. Đồng thời, các bài kiểm tra chức năng này không thay đổi và không thất bại! Đó là, logic chung vẫn giữ nguyên. Từ đó tôi đi đến kết luận rằng: những 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à nó trở nên ở cấp độ cao hơn đáng kể. Vậy thì, bạn hỏi khi nào thì đáng để sử dụng các mẫu và thuật toán? Khi đó, khi sử dụng chúng sẽ là cách đơn giản và gọn nhẹ nhất.

9. Việc phát minh ra xe đạp

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

10. Đừng viết bài kiểm tra

Tất cả những người mới bắt đầu đều không thích viết bài kiểm tra. Còn người mới thì sao: những người không phải là người mới cũng không thích viết bài kiểm tra, nhưng họ hiểu rõ hơn lý do tại sao nó lại cần thiết. Khi bạn hoàn toàn xanh, bạn nghĩ: tại sao lại viết chúng? Tất cả đều hoạt động và không thể có lỗi. Nhưng làm thế nào bạn có thể chắc chắn rằng những thay đổi của mình không phá vỡ điều gì đó trong phần khác của hệ thống? Đồng nghiệp của bạn sẽ không đánh giá cao nếu bạn thực hiện những thay đổi mang lại nhiều rắc rối hơn là lợi ích của họ. Đây là nơi các bài kiểm tra đến để giải cứu. Ứng dụng càng được kiểm thử bao nhiêu thì càng tốt (còn gọi là tỷ lệ phần trăm bao phủ). Nếu ứng dụng được kiểm tra tốt, bằng cách chạy tất cả chúng, bạn có thể tìm thấy những chỗ có thể bị phá vỡ do những thay đổi của bạn. Và như tôi đã nói trong ví dụ trên, khi tái cấu trúc chức năng, các thử nghiệm không thất bại, tất cả là do logic chung không thay đổi. Điều này có nghĩa là các bài kiểm tra cũng có thể cho biết liệu logic của một 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 viết bài kiểm tra, chúng vẫn mang lại những lợi ích chắc chắn và đáng để bạn dành thời gian cho chúng.

11. Bình luận quá mức

Nhiều nhà phát triển mắc phải chủ nghĩa cầu toàn và những người mới bắt đầu cũng không ngoại lệ. Nhưng đôi khi tác dụng phụ của mong muốn này là họ bắt đầu bình luận về mọi người và mọi thứ. Ngay cả những gì không cần thiết, bởi vì nó quá rõ ràng:

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

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

12. Đặt tên sai

Thông thường, những người mới bắt đầu làm sai lệch tên của các lớp, biến, phương thức, v.v. Ví dụ: khi họ tạo một lớp mà tên của nó hoàn toàn không mô tả mục đích của nó. Hoặc một biến được tạo với một tên ngắn, chẳng hạn như x và khi có thêm hai biến có tên n và y được tạo , sẽ rất khó nhớ x làm gì . Trong những trường hợp như vậy, bạn phải suy nghĩ cẩn thận về mã và nghiên cứu chức năng này dưới kính hiển vi (có thể sử dụng trình gỡ lỗi) để hiểu đơn giản những gì đang xảy ra ở đó. Đây là lúc việc đặt tên chính xác trong mã mà tôi đã đề cập ở trên sẽ hỗ trợ chúng tôi. Tên chính xác cải thiện khả năng đọc mã, do đó tiết kiệm thời gian làm quen vì việc sử dụng một phương thức trong đó tên mô tả gần đúng chức năng của nó sẽ dễ dàng hơn nhiều. Trong mã, mọi thứ đều bao gồm tên (biến, phương thức, lớp, đối tượng tệp, v.v.), điểm này trở nên rất quan trọng khi tạo mã chính xác, rõ ràng. Điều đáng ghi nhớ là tên phải truyền tải ý nghĩa: ví dụ như tại sao biến tồn tại, nó làm gì và nó được sử dụng như thế nào. Và tôi sẽ lưu ý nhiều lần rằng nhận xét tốt nhất để mô tả một biến là tên chính xác của nó. Để nghiên cứu sâu hơn về nhận xét và cách đặt tên chính xác, tôi khuyên bạn nên đọc tác phẩm kinh điển vượt thời gian: “Mã sạch. Sáng tạo, phân tích và tái cấu trúc”, Robert Martin . Theo lưu ý này, phần đầu tiên của bài viết này (phản ánh) đã kết thúc. Còn tiếp…