Thuật toán phát triển phần mềm của chúng ta

 (grantslatton.com)
44 điểm bởi GN⁺ 2024-08-20 | 5 bình luận | Chia sẻ qua WhatsApp
  • Gần đây, trong một cuộc trò chuyện với một CEO công nghệ nổi tiếng và một kỹ sư, tôi đã nghe về một phương pháp phát triển phần mềm thú vị. Phương pháp này khiến tôi suy nghĩ về các heuristic và các phép khái quát hóa khác.

Phương pháp của ông ấy

  • Bắt đầu làm tính năng vào đầu ngày. Nếu đến cuối ngày vẫn chưa hoàn thành, hãy xóa hết và bắt đầu lại vào ngày hôm sau. Có thể giữ lại các unit test đã viết.
  • Nếu sau vài ngày vẫn không thể triển khai được tính năng, hãy nghĩ về nền tảng, hạ tầng hoặc việc refactor cần thiết để cho phép tính năng đó, triển khai phần đó rồi quay lại với tính năng.
  • Phương pháp này tương tự phong trào extreme programming vào cuối thập niên 90 và đầu những năm 2000.

Suy nghĩ về phương pháp này

"Viết mọi thứ hai lần"

  • Lời khuyên dành cho kỹ sư junior: giải quyết vấn đề, lưu mã vào branch, rồi viết lại.
  • Tôi tình cờ phát hiện ra phương pháp này sau khi laptop bị hỏng. Việc viết lại chỉ tốn 25% thời gian của lần triển khai đầu tiên, và kết quả tốt hơn nhiều.
  • Với 1,25 lần thời gian, bạn có thể có mã chất lượng cao gấp đôi. Hữu ích cho các dự án cần bảo trì dài hạn.
  • Phương pháp "bắt đầu lại mỗi ngày" còn cực đoan hơn thế. Mỗi lần viết lại, bạn thường tìm được một lời giải mượt mà hơn.

"Lượng có chất riêng"

  • Câu nói của Stalin cũng áp dụng cho kỹ sư phần mềm. Với kỹ sư junior, 100.000 dòng mã đầu tiên là điều thiết yếu.
  • Phương pháp "bắt đầu lại mỗi ngày" giúp viết 100.000 dòng đó nhanh hơn.
  • Việc giải đi giải lại cùng một bài toán có ích cho việc ghi nhớ các pattern.
  • Chỉ với 5.000 dòng mã hoàn hảo, bạn có thể thấy hết các pattern chính. 95.000 dòng còn lại tái cấu trúc các neuron thông qua lặp lại.

So sánh với heuristic "kề súng vào đầu"

  • Hãy hỏi người đưa ra lời giải cho vấn đề rằng: "Nếu phải xong trong 24 giờ thì bạn sẽ làm thế nào?"
  • Phương pháp này phá vỡ framing và anchoring bias. Nó thường có thể dẫn ra một kế hoạch có thể hoàn thành trong một ngày chỉ sau vài phút.
  • Trên thực tế, đó không phải là kế hoạch có thể xong trong một ngày, nhưng lời giải mới thường có thể hoàn thành trong vài ngày.
  • Mục đích của thí nghiệm tư duy này không phải tạo ra lời giải thực tế, mà là thiết lập cận dưới cho lời giải.

Tìm đường

  • Điều cốt lõi là tìm đường trong không gian vấn đề. Mỗi con đường là một lời giải, và vai trò của kỹ sư là tìm ra con đường tốt nhất.
  • Đáng để suy nghĩ về sự tương đồng giữa các heuristic này và các thuật toán tìm đường khác nhau.
  • Heuristic trong kỹ thuật cũng vậy: trở thành một kỹ sư giỏi hơn là tìm ra những con đường tốt hơn trong không gian vấn đề.

Tóm tắt của GN⁺

  • Bài viết này khám phá các phương pháp luận và heuristic hiệu quả trong phát triển phần mềm.
  • Phương pháp "bắt đầu lại mỗi ngày" và phương pháp "viết mọi thứ hai lần" hữu ích để nâng cao chất lượng mã.
  • Việc giải quyết vấn đề lặp đi lặp lại giúp nhận diện pattern và tái cấu trúc neuron.
  • Heuristic "kề súng vào đầu" hữu ích để thiết lập cận dưới của lời giải.
  • Tìm ra con đường tốt nhất trong không gian vấn đề là vai trò cốt lõi của kỹ sư.

Bài viết liên quan

5 bình luận

 
ahwjdekf 2024-08-21

Điên à? Chỉ những người thừa mứa thời gian mới làm nổi chuyện này, chứ trong thực tế đây có phải việc khả thi đâu?
 
dlehals2 2024-08-22

Trong môi trường SI ở Hàn Quốc thì chắc là không thể rồi.. haha, chắc chỉ áp dụng được với dự án cá nhân thôi
 
kaistj 2024-08-20

Cách tiếp cận này đúng là một hướng mà mình chưa từng nghĩ tới.
Mình phải thử một lần mới được haha
 
eususu 2024-08-20

Tôi rất đồng cảm với việc viết lại.
Trước đây tôi từng lỡ tay làm mất đoạn code đang làm, rồi khi viết lại
đã xây dựng có cân nhắc cả những thứ trước đó từng bỏ qua vì ngại thay đổi thiết kế giữa chừng,
nên kết quả ngược lại còn tốt hơn.
 
GN⁺ 2024-08-20
Ý kiến trên Hacker News

  • Việc viết một tính năng hai lần là một chiến lược tốt. Tuy nhiên, với các nhà phát triển phía kinh doanh hoặc quản lý dự án, điều này có thể trông như một sự chậm trễ không cần thiết

    • Viết tính năng từ đầu đến cuối giúp sắp xếp lại logic và hỗ trợ refactor
    • Việc viết lại làm rõ luồng logic và giúp bám theo kế hoạch một cách tuyến tính hơn
    • Nó có xu hướng giảm nhu cầu phải refactor quy mô lớn về sau

  • Câu hỏi “nếu phải xong trong 24 giờ thì sao?” là kiểu câu hỏi mà quản lý dự án không thể đặt ra

    • Đây là một bài tập mang tính học hỏi cá nhân, không phải cách để hoàn thành công việc nhanh hơn

  • Mã tốt được viết bằng cách chọn đúng mức trừu tượng phù hợp

    • Để chọn được mức trừu tượng phù hợp, bạn cần hiểu toàn bộ bức tranh
    • Trong các ngành kỹ thuật khác, người ta dùng những mô hình bản thiết kế tốt như bố cục CAD
    • Trong phần mềm thì lại thiếu những bản thiết kế như vậy
    • Đó là lý do kinh nghiệm quan trọng: để cân bằng những yếu tố này

  • Nếu có đồng nghiệp giỏi, họ có thể cho thấy trong thời gian ngắn có thể làm được những gì

    • Có nhiều lý do khiến việc làm nhanh là quan trọng
    • Giống như sửa ô tô, càng mất nhiều thời gian thì càng dễ quên cách lắp lại
    • Nếu triển khai tính năng trong một ngày, rủi ro sẽ giảm xuống
    • Điều này đòi hỏi sự hiểu biết chắc chắn về công cụ và một quy trình CI/CD đáng tin cậy

  • Đồng cảm với ý kiến rằng viết phần mềm hai lần là điều tốt

    • Sau khi đã đánh mất đoạn mã từng viết một lần, tôi mất động lực để viết lại nó
    • Khi cố viết lại, tôi không còn tập trung được và cũng không nhớ rõ cách tiếp cận trước đó

  • Nếu vài ngày sau vẫn không thể triển khai được tính năng, thì trước tiên cần thực hiện hạ tầng hoặc refactor cần thiết

    • Điều quan trọng là xây dựng và duy trì “vốn từ vựng” của công cụ

  • “Trong vòng 24 giờ” và “viết lại mọi thứ hai lần” có liên hệ với nhau

    • Nếu viết mã cẩu thả, cuối cùng bạn vẫn sẽ phải viết lại

  • Bài đăng này là một trong những lời khuyên về lập trình hay nhất

    • Nó giống với lời khuyên của grug brained developer

  • Đôi khi cần để một luồng nền chạy để giải quyết vấn đề

    • Người có nhiều kinh nghiệm có thể nhận ra những vấn đề như vậy nhanh hơn
    • Có lúc tốt hơn là tạm gác vấn đề sang một bên và làm việc khác

  • Cách tiếp cận sau đây khá hữu ích

    • Trước tiên hãy viết ra nhiều ý tưởng khác nhau để giải quyết vấn đề
    • Chia công việc theo cách có thể “hoàn thành trong một phiên làm việc”
    • Triển khai sao cho đến cuối mỗi phiên, mã luôn ở trạng thái “đang hoạt động”
    • Cuối mỗi phiên, ghi lại toàn bộ suy nghĩ vào comment hoặc README