5 bài học quý giá cho 20 năm “chinh chiến” trong ngành lập trình

Nhu cầu về developer trong ngành lập trình  tăng lên đáng kể trong 4 đến 5 thập kỷ gần đây, trung bình tăng gấp đôi trong mỗi 5 năm. Kết quả là, một lập trình viên với 5 năm kinh nghiệm sẽ có nhiều cơ hội làm việc tại những công ty mơ ước hơn so với lập trình viên ít năm kinh nghiệm. 

Trong những năm bạn đi làm việc, bạn không chỉ làm việc mà còn tích lũy cho mình những bài học đáng giá. Đó gọi là kinh nghiệm, và còn là thứ tạo khác biệt giữa bạn – người làm việc lâu năm và newbie mới vào nghề. Thử hỏi: nếu bạn là người đi làm lâu năm mà không biết gì, giống như người mới vào nghề, vậy bạn đi làm vì điều gì? 

  Bách khoa toàn thư giải quyết mọi vấn đề của lập trình viên mới học code!

Những điều mình chia sẻ dưới đây được chắt lọc từ những bài học, vấp ngã đáng nhớ trong 20 năm theo đuổi lập trình và nhảy việc tại nhiều nơi khác nhau. 

Copy, paste code là điều tối kỵ trong lập trình

Nếu như bạn đã từng làm như vậy, copy code ở source nào đó và paste vào project của bạn, edit sao cho match và chạy được, thì tốt nhất bạn nên ngừng việc đó lại.

Cũng giống như việc bạn lấy cách tính lương, tính thuế của Nhật mà áp dụng vào Việt Nam vậy, rồi đổi tên lại. Mỗi nơi có một đặc điểm, đặc thù khác nhau, không thể bê nguyên xi từ đất nước khác vào đất nước mình được.

Copy-paste code thường xảy ra với những người mới bắt đầu học lập trình. Có nhiều rủi ro khi bạn làm như vậy, tình huống tốt nhất bạn cần chuẩn bị sẵn là quy trình và theo dõi hệ thống của mình thường xuyên, để đảm bảo bạn sẵn sàng ứng biến khi gặp sự cố, nếu như bạn không muốn leader của mình luôn cằn nhằn và luôn “chen chân” vào khi bạn đang cố fix nó. 

Một điều cần lưu ý đó là khi ban bắt đầu build gì đó phức tạp hơn ngay trên code trước đó của mình, và bạn cần phải đảm bảo rằng vẫn mang tính đồng bộ. 

Ví dụ, bạn triển khai một database bất cứ khi nào có một thay đổi đối với cột Tổng nhưng vẫn đảm bảo rằng Pretax Total cộng Tax vẫn bằng Tổng. Hoặc bạn viết code để ghi lại cảnh báo khi value không khớp với giá trị được gán trong tệp cấu hình. Và trường hợp xấu nhất xảy ra là tất cả dữ liệu không đồng bộ. Với những tình huống như vậy, bạn không có gì phải lo lắng cả, vì việc tính toán và tìm ra xem lỗi ở đâu không phải là nhiệm vụ của bạn mà là của một người khác, một bộ phận khác, bạn là lập trình viên, bạn chỉ code thôi. 

Nhưng có cách để khắc phục tình trạng đó là hãy chủ động trong code của mình, đừng copy-paste code của người khác. Vì khi chính bạn build thì bạn sẽ biết nó trục trặc ở đâu ngay. 

Code có trách nhiệm

Có một quan niệm sai lầm cho rằng, bạn càng viết nhiều code thì chứng tỏ bạn càng làm việc hiệu quả, thật ra không phải vậy. Không nên tư duy code là “tài sản” càng nhiều càng tốt. Mà tư duy code như một phần “trách nhiệm”, viết ít nhưng phải chất lượng và hiệu quả. Một đoạn code như một đoạn mã ADN, quan trọng cấu thành nên sản phẩm và thành công của doanh nghiệp. Vì vậy chúng ta cần CHẤT hơn LƯỢNG.

Vậy chất đó lấy đâu ra? Đọc đến đây chắc nhiều bạn sẽ thắc mắc: ủa? Ông này bị lag à, nói chẳng hiểu cái gì. Các bạn bình tĩnh, hãy đọc tiếp thôi rồi sẽ hiểu 

Tôi dành ra nhiều năm làm việc cho vị trí tư vấn quản lý. Công việc chính của tôi là thực hiện các đánh giá dựa trên cơ sở dữ liệu và giúp lãnh đạo công nghệ thông tin đưa ra các quyết định chiến lược về codebase. Vì vậy tôi xem xét, phân tích và thu thập dữ liệu từ rất nhiều nguồn. Tôi đã thu thập thông tin thống kê chi tiết về hơn 1000 codebase của khách hàng. Sau đó, tôi đã lấy dữ liệu đó và chạy phân tích, tìm kiếm mối quan hệ tương quan. Nếu tôi không thu thập càng nhiều thông tin càng tốt thì tôi sẽ không có nguồn dữ liệu để phân tích, điều quan trọng là bạn cần có cơ sở dữ liệu thiệt nhiều data, còn có thể hiểu là bigdata, thì kết quả phân tích sẽ tương quan hơn nhiều. 

Senior Developer: Đừng quá tin nhau người ơi

Ở độ tuổi 23, tôi có công việc đầu tiên của mình, đó là kỹ sư phần mềm, tôi nhận ra các lập trình viên senior ở đó đầy lòng nhiệt huyết của tuổi trẻ. Đồng nghiệp của tôi – những người trung bình có trên dưới 20 năm kinh nghiệm trong ngành – tôi học được rất nhiều điều thú vị từ họ, biết được nhiều ngôn ngữ lập trình khác nhau cũng từ họ. 

Tôi đưa cho các bạn một bức tranh tổng thể đẹp đẽ như vậy để các bạn bất ngờ ở những điều tiếp theo thôi (surprise :v) 

Nếu bạn là người mới vào làm trong công ty, đương nhiên bạn sẽ giống như tôi vậy, luôn hoài nghi với những lời nói của các lập trình viên đàn anh. Họ có thể thảo luận về kiến trúc hệ thống hoặc thiết kế thành phần của phần mềm. Họ hiểu về kiến trúc thiết kế và sử dụng các mẫu có sẵn. Và những người này có khả năng phát hiện được vấn đề có khả năng phát sinh và biết làm sao để tối ưu trước khi nó xảy ra. Nhưng không phải hầu hết lập trình viên senior đều như vậy, nếu bạn may mắn, bạn sẽ gặp được người tài. 

Nhưng nhìn lại, chuyện vui tôi kể phía trên thực ra toàn là những lập trình viên giỏi và tôi học được từ họ rất nhiều thứ. May thay tôi cũng học được từ chính “bước đi đầu” trong sự nghiệp của mình.  

Đôi khi một sinh viên mới tốt nghiệp cũng có thể làm việc cùng với những lập trình trên 20 năm kinh nghiệm cũng đều là bình thường. Tôi không nói khoe khoang. Tôi nói những điều này để cảnh báo bạn những lập trình viên đàn anh ngoài kia trông có vẻ là giỏi, nhưng không phải là tất cả. Vì vậy, khi bạn là người mới trong công ty, đừng quá chú ý, để tâm đến những lời nói của các lập trình viên senior và cố xem cái nào đúng cái nào sai. Tự bản thân bạn đi xác nhận những lời nói của họ (tốt nhất là lúc khi không có họ ở đó) 

TDD thật sự ngon!

Khi nói đến bất cứ điều gì về lập trình, hoặc liên quan đến lập trình, chúng ta đều có xu hướng đưa mọi thứ vào để so sánh 

  • IDE với lightweight editor?
  • Apple, Windows, hoặc Linux? 
  • Bạn nghĩ gì về PHP?
  • Tabs hay Space? 

Đưa tất cả những điều này lên bàn cân, bạn biết đấy sẽ có những cuộc cãi nhau nảy lửa. Vì vậy, dù có nói gì đi nữa thì tôi vẫn sẽ lao đầu vào lập trình dù có TDD hay là không. Ý định của tôi không phải là để lên lớp giảng giải cho ai mà chỉ nhằm chia sẻ kinh nghiệm của bản thân mình.

Cách đây khoảng 10 năm, tôi luôn hoài nghi TDD, công cụ unit testing, và tôi đã quyết định viết một bài blog lý giải lý do TDD chưa hẳn là một sự lựa chọn hay. 

Đó là một ngày kinh khủng và tồi tệ. Mọi thứ cứ thế diễn ra và tôi ghi note trong mớ bằng chứng, chứng minh đó là một cách kinh khủng để làm mọi thứ. Nhưng sau đó một thứ hay ho xảy đến. 

Tôi tập trung hoàn toàn và dành ra 4-5 tiếng một ngày để viết code mà không chạy application nào để xem có sự thay đổi nào không. Cứ mỗi 10 phút tôi kiểm tra lại để chắc chắn nó đang hoạt động.

Tôi nhận ra rằng tôi đắm chìm trong mớ hỗn độn đó, dành ra nhiều giờ để fix mớ đấy. Nhưng sau tất cả, một điều kì lạ xảy ra, mọi thứ work một cách mượt mà. Lần đầu tiên mọi thứ hoạt động hoàn hảo đến vậy, tôi đã code mà không cần đến sự hỗ trợ của GUI đấy. Tôi đã học được kĩ thuật này, thành thạo về nó. Tôi đã kiểm tra hiệu ứng của unit testing trên code và thấy hiệu ứng rõ ràng là tốt. Bạn hãy tìm hiểu về TDD thử xem, sẽ không làm bạn hối tiếc đâu. 

Luôn biết cách chứng thực ý tưởng của mình 

Bạn sẽ nghe những thứ như “đó không phải là bản design đẹp” hoặc “nó chưa có hiệu quả”. Và bạn cũng sẽ chỉ nghe như thế mà không có một sự kiểm chứng nào (vì người ta là sếp mà, bạn là lính nào dám bật lại). Hãy cải thiện điều này. 

Bạn có nghĩ rằng công việc của nhóm cũng đang ảnh hưởng đến uy tín và sự tín nhiệm của bản thân không ? Việc chứng minh được hiệu quả của giải pháp mà mình đưa ra sẽ giúp bạn giành được sự tôn trọng và sự thăng tiến (lên vị trí lãnh đạo chẳng hạn) trong sự nghiệp của mình. 

Đã có ai trong team yêu cầu bạn sử dụng một nguồn khác hoặc API khác, hơn là cái bạn đang sử dụng chưa? Điều đó chắc sẽ làm bạn không hài lòng nhỉ? 

Hãy chứng minh là team mem của bạn đã sai. Chạy thực nghiệm để chứng minh điều đó thay vì lớn tiếng tranh cãi nhau ai đúng ai sai. Bắt tay vào làm và chứng minh điều đó sẽ có giá trị xác thực hơn là những suy nghĩ hiện diện trong đầu. Đôi khi bạn nghĩ mình đúng khi bắt gặp hoài nghi, nhưng đôi khi bạn nhận ra rằng mình sai, dù là gì thì đều có giá trị tốt. 

Khả năng code đảm bảo được bạn có miếng ăn (vì bạn là lập trình viên mà). Nhưng khả năng code kết hợp với việc luôn kiểm chứng lại những gì mình đã làm sẽ giúp bạn tiến xa (dù là một chút). Bạn kiểm chứng lại rồi thì sẽ khó ai bắt bẻ được bạn, hay tranh giành lấy mất công, lấy mất danh tiếng của bạn; điều này sẽ hỗ trợ trong sự nghiệp thăng tiến của bạn. 

Những điều tôi chia sẻ không phải là “luật lệ ngành” mà chỉ là những bài học tôi đúc kết trong suốt sự nghiệp của mình. Bạn có câu chuyện nào trong nghiệp đi code thì kể với TopDev, tụi mình cùng tranh luận. 

Đừng bỏ lỡ cơ hội nâng cấp kỹ năng liên quan của nghề:

Xem thêm việc làm Senior Developer hấp dẫn tại TopDev

TopDev via DaedTech