1. Low-code software development
Vào vài thập niên trước, việc phát triển phần mềm có lẽ là chỉ dành cho những người thực sự yêu thích kỹ thuật vì công việc đòi hỏi những hiểu biết sâu sắc về phần mềm cũng như phần cứng và khả năng tư duy logic ở cấp độ cao.
Chúng ta khó có thể tưởng tượng được việc lập trình của những năm 60's ở thế kỷ trước như thế nào, nhưng trước khi xuất hiện sự bùng nổ của world-wide-web và search engine vào những năm đầu thế kỷ 21 thì một lập trình viên thường có một tủ sách như thế này:
Lúc này thì copy-paste programmer và fullstackoverflow programmer chưa ra đời nên cái gì không biết thì giở sách ra tra thôi nhé =)) 😂😂😂😂.
Tuy nhiên thì chúng ta quá lười biếng, thế nên việc thiết kế ra máy tính và phần mềm chỉ để đơn giản hóa việc tính toán hay giải trí bình dân chưa bao giờ là đủ.
In the last 20 years, software ate the world.
Cho đến thời điểm hiện tại chúng ta đã có hàng tỉ trang web và hàng triệu phần mềm để phục vụ những nhu cầu khác nhau của cuộc sống.
Và những nhà tiên phong về công nghệ đã sớm nhận ra rằng, hầu hết mọi tính năng cơ bản của một trang web đều đã từng được viết ra, tại sao chúng ta không tìm cách sử dụng lại bằng một cách đơn giản hơn thay vì việc dùng lại code?
Bẵng đi một thời gian thì low-code development platform đã nổi lên mạnh mẽ như một câu trả lời dõng dạc nhất cho câu hỏi đó.
Chắc hẳn bạn sẽ nghĩ rằng, hay đấy nhưng mà chưa đủ, những tính năng phức tạp, những thuật toán tối ưu thì vẫn phải code chứ? 🤔🤔🤔
Đúng là vẫn phải code nhưng là code ít hơn, nhanh hơn và hiệu quả hơn với sự giúp đỡ của Github Copilot.
In the next 20 years, AI will eat software.
2. Workflow
Nguyên lí Pareto hay còn gọi là nguyên lí 80/20 phát biểu như sau:
Khoảng 80% kết quả là do 20% nguyên nhân gây ra.
Nếu áp dụng nguyên lí này vào quá trình phát triển phần mềm thì có thể biểu diễn dưới nhiều dạng và trong nhiều lĩnh vực khác nhau, ví dụ:
~80% kết quả test được hoàn thành trong 20% thời gian test.
~80% của task được hoàn thành bởi 20% thời gian code.
Nhưng với sự giúp đỡ của low-code/no-code development platform thì thời gian viết code đôi lúc còn giảm xuống thấp hơn. Vậy thì lượng phần lớn thời gian còn lại ở đâu, dành cho việc gì?
- ~25% - Nghĩ tên biến.
- ~15% - Đọc hiểu code.
- ~10% - Lên ý tưởng code + search stackoverflow + dịch chuyển não liên tục từ relax mode sang hardcode.
- ~7% - Meeting.
- ~5% - Testing.
- ~5% - Copy paste.
- ~5% - Nhấn tổ hợp phím
ALT+TABchuyển màn hình hay di chuyển con trỏ chuột qua lại giữa các điểm ảnh. - ~3% - Copy request từ Chrome Devtools vào Postman hay bật terminal gõ lệnh ssh để monitor log trên server.
- ~1% - Tìm kiếm dấu ; còn thiếu.
- ~4% - Các hoạt động khác.
Trên đây là một ví dụ minh họa 😂😂😂😂 về việc phân bổ thời gian tham việc của một lập trình viên nhưng qua đó chúng ta có thể thấy rằng, trong thực tế luôn có những workflow không hiệu quả cần tái cấu trúc để việc phân bổ thời gian được tối ưu nhưng có thể bởi vì chúng ta quá bận rộn nên không có thời gian để quan sát xem vấn đề gì đang xảy ra với workflow hiện tại.
Đó chính là số lượng 20% thời gian bỏ ra để giải quyết vấn đề liên quan trực tiếp đến chuyên môn cốt lõi (coding) rất khó để cải tiến vì khi năng lực của bạn tăng lên thì độ khó của nhiệm vụ bạn được giao cũng sẽ tăng lên. Cái chúng ta cần cải tiến nên là 80% lượng gian bỏ ra cho những công việc rườm rà còn lại đơn cử như một vài gạch đầu dòng ở trên.
Tuy nhiên thì việc cải tiến thường đi kèm với việc thay đổi thói quen. Thật là khó để chuyển từ Window sang Linux mặc dù biết rằng Linux mạnh mẽ và tiện dụng biết bao nhiêu, thật là khó khi phải liên tục học hỏi và đuổi theo những công nghệ tiên tiến nhất mà không biết bao giờ sẽ dừng lại. Thật là khó để chuyển sang nghe nhạc Nam Cường với một đôi tai đã quá quen những âm thanh dịu dàng của nhạc Trịnh Công Sơn. Nói chung thì thật là khó.
Khó nhưng mở ra nhiều cơ hội để sáng tạo và học hỏi. Liên tục cải tiến giúp chúng ta có thêm thời gian trống không phải là để nhận thêm task mà là để lại tiếp tục cải tiến. Và người ta gọi đó là organic development.
Đôi khi việc nhận ra những gì không cần phải cải tiến còn quan trọng hơn việc nhận ra những gì cần cải tiến. Gần như không có giải pháp nào khả dĩ cho mọi vấn đề mà chỉ có giải pháp giải quyết vấn đề này nhưng lại phát sinh thêm một vài vấn đề khác.
Ngày hôm nay chúng ta phải đối mặt với quá nhiều vấn đề cần cải tiến/giải quyết cũng chỉ vì trước đó chúng ta đã giải quyết/cải tiến quá nhiều vấn đề.