- Thay đổi yêu cầu và sự bất định, công việc lặp lại và các giải pháp chắp vá vốn thường bị xem là đặc trưng riêng của phần mềm cũng rất phổ biến trong kỹ thuật truyền thống; hai lĩnh vực này có nhiều điểm chung hơn là khác biệt
- Việc phân chia kỹ thuật truyền thống là Waterfall còn phần mềm là Agile là cách nhìn quá đơn giản. Sản xuất vật lý có chi phí lặp lại cao hơn nên cần nhiều thiết kế trước, nhưng các lĩnh vực như đường hầm, công trình dân dụng và điện tử cũng dùng phát triển từng bước và thích ứng tại hiện trường
- Kỹ thuật truyền thống cũng gặp những vấn đề có thể đảo lộn kế hoạch như nhà cung cấp phá sản, thay đổi thiết bị sản xuất, hay đặc tính đất ngoài dự kiến, nên khó có thể nói chỉ riêng phần mềm mới khó dự đoán
- Khác biệt thực sự nằm ở tính nhất quán cao và khả năng thay đổi nhanh của phần mềm, cùng các ràng buộc tương đối linh hoạt hơn. Sản phẩm vật lý phải chấp nhận sai lệch vật liệu và hao mòn, các ràng buộc cứng như độ bền và kích thước, cùng những thay đổi khó hoàn tác
- Khả năng sửa nhanh giúp việc thử nghiệm và kiểm chứng dễ hơn, nhưng cũng có thể tạo áp lực phải lách lỗi bằng code cho các khiếm khuyết vật lý. Mỗi ngành kỹ thuật đều có thể học hỏi lẫn nhau về thiết kế, kiểm chứng và tự động hóa
Lập luận tự vệ rằng phần mềm là đặc biệt
- Tầng chứa dầu không phải là quả bóng đầy dầu mà là cấu trúc đá xốp, nên rất khó xác định việc sụt áp đột ngột là do một khoảng rỗng cục bộ hay do đã thông ra biển
- Người ta bơm vỏ hạt phỉ vào các khoảng rỗng nhỏ để lấp dần, cân bằng áp suất và kiểm tra xem chúng có nằm trong cấu trúc hay không
- Ví dụ các công ty dầu mỏ ở Na Uy là bên mua vỏ hạt phỉ lớn nhất cho thấy kỹ thuật truyền thống cũng dựa vào vật liệu bất ngờ và ứng phó tại hiện trường
- Khi so sánh phần mềm với kỹ thuật truyền thống, người ta vừa đánh giá phần mềm thấp hơn kỹ thuật do khác biệt về giấy phép hay mức độ nghiêm ngặt, vừa biến phần mềm thành một lĩnh vực đặc biệt không thể hiểu bằng khuôn khổ kỹ thuật thông thường
- Lập luận rằng yêu cầu thay đổi quá nhanh nên không cần áp dụng kế hoạch từ trước hay phương pháp kỹ thuật đã trở thành một cơ chế tự vệ
- Phong trào NoEstimates muốn loại bỏ hẳn việc ước lượng vì cho rằng ước lượng phần mềm khó hơn kỹ thuật truyền thống
- Nhưng phần lớn những vấn đề bị xem là đau đầu trong phần mềm cũng tồn tại ở các ngành kỹ thuật khác, và những kỹ sư từng trải nghiệm cả hai bên thường thấy bản chất công việc rất giống nhau
Năm khác biệt thường được nhắc tới
- Nếu coi toàn bộ kỹ thuật truyền thống như một lĩnh vực duy nhất hoặc đồng nhất với kỹ thuật dân dụng thì khác biệt giữa các phân ngành sẽ bị xóa nhòa
- Các điểm thường được nêu là khác biệt phổ quát giữa phần mềm và kỹ thuật truyền thống gồm:
- Kỹ thuật truyền thống hợp với Waterfall, còn phần mềm hợp với Agile
- Kỹ thuật truyền thống dễ dự đoán còn phần mềm khó dự đoán
- Kỹ thuật chủ yếu là sản xuất còn code là thiết kế, nên “code chính là thiết kế”
- Kỹ thuật truyền thống nghiêm ngặt hơn kỹ thuật phần mềm
- Phần mềm vận động nhanh hơn kỹ thuật truyền thống rất nhiều
- Một vài điểm có khác biệt thực sự, nhưng phần lớn là sai hoặc thiếu ngữ cảnh cốt lõi cần để đánh giá
Sự phân chia đơn giản giữa Waterfall và Agile
- Theo câu chuyện phổ biến, Winston Royce đã tạo ra Waterfall vào năm 1970 dựa trên quy trình xây dựng, và phương pháp này yếu trước thay đổi yêu cầu nên bị thay thế vào năm 2001 bởi Agile Manifesto
- Trên thực tế, Waterfall chưa từng cứng nhắc hay phổ quát như cách người ta nhận thức ngày nay
- Các nhà phát triển thập niên 1970~1980 đã dùng nhiều mô hình tăng dần như kế hoạch tạm thời, Spiral Model hay V Model
- Agile gần với kết quả tự nhiên của xu hướng lúc bấy giờ hơn là một cuộc cách mạng đứt đoạn
- Đúng là kỹ thuật truyền thống dành nhiều thời gian hơn cho thiết kế trước và kiểm thử tách biệt, nhưng điều này xuất phát từ tính kinh tế của chi phí lặp lại hơn là sự cứng nhắc của Waterfall
- Càng tốn nhiều thời gian và tiền bạc để lặp lại thì càng hợp lý khi lên kế hoạch lâu hơn cho một lần làm
- Nếu bo mạch không chạy ngay từ đầu, nó phải được gửi lại nhà máy, kéo theo thêm hàng nghìn bảng Anh và 2 tuần lịch trình
- Ranh giới giữa thiết kế và triển khai cũng không rõ ràng
- Mô hình thu nhỏ của kỹ sư dân dụng hay mô hình đất sét kích thước thật mà kỹ sư ô tô tạo ra để thử nghiệm thẩm mỹ và khí động học vừa có thể xem là thiết kế, vừa có thể xem là triển khai
- Các ngành khác cũng có phương thức tương tự Agile
- Phương pháp đào hầm kiểu Áo dựa vào phát triển lặp và ứng biến tại hiện trường
- Handbook of Industrial Engineering nhấn mạnh hợp tác liên phòng ban và phản hồi khách hàng nhanh
- Kỹ thuật dân dụng cũng chuyển sang giao tiếp cởi mở và thích ứng khi thi công bắt đầu để xử lý các vấn đề tại hiện trường
Kỹ thuật truyền thống cũng khó dự đoán
- Nếu chỉ nhìn cây cầu hay sản phẩm đã hoàn thành, ta dễ bỏ qua những va chạm, đội chi phí và chậm trễ phát sinh trong quá trình đó
- Chỉ cần xây lệch tường 1 inch hoặc một nhà cung cấp chủ chốt phá sản cũng đủ làm kế hoạch chao đảo
- Trong phần mềm, có vẻ như framework hay ngôn ngữ thống trị thay đổi mỗi 1~2 năm, nhưng kỹ thuật truyền thống cũng trải qua thay đổi về công cụ và môi trường sản xuất
- Khi một xưởng đúc bán dẫn đưa vào thiết bị sản xuất mới, kế hoạch thiết kế chip cũng phải thay đổi
- Có thể không nhanh như thư viện phần mềm, nhưng không có nghĩa là không đổi
- Cũng có những trường hợp quyền sở hữu thay đổi giữa chừng khi thi công, một quy trình đã được kiểm chứng đột ngột thất bại vĩnh viễn, hay một sự thật mới chỉ được phát hiện ở giai đoạn muộn của dự án
- Nếu sau khi bắt đầu làm móng cầu mới phát hiện một loại đất đóng băng khác với dự kiến và bị hóa lỏng quá mức khi động đất, thì phải bắt đầu lại từ khâu thiết kế
- Ý nghĩ rằng chỉ phần mềm mới đặc biệt khó dự đoán xuất phát từ việc không nhìn thấy quy trình làm việc thực tế ở các ngành kỹ thuật khác
Lập luận “code chính là thiết kế”
- “Code chính là thiết kế” là phản ứng chống lại ý tưởng rằng chỉ cần tạo mô hình UML hoàn hảo rồi tự động sinh code
- Nick Coghlan, nhà phát triển lõi CPython và từng là kỹ sư tích hợp hệ thống tại Boeing, xem đây là khác biệt nền tảng giữa phần mềm và công việc trước đây của ông
- Ông từng điều phối để nhiều nhóm hệ thống độc lập như máy bay, kiểm soát không lưu, hay dàn ăng-ten tạo ra các giao diện tương thích
- Với kỹ sư bán dẫn, toàn bộ quá trình từ sơ đồ mạch CPU đầu tiên đến con chip cuối cùng ra khỏi xưởng đúc đều là thiết kế; còn sản xuất có thể chỉ là bước tương đối đơn giản là bàn giao thiết kế rồi nhận chip về
- Nếu chip hay sản phẩm cơ khí hoàn thiện có lỗi thì phải thay đổi thiết kế, nên thiết kế và chế tạo không tách rời nhau
- “fettling” trong cơ khí là công việc điều chỉnh thiết kế cho phù hợp với những sai sót nhỏ trong quá trình chế tạo
- Việc chế tạo làm thay đổi thiết kế, rồi thiết kế đã đổi lại tiếp tục làm thay đổi việc chế tạo
- Phạm vi của thiết kế bản thân nó cũng mơ hồ
- Tổng quan kiến trúc, đặc tả hình thức và bản vẽ chi tiết đều là thiết kế ở những cấp độ khác nhau
- Trong các dự án phức tạp như bản thiết kế cầu, các chi tiết lặp lại ở nhiều tầng mức
- Đặc điểm dành nhiều thời gian và chi phí nhất cho thi công chỉ áp dụng cho một số nhánh kỹ thuật dân dụng xoay quanh cầu và nhà, không thể khái quát thành hình ảnh đại diện cho mọi ngành kỹ thuật truyền thống
- Bản thân kỹ thuật dân dụng cũng bao gồm nhiều lĩnh vực cần cho xây dựng đô thị, chứ không chỉ gói trong cầu và nhà
Hiểu lầm về mức độ nghiêm ngặt
- Cách phân biệt rằng kỹ thuật truyền thống suy luận cẩn trọng từ các nguyên lý đầu tiên còn phần mềm dựa vào copy-paste không phản ánh công việc thực tế
- Mức độ nghiêm ngặt có vẻ thấp hơn ở phần mềm không chỉ là vấn đề văn hóa, mà còn có thể là sự đánh đổi hợp lý do đặc tính vật liệu khiến việc triển khai và kiểm thử dễ hơn
- Trong nhiều trường hợp, cách dễ nhất để kiểm tra giả định là trực tiếp triển khai và chạy thử
- Việc nhanh chóng thu thập thông tin thực nghiệm tự nó cũng là một hình thức kiểm chứng nghiêm ngặt
- Giả định rằng sản phẩm kỹ thuật truyền thống nhất quán và có hệ thống hơn phần mềm cũng không đúng
- Phần mềm đôi khi còn đi trước về lưu trữ hồ sơ và kiểm chứng toàn diện
- Có rất nhiều trường hợp thông tin cốt lõi của kỹ thuật truyền thống được lưu trong file Excel hoặc tủ hồ sơ cũ rồi xuống cấp hay hư hỏng
- Nhiều kỹ sư truyền thống cũng muốn áp dụng kiểm thử tự động vốn được xem là đương nhiên trong phần mềm
- Ngay cả ở các cấu trúc vật lý, những giải pháp chắp vá như gắn thêm giá đỡ vẫn liên tục được dùng khi cần
Khác biệt thực sự 1: Tính nhất quán
- Phần mềm được cấu thành hoàn toàn bằng logic và không bị hao mòn như lò xo, nên nhất quán hơn rất nhiều so với các sản phẩm kỹ thuật khác
- Nếu một hàm sắp xếp chỉ sắp đúng 95% các danh sách số hợp lệ thay vì đầu vào bất thường, rất khó chấp nhận đó là hoạt động bình thường
- Vật liệu và linh kiện vật lý vốn dĩ luôn có sai lệch so với giá trị lý thuyết
- Điện trở được cung cấp từ 1Ω đến hàng trăm triệu Ω, và các vạch màu biểu thị giá trị điện trở lý thuyết
- Vạch xanh lá, xanh dương, đỏ nghĩa là 5,600Ω, nhưng nếu có thêm vạch dung sai màu vàng kim thì giá trị thực có thể lệch tối đa 5%
- Trong 100 điện trở cùng loại, một số có thể là 5,320Ω, số khác là 5,880Ω, nên phải đo từng cái
- Nếu tính cả hao mòn và thay đổi nhiệt độ thì sai lệch còn phức tạp hơn nữa
- Mọi vật liệu vật lý đều có vấn đề tương tự, và cả nhà sản xuất ốc vít Fastenal cũng cảnh báo không dùng ốc thép không gỉ với tấm nhôm
Khác biệt thực sự 2: Tốc độ thay đổi
- Phần mềm có thể thay đổi nhanh hơn rất nhiều so với các hệ thống kỹ thuật khác
- Trong kỹ thuật truyền thống, phải chia sẻ đặc tả rồi chờ nhà máy hay xưởng gia công chế tạo, lắp đặt và kiểm thử trong nhiều tuần
- Có những thay đổi kỹ thuật mà mỗi lần thực hiện đều rút 5.000 đô la trực tiếp khỏi ngân sách
- Với code, sau khi thay đổi có thể chạy toàn bộ bài kiểm thử chỉ trong vài giây
- Trong các lĩnh vực ngoài phần mềm, kỹ thuật hóa học có tốc độ gần nhất, nhưng ngay cả việc chuyển đổi theo đơn vị phút cũng vẫn khó tưởng tượng
- Việc các ngành kỹ thuật khác ngày càng dùng nhiều phần mềm cho công cụ thiết kế và mô phỏng cũng vì có thể tạo nguyên mẫu ý tưởng nhanh trước khi triển khai thực tế
- Khả năng thay đổi nhanh cũng có mặt tiêu cực
- Khi vấn đề ở thiết bị điện tử hay cơ khí chưa được giải quyết triệt để, áp lực thường dồn sang kỹ sư phần mềm phải vá bằng code
- Sự phụ thuộc này có thể dẫn đến hậu quả chết người
- Hai vụ rơi Boeing 737 MAX năm 2019 đã khiến hơn 300 người thiệt mạng
- Điều tra xác định nguyên nhân là lỗi trong hệ thống điều khiển bay tự động MCAS
- Boeing đã thêm MCAS thay vì sửa bằng thiết kế vật lý vấn đề đặc tính khí động học của máy bay được phát hiện muộn
Khác biệt thực sự 3: Ràng buộc và thay đổi không thể hoàn tác
- Sản phẩm kỹ thuật truyền thống có những giới hạn vật lý bắt buộc phải tuân thủ như trọng lượng, độ bền, điện trở và nhiệt độ
- Trong thiết kế chip, người ta có thể phải thương lượng với đội khác về cả phần thời gian dư chỉ tính bằng những phần của nano giây
- Phần mềm cũng có ràng buộc như dung lượng bộ nhớ, phản hồi 10 chu kỳ của cảm biến, hay giới hạn gọi API
- Tuy vậy, ràng buộc phần mềm thường là ràng buộc mềm, nơi trạng thái chỉ xấu dần khi vượt ngưỡng, nên có thể nới biên đôi chút để đổi lấy tốc độ phát triển hoặc thuật toán đơn giản hơn
- Còn ràng buộc trong kỹ thuật truyền thống thường là ràng buộc cứng: vượt qua là sản phẩm không hoạt động
- Hộp chỉ cần rộng hơn một chút là không thể đi qua cửa
- Có trường hợp một vít tải trục xoắn lắp cho cơ sở khoan dầu lại cao hơn căn phòng vài inch, và cũng không thể hạ thiết bị xuống hay nâng trần lên vì phía trên là bốn tầng khác
- Họ phải khoét một lỗ trên trần để đưa thiết bị vào, rồi đặt một cái hộp quanh lỗ để người ở tầng trên không bị vấp
- Thay đổi này trở thành một phần vĩnh viễn của cấu trúc cơ sở và về sau phải tiếp tục được tính đến trong mọi thay đổi khác
- Kỹ sư phần mềm có thể hoàn tác các giải pháp chắp vá, nhưng những chắp vá vật lý trong kỹ thuật truyền thống rất dễ trở thành cấu trúc vĩnh viễn
Khác nhưng không đặc biệt
- Phần mềm có các vấn đề bảo mật riêng, nhưng kỹ thuật dân dụng có thời tiết, kỹ thuật hóa học có đặc tính hóa học; mỗi lĩnh vực đều có những bài toán khó riêng
- Mọi ngành kỹ thuật đều coi trọng tư duy trừu tượng từ trước, công việc ngăn nắp và các giải pháp chắp vá phù hợp, đồng thời đối mặt với yêu cầu thay đổi và những ẩn số chưa biết
- Mỗi lĩnh vực tồn tại khá tách biệt, nên cũng như kỹ sư phần mềm không biết cơ khí, kỹ sư hóa học thường cũng khó hiểu công việc thực tế của các ngành kỹ thuật khác
- Vì phần mềm không đặc biệt nên ta có thể học các cách cải thiện từ những ngành kỹ thuật khác; và kỹ thuật truyền thống cũng có thể học từ phần mềm về lưu trữ hồ sơ, kiểm chứng và tự động hóa
- Bài viết tiếp theo Những gì kỹ thuật có thể dạy chúng ta và những gì có thể học từ chúng ta bàn về các bài học cụ thể mà hai bên có thể trao đổi
1 bình luận
Ý kiến trên Lobste.rs
Tôi đồng ý với nhiều phần của bài viết, nhưng nó quá lạc quan về tính nghiêm ngặt của kỹ nghệ phần mềm. Ngay cả bây giờ, việc đưa kiểm thử tự động, đặc biệt là kiểm thử vững chắc ở nhiều tầng, vào quy trình phát triển vẫn chưa phải điều hiển nhiên; đôi khi người ta coi chính lập trình viên là chốt kiểm duyệt duy nhất, hoặc tổ chức xem quy trình là vật cản rồi loại bỏ nó
Ngành này cứ vài năm lại phát minh lại bánh xe mà không hệ thống hóa các thực hành tốt nhất đã được kiểm chứng. Ngay cả những thứ được gọi là chuẩn hóa cũng thường chỉ là bộ từ vựng chung rất lỏng lẻo, ý nghĩa khác nhau đáng kể giữa các công ty; tiêu biểu là “Agile” hay “kiểm thử”. Nhiều lập trình viên chỉ nghĩ kiểm thử là unit test, một số thì tính cả kiểm thử thành phần và kiểm thử tích hợp, nhưng ở vài công ty chỉ qua chừng đó đã triển khai lên môi trường production
Như bình luận tôi từng viết trước đây, trong một tổ chức lành mạnh, code review nên là một trong nhiều quy trình chịu trách nhiệm về chất lượng, chứ không nên là cổng duy nhất quyết định triển khai vận hành. Có rất nhiều nhóm và công ty mà quy trình bảo đảm chất lượng sau khi merge code gần như không tồn tại
Không phải là muốn làm loãng trách nhiệm, mà là phải tích hợp chất lượng vào quy trình ngay từ trước khi viết code. Cần có các phiên Three Amigos để nhiều vai trò cùng thảo luận đặc tả và yêu cầu, phát triển hướng kiểm thử, phân tích tĩnh được tích hợp vào IDE và từng chốt kiểm duyệt, cùng các chuyên gia QA và tự động hóa kiểm thử tách biệt với lập trình viên
Trong kỹ thuật dân dụng, không một người nào vừa là người thiết kế cầu, vừa là người thi công, vừa là người chịu trách nhiệm duy nhất. Có nhiều bước như tính toán và lập tài liệu, kiểm tra tính lại, phê duyệt của chính phủ, kiểm toán và thanh tra trong lúc thi công; ngay cả nhà ở riêng lẻ cũng phải qua bản vẽ, phê duyệt, giấy phép và kiểm tra. Các thảm họa kỹ thuật cũng thường là thất bại của toàn bộ quy trình khi không chặn được ở nhiều công đoạn
Nếu muốn so sánh phát triển phần mềm với kỹ thuật dân dụng, cũng phải thừa nhận rằng mức độ quy trình hoàn toàn không giống nhau. Nhiều trường hợp, nó gần với nhà phát triển bất động sản xây căn nhà rẻ nhất có thể trong khi lách các yêu cầu pháp lý hơn
Vì vậy, ngoài những lĩnh vực như phần mềm điều khiển MRI, trong phần mềm thông thường điểm đánh đổi giữa chi phí kiểm thử/xác minh và hiệu quả của nó tất yếu sẽ khác với kỹ thuật dân dụng
Cả ba bài đều rất hay, tôi khuyên nên đọc. Cũng có thể xem thêm các cuộc thảo luận trước đó
https://lobste.rs/s/fv8swh/crossover_project (giới thiệu dự án)
https://lobste.rs/s/lmvroa/are_we_really_engineers (thảo luận lại)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (một lần thảo luận lại khác)
Bài nói này của Glenn Vanderburg cũng rất liên quan
Khác biệt lớn nhất giữa phát triển phần mềm và kỹ thuật truyền thống là ma sát đi kèm với thay đổi. Phần mềm có thể thay đổi với chi phí tương đối thấp và rất linh hoạt, mở ra những khả năng hoàn toàn mới
Kỹ thuật truyền thống cũng có thể mở rộng khả năng thay đổi theo hướng giống phần mềm hơn trong giới hạn vật lý và hóa học nếu tạo ra nhiều mô phỏng hơn
Câu nói “không ai kỳ vọng một hàm sắp xếp chỉ sắp xếp đúng một danh sách số không bệnh lý với xác suất 95%” giờ đây lại thực sự đúng với code do LLM tạo ra. Phần lớn thì hoạt động, nhưng không phải lúc nào cũng hoạt động
Tôi thắc mắc vì sao ~hwayne lại vô hiệu hóa tài khoản