Phần mềm được tạo ra giữa các commit

 (zed.dev)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • DeltaDB là một dạng hệ thống quản lý phiên bản mới, quản lý phiên bản cùng lúc cả các cuộc trò chuyện với agent và worktree mà agent đã chỉnh sửa
  • Git được tổ chức xoay quanh từng commit riêng lẻ, nên không được thiết kế để xử lý cùng lúc các cuộc trò chuyện đang tiếp diễn và các thay đổi mã trong lúc mã liên tục thay đổi
  • DeltaDB ghi lại không chỉ commit mà mọi thao tác phát sinh trong quá trình làm việc dưới dạng luồng delta chi tiết, và gán cho mỗi delta một định danh ổn định
  • Tin nhắn và các chỉnh sửa do chính tin nhắn đó tạo ra được ghi lại song song, và nhiều người cùng agent có thể đồng thời chỉnh sửa cùng một tệp trên các máy khác nhau
  • Việc cộng tác có thể diễn ra trực tiếp hơn trong cuộc trò chuyện và ngay bên trong worktree khi mã đang được tạo ra, thay vì qua quy trình review sau khi commit và push

Bối cảnh và vấn đề

  • Đội ngũ Zed không quen với cách làm việc dựa trên pull request, mà đã xây dựng niềm tin và sự thấu hiểu chung bằng cách cùng làm việc trên một worktree và thảo luận ngay trong lúc viết mã
  • GitHub chỉ cho phép thảo luận về mã sau khi đã commit và push, nhưng những cuộc trao đổi quan trọng của đội Zed thường đã kết thúc trước thời điểm đó
  • Zed được khởi động từ năm 2021 để vượt qua các giới hạn của commit, với mục tiêu trước tiên là tạo ra một editor xứng tầm với những lập trình viên giỏi nhất thế giới, rồi từ đó cung cấp cách cộng tác tốt hơn ngay bên trong nó
  • Vấn đề đã được suy nghĩ từ lâu trong bối cảnh cộng tác giữa con người với nhau nay càng trở nên quan trọng hơn khi cộng tác với agent
  • Cuộc trò chuyện tạo ra mã ngày càng trở thành nguồn gốc thực sự của phần mềm, và cuộc trò chuyện đó cần được tham chiếu qua lại với phần mã đang liên tục phát triển và thay đổi
  • Git được tổ chức quanh từng commit riêng lẻ nên không được thiết kế để hỗ trợ sự gắn kết giữa các cuộc trò chuyện liên tục như vậy với các thay đổi của mã

DeltaDB và bước tiếp theo

  • Không phải mọi commit, mà là mọi thao tác

    • DeltaDB chia công việc thành các luồng delta chi tiết; khác với Git lưu snapshot theo từng commit, nó ghi lại mọi thao tác diễn ra giữa các commit
    • Mỗi delta có một định danh ổn định, vì vậy có thể chỉ tới một thời điểm cụ thể trong quá trình tiến hóa ngay cả khi mã vẫn tiếp tục thay đổi
    • Worktree được quản lý phiên bản ngay ở chính quá trình biến đổi của nó, cùng với cuộc trò chuyện dẫn dắt sự thay đổi đó
    • Tin nhắn và các chỉnh sửa do tin nhắn đó tạo ra được ghi lại cạnh nhau, không bị tách rời
    • DeltaDB tích hợp replicated worktree không xung đột, cho phép nhiều người và agent đồng thời chỉnh sửa cùng một tệp trên các máy khác nhau
    • Tệp vẫn là các tệp thực, agent làm việc với tệp qua terminal, và người dùng có thể mount toàn bộ worktree ra đĩa khi cần để dùng các công cụ của mình

  • Mã nguồn giờ là cuộc trò chuyện nguồn

    • Vì tham chiếu được neo vào delta chứ không phải số dòng, nên tham chiếu vẫn được giữ nguyên ngay cả khi đoạn mã bị dịch chuyển xuống dưới
    • Từ bất kỳ dòng nào trong cuộc trò chuyện trước đây, có thể chuyển tới mã ở trạng thái hiện tại hoặc tới phần mã tại thời điểm agent đã viết nó
    • Từ bất kỳ dòng mã nào, có thể tìm lại cuộc trò chuyện đã tạo ra dòng mã đó và mọi cuộc trò chuyện sau này từng tác động vào nó
    • Agent cũng có thể dùng thông tin này để lấy lại ngữ cảnh nền của phần mã mà nó đang chỉnh sửa
    • Agent có thể gọi lại agent trước đó từng làm việc trên đoạn mã đó để hỏi vì sao nó được viết theo cách ấy

  • Không nên phải commit mới có thể cộng tác

    • Mục tiêu là biến cuộc trò chuyện với agent thành cuộc trò chuyện duy nhất cần thiết cho cộng tác
    • Thành viên trong nhóm có thể tham gia khi công việc vẫn đang diễn ra, trò chuyện với agent đã thực hiện công việc và để lại chú thích ngay trong quá trình đó
    • Thành viên nhóm không cần phải chờ commit và push xong mới có thể tham gia
    • Pull request, review thread và inline comment vốn là những thủ tục để gắn lại phần thảo luận vào mã về sau, vì mã và thảo luận nằm ở hai nơi khác nhau
    • Khi mã và thảo luận ở cùng một nơi, những thủ tục đó sẽ biến mất
    • Git và CI vẫn giữ vai trò chạy kiểm tra và kết nối với thế giới bên ngoài, chứ không còn là nơi buộc cộng tác phải diễn ra

  • Bước tiếp theo

    • Phần mềm giờ đây không còn thành hình trong các commit mà trong cuộc trò chuyện
    • DeltaDB là hệ thống quản lý phiên bản cho điều đó, và dự kiến sẽ được cung cấp cho những người dùng đầu tiên trong vài tuần tới
    • Nếu muốn dùng thử sớm, bạn có thể đăng ký danh sách chờ

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Công việc giữa các commit là một mớ hỗn độn nên nhìn vào cũng không hữu ích cho ai. Dùng git rebase để viết lại lịch sử, biến mỗi commit thành nhỏ gọn và có tính nguyên tử, rồi để câu chuyện do các commit tạo ra giải thích vì sao mọi thứ lại thành ra như hiện tại
    Việc thực tế đã diễn ra theo trình tự thời gian nào không quan trọng. Tôi đồng ý rằng review pull request là quá muộn, nhưng vấn đề là pull request được thiết kế để review toàn bộ kết quả của cả nhánh cùng lúc nên rất khó review từng commit riêng lẻ. Giải pháp nên là khuyến khích các commit nhỏ và có tính nguyên tử để có thể review công việc ban đầu trước khi tính năng hay bản sửa lỗi hoàn tất, chứ không phải chia sẻ toàn bộ nhiễu

    • Nhìn vào các bình luận ở đây và mạng lưới nghề nghiệp của tôi, mọi người phần lớn chia làm hai phe. Một phe dùng Git như tự động lưu thô ráp rồi gộp lại khi merge, phe kia thì thích các commit nguyên tử hoàn chỉnh, được sắp xếp gọn gàng
      Theo kinh nghiệm của tôi thì kiểu 1 phổ biến hơn, có thể vì GitHub tự nhiên hỗ trợ cách đó tốt hơn và các commit tích lũy có thể giải quyết một phần vấn đề của kiểu 2. Nếu phải chọn thì tôi thấy kiểu 1 hợp lý hơn nhiều
    • Chẳng phải đây không phải vấn đề của các công cụ như Phabricator hay Gerrit, mà đơn giản là vấn đề của GitHub sao?
    • Dù là mớ hỗn độn hay không, nếu dung lượng đĩa hay chi phí không thành vấn đề thì việc ai đó—có lẽ là agent—xem tôi đã làm gì cũng không sao
      Tôi không quá chắc chắn, nhưng tôi nghĩ agent sẽ thích thông tin bổ sung dù với một số người đó có thể chỉ là nhiễu
    • Tôi đã đoán trước sẽ có phản ứng như thế này. Khi đọc bài, tôi nhớ lại cảm giác thất vọng vì cứ thấy cùng một kiểu cảm xúc mỗi khi người ta nói về quản lý phiên bản
      Quá nhiều người quá dễ dàng vứt bỏ lịch sử chỉ để làm cho nó trông “gọn gàng”. Điều đó không hợp lý, nhưng lại có vẻ đúng theo một kiểu logic rất đặc trưng của một số lập trình viên, và đáng ngạc nhiên là khá phổ biến
      Cách của tôi là commit thường xuyên, hàng chục lần mỗi ngày. Commit là bản ghi về những gì đã xảy ra, và tôi muốn giữ lại càng nhiều bản ghi đó càng tốt. Nhiều lần git bisect đã chỉ ra một commit nhỏ chỉ thay một dòng tưởng như vô hại, và nhờ vậy tìm ra một bug tinh vi chỉ được phát hiện rất lâu sau đó
      Theo tôi, quản lý mã nguồn tồn tại là để tìm ra những thứ như vậy. Nếu phải bới qua mọi dòng trong một commit lớn thì những vấn đề này sẽ đau đớn hơn rất nhiều
      Vì thế tôi thật sự không hiểu khi thấy mọi người cố tình gộp các commit lại thành đúng kích thước của cả PR, rồi vứt bỏ phần duy nhất khiến quản lý phiên bản trở nên hữu ích. Vì cũng có nhiều người cùng phe như bình luận cha, nên kế hoạch lưu lịch sử chi tiết hơn của tác giả có lẽ sẽ là một cuộc chiến không dễ dàng
    • Cách bạn dùng commit nghe khá giống cách tôi dùng stacked PR ở công ty
      Vệ sinh commit tốt thì khó ép buộc ở cấp độ nhóm, nhưng lạ là ở cấp độ PR mọi người lại khá hợp tác trong việc viết mô tả tốt và giữ các nhóm thay đổi gọn gàng

  • Nghe giống kiểu tự động commit thường xuyên với mức độ tin tưởng Git thấp hơn. Git hoàn toàn xử lý tốt việc tự động commit thường xuyên
    Nếu bạn muốn cuộn các auto-commit thường xuyên đó lên thành những commit cấp cao “sạch” hơn mà vẫn giữ được “cuộc trò chuyện” của các auto-commit theo từng thời điểm, thì thỉnh thoảng dùng git merge --no-ff và tập trung vào các commit cấp cao bằng những công cụ như --first-parent thay vì các commit “hội thoại” là được
    Backend của Git vốn đã có rất nhiều tối ưu hóa DB delta trong Git pack và các công cụ khác; nơi thực sự cần chỉnh thêm một chút là frontend Git—chủ yếu là --first-parent—và vô số UI Git kiểu “ưu tiên/chỉ dành cho sơ đồ tàu điện ngầm”. Nhiều người thấy sơ đồ đó xấu, rối và khó chịu, nên cần nhiều UI drill-down tương ứng với --first-parent hơn

    • Tôi cũng làm vậy. Các commit trong nhánh bình thường tôi không xem, nhưng khi cần thì chúng vẫn còn đó. git blame cũng có thể được cấu hình để dùng --first-parent

  • Tôi đồng ý với câu “phần mềm được tạo ra giữa các commit”, nhưng không đồng ý với câu “DeltaDB ghi lại mọi công việc giữa từng commit”
    Trước hết, nó tạo cảm giác xâm phạm. Tôi cũng không muốn một máy quay màn hình chạy 24/7 trong lúc làm việc. Không phải là việc để lộ sai sót của tôi có gì sai, nhưng nếu tôi đang làm việc đúng cách thì giá trị tôi tạo ra được chứa trong các commit, và cách đó tạo cảm giác ít xâm phạm hơn nhiều
    Thứ hai, tôi dùng nhiều công cụ khác nhau, và không muốn tích hợp tất cả chúng vào một DB kỳ quặc nào đó. Nếu đến một thời điểm nào đó mọi thứ chỉ kết thúc bằng “một tiến trình bên ngoài đã làm gì đó”, thì việc ghi lại toàn bộ có ý nghĩa gì? Việc Zed có thể tích hợp nhiều thứ là điểm tốt, nhưng không có nghĩa là tôi sẽ dùng mọi thứ được tích hợp vào Zed. Lần cuối tôi kiểm tra, khi dùng Claude Code qua ACP trong Zed thì thậm chí còn không thể tua ngược để sửa các tin nhắn cũ
    Cuối cùng, cá nhân tôi nghĩ chúng ta đã đánh mất bản chất của commit. Phần lớn mọi người tạo ra một nhóm thay đổi tùy ý với kích thước không giới hạn rồi chạy git commit, sau đó nhóm thay đổi đó được review như một khối khổng lồ và các commit lại bị gộp vào nhau. Không phải tận thế, nhưng những commit được nhào nặn cẩn thận bằng tay thực sự rất tuyệt. Chỉ cần chạy git blame trong một dự án bắt buộc cách làm đó là bạn sẽ hiểu ngay tôi muốn nói gì
    Những thứ như DeltaDB chỉ càng củng cố và làm cố định thêm thói quen gộp commit cẩu thả. Nếu muốn biết chuyện gì đã xảy ra thì giờ người ta chỉ cần soi mói phát lại cuộc trò chuyện giữa người dùng và LLM là xong
    Điểm cuối cùng này vừa thú vị vừa gây bực bội. Trước đây không thể thuyết phục mọi người ghi lại thay đổi và động cơ chỉ vì đó là thực hành kỹ thuật tốt giúp ích cho đồng đội, nhưng giờ ai cũng sẵn sàng giải thích cho LLM. Phần lớn là vì LLM cần điều đó để làm việc, nhưng vẫn rất thú vị khi thấy người ta làm bao nhiêu điều trước đây không làm chỉ để làm hài lòng LLM. Đột nhiên những thứ kỳ lạ vốn chẳng hề được ghi chép lại nay lại được ghi vào CLAUDE.md

  • Đoạn mã tôi viết giữa các lần commit chính là quá trình tư duy của tôi. Tôi suy nghĩ bằng cách viết code, xóa đi rồi viết lại
    Phần code được đưa lên trong commit là thứ được viết để người khác có thể hiểu, và là kết quả của quá trình viết ra để suy nghĩ. Tôi không muốn suy nghĩ của mình bị tuần tự hóa, bị quản lý phiên bản và trở nên có thể truy cập công khai
    https://www.nature.com/articles/s44222-025-00323-4

    • Tôi cũng có cùng vấn đề với JJ. Tôi không muốn mọi thứ giữa các lần commit đều bị quản lý phiên bản
      Tôi cũng không chắc mọi trạng thái trung gian giữa các lần commit đều có liên quan hay hữu ích. Nhưng có cảm giác như tôi thuộc phe thiểu số
    • Vì vậy tôi dùng rebase trước khi mở PR, và ghét squash. Hai năm sau bạn sẽ không nhớ vì sao mình viết code theo cách đó, và để hiểu bug cũng như nhận ra tình huống hàng rào của Chesterton, thứ duy nhất còn lại chỉ là delta và lịch sử commit
      Nếu squash lại thì bối cảnh duy nhất còn lại là 400 dòng code bạn đã viết “một phát” cùng với feature request mà đoạn code đó được giao. Chẳng giúp ích gì cả
      Người tệ nhất tôi từng gặp là kiểu viết cả một module mới mà không check in gì cho tới khi nó chạy được ở mức nào đó. Có vẻ điều đó cũng liên quan tới cái tôi mong manh khiến họ lặng lẽ sửa bug trong code của mình mà không nói ra trước. Anh ta viết thứ code khó hiểu đúng kiểu định luật của Kernighan lộ rõ, và lẽ ra phải có thêm 10 năm kinh nghiệm nữa mới nên làm trò đó. Anh ta còn khoe code của mình là “mạnh mẽ”, mà đó không phải lời khen, đó là điềm báo. Tôi đã nhiều lần tìm ra bug từ code ở các commit ban đầu. Thật lòng chỉ mong người ta để lại thứ gì đó
      Bạn không cần phải thú nhận rằng mình đã thử đủ mọi cách cho tới khi tìm ra vấn đề. Sau khi biết có thể đi tới điểm B, bạn chỉ cần dựng lại câu chuyện mong muốn từ A tới B. Hãy sắp xếp lại các commit theo cách bạn lẽ ra đã viết nếu ngay từ đầu đã biết chính xác phải làm gì. Có thể vứt bỏ 90% đoạn code viết ra rồi xóa ngay, hoặc bất cứ thứ gì không nâng đỡ cho câu chuyện đó
      Trong thực thi pháp luật có khái niệm dựng lại song song. Bạn có thể biết nghi phạm có tội nhờ những sự thật không được phép dùng ở tòa, nhưng vẫn phải khám phá lại cùng những sự thật đó theo đúng thủ tục. Kiểu như giữ lại rác vào ngày xe rác tới, phỏng vấn hàng xóm, gom đủ chứng cứ tình huống để xin lệnh khám xét rồi tìm lại chứng cứ đó
    • Có vẻ chủ yếu họ đang nghĩ tới AI agent. Đây là một ý tưởng thú vị mà tôi từng thấy trước đây, và việc ai cũng muốn tái phát minh thứ gì đó cho AI cũng khá buồn cười
      Nhưng tôi khá hoài nghi vì thấy chỉ cần tạo một file văn bản rồi chèn tham chiếu commit vào là được mà. Tôi cũng không hiểu vì sao không thể dùng Fossil. Nó là cơ sở dữ liệu SQLite nên vốn đã có thể gói những gì bạn muốn vào đó, và tích hợp sẵn đủ loại tính năng có thể tham chiếu commit
    • Tôi hoài nghi về phần cộng tác, nhưng nghe có vẻ là tính năng dành cho khách hàng doanh nghiệp nên tôi hiểu chủ đích
    • Hoàn toàn đồng ý. Cảm giác bị giám sát rất khó chịu. Đặc biệt là đoạn “DeltaDB chia nhỏ công việc thành một luồng delta chi tiết. Trong khi Git chụp snapshot của từng commit, DeltaDB ghi lại toàn bộ công việc ở giữa và gán cho mỗi phần một định danh ổn định”
      Tôi từng định thử Zed vì nghe nói nó đã có keymap emacs, nhưng giờ thì thôi. Đây là tính năng xâm phạm quá mức một cách khủng khiếp, và tôi hoàn toàn không muốn đồng nghiệp xem lại mọi chỉnh sửa trung gian dẫn tới commit tôi công khai để review, ở cấp độ từng phím bấm
      Trước khi mở PR, đôi khi tôi chỉnh sửa lại lịch sử commit trong magit một chút để nó tuyến tính hơn và dễ tiêu hóa hơn. Chẳng hạn sửa phần mô tả hoặc gộp các commit liền kề. Nhưng tính năng này quăng nguyên một khía cạnh của công việc đó đi, rồi bảo rằng: “Này đồng nghiệp, hãy hút vòi cứu hỏa delta này và tận hưởng đi”
      Câu “Điều chúng tôi thực sự muốn rất đơn giản. Cuộc trò chuyện với agent sẽ trở thành cuộc trò chuyện duy nhất bạn cần” rốt cuộc có nghĩa là gì vậy. Không, sai rồi

  • Tôi thấy khó chịu trong bụng vì có cảm giác việc Anthropic hoặc OpenAI thâu tóm Zed là điều không thể tránh khỏi. Ý tưởng thì quá hay và phần mềm cũng quá tốt

    • Bộ harness để coding của Zed tốt hơn Claude Code rất nhiều, nhưng vì nó dùng trực tiếp Claude API nên đắt hơn nhiều. Nếu được đưa vào cùng một dòng sản phẩm thì nó có thể trở thành thứ định nghĩa luôn cả một hạng mục sản phẩm
    • Sao lại dừng ở Zed? 1 nghìn tỷ USD tiền đầu tư mà các công ty AI huy động được trên danh nghĩa là cho trung tâm dữ liệu, nhưng khi chi phí tăng lên và tiến độ hoàn thiện vượt quá phạm vi của kế hoạch kinh doanh thông thường, thì dùng số tiền đó vào chỗ khác sẽ hiệu quả hơn. Với 1 nghìn tỷ USD thì muốn mua gì cũng được
    • Nơi Anthropic hay OpenAI đang hướng tới dường như sẽ không còn editor nữa. Cá nhân tôi muốn có công cụ đọc mã tốt hơn ở chế độ chỉ đọc, hoặc sự trở lại của UML

  • Hiện giờ có rất nhiều startup giai đoạn đầu đang cạnh tranh trong lĩnh vực này. Trong vài tuần gần đây khi đi phỏng vấn, tôi đã nói chuyện với ít nhất hai nơi như vậy
    Để những công cụ này thực sự đứng vững và thành công ở quy mô lớn thì cạnh tranh sẽ rất khốc liệt. Tuy vậy, tôi vẫn không xua đi được cảm giác rằng tất cả những thứ này dường như mở đường cho mức độ giám sát nhà phát triển khiến tôi cực kỳ khó chịu

    • Nếu một quản lý dành toàn bộ thời gian để quan sát mọi phím bấm của tất cả lập trình viên dưới quyền mình, thì hẳn là họ chẳng có việc thực sự nào để làm và cũng chẳng có vấn đề kinh doanh nào đáng để bận tâm

  • Commit hữu ích vì đã được dọn dẹp trước. Quá trình thử và sai ở giữa là nơi để thử thứ gì đó rồi xóa đi những ngõ cụt, và phần lớn nên bị vứt bỏ
    Nếu lưu lại mọi thay đổi và mọi tin nhắn của agent thì chỉ khiến đống rác đó tồn tại mãi

  • Google có lẽ đã làm việc này từ khoảng 10 năm trước với citc. Tôi không biết khi nào Gemini thực sự sẽ tận dụng điều đó, nhưng Google về cơ bản đã nắm gần như toàn bộ lịch sử của hầu hết mọi lập trình viên ở cấp độ Ctrl-S trong ít nhất 10 năm qua
    Nếu Gemini trông vẫn ngu ngốc lúc này, thì chỉ là vì họ đang tiết kiệm trong việc phân bổ tài nguyên tính toán mà thôi
    0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

  • Ở đây tôi không hiểu đề xuất giá trị là gì. Tôi đã thấy nhiều công ty đề xuất đại loại những tính năng như thế này, nhưng chưa nơi nào đưa ra được lý do đủ thuyết phục rằng công nghệ này cần phải tồn tại

    • Thật thú vị khi trải nghiệm và quy trình làm việc của bạn khác tôi đến vậy. Đây là tính năng được quảng bá là giải quyết một vấn đề có thật mà tôi gặp hằng ngày
      Công ty chúng tôi làm việc hoàn toàn từ xa, và phần lớn đồng nghiệp không sống gần tôi. Mỗi ngày chúng tôi gọi video vài lần, nhưng chủ yếu giao tiếp qua Slack
      Chúng tôi cũng đang ở khá phía trước trên đường cong áp dụng tác nhân LLM để viết mã tốt. Nhờ các mô hình tốt và các cơ chế bảo vệ rất tốt của một coding harness cụ thể, dạo này LLM viết phần lớn mã của chúng tôi
      Một ngày điển hình là tôi lấy một ticket, chỉ cho LLM và bắt đầu cùng nó giải quyết vấn đề. Chúng tôi đưa ra quyết định kiến trúc, lập kế hoạch và thực thi. Tính năng tôi triển khai gần đây nhất có chi phí token là 19 đô la, và lúc đang chạy mạnh thì LLM đã tiếp tục làm việc khoảng 30 phút mà không cần tôi nhập gì
      Chỉ khi không chắc hướng nào tốt hơn, tôi mới đăng câu hỏi vào chat nhóm để xin ý kiến đồng nghiệp. Nhưng nhiều ticket được hoàn thành hoàn toàn tự chủ
      Sau đó tôi mở PR và đăng liên kết PR lên Slack để xin review, và đó là lúc đồng nghiệp lần đầu nhìn thấy phần triển khai. Đôi khi họ có câu hỏi. Vì bình luận GitHub không hợp cho các cuộc trao đổi nhanh theo thời gian thực, họ thường hỏi trong thread Slack thay vì bình luận trên PR
      Câu trả lời cho những câu hỏi đó có trong lịch sử chat với LLM trên laptop của tôi, nhưng không có cách nào dễ dàng để cho đồng nghiệp xem. Vì thế tôi phải chơi trò tam sao thất bản: sao chép câu hỏi của đồng nghiệp từ Slack sang cuộc chat với LLM, rồi dán ngược câu trả lời trở lại
      Ý tưởng rằng đồng nghiệp, LLM và tôi có thể cùng tham gia vào một cuộc trò chuyện dễ dàng hơn là điều rất hấp dẫn
      Điều đó không có nghĩa là hướng đi của đội Zed là đúng, và cũng có thể đội chúng tôi sẽ tốt hơn nếu làm việc theo cách khác. Nhưng cách tiếp cận hiện tại đang “thành công” đến mức không có nhiều áp lực ở cấp tổ chức để thay đổi

  • Công việc của một đội phần mềm là cùng nhau học ra các mô hình hoạt động hiệu quả trong một miền nào đó. Chúng tôi biểu đạt các mô hình và bài học đó bằng mã, kiểm thử và tài liệu liên quan
    Vì vậy, một mặt tôi hoàn toàn đồng ý rằng pull request và code review đang làm tổn hại nghiêm trọng quá trình này, nhưng mặt khác tôi lại chùn lại trước ý tưởng lập tức tạo thêm các thủ tục và đầu ra thứ cấp khác chỉ để khiến chúng tôi phân tâm thêm. Tất cả những điều đó lẽ ra phải bộc lộ trong codebase
    Chứ không phải ở một thứ tách rời. Không phải trong commit message hay một chồng ADR. Nếu codebase không thể tự mình giải thích đầy đủ cái gì và tại sao cho cả con người lẫn AI, thì đó là một thất bại, và chúng ta sẽ dành cả đời để tạo thêm quy trình nhằm quản lý thất bại đó

    • Phân nhánh rẻ cho tính năng và thử nghiệm, khả năng nhanh chóng hoàn tác một commit cụ thể, và việc đọc commit message của lần cuối cùng một dòng mã được thay đổi đều cực kỳ quan trọng, và đó là những gì hệ thống quản lý phiên bản phân tán đã làm được
      Chỉ trạng thái mã hiện tại thôi thì không đủ cho phát triển phần mềm hiện đại