Mình có đọc được một bài viết hay có tiêu đề On Being a Junior Developer
Sau khi đọc xong mình muốn dịch lại bài viết đó qua tiếng việt và mình đã làm nó.
Mình đồng ý với việc là dịch từ tiếng anh qua tiếng việt là không nên.
Nhưng mình muốn làm như vậy, vì mình, bạn bè mình hay các bạn khác nếu tiếng anh chưa thực sự tốt thì có thể tham khảo nó.
Nhưng mình thấy rằng bản dịch của mình chưa được ổn, không hay và mất mất ý nghĩa của bài viết.
Mình up bản dịch nên đây để mọi người ai có góp ý nào vào bản dịch thì có thể chỉnh sửa. Mình hy vọng sẽ có một bài dịch tốt D:
Cảm ơn mọi người đã quan tâm!
Link gốc bài viết :
On Being a Junior Developer
Link bản dịch :
Làm một Junior Developer !
Junior developer là gì?
Junior developer là từ để chỉ những developer(nhà phát triển) 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.
Tôi vừa tốt nghiệp tại trường đại học Stanford với lĩnh vực Computer Science(Khoa học máy tính). Tôi đã lập trình trong 4 năm và tôi có thể thoải mái thừa nhận rằng tôi có ~1,5 năm kinh nghiệm qua công việc thực tập sinh vào mùa hè, thất bại trong việc trở thành một nhà sáng lập, là một trưởng nhóm kỹ thuật cho dự án khởi nghiệp, trải qua nhiều dự án với vị trí freelance, và vị trí hiện tại của tôi trong dự án khởi nghiệp mobile health, tôi đã giúp thành lập vào Tháng 1o. Dưới đây là danh sách mà tôi ước gì có một ai đó viết cho tôi như là một nhà phát triển công ngành công nghiệp công nghệ cao :
#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à phát triển trong môi trườ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ọ.
– 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 theo dõi các bài viết sau để có thể hiểu hơn về Coding Style
Hãy thử đưa toàn bộ hệ thống vào đầu của bạn và hiểu nó. Chú ý các thành phần khác nhau sẽ được tách riêng, các mẫu thiết kế, và còn làm cách nào để có thể đưa ra các phần kiểm tra.
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 trong môn điền kinh.Việc hình dung chính mình trong một tình huống tốt nhất hoặc làm một kỹ thuật cụ thể một cách chính xác có liên quan đến cải thiện hiệu suất.
Làm điều đó tương tư với việc code (Do it for coding too.)
#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 phác thảo đừ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.
– Có hai bài viết sau mình muốn mọi người đọc :
1, 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 ĐỀ – Bài viết này của Anh Huy Hoàng – Người tạo cảm hứng cho mình làm blog này😀
2,Cảnh báo dành cho người mới học lập trình – Bài viết này của anh Vô Thin bên DayNhauHoc !
Hy vọng mọi người sẽ bỏ chút thời gian ra đọc và tìm hiểu !
#3,Có quan điểm
Là Developer 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 đó.
Thậm chí tự hỏi chính mình “Tại sao bạn đã chọn sự lựa chọn X? 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 giải quyết 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 backenddeveloper đã viết một lớp cơ sở trừu tượng cho tất cả các mô hình của chúng tôi trong Django, mà chủ yếu đóng vai trò như wrapper rất 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 đã đi qua những rắc rối của việc này … .
Sau tất cả không phải là những gì một ORM được thiết kế? Câu trả lời của anh ấy:
“I did that because it makes it easy for us to change the underlying database without having huge migration issues”.
“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 cơ bản mà không có nhiều sự cố về vấn đề di chuyển(cơ sở dữ liệu)”.
Anh ấy đã hỏi các 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: một postgres tới NoSQL) và có đủ khôn ngoan để hành động phòng ngừa.
Đặt câu hỏi về nhiều thứ đặc biệt, nhờ sự khôn ngoan và học hỏi để có được.
#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.
Họ có bằng khoa học máy tính, trình độ không phải là một ‘lập trình cho ngành công nghiệp’ và nó làm họ sợ hãi một chút. Tất cả mọi người Stanford đã được biết đến khi lớn lên là được đứng đầu lớp và năng khiếu tự nhiên. Khi phải đối mặt với một tình huống mà họ không giỏi họ thường cứng đơ 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
As junior developer it is in your best interest to fight those instincts and cast your net far and wide
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.
Lưu ý: Các cuộc tranh luận kinh điển là về functionalvs OOP.
Tuy nhiên, ngay cả một thứ gì đó nhỏ như là Node.js, thử nó 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 của họ cho việc không đồng bộ code bởi vì tôi thực sự thích sự tách biệt đó.
#6) Coi trọng phần kiểm tra
Một điều tôi đã không làm đầy đủ tại Stanford là phần kiểm tra. Tôi đã có một người hỗ trợ sửa lỗi(tới giờ tôi vẫn không làm điều đó);
Tuy nhiên phần còn lại 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 phần kiểm tra và chúng tô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 thử nghiệm.
Là một Junior Developer bạn thực sự cần tôn trọng phần kiểm tra. Tôi sẽ ủng hộ cho phát triển Test Driven (TDD) không chỉ vì nó cải thiện sự tự tin của tôi rằng code của tôi là hoạt động bình thường. Nhưng cũng đã thực sự cải thiện hàm nguyên mẫu của tôi, tôi thường “gọi” các hàm trước khi thậm chí nó được xây dựng. Tôi không đặc biệt thích BDD; Tuy nhiên bất kỳ hình thức kiểm tra nào, bạn có thể làm là có còn hơn không (tôi tin tưởng khi nói về version 1.1 ứng dụng của bạn, bạn sẽ muốn những phần kiểm tra).
#7,Refactor
Một trong những vấn đề của Junior developer là bạn đã không được trong ngành công nghiệp đủ lâu để được hỏi bởi code được viết kém mà trở thành không thể để duy trì. 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 làm việc trong khi đồng thời đánh vào mục tiêu kinh doanh và duy trì.
Khi bạn bắt đầu với một phiến đá trắng tất cả mọi thứ là vàng: bạn có thể xây dựng từ mặt đất lên, 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 càng nhiều và bầu trời là giới hạn. Nếu bạn chỉ đơn giản slinging mã mà không có bất kỳ liên quan đến bảo trì, sau khoảng 6 tháng bạn sẽ tích lũy được một đống lớn về lỗi kỹ thuật.
Các tính năng mới không thể được đưa ra càng nhanh, phải mất thời gian để biết một chức năng nhất định nào và thay đổi ‘sự tàn phá’ trên một thành phần của hệ thống.
Thật không may là nhu cầu cho các tính năng mới từ khách hàng của bạn không chỉ đơn giản là từ chối với các lỗi kỹ thuật của bạn; trong thực tế, nó có khả năng ngày càng tăng. Điều này khiến các nhà phát triển ở một vị trí xấu bởi vì họ có một đống code lộn xộn và những người kỹ thuật không yêu cầu tính năng mới với tốc độ cháy nhanh chóng, những người không có ý tưởng những gì nó có nghĩa là khi bạn nói “spaghetti code”.
Vậy, những gì sẽ xảy ra tiếp theo? Các nhà phát triển nói rằng hệ thống cũ là chậm và tất cả mọi thứ kỳ diệu sẽ tốt hơn nếu chúng ta chỉ có thể ghi lại các điều từ đầu. phát triển như vậy mới được đưa vào để duy trì stack cũ và phát triển “tốt nhất” của bạn bắt đầu tạo 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à không làm việc anyways (nó luôn luôn mất nhiều thời gian để viết lại hơn bạn nghĩ, chồng mới là luôn luôn cố gắng để bắt kịp với chồng cũ, rất nhiều thời gian QA, vv).
Nhưng đây là kicker, người đã viết phiên bản ban đầu ở nơi đầu tiên? Các nhà phát triển.
Tôi muốn các bạn tưởng tượng cho một thứ hai một cách tiếp cận nhân viên phát triển kinh doanh và nói rằng: “Vâng, đó là quan hệ đối tác cũ mà là nghĩa vụ phải được thỏa thuận hàng đầu của chúng tôi là làm chậm và tôi sai lầm mối quan hệ khá xấu. Đừng lo, nếu chúng ta đi có được sự hợp tác khác trong khi vẫn cố gắng để chuỗi cũ cùng chúng ta có thể trở lại với tốc độ đầy đủ! “. Đó là không chuyên nghiệp, và thẳng thắn như vậy là code không thể bảo trì.
Các giải pháp 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 viết lại và refactoring code của bạn. Đừng bao giờ kiểm tra trong code đó không phải là một chút tốt hơn so với trước khi bạn bắt đầu. Code duy trì là Code dễ dàng đọc được, mở rộng, và có thể kiểm chứng bởi các nhà phát triển bên ngoài.
Unless you have a very very good reason to put in that ‘quick fix’ don’t ever sacrifice a local maxima of productivity for the long term health of your codebase.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?