What does it mean to be a true software craftsman?

Cuốn “The clean coder” là một cuốn sách khá nổi tiếng của Uncle Bob, sau đây là một vài đoạn trích mà mình dùng để tóm tắt lại cuốn sách này.

Do no harm – Đừng trẻ trâu

Phải công nhận rằng, phần mềm là một thứ phức tạp, quá khó để tạo ra một sản phẩm mà không hề có dấu tích của bug – hầu như là không thể.

    Thế nhưng, là một người phát triển sản phẩm, bạn phải có trách nhiệm với sự tồn tại của bugs (nếu có) trong sản phẩm. Hãy nhớ, lời xin lỗi là cần thiết, nhưng không đủ. Khi bạn phát triển kĩ năng của mình, hãy đảm bảo tỉ lệ lỗi mà bạn gây ra phải giảm xuống. Luôn cố gắng để:

  • QA không thể tìm thấy lỗi nào cả

    Đừng nghĩ rằng việc của QA là tìm ra bugs, nghĩa là bạn có thể đùn đẩy mọi công việc kiểm tra sản phẩm cho họ. Trước hết, khi xây dựng thứ gì đó, bạn phải là người có trách nhiệm đầu tiên:

  • Bạn phải đảm bảo chức năng chạy được, và chạy đúng

    Hãy test lại những gì bạn đã xây dựng, và … test lại chúng lần nữa.

    Bạn có thể sai sót, và QA sẽ tìm được nó. Nhưng, hãy học từ những sai lầm đó, hạn chế và đừng bao giờ để những lỗi tương tự xuất hiện.

Work ethic – Đạo đức làm việc

    Mình sẽ chuyển thể nguyên văn tác giả như sau:

  • Đừng nghĩ rằng sếp phải có trách nhiệm nâng cao tay nghề của bạn, đừng nghĩ rằng sếp sẽ là người cầm tay chỉ việc, hướng dẫn bạn hoàn thành công việc, cho bạn đi học hỏi các lớp nâng cao tay nghề, hay là người mua sách cho bạn. Tất cả điều đó là trách nhiệm của bạn.
  • Nếu bạn được thuê để làm việc 40h mỗi tuần, hãy làm việc 60h. 40h đầu tiên là thời gian dành cho sếp và công ty của bạn, 20h còn lại, hãy làm mọi thứ để nâng cao giá trị của bạn: đọc sách, viết code, luyện tập coding, đi học thêm, … Sự nghiệp của bạn nằm trong tay bạn, không phải trong tay sếp.

    Thật ra, khi mình dịch nội dung sang tiếng Việt, thông điệp truyền tải có thể không còn khớp 100%. Hãy đọc bản gốc tiếng anh nếu bạn thực sự muốn hiểu ý tác giả

Mentoring – Hướng dẫn để học hỏi

    Người ta có câu, cách tốt nhất để học chính là khi bạn hướng dẫn cho người khác. Không có cách nào nhanh hơn và hiệu quả hơn khi bạn buộc phải tìm hiểu mọi thứ, và diễn tả lại nó theo cách mà những người chưa biết gì về nó có thể hiểu được.

    Khi bạn dạy / hướng dẫn cho người khác, tức là bạn đã học tới 2 lần.

Good code – Code tốt trông như thế nào

Ai ai cũng nói về good code, ai ai cũng muốn viết good code. Nhưng mà, phải như thế nào mới là good code?

  • Thứ nhất: Code phải chạy được và chạy đúng. Là người phát triển phần mềm, bạn cần phải biết được bạn đang muốn làm gì, và làm thể nào để hiện thực hoá điều đó. Bạn phải hiểu và kiểm soát được những gì bạn viết ra sẽ tương tác như thế nào với các thành phần khác trong hệ thống (từ ngôn ngữ, platform, kiến trúc, …)
  • Thứ hai: Code phải giải quyết được vấn đề khách hàng yêu cầu. Đôi khi khách hàng đưa bạn yêu cầu, nhưng bản thân họ lại không thực sự lường hết được mọi tình huống có thể xảy ra. Hãy là người biết phân tích và làm rõ chúng, để thực sự đáp ứng được nghiệp vụ mà khác hàng yêu cầu.
  • Thứ ba: Code mới phải phù hợp và tương thích với những thứ đang hiện hữu. Đừng làm cho code-based của bạn trở nên rối tung, mất đi tính thống nhất và khó kiểm soát. Hãy chú ý các nguyên lí thiết kế và lập trình, như SOLID chẳng hạn.
  • Thứ tư: Không chỉ viết code cho máy tính, code còn dành cho cả cho con người. Bởi vì phần mềm luôn cần được bảo trì, hãy chú trọng vào tính “trong sáng” của source code.

3AM code – Đoạn code lúc nửa đêm

    Một trong những ví dụ nổi bật là “3AM code”, nói về việc các đoạn code được viết trong khoảng thời gian không chính thức, ví dụ như: thời gian OT, thức khuya cày code, …

  • Khi bạn không có đủ tỉnh táo và sự tập trung, những gì bạn làm thường có khả năng tiềm ẩn lỗi. Nó có thể bị sai kiến trúc tổng thể, có thể tối nghĩa, lòng vòng, bị overwhelmed, … hay tệ hơn là chạy sai khiến bạn phải code lại khi review. Làm việc trong lúc bị phân tâm nghĩa là bạn đang lãng phí.

Nói thêm ý kiến cá nhân về cái này 1 chút, tình huống này rất hay gặp phải trong thực tế, cả khi bạn chủ động lẫn bị động:

  • Tình huống bị động là khi bạn bị bắt phải OT nhiều giờ liền, thậm chí trong nhiều ngày liền. Làm việc quá sức mà không có thời gian để hồi phục về sức khoẻ và tinh thần sẽ dẫn tới năng suất làm việc bị giảm sút. Hãy nghĩ tới những cách khác để tối ưu thay vì làm OT (làm thêm giờ)
  • Tình huống chủ động là khi bạn làm thêm một công việc khác (có thể là code freelancer partime, làm job khác không liên quan IT, …). Tình huống này xảy ra trong thực tế không phải là ít khi mà nhiều developers hiện nay thường muốn làm thêm ngoài giờ để tăng thu nhập. Điều này không có gì sai, nhưng đã có nhiều trường hợp vì mải làm việc ngoài giờ mà không còn đủ sức để duy trì main-job của họ với một năng suất cao.
    • Về mặt pháp lí, khi bạn kí hợp đồng mà lại không đủ sức làm việc, tức là bạn đã sai. Tuy nhiên, cũng phải nói tới trách nhiệm của công ty / sếp trong tình huống này, khi mà lương (hoặc nhiều vấn đề khác) trả cho hợp đồng đã không đủ (hấp dẫn) để khiến lập trình viên có thể yên tâm mà cống hiến.
    • Thật tốt nếu bạn có thể sống khoẻ sống tốt với công việc chính của bạn, bạn nhiệt tâm làm việc, cống hiến và phát triển sự nghiệp. Nếu không, có nên tiếp tục gọi nó là “việc chính” (main-job) nữa hay không?

False delivery – Đừng khẳng định khi bạn không chắc chắn

    Điều tồi tệ nhất mà một lập trình viên có thể mắc phải, đó là khi bạn xác nhận công việc (hoặc tính năng) nào đó đã hoàn thành và sẵn sàng chuyển giao, trong khi bạn chưa thực sự chắc chắn về sự kiểm định bạn đã thực hiện.

Ask for help – Biết sử dụng sự trợ giúp

    Hãy học cách yêu cầu sự giúp đỡ nếu cần thiết. Bạn không thể biết hết mọi thứ trên đời, vậy nên sẽ có lúc bạn bị bí kèo, phân vân, hoặc không thực sự chắc chắn về một giải pháp nào đó. Đừng ngại kêu gọi sự trợ giúp cũng như tham khảo ý kiến của người khác.

    Hợp tác là rất quan trọng trong phát triển phần mềm. Pair programming hoặc Mob programming nếu cần, đó đều là những cách rất hay.

Team efforts – Nỗ lực đồng đội

    Tinh thần chuyên nghiệp không chỉ là hoàn thành việc của bản thân, mà còn biết hỗ trợ đồng đội khi cần. Mọi người đều có trách nhiệm xem xét các lỗi hoặc các vấn đề chưa tốt vẫn còn tồn tại, và cùng chung tay giải quyết nó.

Về điều này, LESS framework cũng có nhắc tới: đừng phụ thuộc vào 1 team chuyên biệt để “dọn rác”, hãy cùng làm điều đó.

Meeting

  • Đừng họp nếu bạn thấy nó không giải quyết được gì cho vấn đề của team bạn.
  • Khi bạn thấy cuộc họp trở nên chán ngắn và vô nghĩa, hãy rời khỏi đó. Hãy sử dụng thời gian của bạn hợp lí.

Stand-up meeting

    Nếu hoạt động theo mô hình Scrum, bạn phải trả lời những câu hỏi sau trong buổi daily meeting đầu ngày:

  • Hôm qua bạn làm gì?
  • Bạn sẽ làm gì hôm nay?
  • Có điều gì trở ngại hay không?

Bạn không nên mất quá 1p30s để trả lời xong những câu hỏi này.

Priorities – Biết điều gì là quan trọng

    Người chuyên nghiệp phải biết đánh giá thứ tự ưu tiên của từng nhiệm vụ, tránh để những lo lắng hay mong muốn chủ quan gây ảnh hưởng.

    Một khi đã xác định được thứ tự, hãy tiến hành như dự định.

Swamps – Đừng a lầy

    Người có kĩ năng là người có thể nhận ra được những mớ lộn xộn tiềm tàng, họ luôn nhìn quanh trong lúc làm việc để sớm phát hiện và xử lí chúng.

    Hãy giữ sự gọn gàng và trong sáng cho source code, kiến trúc và sản phẩm của bạn.

Commitments – Giữ chữ tín

Trong bất cứ công việc gì, sự tin tưởng luôn đóng vai trò quan trọng.

    Đừng hứa, nếu bạn chỉ định làm vui lòng người nghe và không hề có ý muốn thực hiện. Đừng cam kết, nếu bạn không thực sự chắc chắn về điều gì đó. Hãy luôn thể hiện sự nỗ lực, trung thực và truyền tải đúng thông tin mà mọi người cần phải biết.

    Sự tin tưởng luôn cần thời gian và trách nhiệm.

Craft – Lành nghề

  • Giải quyết nhanh chóng, nhưng không vội vàng.
  • Ước lượng hợp lí và thực tế, thay vì làm đẹp con số.
  • Biết lúc nào phải “say NO”, nhưng luôn nỗ lực một khi đã “say YES”.

Có kĩ năng, thái độ chuyên nghiệp là phải thế.