Lời nói đầu

Là một người cũng đang trở thành một Junior Developer - Tôi nghĩ bài viết này sẽ có ý nghĩa với những người mới. Vì nó đưa ra các keyword là các công việc cụ thể để bạn có thể vận dụng nó trong quá trình phát triển bản thân.

Bài viết được lược dịch và bổ sung, chắc chắn sẽ còn rất nhiều sai sót. Mong sẽ nhận được ý kiến phản hồi từ bạn đọc 😅

Bài viết gốc : On Being a Junior Developer

Junior developer là gì?

Junior developer là từ để chỉ những developer với < 2 năm kinh nghiệm trong công việc lập trình. Họ quan tâm tới việc trau dồi các kĩ năng chuyên môn của bản thân. Dưới đây là danh sách tôi ước ai đó đã viết cho tôi với tư cách là nhà phát triển trong ngành công nghệ:

1. Đọc code của người khác

Có lẽ, con đường nhanh nhất để phát triển kỹ năng của bạn là trực tiếp đọc code của người khác. Github là một nguồn tài nguyên tuyệt vời để bạn thực hiện điều đó; và nó còn tuyệt vời hơn nữa nếu bạn có những người anh em dev cùng làm việc mà bạn có thể hỏi tất cả các vấn đề.

Đây là hai điều mà tôi nghĩ là rất quan trọng :

• Chú trọng vào các quy ước đặt tên
  • Lập trình viên giỏi sẽ đặt tên các biến: nhằm nâng cao khả năng đọc hiểu code của họ với người khác. Nhưng cũng đừng kết hợp tên biến thành một kiểu cấu trúc nhất định. Hãy đọc thêm các bài viết sau để có thể hiểu hơn về Coding Style
  • Hãy hình dung toàn bộ hệ thống(thứ mà bạn sẽ tạo ra) trước khi bắt tay vào làm việc. Quan trọng nhất: Hãy hiểu nó. Chí ít là bạn phải hiểu sản phầm mình tạo ra sẽ như thế nào, hệ thống hoạt động ra sao, cần những tài nguyên gì. Điều đó rất có lợi sau này, khi mà bạn phải fix hàng tá lỗi hay tạo thêm những tính năng mới hay ho. Thiết kế tốt các hệ thống trong đầu của bạn rất giống với việc hình dung bản thân như một game thủ.
    • Việc hình dung cách thức game vận hành, hiểu nó, và biết mình đang làm gì và sẽ có điều gì xảy ra. Tính toán các nước đi. Hay việc tưởng tượng chính mình trong việc xử lý một tình huống trong game yêu cầu kĩ thuật và sự chính xác. Những điều đó đều có liên quan đến cải thiện hiệu suất sau này. Tương tự với việc "lên tay" hay tăng rank trong game vậy. Khi code, hãy làm những điều tương tự như vậy.

2. Kế hoạch hóa mọi thứ

Trước đây, bạn đã bao giờ bắt đầu code bằng việc ngồi xuống với một cái bảng trắng hoặc giấy và bút. Những bản nháp trước đừng quá phức tạp, nhưng sẽ phải cung cấp cho bạn một cái nhìn toàn diện về tất cả các thành phần mà bạn muốn code hoặc cần tương tác.

Ngoài ra, bạn cần phải khám phá các thiết kế khác nhau ở giai đoạn này. Việc xóa một tấm bảng dễ dàng hơn nhiều việc bạn cắm đầu vào code. Sau một tuần, bạn nhận ra có một mớ hỗn độn. Tất cả những thứ đó là do bạn thiếu kế hoạch.

Hãy thử tham khảo các bài viết sau

Do đó, khi viết code mà bị rối, tốt hơn hết là bê đoạn code đó lên trên bảng để phân tích. Nếu có tấm bảng bự càng tốt, chia làm hai, một bên viết code và một bên diễn giải từng bước chạy của đoạn code để có lúc thì bí rị ngay tại đó, nhưng đi tắm xong/ đi ăn chè với bạn gái xong, về nhìn lên bảng chợt vỗ trán chửi thề “cái đệch, đơn giản thế mà ngồi loay hoay cả ngày như gã điên”.

Với tấm bảng như vậy, nếu bạn cùng học tới thăm chơi hay cần hỏi ai thì họ có thể xắn tay áo vào phụ giúp ngay, chụp tấm bảng đó với những khoanh tròn, ghi chú thắc mắc cần hỏi thì người giúp đỡ cũng cảm thấy rất muốn được hỗ trợ. - Trích Cảnh báo dành cho người mới học lập trình.

Và bài viết: SỰ THẬT ĐẮNG LÒNG: ĐÔI KHI CẮM ĐẦU NGỒI CODE LÀ CÁCH … NGU NHẤT ĐỂ GIẢI QUYẾT VẤN ĐỀ

3. Có quan điểm

Là một junior bạn nên có các quan điểm và bạn cần phải có lý do là tại sao bạn có quan điểm như vậy. Thậm chí tự hỏi chính mình "Tại sao bạn đã chọn sự lựa chọn này? Code như vậy đã hợp lý chưa? v..v". Đó là một cách tốt để có một câu trả lời mạnh mẽ và giải pháp cho vấn đề của bạn.

Thay vì chỉ đơn giản theo dõi thì bạn nên có các quan điểm bởi vì điều đó có nghĩa là bạn đang học hỏi trong sự hiểu biết. Hãy tự hỏi mình những câu hỏi khó. Để khi Developer Senior đánh giá code của bạn thì bạn sẽ có một lý giải thiết thực, mạnh mẽ.

4. Đặt câu hỏi

Trong những ngày đầu trong dự án hiện tại của tôi, một backend-developer đã viết một lớp trừu tượng cho tất cả các Models của chúng tôi trong Django, mà về cơ bản hoạt động như lớp wrapper riêng của chúng tôi trên Django ORM.

Tôi đã được đọc qua code của anh ta và đã rất tò mò là tại sao anh ấy đã vượt những khó khăn để làm được việc này.

Rốt cuộc, thì câu trả lời không phải là ORM được thiết kế để làm gì? Đây là điều mà anh ấy đã nói với tôi:

"Tôi đã làm điều đó bởi vì nó làm cho chúng ta dễ dàng thay đổi cơ sở dữ liệu mà không gặp phải khó khăn trong việc di chuyển cơ sở dữ liệu."

Anh ấy đã gặp phải những khó khăn liên quan tới vấn đề di chuyển cơ sở dữ liệu trước đó(đặc biệt là giải pháp: postgres tới noSQL) và anh ta có đủ nhanh nhạy để hành động phòng ngừa cho việc đó xảy ra một lần nữa.

Đặt câu hỏi về nhiều điều đặc biệt thường sẽ mang lại sự khôn ngoan và tìm tòi học hỏi.

5. Khám phá những công nghệ mới

Một trong những xu hướng không may tôi thấy với một số bạn bè tốt nghiệp Stanford CS là họ thường sợ hãi khi phải thử tiếp cận với công nghệ mới. Tất cả những người Stanford đã biết họ là những người rất giỏi và tài năng. Nên khi phải đối mặt với một tình huống mà họ không giỏi, họ thường lo ngại vì sợ thất bại.

Với Junior developer, việc khám phá những công nghệ mới chính là lợi ích tốt nhất của bạn để chống lại những bản năng và nâng tầm kiến thức. Từng phần công nghệ mà bạn tìm hiểu sẽ ảnh hưởng tới bạn ít nhiều theo cách nào đó. Sử dụng nhiều công nghệ khác nhau sẽ cho bạn thấy được nhiều mô hình kiểu mới và cách làm việc mới. Thử một công nghệ mới hay một ngôn ngữ lập trình mới là sự mở rộng về thế giới quan của bạn trong lập trình.

Không nhất thiết phải tìm hiểu những công nghệ thật lớn lao. Ngay cả một thứ gì đó nhỏ như là Node.js, nó cũng có thể mang lại lợi ích. Sau khi "chơi đùa" với Node.js bây giờ tôi thường sử dụng hai phần callback cho việc "bất đồng bộ" code bởi vì tôi thực sự thích sự tách biệt đó.

6. Coi trọng việc kiểm thử đơn vị

Lớp học của tôi không bao giờ làm điều đó. Chúng tôi không được chấm điểm dựa trên kiểm thử và chúng tôi phải thiết lập lại các project của chúng tôi mỗi 10 tuần. Đại học chỉ là không được xây dựng để phát triển một văn hóa kiểm thử.

Là một Junior Developer bạn thực sự cần tôn trọng việc kiểm thử đơn vị. Tôi sẽ ủng hộ cho Test-Driven Development (TDD) vì nó cải thiện sự tự tin rằng code của tôi là hoạt động tốt. Và nó cũng đã thực sự cải thiện các function mà tôi viết vì tôi thường sử dụng trước khi nó được xây dựng. Tôi không đặc biệt thích Behavior-Driven Development(BDD).

Tuy nhiên, với việc sử dụng bất kỳ hình thức kiểm tra nào. Bạn cũng nên làm vì có còn hơn không

7. Refactor

Một trong những vấn đề để trờ thành junior developer là bạn đã chưa gặp phải những khó khăn do code "thối" gây ra. Nghiêm trọng đến mức không thể tiến hành bảo trì code được nữa. Trở thành một nhà phát triển không phải là về cách viết code, mà là về sản xuất phần mềm. Tức là làm việc và đồng thời tập trung vào mục tiêu kinh doanh và bảo trì.

Khi bạn bắt đầu với một khoảng đất trống thì mọi thứ đều là vàng: bạn có thể bắt đầu xây dựng phát triển từ mặt đất, các tính năng được tách ra nhanh hơn bởi vì chúng không tương tác với các bộ phận khác của hệ thống mà không gian là thì có hạn. Nếu bạn đơn giản chỉ việc "lướt phím" code, mà không có động thái nào liên quan đến khả năng bảo trì của hệ thống. Thì sau khoảng 6 tháng bạn sẽ "tích lũy" được một lượng lỗi đáng kể.

Các tính năng mới không thể được sinh ra quá nhanh, phải mất thời gian để biết một chức năng làm cái gì và chỉ cần thay đổi một phần cũng có thể ảnh hưởng phần khác của hệ thống. Thật không may, nhu cầu cho các tính năng mới từ khách hàng của bạn sẽ không được từ chối một cách dễ dàng chỉ vì các vấn đề kỹ thuật. Sự thật, nhu cầu có tính năng mới sẽ ngày càng tăng lên. Điều này, đưa các nhà phát triển vào tình huống khó khăn. Bởi vì, họ đang có một đống code lộn xộn và những non-tech thì lại yêu cầu có tính năng mới với một tốc độ bàn thờ, những người non-tech đó không hề hiểu khi bản nói "Tôi nhận một đống code mà không thể refactor". ☉▵☉凸

Vậy, chuyện gì sẽ xảy ra? Các nhà phát triển nói rằng hệ thống cũ hoạt động chậm chạm và mọi thứ sẽ tốt hơn nếu chúng ta có thể đập đi và làm lại từ đầu. Rồi các nhà phát triển mới đưa vào để duy trì hệ thống cũ và nhà phát triển "tốt nhất" của bạn bắt đầu tạo lại các hệ thống từ đầu ¯\(ツ)//¯

Tóm lại, đây là một sự lãng phí rất lớn về tài nguyên và dẫu sao đi nữa nó cũng không hiệu quả(nó luôn luôn mất nhiều thời gian hơn bạn nghĩ so với việc đập đi làm lại, phần mới luôn luôn cố gắng để bắt kịp với phần cũ, tốn rất nhiều thời gian để kiểm thử, rà soát lại hệ thống, và nhiều thứ khác nữa).

Và ngạc nhiên chưa, ai là người đã tạo ra động code lộn xộn đó??? Chính là Các nhà phát triển.

Tôi muốn bạn tưởng tượng lần thứ hai một nhân viên kinh doanh tiếp cận bạn và nói rằng: "Yah, mối quan hệ đối tác cũ được cho là thỏa thuận hàng đầu của chúng tôi rất kém và tôi đã làm rối tung mối quan hệ đó khá tệ đó. Mặc dù vậy, hãy lo lắng, nếu chúng ta có được một mối quan hệ đối tác khác trong khi vẫn cố gắng kết nối mối quan hệ cũ, chúng ta có thể trở lại tốc độ tối đa!." Việc đó không chuyên nghiệp chút nào cả, và thẳng thắn mà nói như vậy là code không thể bảo trì.

Giải pháp cho vấn đề này là cách phòng tránh. Là một nhà phát triển bạn nên liên tục cập nhật và cấu trúc lại code của bạn. Hãy kiểm tra code, điều đó sẽ làm cho code của bạn tốt hơn một chút so với trước khi bạn bắt đầu. Code có thể bảo trì là code dễ dàng đọc, mở rộng, và có thể kiểm tra bởi các nhà phát triển bên ngoài.

Trừ khi bạn có một lý do rất chính đáng để khắc phục điều đó - "quick fix". Đừng bao giờ dành tối đa nguồn lực cho việc phát triển một codebase cho việc sử dụng dài lâu.