Hội họp do triển khai chậm (2015)

 (tidyfirst.substack.com)
4 điểm bởi GN⁺ 2024-12-23 | 2 bình luận | Chia sẻ qua WhatsApp

Triển khai chậm gây ra cuộc họp

  • Thiết kế phần mềm là một bài tập cho kỹ năng quan hệ con người; các kỹ năng khác dùng trong phát triển phần mềm cũng vậy.
  • Khi một kỹ sư phàn nàn rằng "quá nhiều cuộc họp nên không thể triển khai mã", có thể do giới hạn dung lượng triển khai.
  • Chuck Rossi nhận thấy tại Facebook rằng số lượng thay đổi có thể xử lý trong mỗi lần triển khai là cố định; nếu muốn có nhiều thay đổi hơn, cần nhiều lần triển khai hơn.
  • Trong 5 năm qua, Facebook đã tăng tốc độ triển khai từ mỗi tuần lên mỗi ngày và ba lần một ngày, đồng thời rút ngắn chu kỳ triển khai ứng dụng di động từ 6 tuần xuống 4 tuần rồi 2 tuần.
  • "Thay đổi mỗi lần triển khai" là một chỉ số không co giãn, có thể cải thiện nhưng tốn thời gian. Nếu số thay đổi vượt ngưỡng hiện tại, cần giảm bớt thay đổi.
  • Khi overhead tổ chức tăng, một vòng phản hồi tích cực bắt đầu: khối lượng công việc giảm -> áp lực tăng -> sai sót tăng -> thay đổi mỗi lần triển khai giảm -> overhead tăng -> khối lượng công việc giảm.
  • Để xử lý nhiều thay đổi hơn, cần tăng dung lượng triển khai. Có thể giảm chu kỳ triển khai hoặc tăng số thay đổi mỗi lần triển khai.
  • Nỗ lực giảm overhead có thể cuối cùng dẫn đến các cuộc họp. Điều này ngăn ngừa việc cố gắng triển khai quá nhiều mã.

Thiết kế phần mềm: Tidy First?

  • Thiết kế phần mềm là một bài tập cho kỹ năng quan hệ con người. Việc nâng cao kỹ năng là một trong những cách để cải thiện các mối quan hệ.

Bài viết liên quan

2 bình luận

 
roxie 2024-12-24

Ý kiến này thật hay
 
GN⁺ 2024-12-23
Ý kiến Hacker News

  • Việc cải thiện quá trình kiểm thử và đặc tính tổ chức để giảm rủi ro triển khai rất quan trọng nhưng không phải là cách tiếp cận duy nhất

    • Giảm số lượng thay đổi trong mỗi lần triển khai thường hiệu quả hơn
    • Triển khai những thay đổi nhỏ thường xuyên giúp truyền giá trị nhanh hơn và chấp nhận được những thất bại nhỏ
    • Kết hợp cùng triển khai canary và rollout dần dần khiến việc triển khai không còn là rủi ro lớn
    • Nghiên cứu của DORA, cùng với Accelerate, The Phoenix Project và The Goal, đều ủng hộ cách tiếp cận này

  • Đang cố giải thích khái niệm "software literacy"

    • Nghĩa là khả năng một công ty có thể vận hành bằng mã nguồn
    • Nếu không phải tất cả các nhà ra quyết định đều tập trung vào code thì đó là dấu hiệu thiếu phần mềm tri thức
    • Một công ty cần có thể vận hành dựa trên các khái niệm mới

  • Khi thời gian kiểm thử trong pipeline CI ngày càng dài, quyết định tập trung vào phục hồi

    • Đơn giản hóa kiểm thử và tập trung vào khả năng phục hồi, đồng thời dùng chiến lược triển khai canary
    • Cách tiếp cận này là một trải nghiệm mới

  • Các tổ chức có thể làm cản trở cải thiện triển khai

    • Chiến đấu với quan liêu là gần như không khả thi trong hầu hết các tổ chức
    • Triển khai chậm là một vấn đề, nhưng không phải vấn đề duy nhất

  • Việc test tăng lên vì sợ thay đổi lớn

    • Họp hành có xu hướng trở thành mục tiêu
    • Cần lời khuyên về cách dẫn dắt thay đổi kỹ thuật đối với quản lý không kỹ thuật

  • Câu hỏi về lý do CloudFormation chậm

  • Microservices giúp mở rộng tần suất triển khai theo hướng ngang

  • Hiệu năng phần mềm, hay nói cách khác, hiệu năng con người là rất quan trọng

    • Cần tự động hóa kiểm thử nhanh để lặp nhanh hơn và giảm rủi ro

  • Triển khai nhanh dẫn tới các cuộc họp ứng phó sự cố