Nhiều người đều tìm kiếm đáp án cho "Lập trình viên cần học những gì?" Nhưng việc quan trọng là điều gì khiến bạn trở thành một lập trình viên tốt thì lại ít người tìm kiếm.
Các câu hỏi kiểu như:
-
Lập trình viên cần học gì?
-
Lập trình viên học ngôn ngữ lập trình gì?
-
Lập trình viên nên học những môn nào?
-
Học làm Back-end thì học cái gì?
-
Học làm Front-end thì học React hay là Angular?
Đấy là những câu hỏi thường là về mặt kỹ thuật. Mà về kỹ thuật thì.
Bạn có thể biết ngay cần học gì khi nhìn vào các khung chương trình học trên các trang học tập lập trình trực tuyến như W3C, Freecodecamp, Tutorialpoint...
>> Hoặc có thể tham khảo: Khung chương trình Học Lập trình Web PHP, Học Lập trình Web Java, Lập trình viên Quốc tế DigiNxt
Tất cả đều đã nêu rất kỹ về công nghệ và lộ trình học. Mình sẽ nói thêm ở một bài khác.
Còn việc "Lập trình viên cần học gì để trở nên tốt hơn?" thì có lẽ ít người tìm kiếm.
Nhưng điều này lại khá quan trọng mà bạn nên biết trước khi bạn bắt đầu học bất kỳ kỹ thuật lập trình hay công nghệ nào đó.
Hôm nay mình muốn chia sẻ một vài suy nghĩ về những thứ mà một Lập trình viên cần học để trở thành lập trình viên tốt hơn (Không bao gồm các vấn đề kỹ thuật).
Lưu ý: Các chủ đề được nêu ra ở đây là tổng quát và không cụ thể cho bất kỳ mảng nào.
Đây là những lời khuyên chung về cách phát triển các đặc điểm cá nhân của bạn, cải thiện sự hợp tác với các đồng nghiệp và khách hàng và thúc đẩy sự nghiệp của bạn như một lập trình viên phát triển phần mềm cao cấp.
Một số điều trong bài viết này là chủ quan và phản ánh kinh nghiệm cá nhân của mình, và cả những điều đã được những người khác chấp nhận và sử dụng thành công.
1. HỌC CÁCH HIỂU QUÁ TRÌNH HOẠT ĐỘNG ĐỂ PHỐI HỢP TỐT NHẤT
Rất nhiều lập trình viên nghĩ rằng phát triển phần mềm chỉ là ngồi trước màn hình máy tính viết code và viết code, mọi thứ khác chỉ là do những người khác cố gắng gây phiền nhiễu và lãng phí thời gian quý báu của họ.
Điều này là sai lầm. Trước khi bạn mã hóa một phần mềm, nó cần trải qua một quá trình chuyển đổi từ một ý tưởng mơ hồ thành một giải pháp được thiết kế cẩn thận và sẵn sàng để thực hiện.
Sau khi bạn đẩy phiên bản mới nhất của mình vào Git, phần mềm cần được kiểm tra, triển khai, theo dõi, phân tích và cải tiến. Viết code chỉ là một trong nhiều bước của quy trình phát triển phần mềm.
Vậy tại sao mình lại nhắc đến điều này?
Điều này rất quan trọng trong việc phát triển sự nghiệp, đặc biệt là khi làm việc trong các tổ chức lớn hơn, các giai đoạn khác nhau của các dự án phần mềm sẽ được xử lý bởi các nhóm khác nhau hoặc thậm chí các phòng ban khác nhau.
Tất cả bắt đầu giống như sau:
-> Các nhà phân tích kinh doanh thu thập các yêu cầu.
-> Các yêu cầu sau đó được bàn giao cho các nhà thiết kế sản xuất các bản thiết kế -> cho các lập trình viên.
-> Các lập trình viên viết chương trình và đưa kết quả cho các kỹ sư QA.
Nếu mọi thứ đều ổn, phần mềm sẽ được gửi đến các nhóm triển khai để phân phối nó cho người dùng cuối.
Quá trình này là quá trình nhận đầu vào (input) và trả đầu ra (output) cho bộ phận khác.
Nếu thiếu sự giao tiếp giữa các bộ phận hoặc người đại diện của họ thường không thực sự hiểu mục tiêu của bộ phận khác thì điều này dẫn đến sự hiểu lầm và thậm chí là xung đột.
=>> Vấn đề này xảy ra cực kỳ thường xuyên.
Học cách hiểu quá trình hoạt động
Đối với việc phát triển phần mềm ngày nay thì điều này nghe có vẻ là hơi quá. Ngày nay, với sự phát triển của các phương pháp Agile, nhiều công ty đã cố tránh xa cách tiếp cận cứng nhắc như vậy.
Nhưng ngay cả khi đó chúng ta cũng thấy rằng mọi người không thực sự cố gắng để hiểu công việc của người khác.
Bạn có bất mãn đối với bộ phận thiết kế vì họ muốn bạn custom một hộp checkbox làm bạn quá tốn thời gian?
Ngược lại, bộ phận thiết kế có bất mãn khi bạn phản hồi rằng font chữ của họ không phù hợp?
Rất nhiều sự khác biệt này có thể được khắc phục bằng cách:
Chú ý đến công việc của người khác!
Hãy ngồi xuống với bộ phận thiết kế của bạn và giải thích cho họ rằng việc thực hiện custom checkbox sẽ mất thời gian một chút và có một thư viện cung cấp một checkbox tương tự mà có thể sử dụng ngay.
Đổi lại, bạn tìm hiểu những điều cơ bản về font chữ và hiểu chính xác tại sao họ chọn lại chọn font chữ đó.
Thay đổi này cũng rất cần đối với các nhà quản lý, nhà phân tích kinh doanh, kỹ sư QA, Chuyên gia hỗ trợ và tiếp thị.
Note: Cố gắng hiểu cách mọi thứ tác động lên sản phẩm của bạn ngoài bạn.
Bằng cách học hỏi điều gì đó từ mọi người, bạn sẽ có thể dự đoán nhu cầu của họ, rút ngắn quá trình phản hồi và tăng tiến độ sản xuất hơn.
Hơn nữa, việc này sẽ mang lại cho bạn rất nhiều sự tôn trọng từ các đồng nghiệp.
2. HỌC CÁCH HIỂU NHU CẦU CỦA KHÁCH HÀNG HƠN
Có một điều quan trọng mà bạn cần phải hiểu về khách hàng của mình:
Hầu hết họ không hiểu được những gì bạn làm!
Agile, Lập trình chức năng, Cơ sở dữ liệu phi quan hệ ... là những từ ngữ ngoài hành tinh đối với họ.
Ngay cả những người theo sát công việc của bạn và thực sự quan tâm vẫn chủ yếu là nắm bắt được phần nổi.
Do đó, điều này là nguyên nhân của nhiều hậu quả.
Bộ mặt của hầu hết khách hàng khi nói chuyện với các Lập trình viên.
Thuê các lập trình viên phát triển phần mềm cho họ đòi hỏi một mức độ tin cậy nhất định. Mọi người thường có xu hướng cảm thấy không thoải mái khi phải trả nhiều tiền cho một thứ mà họ không hiểu.
Hãy nhớ lần cuối cùng bạn phải đem xe máy đi sửa ở một cửa hàng mà bạn không quen với một mức giá cao. Bạn có nghi ngờ tất cả những gì họ làm không?
=>> Vâng, khách hàng của bạn có cùng cảm giác như thế.
Ngoại trừ việc họ không hiểu những gì bạn làm để tạo ra sản phẩm. Họ còn hàng đống vấn đề với việc sản phẩm đó có đạt yêu cầu kỳ vọng về công việc sản xuất, kinh doanh, tạo lợi nhuận của họ.
Khi làm việc với khách hàng mới, quan trọng nhất là việc có được lòng tin của họ. Hãy chắc chắn rằng họ hiểu cách bạn giải quyết vấn đề của họ. Cung cấp cho họ những câu trả lời nhỏ nhưng thường xuyên.
Bằng cách đó họ có thể thấy tiến độ công việc của bạn, họ có thể dễ dàng đánh giá kết quả đang đạt được và phản hồi cho bạn sớm nhất để cùng đi đến đích cuối cùng.
Nhưng, thông thường khách hàng có xu hướng đưa ra giải pháp của riêng họ thay vì chia sẻ vấn đề của họ.
Vì họ không biết rõ về khả năng của bạn, nên các giải pháp của họ thường sai thực tế, thiếu hoặc quá tập trung. Hãy nhớ lại câu nói nổi tiếng của Henry Ford:
"Nếu tôi từng hỏi mọi người họ muốn gì, họ sẽ nói họ cần con ngựa nhanh hơn."
Thay vì âm thầm thực hiện bất cứ điều gì khách hàng muốn, đôi khi, rất hữu ích khi ngay từ đầu bạn mời họ lùi lại một bước và thảo luận về vấn đề mà họ muốn giải quyết.
Khi kết hợp kiến thức của họ và chuyên môn kỹ thuật của bạn, bạn sẽ tìm ra giải pháp tốt hơn.
Hãy nhớ rằng, không phải ai cũng thích đặt câu hỏi về ý tưởng của mình và chiến thuật này đòi hỏi bạn phải có một chút khéo léo và truyền cảm hứng cho khách hàng.
Có thể bạn sẽ cần cần phải rời ghế làm việc của mình để đến tìm hiểu về doanh nghiệp của họ, hiểu hơn về vấn đề của họ để có thể đề xuất một giải pháp tốt hơn.
Công việc này có thể là thách thức nếu họ làm việc trong các ngành phức tạp như tài chính hoặc chăm sóc sức khỏe.
Nhưng nếu bạn làm việc này một lần, thì có khả năng là lần sau khách hàng sẽ quay lại với tinh thần cởi mở hơn nhiều đấy.
3. HỌC CÁCH SỬ DỤNG CÔNG CỤ PHÙ HỢP VỚI CÔNG VIỆC
Học cách sử dụng công cụ phù hợp với công việc
"Nếu bạn chỉ có một cái búa, mọi thứ sẽ trông giống hệt như một cái đinh."
Thông thường các lập trình viên chỉ học một công nghệ duy nhất vội vàng áp dụng nó cho mọi vấn đề họ gặp phải.
=> Không có gì đáng ngạc nhiên khi cách cách làm này dẫn đến kết quả không tối ưu.
Thay vào đó, khi giải quyết một vấn đề mới, hãy tạm dừng và suy nghĩ xem liệu các công cụ theo ý của bạn có thực sự phù hợp với loại công việc này hay không.
Nếu bạn có nghi ngờ!
Hãy kiểm tra một chút và đưa ra một danh sách các lựa chọn thay thế tối ưu khác.
Để dễ dàng hơn, hãy soạn một danh sách các câu hỏi và đánh giá từng lựa chọn khác nhau. Các câu hỏi có thể khác nhau, nhưng bạn có thể thử:
-
Những nền tảng hoặc thiết bị nào nó phải hỗ trợ?
-
Các yêu cầu phi chức năng là gì, chẳng hạn như hiệu suất hoặc sử dụng bộ nhớ.
-
Cần sử dụng giấy phép bản quyền hay miễn phí, nguồn mở?
-
Giải pháp này cung cấp tất cả mọi thứ bạn cần hay bạn sẽ cần phải tự viết thêm một cái gì đó?
-
Bạn có bất kỳ giới hạn nào khác không? Ví dụ như: Chính sách của công ty, tính pháp lý hoặc bạn thiếu chuyên gia trong nhóm của bạn không?
Trả lời những câu hỏi này sẽ giúp bạn cấu trúc lại các lựa chọn trong đầu và thu hẹp chúng thành một danh sách ngắn hơn.
Để làm được điều này thì bạn phải có background khá tốt, hiểu rõ cốt lõi của lập trình để có cơ sở giúp bạn thoải mái khi lựa chọn công nghệ phát triển phù hợp.
Lưu ý: Khi học Đại học thì nên học ngành nào phù hợp với mục đích công việc sau này. Học nhiều sẽ tốt hơn.
>>> Xem ngay: Lập trình viên học ngành nào?
4. HỌC CÁCH THỬ NGHIỆM AN TOÀN
Điều gì sẽ xảy ra nếu bạn không biết có điều gì bạn đang biết là có phù hợp hay không?
Đặc biệt trong trường hợp của bạn và bạn muốn thử điều gì mới?
Thực tế là nếu bạn không có kinh nghiệm với một thứ gì đó không có nghĩa là tự động loại nó ra khỏi vấn đề cần giải quyết.
Ý mình là bạn cần xem xét một số thứ sau:
Bạn có đủ thời gian để chuẩn bị?
Nếu dòng thời gian dự án của bạn không gấp gáp, bạn có thể tìm hiểu càng nhiều càng tốt trước khi bạn bắt đầu thực hiện và giải quyết phần còn lại khi vào làm thực.
Hoặc ít nhất là áp dụng phương pháp giả định cho đến khi bạn thực hiện phương pháp đó. Điều này giúp thuyết phục khách hàng rằng bạn biết bạn đang làm gì.
Xác định những điều bạn cần kiểm tra trước
Hãy thực hiện các phương pháp tiếp cận nhanh chóng và xác định những điều quan trọng mà bạn cần đánh giá trước khi có thể kết thúc quá trình thử nghiệm.
Có nghi ngờ về hiệu suất của một hệ thống?
=> Thì hãy xây dựng một nguyên mẫu tối thiểu và thử chạy chịu tải.
Không chắc chắn về một thư viện cụ thể hoặc tích hợp với một service bên ngoài
=> Hãy thực hiện điều đó một cách riêng biệt và sau đó xây dựng phần còn lại.
Hãy nhớ rằng nếu bạn đi con đường này thì vẫn có rủi ro cho cả bạn và khách hàng của bạn, và họ cần phải nhận thức được cả rủi ro tiềm tàng và lợi ích nếu thành công.
Nhưng chung quy thì một quy trình kiểm tra, thử nghiệm kéo dài 2 tuần vẫn có thể tiết kiệm thời gian nhiều tháng, nghe có vẻ khá tốt nhỉ?
Đúng thế, ngay cả khi thử nghiệm thất bại, cũng chỉ có mất 2 tuần thôi mà.
5. HỌC CÁCH ĐỨNG TRÊN VAI NGƯỜI KHỔNG LỒ
Học cách đứng trên vai người khổng lồ
Dân lập trình thường có hai đặc điểm chung:
-
Tôi là người sáng tạo
-
Tôi thích công việc của mình.
Cái này nghe có vẻ như là tốt, nhưng nó đi kèm với một tác dụng phụ:
"Chúng ta có xu hướng đưa ra các giải pháp của riêng mình cho các vấn đề đã được giải quyết trước đây."
Vì vậy, bất cứ khi nào chúng tôi phải đối mặt với việc lựa chọn sử dụng Framework, thư viện hoặc service hay tự mình code, chúng ta sẽ có xu hướng chọn cái sau cùng.
Và điều này giống như chúng ta đang bỏ thời gian khá là vô ích khi phát minh lại cái bánh xe. Một số sai lầm phổ biến dẫn đến điều này là:
Tự mình thực hiện một cái gì đó dễ hơn là học sử dụng một giải pháp của bên thứ 3
Mặc dù đây có thể là một lý do hoàn toàn hợp lệ, nhưng điều quan trọng là nhiệm vụ này không phải lúc nào cũng trong tầm tay.
Thông thường, một chức năng nào đó lúc đầu có vẻ đơn giản nhưng khi nâng cấp lại không đơn giản.
Cuối cùng, bạn có thể sẽ dành cả đống thời gian để xử lý "Bug" (lỗi) và trong trường hợp này, chẳng ai muốn xử lý thay bạn cả.
Giải pháp này làm được nhiều thứ hơn tôi cần
Trừ khi có những lý do cụ chứng mình giải pháp này tệ, chẳng hạn như tăng kích thước của file, thêm các lỗ hổng tiềm ẩn hoặc làm chậm đáng kể quá trình xây dựng, thì đây thường không phải là điều tệ.
Bạn có thể sẽ cần nó sau này. Tuy nhiên, việc thêm toàn bộ thư viện để sử dụng chỉ một chức năng thì lại có thể là quá mức cần thiết.
Chúng ta có thể tự làm điều đó tốt hơn
Mặc dù có một số dự án cho phép bạn có thể tự làm tốt hơn, nhưng điều này không xảy ra thường xuyên.
Nếu so với giải pháp của bên thứ 3 chất lượng được duy trì bởi các nhóm có kinh nghiệm và họ có nguồn lực dành cho việc giải quyết vấn đề đặc biệt này.
Để cạnh tranh với họ, bạn cần phải đầu tư nhiều hơn, tốn công sức, tiền của hơn. Hầu hết các dự án không có đủ tài nguyên cũng không cần phải làm điều đó.
Quyền sở hữu mã nguồn và Bảo trì dài hạn sẽ trở thành một vấn đề.
Một số người sợ rằng nếu sử dụng giải pháp của bên thứ ba, dự án có nguy cơ bị bỏ rơi tại một thời điểm nào đó.
Nguy cơ này là có thật, và bạn nên xem xét một chiến lược giảm thiểu nhất có thể. Nếu nó là một dự án nguồn mở, bạn có thể tự mình duy trì nó không?
Hoặc nếu nó là một dự án độc quyền, thì mất bao nhiêu chi phí để thay thế nó?
Dựa trên những yếu tố đầu vào này, bạn có thể đưa ra quyết định sáng suốt về việc liệu nó có đáng để mạo hiểm hay không?
6. HỌC TỪ VIỆC LÀM LẠI CÁC DỰ ÁN
Có một mặt khác của câu chuyện này. Thực hiện lại một cái gì là một cách tuyệt vời để học hỏi.
Mặc dù viết Framework riêng cho một dự án sản xuất hầu như luôn là một ý tưởng tồi, nhưng việc tạo ra nó như là một bài học lại rất giá trị.
Cách nào tốt hơn để làm quen với các vấn đề mà giải pháp đó giải quyết bằng cách giải quyết cùng vấn đề đó.
Đừng đi quá sâu vào nó, làm lại một cách thô sơ đơn giản là đủ để bạn hiểu được rồi.
Trong khi bạn làm điều đó, đừng ngại khi xem source code của các dự án tương tự. Nghiên cứu mã của các dự án nguồn mở sẽ cho phép bạn hưởng lợi từ kinh nghiệm của các lập trình viên dày dạn hơn.
7. HỌC CÁCH LÀM VIỆC THEO QUI TRÌNH BÀI BẢN
Học cách làm việc theo qui trình bài bản
Phấn đấu để cải tiến không chỉ ở khía cạnh công nghệ, mà cả về phương pháp.
Giống như phần mềm được thiết kế và tối ưu hóa hợp lý, quy trình làm việc được thiết lập tốt sẽ cho phép bạn làm việc dễ dàng và đỡ căng thẳng hơn trong khi tạo ra kết quả tốt hơn.
"Lập trình không khó, Lập trình bài bản mới khó - Mai Văn Hà"
Thiết lập một qui trình làm việc hiệu quả không phải là một nhiệm vụ dễ dàng. Có rất nhiều sách và tài liệu có sẵn về chủ đề này. Nhưng để bắt đầu, hãy xem xét cải thiện các phần sau:
Phương pháp quản lý nhóm và dự án
Vì hầu hết chúng ta làm việc theo nhóm, điều quan trọng là phải áp dụng một quy trình cải thiện sự hợp tác và phối hợp nhịp nhàng giữa các thành viên trong nhóm.
Phong trào Agile trong phát triển phần mềm đã sinh ra một số phương pháp được áp dụng rộng rãi, như Scrum hoặc Kanban.
Chúng giúp tổ chức, cấu trúc công việc tổng thể nhưng không bao gồm tất cả mọi thứ. Có nhiều phương pháp khác giúp bạn ước tính, ưu tiên các vấn đề, cải thiện giao tiếp, v.v.
Bạn sẽ cần xác định các lĩnh vực bạn đang vật lộn và tìm kiếm các phương án tốt nhất giúp giải quyết các vấn đề đang tồn tại.
Cá nhân hóa qui trình
Giống như một dàn nhạc, một nhóm hiệu quả phải có cùng một nhịp điệu, nhưng điều đó không có nghĩa là mọi người phải làm việc theo một cách giống hệt nhau.
Mỗi người có sở thích riêng và nên làm việc theo cách phù hợp giúp họ làm việc hiệu quả hơn.
Ví dụ, rất nhiều người không thích bị quấy rầy hàng giờ khi viết mã, nhưng cá nhân mình, mình thích làm việc trong một hai tiếng với các khoảng nghỉ ngắn ở giữa ( Đây là một phiên bản giản lược của kỹ thuật pomodoro).
Mình cũng không thích làm việc tại nhà (vì tránh phiền nhiễu việc gia đình), mình thích làm việc ở văn phòng hoặc quán cà phê hơn.
=> Hãy tìm hiểu những gì phù hợp với bạn và tuân thủ nó, nhưng cũng đảm bảo rằng thói quen của bạn không tạo ra vấn đề cho các thành viên khác trong nhóm.
Các phương án Kỹ thuật
Rất nhiều phương án cải thiện quá trình phát triển thực tế nằm trên ranh giới giữa công nghệ và lý luận
Ví dụ:
-
Test-driven development và behavior-driven development giúp giữ cho code base của bạn được cấu trúc và kiểm tra tốt.
-
Review code giúp giảm nhược điểm trong mã và cũng truyền bá kiến thức trong nhóm.
-
Tích hợp liên tục và phân phối liên tục đảm bảo quá trình triển khai dễ dàng và an toàn hơn.
Hãy sử dụng các phương án này kết hợp với các phương pháp khác để đạt được kết quả tối đa.
Hãy nhớ rằng, không có quy trình nào tốt nhất cho tất cả mọi người, điều bạn cần làm là thử nghiệm nó xem có phù hợp với bạn không.
Ngoài ra, hãy chắc chắn rằng bạn hiểu hoàn toàn quá trình và thực hiện nó một cách chính xác.
Tìm kiếm lời khuyên từ các đội đã trải qua quá trình và hưởng lợi từ kinh nghiệm của họ.
Hãy để cho qui trình mới thử nghiệm một chút thời gian và sau đó đánh giá xem liệu mọi thứ đã được cải thiện.
8. HỌC CÁCH PHÁ BỎ CHƯỚNG NGẠI VẬT
Học cách phá bỏ chướng ngại vật
Điều mình nghĩ là cần phải nói riêng. Đây là một lỗi phổ biến để bỏ qua những phiền toái nhỏ có vẻ không quan trọng nhưng thực sự có thể có ảnh hưởng độc hại đến công việc của bạn.
-
Nhà thiết kế sản phẩm của bạn đang ngồi trong một phòng riêng biệt?
-
Sếp A dùng Zalo trong khi sếp B dùng Skye và bạn lại thích dùng Facebook?
-
Team Dev ngồi gần Team Design là đúng. Nhưng tự nhiên đội Telesale lại cũng ngồi ngay bên cạnh?
Không điều gì trong số những điều này đặc biệt nguy hiểm, nhưng chúng có xu hướng chồng chất trở ngại và gây ra hậu quả nghiêm trọng.
Và điều khó chịu là, bạn thường không chú ý đến chúng cho đến khi quá muộn.
Đặc biệt là khi luôn có những nguy hiểm nghiêm trọng hơn cần giải quyết. Hãy nhớ câu chuyện ngụ ngôn về con ếch trong nồi nước sôi và khái niệm về sự bình thường của cây leo.
Hãy cảnh giác và chiến đấu với những điều này từ gốc rễ của chúng trước khi chúng gây ra hậu quả cho bạn.
>> Xem ngay: 101 Điều Lập trình viên cần phải học để KHÁC
9. HỌC CÁCH TẬP TRUNG VÀO NHỮNG NGUYÊN TẮC CƠ BẢN
Học cách tập trung vào những nguyên tắc cơ bản
Công nghệ thông tin là một ngành thay đổi cực kỳ nhanh. Hàng tuần đều có các công cụ mới được phát hành vào thị trường.
Mình cũng đã đề cập đến hội chứng mệt mỏi vì Javascript. Rất nhiều lập trình viên đã bị căng thẳng và cảm thấy buộc phải đánh giá lại kỹ năng với các dự án sử dụng JS.
Thật vậy, luôn luôn ở rìa có thể là một thách thức lớn, nhưng có một vài ý tưởng có thể làm cho nó dễ dàng hơn.
Trước hết, tập trung vào các nguyên tắc cơ bản. Mặc dù các công nghệ mới xuất hiện khá thường xuyên, nhưng các khái niệm cơ bản lại hiếm khi thay đổi.
Khi học một cái gì đó mới, hãy chắc chắn rằng bạn hiểu những ý tưởng tiềm ẩn dẫn đến việc thực hiện này.
Rất có thể, những ý tưởng này cũng được sử dụng trong các dự án khác, và một khi bạn gặp phải điều gì đó tương tự, bạn sẽ dễ dàng nắm bắt được nó hơn.
Ví dụ: Các Framework UI JavaScript hiện đại dựa trên các component và khi bạn hiểu cách cấu trúc một ứng dụng hướng thành phần bằng React, bạn có thể sử dụng kinh nghiệm này khi làm việc Angular.
Theo cách tương tự, các ý tưởng của Redux đã tìm thấy trong Angular và Reactive State management từ Angular đã được triển khai cho React dưới dạng MobX.
Dành chút thời gian để làm quen với những cuốn sách cổ điển về các mô hình phổ biến trong phát triển phần mềm, chẳng hạn như: "Enterprise Integration Patterns", của Gregor Hohpe và Bobby Woolf hoặc “Design Patterns: Elements of Reusable Object - Oriented Software”.
Mặc dù một số điều được mô tả trong sách có thể bị lỗi thời, nhưng bạn có thể sử dụng chúng để tìm hiểu cách các mô hình phát triển cho đến ngày hôm nay.
Thứ hai, đừng vội vàng để tìm hiểu về mọi điều mới mẻ vừa xuất hiện ngoài kia. Mình hiểu rằng nó hấp dẫn để theo dõi và cũng khá là thú vị. Nhưng hầu hết chỉ là phong trào thôi.
Thay vào đó hãy để mắt đến những thứ đang lan truyền trong cộng đồng một thời gian và đã trưởng thành vượt ra ngoài tiếng PR ban đầu.
Bạn chỉ cần chút ý một chút về những điều dang diễn ra thì sẽ không có vấn đề gì.
Chúng ta đã nói về rất nhiều điều trong bài viết này, nhưng có một vài điểm khác mình muốn nêu bật trước khi chúng ta kết thúc. Một vài mẹo nhỏ này tập trung nhiều vào đặc điểm cá nhân của bạn hơn, nhưng mình vẫn tin rằng chúng có tác động cao đến sự nghiệp của bạn.
BONUS #1. HỌC CÁCH CHIA SẺ KIẾN THỨC
Học cách chia sẻ kiến thức
Thông thường mọi người nghĩ rằng tích trữ kiến thức có giá trị sẽ làm cho mọi người cần chúng ta.
Nếu có những người như thế này trong dự án của bạn thì khả năng dự án của bạn sẽ lao đao khi họ bỗng nổi hứng startup riêng.
Nếu bạn là một trong số những người này, hãy cân nhắc rằng ngoài việc khiến bạn trở nên quan trọng, việc bạn giữ kiến thức cho riêng mình cũng sẽ khiến bạn trở nên "Không đáng tin".
Thậm chí bạn có thể bỏ lỡ các cơ hội thăng tiến khác trong tổ chức của mình vì bạn bị trói buộc ở trong vai trò này. (Khó có ai thay thế được bạn ở chỗ ngồi đó)
Thay vào đó, hãy chia sẻ kiến thức với các đồng nghiệp của bạn, nếu có thể, hãy ủy thác một phần công việc của bạn cho họ và sử dụng sự hợp tác này để xây dựng những điều tuyệt vời hơn nữa.
Điều này thực tế còn làm cho kiến thức của bạn tăng nhanh chóng vì bạn sẽ phải không ngừng đào sâu để có thể truyền cho người khác.
BONUS #2: HỌC CÁCH CÙNG NHAU GIẢI QUYẾT VẤN ĐỀ.
Học cách cùng nhau giải quyết vấn đề
"Đừng đổ lỗi cho bản thân hoặc bất kỳ người nào khác"
Mình nhớ cách đây rất lâu bọn mình đã có một sự cố trong một dự án do lỗi của mình. Bọn mình đã xoay sở để phục hồi sau sự cố khá nhanh và mình nhớ khách hàng nói với mình thế này:
"Bạn không đánh giá một đội bằng cách nhìn vào quá trình họ hoạt động tốt cho đến khi đội của họ trục trặc"
Cho dù bạn có giỏi đến đâu, đôi khi mọi thứ sẽ trở nên sai lầm và trong những lúc như vậy, điều quan trọng là bạn có thể giữ bình tĩnh và xử lý tình huống và tôn trọng lẫn nhau.
Sau khi sự cố đã được khắc phục, cũng đừng quá tập trung vào việc tìm kiếm người gây ra lỗi.
Đừng để công ty của bạn biến thành sân chơi chính trị, nơi mọi người âm thầm nghi kỵ và đề phòng lẫn nhau.
Thay vào đó, hãy cùng ngồi lại và giải quyết vấn đề chung. Rút kinh nghiệm cho dự án sắp tới.
Tập trung vào những điều dẫn đến vấn đề chứ không phải ai gây ra vấn đề, tìm hiểu lý do tại sao nó xảy ra và suy nghĩ về việc cải thiện hệ thống, qui trình để có thể cover lẫn nhau, tránh sai lầm tương tự trong tương lai.
BONUS #3: HÃY HỌC CÁCH ĐÓNG GÓP. DÙ CHỈ LÀ VỖ TAY KHÍCH LỆ
Cộng đồng lập trình viên có 2 mặt trái ngược.
Nhiều người thì tích cực đóng góp cho cộng đồng nguồn mở, truyền đạt ý tưởng mới qua các chương trình hội thảo, viết bài phân tích.
Trong khi có những người chỉ chăm chăm troll, tỏ ra thiếu tôn trọng người khác khi nghe họ trình bày ý tưởng mới.
Hãy học làm người tử tế trước khi học làm một lập trình viên giỏi.
Bạn thấy đấy, không phải cứ học tốt kỹ thuật là được đánh giá là một lập trình viên tốt. Không cứ Lập trình tốt là có sản phẩm tốt.
>>> Xem thêm sự thật: Học Lập trình là phải học Khối A?
TỔNG KẾT
Điều tốt nhất trong công việc Lập trình của chúng ta là nó không có giới hạn. Luôn luôn có những con đường mới để đi và khám phá.
Cho dù bạn chỉ mới bắt đầu cuộc hành trình trở thành một lập trình viên hay là một chuyên gia có kinh nghiệm thì câu hỏi Lập trình viên cần học gì để trở nên tốt hơn? luôn tốt hơn câu hỏi Lập trình viên cần học gì?