Xu hướng chuộng Throwaway Code hơn tài liệu thiết kế

 (softwaredoug.com)
3 điểm bởi GN⁺ 2024-12-16 | 1 bình luận | Chia sẻ qua WhatsApp

  • Chúng ta thường hình dung việc phát triển phần mềm sẽ tuân theo một quy trình gọn gàng và có trật tự

    • Viết tài liệu thiết kế, rồi rollout các thay đổi nhỏ qua PR để triển khai tính năng
    • Lịch sử Git trông sạch sẽ và ngăn nắp
    • Nhưng thực tế thì khác

  • Sự khác biệt giữa tài liệu thiết kế và triển khai thực tế

    • Việc hiện thực hóa nguyên xi tài liệu thiết kế là một ảo tưởng
    • Khi bắt đầu viết code, nội dung trong tài liệu thiết kế sẽ bị chỉnh sửa
    • Kế hoạch không thể sống sót sau lần tiếp xúc đầu tiên với đối phương

  • Phương pháp thiết kế mới: đắm mình vào code

    • Dùng draft PR để triển khai prototype
    • Nhận phản hồi sớm để điều chỉnh cách tiếp cận
    • Ghi lại draft PR như các ý tưởng thiết kế mang tính lịch sử
    • Sẵn sàng vứt bỏ hoàn toàn draft PR
    • Từ draft PR, dần dần tách thành các PR theo từng bước
    • Kiểm thử từng PR theo từng giai đoạn và bổ sung độ vững chắc

  • Tầm quan trọng của sự trưởng thành

    • Khả năng vứt bỏ những ý tưởng đã code là điều quan trọng
    • Điều quan trọng là truyền đạt tri thức tổ chức, không phải số dòng code
    • Cần căn chỉnh sớm về các phần quan trọng để công việc prototype không bị lãng phí

  • Cách dùng PR như tài liệu hóa

    • PR là một trong những hình thức tài liệu hóa tốt nhất cho developer
    • PR là một hiện vật lịch sử phản ánh trạng thái tại một thời điểm cụ thể
    • Tài liệu thiết kế thường cung cấp thông tin khác với thực tế

  • Tầm quan trọng của prototype

    • Một prototype có giá trị hơn 1000 tài liệu thiết kế
    • Muốn dẫn dắt thay đổi thì phải làm bằng code, không phải bằng tài liệu
    • Tổ chức nên xem prototype là câu hỏi chứ không phải câu trả lời

  • Tính hữu ích của tài liệu thiết kế

    • Hữu ích để tổ chức và lưu trữ phản hồi từ nhiều bên liên quan khác nhau
    • Hữu ích khi ý tưởng còn quá mang tính khái niệm hoặc quá dài hạn
    • Hữu ích khi việc diễn đạt ý tưởng bằng văn bản hiệu quả hơn bằng code
    • Hữu ích khi tổ chức không có kỷ luật để vứt bỏ giải pháp đầu tiên
    • Tạo ra môi trường để nhân sự junior có thể an toàn đặt câu hỏi về ý tưởng của developer senior

  • Cách dùng sai tài liệu thiết kế

    • Bị dùng để làm chậm quy trình đối với các developer kém kinh nghiệm hơn
    • Được dùng như tài liệu hóa nhưng nhanh chóng lỗi thời
    • Cố gắng giải quyết mọi vấn đề thiết kế, nhưng vấn đề thực sự lại được phát hiện qua coding

  • Nếu đội ngũ có thể giữ được kỷ luật, thì hacking hiệu quả hơn thiết kế rất nhiều

    • Tác giả khuyến nghị xây dựng kiểu kỷ luật này trong tổ chức
    • Cuối cùng, code có sức nặng hơn lời nói rất nhiều

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-16
Ý kiến trên Hacker News

  • Tạo prototype là một phần quan trọng của quá trình thiết kế, và cần xác định rõ vấn đề cũng như giải pháp

    • Đôi khi chỉ một tài liệu đơn giản là đủ, nhưng cũng có lúc cần nhiều phản hồi và lặp lại
    • Có câu nói rằng "vài tuần viết code có thể tiết kiệm vài giờ lập kế hoạch"

  • Viết lách hữu ích cho việc khám phá vấn đề; đã có lần tưởng rằng mình hiểu vấn đề, nhưng khi viết ra lại nảy sinh những câu hỏi mới

    • Điều này gợi nhớ đến một trường hợp người cố vấn đã dùng Lucidchart để giải thích khối lượng công việc của 6 tháng

  • Có kinh nghiệm dùng giải pháp tạm thời để hoàn thành dự án đúng hạn

    • Giải pháp tạm thời đó cũng được dùng như công cụ hỗ trợ production, và khi phiên bản vĩnh viễn bị gián đoạn thì nó được tận dụng như một đường thay thế

  • Vấn đề lớn nhất của tài liệu thiết kế là không ai đọc chúng

    • Vấn đề của việc tạo prototype là mọi người lại coi đó là code cuối cùng
    • Ưa thích cách tiếp cận hybrid: lập kế hoạch và tài liệu hóa kỹ lưỡng, đồng thời viết mã prototype có chất lượng đủ để dùng trong sản phẩm cuối cùng

  • Sự khác biệt trong phản hồi dành cho code và cho thiết kế là rất lớn

    • Tài liệu thiết kế gợi ra câu hỏi "tại sao" về không gian vấn đề
    • Khi prototype hoạt động được, sẽ khó đặt ra những câu hỏi như vậy hơn

  • Nếu mô tả công việc là viết nhiều code để xem cái gì hiệu quả, thì GPT có thể thay thế nhanh hơn và rẻ hơn

    • Đạt được sự đồng thuận về việc nên xây dựng cái gì luôn là một thách thức

  • Hầu như không ai tưởng tượng rằng phát triển phần mềm tuân theo một luồng sạch sẽ và ngăn nắp

    • Viết code giống như viết văn: bản nháp luôn tệ, và bài viết hay là kết quả của rất nhiều lần chỉnh sửa

  • Đã từng thấy code bị chất chồng như một tháp Jenga đến mức không ai muốn động vào

  • Ưa thích quy trình dùng các chuỗi bình luận liên tục để ghi lại các quyết định thiết kế

    • Dùng GitHub issue để thực hiện quá trình này

  • Vẫn đang suy nghĩ về cách tiếp cận này, vì trong trường hợp tệ nhất có thể lãng phí rất nhiều thời gian

    • Việc viết tài liệu thiết kế hữu ích nhất khi đã suy nghĩ đủ sâu về vấn đề để có thể nêu rõ những thuộc tính cần thiết cho cách triển khai đúng đắn
    • Việc triển khai các giải pháp từng phần rồi cải thiện dần cũng đã mang lại thành công