Kỹ sư không được phép mắc sai lầm kiểu startup khi xây dựng Ledger

 (news.alvaroduran.com)
1 điểm bởi GN⁺ 2024-11-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong fintech xử lý tiền thật, chênh lệch chỉ vài cent cũng có thể phá vỡ niềm tin của người dùng, và một startup giao dịch cổ phiếu đã ghi nhận giao dịch theo kiểu single-entry nên gặp vấn đề dancing cents
  • Sổ cái single-entry chỉ lưu lại tiền vào và tiền ra, nên khó truy vết nguyên nhân tạo ra chênh lệch như ngoại hối, cơ chế rounding to even của broker hay phí FINRA TAF
  • Sổ cái double-entry xem tiền luôn di chuyển từ tài khoản này sang tài khoản khác, và tách riêng Accounts, Entries, Transactions để ghi lại cả nguồn lẫn đích
  • Nếu xác định rõ trạng thái pending, discarded, posted của Entries và điều kiện ghi sổ của Transactions, có thể xử lý an toàn hơn các lỗi thất bại từng phần và compensating Entries
  • Ledger vừa là giao diện cho báo cáo kế toán vừa là system of record giữ cho tiền nhất quán, nên khi mở rộng sẽ phát sinh căng thẳng giữa tính sẵn sàng và tính nhất quán mạnh

Vài cent chênh lệch đã làm sụp đổ niềm tin người dùng

  • Một startup xây dựng nền tảng giao dịch cổ phiếu đã làm theo nguyên tắc “make it work, make it right, make it fast” nên không xây dựng hệ thống kế toán double-entry ngay từ đầu
  • Ngay sau khi ra mắt, số tiền mà nhà cung cấp ghi nhận và số tiền mà hệ thống nội bộ ghi nhận bị lệch vài cent
    • Nội bộ gọi đây là dancing cents
    • Người dùng mua 5 đô la cổ phiếu Apple nhưng nếu đơn hàng hiện 4,98 đô la thì sẽ lập tức liên hệ bộ phận hỗ trợ
  • Bản chất vấn đề không nằm ở số tiền thất thoát mà ở niềm tin và tăng trưởng
    • Người dùng tức giận sẽ không giới thiệu dịch vụ, khiến startup bị chặn đà tăng trưởng
    • CEO chỉ đạo bộ phận hỗ trợ khách hàng bồi hoàn thủ công vài cent nếu có giao dịch sai
    • Họ còn tạo cả bot Slack để xử lý việc này

Tiền không chỉ theo dõi số dư hiện tại mà còn cả giá trị trong tương lai

  • Ledger là hệ thống theo dõi tiền
  • Tiền không chỉ là số dư hiện tại mà còn cần để biểu diễn giá trị sẽ nhận được hoặc sẽ phải trả trong tương lai
    • Về mặt khái niệm, tiền là tài sản tương lai
  • Nếu chỉ ghi nhận vào/ra như “người dùng đã trả 5 đô la”, “người dùng đã trả 6 đô la” thì không đủ để giải thích dòng chảy tài chính thực tế
  • Chuyển khoản ngân hàng chậm theo tiêu chuẩn Internet, và nhiều ngân hàng chỉ quyết toán chuyển khoản vào ngày làm việc tiếp theo
    • Khi thanh toán hoàn tất, ta có cơ sở tin rằng cuối cùng sẽ nhận được tiền
    • Nhưng cổ phiếu thì phải mua qua broker ngay bây giờ
    • Cần đồng thời biểu diễn khoản pending sẽ được quyết toán sau vài ngày và khoản tiền đi ngay tới broker
  • Với cách single-entry, khi xảy ra lỗi thì rollback cực kỳ khó, và trong một số corner case thậm chí không thể thử rollback

Vì sao sổ cái single-entry cản trở việc debug

  • Sổ cái single-entry có thể cho thấy dòng tiền, nhưng không thể giải thích vì sao nó xảy ra
  • Muốn tìm nguyên nhân của một lần dịch chuyển tiền cụ thể thì phải nối dữ liệu từ nhiều model khác nhau, và có trường hợp ngay cả như vậy cũng không thể làm được
  • Sổ cái double-entry ghi lại đồng thời điều gì đã xảy ra và vì sao nó xảy ra
    • Mọi dịch chuyển tiền đều diễn ra từ tài khoản này sang tài khoản khác
    • Mỗi cent được ghi rõ rời khỏi tài khoản nào và đi vào tài khoản nào
  • Vấn đề dancing cents rất khó giải quyết trong hệ thống single-entry
  • Nếu không hiểu hệ thống vận hành ra sao thì cũng khó loại bỏ bug

Mô hình dữ liệu Ledger: Accounts, Entries, Transactions

  • Nhiều kỹ sư khi bắt đầu theo dõi tiền thường đặt số tiền ngay trong domain model
    • Ví dụ đặt thuộc tính price trong Order hoặc cột amount trong bảng expenses
    • Đây là cách tiếp cận balance as property
  • Cách này chạy nhanh ở giai đoạn đầu, nhưng theo thời gian báo cáo sẽ phức tạp và chậm hơn, còn xử lý thanh toán và phân tích cũng trở nên khó khăn
    • Nếu job báo cáo ban đêm mất nhiều giờ thì cách tiếp cận này có thể là nguyên nhân gốc rễ
  • Tốt hơn nên xem Ledger là một mô hình dữ liệu riêng biệt có thể suy ra mọi giao dịch tài chính trong hệ thống
  • Ba thực thể tạo nên cấu trúc cơ bản
    • Accounts: các bucket giá trị và cũng là góc nhìn để xem giá trị thay đổi thế nào theo thời gian
    • Entries: dòng tiền giữa các tài khoản, luôn biểu diễn sự trao đổi giá trị
    • Transactions: đơn vị đảm bảo các Entries được ghép cặp và xử lý đúng cách

Trạng thái và tính bất biến của Entries

  • Entries có thể có ba trạng thái: pending, discarded, posted
  • Entry luôn được tạo ở trạng thái pending
    • giá trị được trao đổi
    • hướng là credit hoặc debit
    • thông tin account được tham chiếu
  • Biểu diễn hướng của số tiền bằng số dương và số âm là một lỗi phổ biến
  • Entries về cơ bản là bất biến, nhưng một pending Entry có thể bị discarded để tạo ra posted Entry
  • Một lựa chọn khác là tạo reversal Entry để đảo lại pending Entry
    • Tuy nhiên cách reversal Entry có thể làm lịch sử của tài khoản trở nên lộn xộn
    • Nếu dùng trạng thái discarded, khi xem Entries hiện tại chỉ cần loại bỏ các mục có discarded_at được thiết lập mà vẫn không mất lịch sử
  • Trong hệ thống double-entry, tổng các credit Entries chưa bị discarded bằng tổng các debit Entries chưa bị discarded
    • Về mặt khái niệm, dù bạn chuyển tiền giữa các túi theo cách nào thì tổng số tiền vẫn như nhau
  • Một số tài khoản đặc biệt đại diện cho thế giới bên ngoài và được gộp vào Profit and Loss statement có thể là ngoại lệ, không cần cân bằng

Transactions và xử lý lỗi thất bại từng phần

  • Entries được tạo thành từng cặp, và Transactions đảm bảo quá trình đó diễn ra đúng như dự định
  • Transaction chỉ được posted khi các Entries liên kết ở trạng thái posted hoặc discarded và đã được thay thế bằng posted Entries
  • Một Transaction bị lỗi từng phần có thể được đảo ngược về mặt ngữ nghĩa bằng compensating Entries
  • Cách tiếp cận này rất phù hợp với Saga pattern
    • Saga đánh đổi tính nguyên tử để lấy tính sẵn sàng
    • Thay vì các transaction chậm phải khóa nhiều bảng, quy trình được chia thành các tác vụ nhỏ hơn và các checkpoint trung gian
    • Trong lúc đó các transaction khác vẫn có thể hoạt động nên thông lượng tốt hơn

Accounts và normal balance

  • Từ góc nhìn của một Account riêng lẻ, Ledger trông giống như một hệ thống single-entry
    • Một Account có quan hệ một-nhiều với nhiều Entries
    • Tổng số dư phải khớp với giá trị được tổng hợp từ số dư riêng của các Entries liên kết
  • Cách tính tổng thay đổi tùy theo normal balance của Account
  • Gắn dấu dương/âm trực tiếp vào số tiền của Entry là điều nên tránh về mặt kế toán
    • Có tài khoản mà net credit là trạng thái bình thường, và có tài khoản mà net debit là trạng thái bình thường
    • Ví dụ tài khoản tiền mặt ngân hàng có thể bình thường là net debit, nhưng nếu bị thấu chi thì có thể thành số âm
  • normal credit balance nghĩa là trạng thái bình thường khi tổng credit Entries liên kết lớn hơn tổng debit Entries
  • normal debit balance thì ngược lại

Căng thẳng giữa hệ thống kế toán và hệ thống kỹ thuật

  • Trong Ledger có hai hệ thống cùng tồn tại với các yêu cầu khác nhau
    • Accounting system: giao diện của Ledger nhìn từ bên ngoài
    • Engineering system: phần triển khai nơi Ledger tự nhìn chính nó
  • Accounting system phơi bày dữ liệu đã được tổng hợp từ nhiều góc nhìn
    • Reporting
    • Financial ratios
    • Business Intelligence
  • Engineering system phải đảm bảo tính nhất quán và độ chính xác của dữ liệu
    • Trong công ty fintech, Ledger đóng vai trò source of truth giống như CRM của đội bán hàng
  • Lý do Ledger khó mở rộng là vì yêu cầu của hai hệ thống này khác nhau
    • Accounting system đòi hỏi tính sẵn sàng cao và độ trễ thấp
    • Engineering system đòi hỏi tính nhất quán mạnh và kiểm tra schema-on-write

Tài liệu kế toán để lập trình viên tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-30
Các ý kiến trên Hacker News

  • Muốn nói thử điều đó với các khách hàng của Synapse. Hàng triệu đô la đã biến mất
    Ngân hàng phải đối soát sổ sách theo các quy tắc nghiêm ngặt để biết tiền đã đi đâu, nhưng fintech thường đặt sổ cái riêng của mình lên trên một hoặc vài tài khoản FBO cơ sở gom tiền của khách hàng, để theo dõi số dư của từng khách hàng. Trong trường hợp của Synapse, tổng số dư khách hàng trên sổ cái riêng của họ lớn hơn rất nhiều so với số dư thực tế trong các tài khoản FBO
    Nhiều người nghi ngờ có gian lận, nhưng tôi sẽ đặt cược rằng đó chỉ là một sổ cái lộn xộn và đầy lỗi. Sau khi nhìn vào bên trong, có lẽ tôi sẽ không bao giờ gửi tiền vào tài khoản tiền gửi fintech nữa; dùng ngân hàng thật vẫn tốt hơn. Dù fintech quảng bá rằng tiền gửi được bảo hiểm FDIC, điều đó chỉ bảo vệ khi ngân hàng nền tảng phá sản, chứ không bảo vệ trường hợp fintech không còn theo dõi được tiền của tôi
    Tham khảo: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • 90 triệu đô la biến mất và 250 triệu đô la bị đóng băng. Phần lớn số tiền đó có thể là tiền mà ai đó cần để trả tiền thuê nhà
      Andreessen Horowitz đã đầu tư, và họ là bên theo kiểu chiến tranh tổng lực chống lại mọi quy định của chính phủ
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • Khi làm ở một công ty lớn, từng có chuyện tiền xuất hiện hoặc biến mất từ hư không vì thiếu nhất quán giữa các hệ thống giao dịch
      Trước đó tôi đã dự đoán rằng codebase quá lộn xộn nên sẽ không thể theo dõi đúng những việc này, và đã tranh luận với sếp, người tin rằng mọi thứ vận hành như phép màu. Vài ngày sau, tôi nhận được email nói rằng một cuộc kiểm toán về sai lệch kế toán sắp bắt đầu
      JPMC từng đề xuất dùng tiền mã hóa để quản lý nhất quán luồng tiền nội bộ, nhưng tôi không biết thực tế họ đã đi đến đâu
    • Synapse nói rằng lỗi kế toán thực sự nằm ở phía ngân hàng Evolve. Bao gồm các giao dịch bị thiếu, các khoản ghi nợ không được báo cáo, và việc khi gửi các giao dịch đang xử lý sang Mercury thì lại trừ sai ở phía Synapse
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • Tôi từng bị mất tiền trong tài khoản HSBC. Đó là một khoản thanh toán giữa hai tài khoản, nhưng bút toán kép lệch một khoản nhỏ, và trên sổ sách không thể đối chiếu dễ dàng
      Tôi đã tranh cãi một thời gian, nhưng họ không thừa nhận đúng mức cũng không sửa. Tôi từng nghi ngờ không có bằng chứng rằng có thể là một vụ trộm tinh vi nội bộ, nhưng bất tài có lẽ là lời giải thích hợp lý hơn
    • Các tổ chức ngân hàng thực sự cũng đáng lo không kém. Ví dụ Vanguard đã thuê ngoài phần lớn công việc phát triển sang Ấn Độ vài năm trước
      Một người bạn từng làm quản trị hệ thống ở BoA nói rằng họ phải lưu một số log nhất định trong 7 năm, nhưng khi đĩa bắt đầu đầy thì họ cứ xóa đi

  • Một trong những điều tôi mất thời gian để hiểu khi bắt đầu làm ở Google là việc đánh đổi độ tin cậy hoặc độ chính xác để lấy khả năng mở rộng
    Trước đó tôi từng xây dựng hệ thống tính phí hoặc các ứng dụng web OLTP quy mô nhỏ, và chưa bao giờ nghĩ đến những câu hỏi như mức mất dữ liệu có thể chấp nhận hay tỷ lệ lỗi khác 0. Điều gây sốc hơn cả việc khi xử lý hàng triệu request mỗi giây thì một số sẽ thất bại, là sự khác biệt trong thái độ kỹ thuật
    Ngay lúc này, có thể có khoảng vài nghìn người mở Gmail nhưng không tải đúng, hoặc nhận lỗi 500. Không ai truy tìm nguyên nhân, vì người dùng sẽ bấm refresh rồi tiếp tục ngày của họ. Ngược lại, dù độ bền lưu trữ đạt con số ấn tượng 99,99999% mỗi năm, nếu có 2 tỷ khách hàng thì 200 người sẽ có một ngày thật sự tệ hại
    Sự chuyển đổi từ thói quen điều tra mọi lỗi trong log sang cách nghĩ rằng mọi thứ luôn hỏng một chút, và trước khi sửa gì đó thì phải tính chi phí trước, khá là gây sốc

    • Mức độ bền thấp như vậy giờ không còn là mức hiện đại nữa
      Một kinh nghiệm thực tế tôi thấy nhiều ở quy mô tương tự là đặt mục tiêu 1 vụ mất dữ liệu trong 100 năm trên toàn bộ hạ tầng. Thông thường chi phí tăng thấp hơn nhiều so với 10%, nhưng cần có người hiểu tổ hợp học khi thiết kế thuật toán bố trí dữ liệu
      Nếu cần hiểu lĩnh vực này, bài báo copyset là một điểm khởi đầu tốt
    • Nói như vậy nhìn chung là đúng, nhưng tôi cũng thường thấy chiều ngược lại. Đặc biệt là những người xuất thân từ các công ty mạng xã hội, vốn có cảm giác rất lỏng lẻo về thất bại, chuyển sang làm ứng dụng tài chính; nhìn chung kết quả không tốt
    • Khi còn ở Google, tôi từng được biệt phái sang nhóm Android để làm về đồng bộ danh bạ. Vấn đề tôi gặp là một tình huống cực kỳ hiếm, và khi lấy dữ liệu tổng hợp production ra xem thì có vẻ sẽ ảnh hưởng đến 0,01% người dùng
      Khi trình bày giải pháp và nói về tỷ lệ lỗi này, tôi bị hỏi 200.000 người dùng Android đó sẽ khôi phục bằng cách nào. Vì không có cách khôi phục và đồng bộ danh bạ sẽ đơn giản là hỏng, tôi được bảo phải thiết kế lại
      Chính các con số khiến người ta khiêm tốn. Chắc chắn có những lĩnh vực mà 99,99% là đủ, nhưng cũng có rất nhiều lĩnh vực mà như vậy là chưa đủ

  • Những việc như thế này sẽ dễ hơn nếu tuyển đúng người ngay từ đầu. Không thể tuyển cả đống chuyên gia LeetCode rồi không hỏi liệu họ có thể thực sự xây dựng thứ bạn muốn xây dựng hay không, ngoài khả năng nghĩ ra cấu trúc dữ liệu và thuật toán trong đầu
    Nếu mọi người biết phải xây dựng thứ đó như thế nào, thì không cần hy sinh tăng trưởng, và nó sẽ được làm đúng ngay từ đầu
    Đôi khi bạn cần những kỹ sư có nền tảng đào tạo khác, như kế toán, tài chính, sinh học. Phần quan trọng nhất trong sự nghiệp của tôi là hiểu sâu ngành của thứ mình đang xây dựng, và quen biết các chuyên gia trong lĩnh vực đó, những người có thể đặt ra những câu hỏi thật sự quan trọng. Đó mới là giải quyết vấn đề và kỹ thuật; phần còn lại là lập trình/coding

    • Đây là lần đầu tôi thấy một bài trên HN mô tả đời sống hiện tại của mình chính xác đến đáng sợ như vậy, mà tôi lại hoàn toàn đồng ý
      Phần lớn sự nghiệp của tôi nằm ở vùng giao nhau giữa công nghệ và tài chính, chủ yếu là tuân thủ thuế bán hàng/thuế sử dụng. Trong quá trình đó, tôi đã không nhận ra đầy đủ các kế toán viên, controller và luật sư đã ảnh hưởng đến mình nhiều đến mức nào
      Gần đây tôi tư vấn cho hệ thống sổ cái của một startup khá lâu đời, và đã kinh hoàng khi thấy hệ thống kế toán trông như thế nào khi được xây bởi các kỹ sư không có nền tảng tài chính hay kế toán
      Không cần phải tìm một người vừa là kế toán vừa là kỹ sư như có phép màu. Chỉ cần để một kế toán thực thụ ngồi cạnh đội kỹ thuật trong quá trình thiết kế là đủ. Sau khi hoàn tất thiết kế đại tu tổng thể, tôi nhờ một người bạn CPA rà soát toàn bộ; họ tìm thấy lỗ hổng trong vài kịch bản, nhưng nhìn chung là ổn
      Tiền là một bài toán kỹ thuật khó. Vì tiền kéo theo đủ mọi sự kỳ quặc của con người xung quanh nó
    • Đúng vậy. Sổ cái là kiến thức miền. Mọi thứ khác, kể cả tối ưu hóa tải cao, phải được xây trên nền đó
    • Trong một số nhóm có xu hướng khó chịu là tin rằng công nghệ có thể giải quyết mọi vấn đề. Vì quá đề cao đổi mới hơn mọi thứ khác nên họ tránh xa chuyên gia

  • Điều này một lần nữa xác nhận tầm quan trọng của kiến thức miền trong lãnh đạo kỹ thuật. Nếu làm ở công ty tài chính, bạn phải hiểu tài chính ở một mức nào đó để đưa ra quyết định kỹ thuật và đánh đổi đúng; báo chí hay thương mại cũng vậy
    Những tổ chức thành công mà tôi từng làm việc luôn đưa các câu hỏi phi kỹ thuật đặc thù miền vào phỏng vấn đội kỹ thuật. Ngược lại, một số đội rất giỏi về kỹ thuật lại loay hoay vì thiếu insight về miền

    • Tôi là kỹ sư phần mềm đồng thời là CPA, nên có kiến thức miền. Nhưng tôi không biết phải tìm công việc áp dụng nó như thế nào
      Nhìn đâu cũng có vẻ họ thích một người có gấp đôi kinh nghiệm kỹ sư phần mềm, dù hoàn toàn không có kiến thức miền, hơn là tôi với kinh nghiệm kế toán và kinh nghiệm kỹ sư phần mềm tương đối ngắn. Tôi tự hỏi có cách nào tận dụng điều này hiệu quả không
    • Tôi đồng ý với tinh thần đó, nhưng sẽ hữu ích hơn nếu coi những câu hỏi đặc thù miền như câu hỏi kỹ thuật thuộc một lĩnh vực kỹ thuật khác
      Tài chính cũng mang tính kỹ thuật, cơ khí cũng mang tính kỹ thuật, và quản lý thể thao hay xã hội học cũng có thành phần kỹ thuật lớn. Khi nhìn rộng hơn về năng lực kỹ thuật là gì, ta sẽ có sự khiêm tốn cần thiết để cộng tác ở nhiều miền khác nhau
    • Sau khi bắt đầu làm việc ở một công ty bảo hiểm, tôi nhận ra rằng hiểu ngành bảo hiểm còn khó hơn nhiều so với hiểu codebase. Nếu codebase hoạt động kỳ lạ, ít nhất bạn còn có thể lần theo bằng debugger
    • Tôi không chắc lắm về điều đó. Tôi luôn hiểu rằng việc nắm toàn bộ kiến thức miền là vai trò của product manager
      Việc của PM là cùng engineering xác nhận rằng yêu cầu là đúng và sản phẩm được xây ra đáp ứng các yêu cầu đó. Trong môi trường agile, những cuộc trao đổi và kiểm chứng như vậy diễn ra mỗi sprint, nên khó có chuyện một thứ gì đó lọt qua quá lâu mà không được sàng lọc
      Nếu không có PM thì đội engineering cần kiến thức miền sâu, nhưng nếu có thì đó không phải trách nhiệm của engineering. Đó là trách nhiệm của tổ chức sản phẩm

  • Kể một chuyện cũ: tôi chưa từng xây hệ thống ghi sổ kép, nhưng nhiều thập kỷ trước tôi từng xây hệ thống tính phí tại một startup internet/viễn thông có doanh thu tăng lên 8 chữ số
    Khi còn là lập trình viên trẻ, tôi không biết nhiều, và tình cờ ngay từ ngày đầu đã được giao xây logic tính phí; tốt hay xấu thì tôi đã xây nó ở hai nơi trong hệ thống. Một là trang web tính phí dành cho người tiêu dùng, hai là một tiến trình backend riêng tạo hóa đơn và thực hiện thanh toán thẻ tín dụng
    Việc giữ cho hai bên khớp nhau khó đến đáng ngạc nhiên. Chúng tôi liên tục lặp lại để đốt vốn và tìm phản ứng thị trường, rồi cứ thêm sản phẩm và dịch vụ mới, cách giảm giá/định giá mới, tính phí theo mức sử dụng, tính phí hằng tháng, miễn phí X lần đầu, người trả tiền chính/tài khoản con cho tài khoản doanh nghiệp, cost center do người dùng chỉ định, phân bổ thuế và phân bổ đến từng xu theo cost center đó. Mỗi lần như vậy lại phát sinh nếp gấp và ngoại lệ mới, khiến con số giữa hai màn hình/cách tính không khớp
    Vì tôi phụ trách tính phí, mỗi tháng tôi dành vài ngày rà soát thủ công toàn bộ hóa đơn, kiểm tra lần cuối xem các con số có khớp không trước khi thu tiền thẻ tín dụng và gửi hóa đơn giấy. Lúc nào, hoặc thường xuyên, tôi cũng phát hiện một vấn đề mới ảnh hưởng đến một hoặc một số ít khách hàng, rồi sửa code trước khi tính phí thật. Tôi luôn thấy bất an nếu buông tay mà không kiểm tra lại mọi thứ bằng tay
    Tôi từng cân nhắc refactor logic tính phí về một chỗ để loại bỏ bất nhất và đối chiếu thủ công, nhưng sau khi suy nghĩ lâu, tôi nhận ra một codebase duy nhất khiến tôi không yên tâm, và ngược lại hai codebase lại giúp bắt lỗi của tôi. Sau đó tôi dần làm cho việc chạy tự động và đối chiếu giữa hai implementation trở nên dễ dàng hơn
    Code tính phí thì hơi bừa bộn, không đáng để khoe, nhưng tôi rất tự hào về độ chính xác trong tính phí, việc ít bị phàn nàn, và những sai lầm thót tim đã tránh được trong nhiều năm. Tôi hơi áy náy về độ phức tạp để lại cho người kế nhiệm, nhưng đến giờ cũng không hối tiếc nhiều
    Sau trải nghiệm đó, tôi luôn hiểu rất rõ động cơ của ghi sổ kép. Về cơ bản, tôi đã tái phát minh code tính phí hai lớp logic theo cách vụng về, để ngăn sai sót của mình gây hại cho khách hàng

    • Bất cứ thứ gì liên quan đến tính phí hay tiền đều rất dễ sai
      Đội dữ liệu mà tôi từng dẫn dắt ở công ty cũ có một thói quen không may là “làm mất” tiền. Không phải tiền thật biến mất khi đang chuyển sang nơi khác, mà là các bản ghi cần dùng để tính phí khách hàng bị biến mất
      Khi không làm mất doanh thu thì họ lại tính phí trùng, và những việc như vậy cứ tiếp diễn. Phải mất 3 năm làm việc vất vả mới giành lại được niềm tin của ban lãnh đạo
    • Không có ý xấu, nhưng nghe như ác mộng. Đồng thời, việc đạt được độ chính xác bất chấp độ phức tạp của hệ thống thật sự là điều tuyệt vời. Bạn có quyền tự hào
    • Điều này cũng rất giống N-version programming

  • Không có cả kiểm thử sao? Nếu mất tiền ở mỗi giao dịch đến mức đưa ra ví dụ “mỗi lần mua 5 đô la, log giao dịch chỉ còn lại 4,98 đô la”, thì vấn đề lớn hơn nhiều so với việc thiếu kế toán kép
    Ai lại xây dựng một hệ thống tài chính như vậy rồi coi là bình thường? Bồi thường cũng là vấn đề, nhưng với một dịch vụ như thế thì nên chạy càng xa càng nhanh càng tốt

    • Chính những người này đã làm vậy. Họ tự nói rằng “lẽ ra có thể làm cho đúng, nhưng đã không làm”. Đó không phải tai nạn mà là lựa chọn
      Họ đùa kiểu “những xu nhảy múa”, và làm vậy vì biết rằng mình sẽ không phải gánh chịu hậu quả đáng kể nào. Họ di chuyển nhanh, làm hỏng thứ gì đó—thứ liên quan đến tiền—rồi cười cho qua
      Giờ họ lại cố dạy người khác như thể mình có thẩm quyền đạo đức và kỹ thuật vì đã cố ý đưa ra những quyết định như thế. Đúng là thứ nhảm nhí theo kiểu văn hóa startup VC kiêu ngạo đến kinh ngạc
    • Vẫn chưa hiểu tiền đã bị mất như thế nào. Kế toán kép có thể giúp chẩn đoán, nhưng thực tế thì nó biến mất bằng cách nào?
    • Tôi cũng nghĩ vậy. Sổ cái có nhiều ưu điểm, nhưng không sửa được vấn đề những xu nhảy múa. Chỉ là các con số sai được đưa vào sổ cái mà thôi
      Tất nhiên nó có thể cho manh mối để tìm bug, nhưng viết các kiểm thử cơ bản cũng sẽ làm được tương tự
    • Một nguyên tắc thiết kế tốt đáng giá bằng 1000 bài test
    • Làm sao biết câu chuyện đó có thật hay không?

  • Tôi không hiểu vì sao tác giả lại dẫn câu châm ngôn “make it work, make it right, make it fast” theo hướng tiêu cực. Có lẽ tác giả hiểu nhầm “make it fast” nằm ở đâu
    “make it right” là bước thứ hai, và công việc phải dừng ở đó cho đến khi làm cho nó vận hành đúng. Hệ thống phải hoạt động lành mạnh. “make it fast”, tức tối ưu hóa, chỉ bắt đầu sau khi các vấn đề về tính đúng đắn và sự lành mạnh đã được giải quyết hoàn toàn
    Câu này không liên quan đến tốc độ giao hàng hay làm việc nhanh, mà có nghĩa là hãy để tối ưu hóa ở bước cuối
    Tuy nhiên, nếu điều tác giả muốn nói là trong khi một thứ có thể “chạy” qua loa, nó lại quá xa với “đúng” đến mức sau này không thể quay lại sửa, và với một số thứ thì phải làm “đúng” ngay từ đầu trước cả khi nó vừa đủ chạy, thì tôi hiểu được

    • Tôi nghĩ câu cuối là đúng. Có vẻ tác giả nói rằng với hệ thống thanh toán, không thể làm cho chạy trước rồi sau đó mới làm cho đúng
      Tôi cũng nghĩ vậy, và từng tham gia kiểm toán hệ thống fintech. Trước khi phê duyệt sổ sách, kiểm toán viên phải tải mọi thứ xuống bảng tính Excel để đối chiếu các con số. Việc đó tốn rất nhiều thời gian và tiền bạc, và tôi đoán sau 3 năm, tại sự kiện thanh khoản nó đã tạo ra chênh lệch ít nhất khoảng 0,1 unicorn
    • Tôi nghĩ tác giả đã chọn nhầm câu châm ngôn
      Trong các startup di chuyển nhanh, họ phát hành thứ thực tế là MVP càng sớm càng tốt. Vì phải xây dựng tập khách hàng, tài chính, v.v., họ bị dừng lại ở bước “make it work”
      Câu phù hợp hơn có lẽ là “move fast and break things” của Facebook. Nhưng điều đó chỉ hiệu quả khi sau này có thể sửa được. Ví dụ nếu chế tạo máy bay thì sẽ không làm như vậy
    • Bài viết nói đội kỹ thuật đã làm theo câu châm ngôn này, mà trong đó có cả “make it right”. Nhưng họ đã không làm vậy. Trước khi xây sản phẩm, họ thậm chí không cố tìm hiểu mình chưa biết gì về fintech
      Nhìn theo ngữ cảnh đó, hiểu nhầm được nói ở câu đầu là khả dĩ nhất. Vì ngay sau đó bài viết nói về áp lực thời gian mà startup phải chịu

  • Phần lớn bình luận ở đây đang lặp lại chính điều mà bài viết phê phán. Tôi thấy vô số cuộc tranh luận dài bênh vực kế toán đơn
    Kế toán đơn có thể dễ hơn và phổ biến hơn, nhưng đôi khi cứ làm theo những hệ thống và trừu tượng đã phát triển qua nhiều thế kỷ lại là ý hay
    Nếu không nhất thiết cần thứ khác, tốt hơn nên dùng kế toán kép. Bản năng của lập trình viên có thể thấy khó chịu, nhưng đến lúc phải gọi kế toán thật sự vào để xử lý các sai lệch thì bạn sẽ biết ơn nó
    Nhân tiện, có ai biết tài liệu hay cho lập trình viên về thanh toán hoặc các lĩnh vực lân cận không? Kiểu như “kế toán cho lập trình viên” ấy

  • Nếu nói rằng bạn đang dùng một hệ cơ sở dữ liệu cứ 10 giao dịch thì làm biến mất 1% dữ liệu, liệu có thể nghiêm túc tiếp nhận lời khuyên kỹ thuật trong blog kiểu này không? Bài này tạo cảm giác được gói ghém một cách điềm tĩnh như quảng cáo PR cho một cá nhân hay nhóm nào đó hơn là giới thiệu khái niệm

  • Muốn thấy thái độ cẩu thả như thế với phần mềm chuyển tiền gây hậu quả gì cho người thật, hãy nhìn vụ bê bối Post Office
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    Bất cứ thứ gì di chuyển tiền đều phải được đối xử nghiêm túc nhất có thể, và nên biết càng nhiều thất bại lịch sử càng tốt