Năm 2024, cách tôi lập trình

 (akkartik.name)
2 điểm bởi GN⁺ 2024-08-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tôi từng nói về cách chọn những chương trình có thể dùng lâu dài và xây dựng hạ tầng đáng tin cậy, nhưng thừa nhận rằng mình vẫn chưa làm tốt điều đó
  • Trong một tháng, tôi đã viết lại phần cốt lõi của chương trình mà mình dùng suốt 2 năm gần đây, và qua đó nhìn lại những thay đổi trong cách lập trình của bản thân suốt cuộc đời

Năm 2015

  • Nghi ngờ sự trừu tượng hóa và coi trọng kiểm thử cùng quản lý phiên bản
  • Tôi cho rằng việc lạm dụng trừu tượng hóa và thiếu kiểm thử/quản lý phiên bản là nguyên nhân của các vấn đề
  • Tôi đã thiết kế nền tảng Mu1 với kiểm thử và các layer là những ràng buộc cơ bản

Năm 2017

  • Bắt đầu làm lại Mu1 thành Mu hiện tại
  • Ban đầu dùng toàn bộ các ý tưởng mới về kiểm thử và layer, nhưng dần dần ngừng sử dụng chúng
  • Mu có nhiều kiểm thử, nhưng theo cách cũ, và không chuyển hạ tầng layer sang

Năm 2022

  • Bắt đầu làm Freewheeling Apps
  • Lúc đầu bắt đầu mà không có kiểm thử, rồi viết kiểm thử kỹ lưỡng cho phần cốt lõi của trình soạn thảo văn bản
  • Các phần còn lại khó kiểm thử hơn, nhưng vẫn hoạt động tốt

Năm 2024

  • Một tháng trước, tôi đã xóa toàn bộ kiểm thử
  • Tôi đã tái cấu trúc triệt để trình soạn thảo văn bản theo cách mà trước đây tôi từng lo sẽ gây xung đột khi hợp nhất với các Freewheeling Apps khác
  • Tôi không còn phải bận tâm về quản lý phiên bản
  • Từ bỏ kiểm thử và phiên bản giúp tôi tạo ra một chương trình tốt hơn rất nhiều

Quan điểm tổng hợp hiện tại về lập trình bền vững

  1. Xây dựng bền vững cho nhiều người là quá khó, nên đừng cố làm ngay từ đầu
  2. Phần lớn phần mềm bị nhiễm các động lực phục vụ thật nhiều người trong ngắn hạn. Hãy tập trung vào phần mềm có ít logo hơn, dễ xây dựng hơn, ít phụ thuộc hơn và không tự động cập nhật
  3. Những thay đổi nhỏ trong ngữ cảnh có thể làm thay đổi tận gốc mức độ phù hợp của chương trình với ngữ cảnh đó
  4. Chương trình mới theo cách nào đó luôn hướng tới một vùng đất chưa biết. Thường thì ta không thật sự biết chính xác mình đang làm gì, dù theo bất kỳ hướng nào
  5. Kiểu dữ liệu, trừu tượng hóa, kiểm thử, phiên bản, state machine, tính bất biến, phân tích hình thức... là những công cụ có thể dùng trên địa hình còn xa lạ
  6. Rốt cuộc ta khó tránh khỏi việc lạm dụng một số công cụ này. Mức sử dụng lý tưởng nhỏ hơn rất nhiều so với những gì ta tưởng. Dùng quá mức chính là nợ kỹ thuật
  7. Khi hiểu biết về ngữ cảnh đã ổn định, việc vứt bỏ một phần đáng kể của chương trình và làm lại từ đầu là điều đáng giá
  8. Trước khi viết lại, bạn phải chứa trong đầu cùng một lúc mọi điều mình muốn từ chương trình và mọi kịch bản mà chương trình phải xử lý
  9. Hãy xây dựng mọi thứ trong một lần
  • Kiểm thử và quản lý phiên bản cản trở việc đi đến giai đoạn cuối của sự tiến hóa này
  • Kiểm thử khiến ta quên đi những mối bận tâm, còn quản lý phiên bản khiến ta vương vấn quá khứ

Ý kiến của GN⁺

  • Nếu chương trình trở nên quá phức tạp thì ở bước 8, việc ghi nhớ mọi thứ có thể trở nên bất khả thi. Điều này đúng với hầu hết phần mềm, đặc biệt là phần mềm do từ hai người trở lên cùng viết
  • Không phải mọi phần mềm đều nhất thiết phải đạt tới bước 9. Nhiều Freewheeling Apps đủ đơn giản và tiến hóa đủ chậm để có thể ổn định ở trạng thái không còn lỗi ngay cả khi chỉ có vài người dùng, bất kể các lựa chọn thiết kế ban đầu là gì
  • Thiết kế hướng dữ liệu rõ ràng hữu ích để đạt tới bước 9. Đây không phải là công cụ có thể áp dụng một cách mù quáng, mà là một cách tư duy nhìn vào bức tranh lớn về cách chương trình truy cập dữ liệu, vượt ra ngoài các lựa chọn cấu trúc dữ liệu tức thời
  • Những bước này có thể không hoàn toàn đúng. Có thể tác giả đang đánh giá thấp những công cụ mà mình ít kinh nghiệm hơn
  • Thật tò mò không biết còn có giai đoạn nào vượt lên trên những bước này hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-06
Ý kiến Hacker News

  • Nếu không có test, bạn sẽ không nhìn thấy vấn đề nên có vẻ như vấn đề đã biến mất

    • Mỗi khi viết test thì luôn phát hiện ra bug
    • Xóa test là đang tự lừa dối bản thân
    • Sau khi đọc bài, có cảm giác tác giả đã mệt mỏi với việc quản lý biến thể/cấu hình
    • Phải có nhiều người dùng thì mới kiếm được tiền

  • Khi từ bỏ test và versioning thì lại có được chương trình tốt hơn

    • Không thể hiểu nổi việc không dùng quản lý mã nguồn vào năm 2024
    • Khả năng làm việc trên nhiều thiết bị, xem lịch sử, rollback và tạo branch là cực kỳ hữu ích

  • Ban đầu tưởng tác giả sai, nhưng vẫn có những góc nhìn đáng suy ngẫm

    • Quy trình làm việc này rất hợp với tác giả
    • Có lẽ tác giả từng trải qua việc Git hoặc test tự động làm giảm năng suất
    • Cũng có những lựa chọn thay thế đơn giản hơn, ví dụ Dropbox, FTP
    • Tác giả thích làm các chương trình nhỏ
    • Test tự động vẫn hữu ích, nhưng trong trường hợp của tác giả có thể chưa thể hiện được giá trị

  • Quản lý phiên bản và test tự động giải quyết các vấn đề có thật

    • Ngày nay bắt đầu một dự án mà không có quản lý phiên bản là điều điên rồ
    • Test tự động là thực tiễn tốt nhất
    • Với trường hợp sử dụng cụ thể của tác giả thì điều đó có thể hợp lý

  • Khi viết/refactor các chương trình lớn, việc viết rồi bỏ đi và viết lại là quan trọng

  • Bài viết này khá khó hiểu

    • Tò mò không hiểu vì sao nó lại được upvote lên đầu tiên

  • Những thay đổi nhỏ có thể làm thay đổi rất lớn mức độ phù hợp của một chương trình

    • Có ví dụ về K9 Mail
    • K9 Mail khởi đầu với một UI không theo lối thông thường
    • Nhiều người dùng đã phàn nàn về UI mới
    • Một thay đổi nhỏ đã phá hỏng sự phù hợp của ứng dụng
    • Vẫn đang dùng phiên bản cũ

  • Làm phần mềm một mình và làm trong đội là hai việc hoàn toàn khác nhau

    • Test là phương tiện chứ không phải mục đích
    • Khi có sự tự tin thì sẽ test ít hơn
    • Thêm integration test cho các phần quan trọng
    • Unit test hữu ích cho việc thiết kế API mới

  • Đã bắt đầu làm Freewheeling Apps vào năm 2022

    • Cảm thấy thất vọng vì không có test
    • Bộ test mang lại sự tự tin để tiếp tục phát triển hệ thống
    • Khi độ phức tạp của tính năng tăng lên thì việc test trở nên khó hơn
    • Đã xóa toàn bộ test vào năm 2024
    • Triết lý này chỉ áp dụng cho một người

  • Không đồng ý rằng những thay đổi nhỏ có thể làm thay đổi rất lớn mức độ phù hợp của chương trình

    • Chủ nghĩa ngắn hạn là để thích nghi với những thay đổi nhỏ

  • Thích tác giả và thích dự án Mu

    • Đó là một Lisp machine hiện đại

  • Bị choáng ngợp trước độ phức tạp của software engineering

    • Bác bỏ mọi ý tưởng không phải là giải pháp
    • Cần viết test, dùng VCS và dùng abstraction
    • Phải biết vì sao mình dùng chúng, và nếu không có lý do thì nên đánh giá lại