Những chuyện “hư cấu/hoang đường” mà dân developer tin sái cổ

Thuở bé, hẳn ai trong số chúng ta cũng từng thích các câu chuyện ngụ ngôn, cổ tích. Lớn lên, khi đi làm, ta không xem truyện cổ tích nữa mà chuyển qua đọc webtretho, truyện tranh, truyện voz.

Bài viết này sẽ kể về những điều “hư cấu/hoang đường” như trong cổ tích, nhưng lại thường được các developer (đang đi học hoặc vừa ra trường) tin sái cổ.

Ngày xưa, lúc còn ngáo ngơ mình cũng tưởng mấy điều này là thật đấy. Vì vậy, hôm nay mình viết bài này để chia sẻ lại cho các bạn lập trình viên để các bạn không giẫm vào vết xe đổ của mình.

hu-cau-tho-bay-mau-2

Chuyện hư cấu khi còn đi học

Cái gì được nhiều người sử dụng tức là nó tốt: Nhiều người nghĩ rằng: PHP được rất nhiều nhiều người, do đó nó là ngôn ngữ tốt, đáng học. Lý do PHP phổ biến là vì nó dễ học, dễ deploy, chứ không hẳn là do nó tốt. Vì vậy, trước chạy theo trào lưu, chạy theo số đông, hãy tự mình nghiên cứu tìm hiểu trước nhé.
Ngôn ngữ/Framework của mình là tốt nhất, xịn nhất, giải quyết được mọi vấn đề: Không có ngôn ngữ/framework nào là vạn năng hay mạnh nhất. Do đó, đừng đi hổ báo kiểu: C, C++ của tao làm gì cũng được, Ruby là mạnh nhất, … coi chừng ăn gạch bể đầu luôn đấy.
Có thể “học xong” một ngôn ngữ: Nhiều bạn mới học lập trình hay lên kế hoạch: em mất 1 tháng để học xong ngôn ngữ A, sau đó chuyển qua ngôn ngữ B. Xin thưa, trong lập trình không có khái niệm “học xong”. Bạn chỉ có thể học cú pháp, một số API cơ bản chứ không phải “học xong”. Bản thân một ngôn ngữ có rất nhiều khái niệm, thư viện mà khi tiếp xúc ta mới biết được. Nhiều developer làm việc với một ngôn ngữ 5-10 năm trời mà vẫn chỉ có thể thành thục chứ không xong được.
Chỉ cần tập trung vào 1 ngôn ngữ/framework là không lo chết đói: Thế giới công nghệ thay đổi rất nhanh, công nghệ nào cũng chỉ sống được vài năm. Ví dụ như cách đây 5-10 năm người ta hay dùng WinForm, dùng Flash, giờ tụi nó sắp xuống lỗ cả. Theo đuổi nghiệp lập trình đồng nghĩa với việc “học, học nữa, học mãi, học tới khi về hưu”. Bạn cần nắm vững các kiến thức nền tảng, khái niệm cơ bản để có thể học nhanh chóng hơn.

Chuyện hư cấu khi mới đi làm

Chỉ cần technical giỏi là bạn sẽ thành trùm, thăng tiến vù vù: Đây là lần thứ 3 mình nhắc lại vấn đề này. Hồi mới ra trường mình cũng nghĩ thế, đi làm một thời gian mới biết: technical chỉ là điều kiện cần chứ không phải điều kiện đủ. Để có thể thăng tiến, gây chú ý của cấp trên, bạn còn phải rèn luyện kĩ năng giao tiếp, thuyết trình,… và các soft-skill khác.
Code cũ như đống sh*t, viết lại từ đầu còn nhanh hơn: Khi tham gia một dự án cũ, bạn sẽ thấy code cũ lòng vòng khó hiểu. Đôi khi bạn sẽ có suy nghĩ đập hết tất cả viết lại từ đầu sẽ nhanh hơn. Cẩn thận nhé!! Đa phần code cũ rắc rối là để giải quyết 1 số bug phức tạp và 1 số case đặc biệt. Viết lại từ đầu rất dễ làm lòi ra thêm bug mới hoặc làm bug cũ sống lại đấy! (Nếu thật sự cần viết lại, các bác dev có kinh nghiệm thường viết unit test trước để bắt bug rồi mới viết lại code).
Phần lớn thời gian lập trình được dùng để viết code: Đôi khi, thời gian test và tìm bug còn nhiều hơn cả thời gian code. Suy nghĩ nhiều lên, viết code ít thôi. Mình thấy hiện tại nhiều bạn chưa nắm rõ vấn đề đã cắm đầu ngay vào code. Theo kinh nghiệm, ta nên xác định vấn đề, xác định cách giải quyết trên giấy trước, sau đó mới bắt tay vào code.

bc990cc6e823b9a8c09958a35fb154dd_1432093928

Viết code chạy đúng là đã hoàn thành công việc: Nếu điều này là đúng thì cuộc sống developer dễ dàng biết mấy. Tiếc thay, code bạn viết ra còn phải đủ comment, dễ hiểu, dễ bảo trì. Vì sao? Khi khách hàng thay đổi requirement thì ta phải vào chỉnh sửa lại code. Viết code ẩu thì chính bạn là người lãnh đủ.
Code tạm cho xong trước đã, khi nào có thời gian thì quay lại refactor sau: Đôi khi chúng ta viết code ẩu để chạy được, sau đó nhủ thầm “khi nào rảnh thì quay lại dọn dẹp cho đẹp vậy”. Tiếc thay, trong ngành lập trình, deadline thường dí sát tới mức bạn không có thời gian “rảnh” để dọn dẹp đống shit mình đã viết. tới khi quay lại đọc code cũ để thêm chức năng mới thấy hối hận.
Nếu chỉ sửa một hai dòng code, không cần test lại làm gì cho phức tạp: Đa số trường hợp thì đúng là vậy, sửa 1,2 dòng code vô hại thường không ảnh hưởng gì đến code. Tuy nhiên, thái độ bất cẩn không test này có thể gây ra những hậu quả khá khủng khiếp. Hồi còn làm FPT, mình từng nghe “huyền thoại” về một bác dev thêm 1,2 dòng code để sửa bug “nhỏ” trước hôm demo, làm ứng dụng crash ngay hôm demo cho khách hàng. Hậu quả ra sao thì các bạn đoán ra rồi hén….
Có thể dễ dàng dự đoán thời gian hoàn thành một task/module: Một sự thật đắng lòng là đa số developer rất kém trong việc dự đoán, họ thường không lường trước được các trường hợp, dẫn tới việc estimate thiếu thời gian. Nếu là junior, các bạn nên cẩn thận khi estimate nếu chưa nắm rõ dự án nhé.

dmL8mza

Kết luận

Biết được sự thật đằng sau những chuyện hư cấu/hoang đường này sẽ giúp bạn dễ sống sót và tiến thân hơn trên con đường lập trình. Đừng tin tưởng hoàn toàn những gì người ta nói, mà hãy google và phân tích trước nhé.

Các bạn nào đã đi làm, có gì muốn chia sẻ thì cứ comment nhé.

larger_kvq1438954585