Liệu bạn có phải là một lập trình viên tốt

Trong một buổi phỏng vấn có một câu hỏi khá là thú vị, người phỏng vấn hỏi hãy nói cho anh ấy biết quá trình giúp bạn trở thành một lập trình viên tốt.

Đây là một câu hỏi lớn và khá là khó có thể trả lời cho câu hỏi này. Để phát triển một kỹ năng như lập trình khá là khó để có thể đạt được một chất lượng đủ tốt, vấn đề ở đây là bạn dành bao nhiêu thời gian tính bằng giờ, bằng ngày hay bằng tuần để có thể giải quyết được kỹ năng này. Chẳng ai có thể khẳng định được, Công nghệ cần thời gian để học.

Thước đo của một tiến trình trong việc học lập trình khác hẳn so với cố gắng trở thành một vận động viên chạy điền kinh. Không phải chỉ cần nhanh và về đích là đạt được mục đích của mình. Với mình nó sẽ là những vòng lặp thói quen tích lũy từng ngày và có thêm một chút yếu tố tư duy logic nữa.

Thật sự thì để có thể đo lường được quá trình xây dựng nên một lập trình viên tốt rất khó có thể xác định rõ ràng được. Đơn cử như bạn chẳng thể hình dung được thế nào là tốt, nhưng có lẽ dưới đây là một số tiêu chuẩn mà mình nhận thấy được thông qua quan sát và thu nhặt được kiến thức từ những anh chị đi trước.

Daily Tracking

Phải nói đây sẽ là một thói quen mà bạn nên hình thành trong dài hạn, tuy nhiên hãy bắt đầu nó càng sớm càng tốt. Nó sẽ giúp bạn theo dõi và điều chỉnh những thứ bạn còn thiếu mỗi ngày. Việc bạn hoàn thành một công việc hay tập trung phát triển một kỹ năng nào đó nó sẽ đi lên từng ngày, từng chút từng chút một. Điều bạn cần làm là theo dõi nó để có thể đảm bảo bạn luôn đi đúng hướng. 

Có 2 cách tiếp cận cho thói quen này như sau:

Lập trình bất cứ thứ gì phải có mục đích

Hãy xác định mục đích một cách rõ ràng trước khi đặt mông xuống và viết code. Ví dụ như bạn muốn thêm một đoạn css để căn lề vào trang index, bạn muốn fix lỗi trong hàm x, bạn một khai báo một biến y để by pass qua một chương trình nào đó. 

Ví dụ vui vui vậy thôi, nhưng ý mình ở đây là trước khi bạn bắt tay vào một công việc gì, đặc biệt là phát triển phần mềm thì bạn phải làm rõ nó trước khi viết. Hãy hình dung bạn không thể mất vài tiếng hay vài ngày để có thể làm ra một thứ sai lệch với yêu cầu ban đầu của khách hàng. Đừng chỉ nghe cái tổng quan của yêu cầu nào đó và võ đoán cái khách hàng cần, ngồi xuống thảo luận và làm rõ các vấn đề đó ra, nếu có gì còn lấn cấn, thì hỏi.

Lúc trước mình có tham gia một buổi traing BA và có một chị đưa cho mỗi bạn một tờ giấy kêu vẽ con voi. Mới ra trường nên mình cũng như bao người khác đặt bút vẽ thôi. Kết quả thì chị ý kêu sai hết rồi các em, chị muốn vẽ con voi nhìn theo chiều từ trước nhìn tới thay vì toàn vẽ ngang

Mình nói do chị không nói rõ ràng, nhưng bạn ơi, khách hàng cũng vậy, họ chỉ có ý tưởng tổng quan thôi, khi mình bắt tay vào làm thì việc của bạn là cần làm rõ vấn đề trước, không rõ không chắc phải hỏi, hỏi thật kỹ, đừng đoán ý khách hàng. Họa chăng khách hàng cũng không lường trước được ý họ muốn thì mình có thể đề xuất giải pháp và hướng đi cho họ. Điều này khiến bạn ghi điểm trong mắt họ đó. Đừng để khi làm xong rồi mới “à..zzz” một câu rồi tốn bao nhiêu công sức và thời gian re-work.

Tin mình đi, giai đoạn đầu này bạn phải chấp nhận tốn thời gian thì bạn sẽ tiết kiệm được bao nhiêu thời gian phía sau đó.

Ghi lại những gì mình đã làm

Thường thì trong quá trình làm việc hay học tập bạn hay gặp những công nghệ hay ho. Việc bạn ghi xuống và nhìn lại công nghệ đó sau quá trình bạn trải qua sẽ giúp bạn hiểu sâu hơn về công nghệ đó. Lý do mình bắt đầu chăm chỉ viết blog hơn về những công nghệ mình đã tiếp xúc là như vậy. Nó không chỉ giúp mình nắm chắc công nghệ mình đã học và làm hơn, mà còn giúp cho những người đi sau có thể có góc nhìn khác từ mình. Mình không đảm bảo tất cả những gì mình tìm hiểu và viết ra là đúng hoàn toàn, nhưng với mình đó là góc nhìn cá nhân mình đã trải qua. Mình cũng hay đọc những quan điểm tương tự trên những diễn đàn để có thể hiểu rõ hơn điểm lợi điểm hại khi chọn và làm việc một công nghệ nào đó.

Bạn có thể đọc thêm bài viết về cách ghi chú để hiểu thêm nhé
# http://blog.ntechdevelopers.com/hay-ghi-chu-di-dung-bien-cai-dau-cua-minh-thanh-to-giay-nhap/

Một điều nữa là bổ sung củng cố nguồn tài liệu cho dự án, thường các SA hay TA là người chịu trách nhiệm document lại những công nghệ và hướng dẫn khách hàng vận hành một sản phẩm phần mềm. Nhưng cái mà giúp học có thể vận hành mức độ micro hơn thì phải là những tài liệu mà ông dev viết ra, những nợ kỹ thuật, cách thức hoạt động, hay những logic chạy trong flow code, điều này thì BA không thể viết được mà phải là những người dev ra nó mới có thể hoàn thiện một cách đầy đủ nhất.

Còn một lý do nữa đó là nguồn tài liệu của dev này giúp cho những người dev mới về sau đỡ vất vả và tốn thời gian nghiên cứu hơn. Chắc hẳn có những người thường vào những dự án ôm lại đống source code của người cũ, chẳng có một tài liệu gì, một mớ bòng bong khiến cho người mới cảm thấy choàng váng và sợ hãi. Điều mình không muốn thì hãy cố gắng đừng để người khác sau này gặp điều tương tự, hãy cố gắng ghi chú lại dù là đơn giản nhất để giúp mình, giúp đời, giúp đồng nghiệp không ghét nhau hơn. Đừng để một ngày bạn cắn phải lưỡi vì có thằng bạn chẳng hề quen biết chửi ở đâu đó vì thứ bạn làm ra. Bạn cũng đừng lấy cớ là không có thời gian nhé, nó cũng chẳng đáng bao nhiêu khi mỗi ngày làm xong bạn notes lại một chút, khi hoàn thành dự án thì bạn chỉ tổng hợp nó lại thôi. Chính việc bạn dồn một đống cuối dự án khiến bạn ngại và lười và than rằng mình không có thời gian.

Có một cái nhìn dài hạn hơn và rút kinh nghiệm những gì mình đã gặp phải

Một lập trình viên thường chỉ nắm một mảng nhỏ trong một dự án hay phần mềm, hãy cố gắng nhìn một cách tổng quát và các mảng khác ngoài phần việc của mình nắm giữ. Điều này giúp bạn có thể hiểu rõ hơn về sản phẩm mình đang làm và có thể backup phần task của những đồng nghiệp khác nghỉ chẳng hạn. Nhiều bạn nghĩ rằng tại sao mình phải làm thay phần việc của người khác và ôm rơm nặng bụng như vậy. Tuy nhiên hãy nghĩ một cách đơn giản là mình đang tìm hiểu và học hỏi cho bản thân mình, việc mình biết thì cái lợi đầu tiên là cho bản thân mình đã, dự án hay công ty chỉ chẳng ai muốn rơi vào trường hợp xấu khi có người nghỉ bắt bạn phải backup cả. Với mình thì mình thường tìm hiểu những mảng của người khác để hoàn thiện toàn bộ bức tranh lớn của một dự án. Từ đó mình tạo một project nhỏ và làm lại từ đầu những gì mình học được, hiểu được, và đó là cách mình củng cố kiến thức trong quá trình làm việc. 

Một điều đáng ghi nhớ nữa là việc lưu lại những vấn đề mà bạn đã gặp phải và đã giải quyết. Thường thì những vấn đề xoay quanh công nghệ thường lặp lại trong các dự án tương tự. Bạn đã từng overtime, vò đầu vứt tóc để giải quyết một cái issue, issue đó có thể vài ngày, vài tháng, thử đi thử lại các cách khác nhau mới tìm được hướng xử lý. Vậy tại sao bạn không ghi lại cách bạn xử lý nó, nó sẽ giúp bạn tiết kiệm thời gian nhiều hơn cho những vấn đề tiếp theo. Đây chính là những case study tốt nhất giúp bạn có thể phát triển bản thân một cách tốt hơn.

Mình từng nghe một anh SA kể, việc quyết định dùng công nghệ nào, kiến trúc nào không phải là do cảm tính, những bài học hay những vấn đề đã từng giải quyết trong mỗi dự án giúp anh quyết định lựa chọn nó ngoài những kiến thức cơ bản. Đó được gọi là kinh nghiệm, và kinh nghiệm này không phải những người mới có thể có được. 

Vấn đề là những người trẻ tuổi không nhận ra được điều này, thường hay vặn vẹo các anh làm có 5 phút đã xử lý được vấn đề rồi. Nhưng chẳng ai hiểu được để mất 5 phút đó, họ đã phải mất biết bao nhiêu đau thương trải qua nó, kinh nghiệm từ những lần trước đó đã giúp họ bắt bệnh một cách nhanh chóng và chính xác. Đó chính là cái đáng tiền của những người cấp cao, mà không phải là thời gian họ bỏ ra.

Đây chính là thứ mình nhận ra được là luôn cố gắng hỏi các anh chị đi trước những câu tại sao ngớ ngẩn, những kinh nghiệm mà họ tích lũy được tại sao mình không thể học hỏi lại được, nhằm rút ngắn thời gian va vấp những vấn đề tương tự.

Tại sao không nhỉ?

Trên đây là bài viết chia sẻ những thứ mà mình nhận ra được trong quá trình làm việc và quan sát được mọi người trong con đường career path để trở thành một lập trình viên tốt.

Ý kiến của bạn về vấn đề này thì sao? Hãy để là dưới phần bình luận nhé!

#ntechdevelopers