Làm một Junior Developer!
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
A post was split to a new topic: Nên tối ưu hóa code và thuật toán ngay từ lúc phát thảo hệ thống hay là làm cho hệ thống chạy được rồi từ từ tối ưu
Mình góp ý là thay vì dịch lại, hãy viết nó theo cách bạn hiểu và dẫn link nguồn như trên, như vậy sẽ dễ dàng hơn. Việc dịch khiến cho bài viết trở nên khô cứng và không hay như khi mình viết lại theo cách mình hiểu. Thật đấy
Vài góp ý nho nhỏ
Tôi đã lập trinhd suốt 4 năm và tôi có thể thoải mái nói rằng tôi có ~1.5 năm kinh nghiệm qua những lần thực tập vào mùa hè, từng thất bại khi trở thành 1 nhà sáng lập, từng là trưởng nhóm kỹ thuật cho 1 dự án khởi nghiệp và công việc hiện tại là trưởng nhóm khởi nghiệp Mobile Heath mà tôi đã hỗ trợ họ thành lập vào tháng 10. Dưới đây là vài điều mà tôi ước gì có ai đó đã viết trước đó cho tôi với tư cách là nhà phát triển của ngành công nghiệp công nghệ cao:
Đặt tên biến dễ hiểu nhằm nâng cao khả năng đọc hiểu code của họ ( tiện cho việc bảo trì code hay khiến người khác dễ dàng đọc và hiểu được code của bạn khi chẳng may bạn bị đuổi việc - just kiđing )
(Đoạn này hơi khó hình dung )
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 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 sau này.
Khi code, hãy làm điều tương tự.
[ Tiêu đề là quan điểm nhưng bạn đề cập tới vấn đề của mục 4 mất rồi ^^ ]
Quan điểm rõ ràng và cứng rắn. Bạn sẽ dễ bị lung lay bởi những ý kiến chủ quan, vậy nên hãy giữ vững quan điểm của mình. Không ai muốn phải nhắc lại câu chuyện “Đẽo cày giữa đường” cả.
Vài góp ý, tham khảo nhe
Tuyệt vời
Mình còn đang trên đường trở thành junior mà. Sao có thể viết theo ý được hehe.
Bài viết là wiki bạn có thể sửa trực tiếp nhé.
Cảm ơn (y)