Chúng ta đã sử dụng quá nhiều tầng trừu tượng
(unixsheikh.com)- Trong ngành công nghệ, số người chỉ học cách dùng công cụ và tự động hóa đang tăng lên, khiến độ sâu kỹ thuật trong việc hiểu nguyên lý vận hành của các tầng bên dưới bị suy yếu
- Trừu tượng hóa giúp công việc trở nên dễ dàng hơn như vô lăng hay trợ lực lái, nhưng khi xảy ra lỗi hay sự cố, nếu không có ai hiểu bên trong thì khả năng phục hồi sẽ giảm đi
- Áp lực phát hành nhanh và cắt giảm chi phí dồn nhiều vai trò vào một người như DevOps·DevSecOps, dẫn tới nhiều tự động hóa hơn và ít hiểu biết sâu hơn
- Trong lĩnh vực bảo mật, việc chỉ tin vào đèn xanh của các công cụ kiểm thử xâm nhập dựa trên GUI có thể dẫn tới tình trạng cuộc xâm nhập thực tế không bị phát hiện trong thời gian dài
- Người học công nghệ cần thay vì chỉ chạy theo xu hướng, hãy tự mình làm những việc mà công cụ đang thay thế, đồng thời duy trì tư duy của một kỹ sư là đào sâu vào mã nguồn và các tầng bên dưới
Khoảng trống trong hiểu biết kỹ thuật bị trừu tượng hóa che khuất
- Ngày nay có vấn đề là nhiều “chuyên gia” biết cách cấu hình công cụ nhưng không hiểu công nghệ vận hành như thế nào ở những tầng sâu hơn
- Bản thân trừu tượng hóa là cần thiết
- Vô lăng là một dạng trừu tượng hóa giúp việc lái ô tô trở nên dễ dàng hơn
- Trợ lực lái là một lớp trừu tượng hóa khác tiếp tục cải thiện trải nghiệm lái xe
- Vấn đề lộ ra khi lớp trừu tượng bị phá vỡ
- Nếu không có người hiểu công nghệ bên trong thì rất khó sửa tầng bị hỏng
- Dù công cụ trông có vẻ hoạt động bình thường, ta vẫn có thể không đánh giá đúng được trạng thái thực của hệ thống
- Ngành công nghệ vận hành dưới áp lực rất lớn từ lợi nhuận và tốc độ phát hành
- Kết quả là có nhiều trừu tượng hóa và tự động hóa hơn được đưa vào
- Ít người hơn phải gánh nhiều việc hơn
- Cách dùng một công cụ cụ thể được nhấn mạnh hơn là sự hiểu biết sâu
- Vai trò lập trình viên và quản trị hệ thống truyền thống đang chuyển thành mô hình đưa phát triển, bảo mật và vận hành vào công việc của một cá nhân như DevOps, DevSecOps
- Vì một người khó có thể thành thạo hoàn toàn cả phát triển, bảo mật lẫn quản trị hệ thống, nên người ta sẽ tự động hóa nhiều nhất có thể
- Kết quả là lực lượng kỹ thuật hiện đại có thể học cách dùng một số công cụ cụ thể nhưng gần như không biết gì về công nghệ bên trong
Tư duy cần có với người học công nghệ
- Cuộc sống hiện đại phụ thuộc rất lớn vào công nghệ, nhưng bản thân công nghệ lại ngày càng khó hiểu hơn
- Trong lĩnh vực bảo mật cũng có chỉ trích rằng nhiều người chỉ biết cách dùng các công cụ kiểm thử xâm nhập dựng sẵn mà lại không hiểu nhiều về bảo mật
- Nếu giao diện web GUI của công cụ hiển thị đèn xanh, người ta có thể mặc định rằng mọi thứ đều ổn
- Ngay cả khi kẻ tấn công thực sự đã xâm nhập hệ thống và đang bán dữ liệu trên darknet, việc rò rỉ hay xâm phạm vẫn có thể không bị phát hiện
- Có liên kết đến bài viết trên Slashdot nêu ví dụ một số sinh viên thậm chí còn không hiểu khái niệm tệp và thư mục
- Những thực hành cần thiết cho người học công nghệ gồm có
- Không chỉ chạy theo mốt hay xu hướng
- Đừng chỉ học công cụ mà hãy hiểu công nghệ nền tảng hoạt động như thế nào
- Nếu có thể, hãy thử làm thủ công ít nhất một lần những việc mà công cụ cấu hình đang thay bạn làm
- Nếu có thể, hãy xem mã nguồn của công cụ
- Tiếp tục học hỏi và thử nghiệm, đồng thời đào sâu hơn vào những công nghệ bạn quan tâm
- Nếu có thể, hãy dựng một homelab để dùng như sân chơi cho việc học và phá thử
- Hãy đặt câu hỏi với những điều bạn chưa hiểu, và đừng mặc định rằng ai đó biết rõ hơn mình như một giá trị mặc định
- Điều này không có nghĩa là ai cũng phải hiểu mọi thứ từ nguyên lý đầu tiên, hay không được dùng công cụ
- Trừu tượng hóa là cần thiết
- Cũng như tài xế lái xe còn thợ máy sửa xe tải, các lĩnh vực chuyên môn vẫn tồn tại
- Vấn đề cốt lõi là tư duy kỹ sư mà người làm công nghệ nên có đang suy yếu
- Trong phát triển phần mềm, quá nhiều vai trò chuyên môn đang bị thay thế bởi công cụ và tự động hóa
- Ngày càng ít người hiểu được ngay cả tầng nằm ngay bên dưới tầng mà họ đang làm việc
- Nếu một lập trình viên web xây dựng trang web chỉ bằng công cụ hoặc framework dựng sẵn mà không có kiến thức về TCP/IP, DNS, HTTP, TLS hay bảo mật, thì khi có sự cố xảy ra, tính hữu dụng của họ sẽ giảm đi đáng kể
1 bình luận
Các ý kiến trên Hacker News
Trong lịch sử hàng không cũng từng có thời điểm người có thể lái máy bay cũng có thể thiết kế và chế tạo nó, và tôi tự hỏi liệu khi đó họ có lo về một tương lai nơi những người không thực sự hiểu nguyên lý thứ nhất của cỗ máy lại ngồi trong buồng lái hay không.
Giờ đây chúng ta đã quen với ý nghĩ rằng lái máy bay và chế tạo máy bay là những kỹ năng, nghề nghiệp riêng biệt; và cũng tự nhiên chấp nhận rằng kỹ sư hàng không không cần biết khai thác bauxite hay luyện nhôm.
Có thể lần theo toàn bộ con đường từ cổng logic đến web request thì cũng yên tâm, nhưng không phải là bắt buộc. Việc số kỹ sư có cái nhìn tổng quan như vậy giảm đi, hơn là một tín hiệu cảnh báo, gần với hiện tượng cho thấy sự trưởng thành của ngành công nghệ và sự phân hóa lĩnh vực hơn.
Ví dụ, trong những câu kiểu “hãy cùng quay lại assembly”, ngay cả sau khi ngôn ngữ bậc cao trở thành chủ đạo, trong một thời gian khá dài lập trình viên vẫn phải biết assembly. Vì các tầng trừu tượng của compiler và công cụ debug vẫn bị rò rỉ.
Vấn đề hôm nay nằm ở chỗ chúng ta chồng chất nhiều lớp trừu tượng bị rò rỉ mà không cho chúng thời gian trưởng thành. Chúng được thiết kế để giảm thời gian làm việc dưới giả định sai rằng developer sẽ luôn ở trên “happy path”, nhưng trên thực tế phần lớn thời gian lại dùng để debug những tình huống không diễn ra như thiết kế. Nếu làm cho happy path nhanh hơn nhưng khiến unhappy path chậm đi, thường thì đó là lỗ ròng.
Vì hệ thống tự động hóa của Airbus khiến việc thất tốc gần như không thể xảy ra trừ khi có điều gì đó sai nghiêm trọng và máy bay quay về luật điều khiển thủ công, anh ta đã không hiểu đúng thất tốc hoạt động như thế nào. Chính chuyện đó đã xảy ra trong chuyến bay ấy, và khi cơ trưởng quay lại buồng lái, ông nhận ra ngay máy bay đang ở tình trạng thất tốc sâu, nhưng đã quá muộn.
Video Mentour Pilot liên quan: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
Quá trình bay ngay từ đầu đã có các giới hạn vật lý, nhưng điện toán và các khung tư duy về nó thì biến đổi vô tận và phạm vi áp dụng cũng rộng. Nếu chuyển những thứ nhảm nhí đang được bán ngày nay sang phép so sánh hàng không, thì nó gần giống với việc bán cưỡi lừa nhưng gọi là bay. Một phần đáng kể khách hàng không có kiến thức để phân biệt sự khác nhau đó.
Một thành phần quan trọng của tiến bộ là ta chỉ có thể tạo bước nhảy lớn trên một nền tảng khi đã tìm ra cách làm cho thứ gì đó trở nên đơn giản. Khi nó trở nên quá phức tạp, sẽ có giới hạn cho quãng đường và độ cao có thể đạt tới. Nó giống như việc phóng to nợ kỹ thuật lên quy mô nhân loại.
Tiếc là trong lịch sử, chúng ta không giỏi nhận ra khoảnh khắc một điều gì đó trở nên đơn giản hơn một bậc. Vì khi nhìn lại, nó tự nhiên trông như chuyện hiển nhiên.
Tôi nghĩ trẻ em ngày nay không được công nhận đủ. Vài tuần trước, con trai của một người bạn đã hào hứng cho tôi xem game Roblox mà cậu bé đang làm cùng bạn bè.
Vì là Lễ Tạ ơn ở Canada nên có nhiều người thân và bạn bè ở đó; cậu bé đã chọn sẵn phần mà từng người có thể quan tâm, còn tôi là “người để cho xem Lua”.
Người ta nghĩ rằng vì điện thoại hay laptop bị khóa nên không khơi gợi được sự tò mò, trẻ em cũng sẽ như vậy; nhưng tôi lại thấy người lớn mới là những người ít tò mò hơn.
Tất nhiên nó được xây trên các tầng trừu tượng, nhưng giữa những ngọn núi trừu tượng cao vẫn luôn có những thung lũng cho một thiểu số tò mò bước vào. C64 BASIC cho phép POKE vào bất kỳ địa chỉ bộ nhớ nào, nhưng được một đứa trẻ 10 tuổi giải thích về một game sưu tầm 3D phức tạp có yếu tố FPS cũng là một chuyện khá tuyệt.
Có cảm giác như một ông già đang hét vào đám mây.
Việc có người là chuyên gia, có người chỉ ở mức tàm tạm chẳng có gì mới. Không phải ai cũng có thể là đấng cứu thế như tác giả, người dùng một nửa bài viết ngắn này để tự khoe khoang.
Bài này gần như chẳng liên quan gì đến trừu tượng hóa. Sau hai đoạn đầu, tác giả đã mất hứng với luận điểm của mình.
Ví dụ cũng rất tệ. “Ai đó dùng framework hiện đại rồi bị hack, nhưng vấn đề hiệu năng không phải do vụ hack mà là vì framework chậm khủng khiếp” — nhưng đó là framework nào, chỉ nhìn diff thì làm sao biết nó chậm, và việc không tinh chỉnh được công cụ cho phù hợp với hiệu năng thì liên quan gì đến trừu tượng hóa?
Một vấn đề khác là chúng ta đã nhiều lần chấp nhận những abstraction sai lầm. Ngày nay trong ngành phần mềm có một kiểu monoculture ngạo mạn tin rằng mình đã đi đến điểm cuối của lịch sử và đã hiểu ra mọi thứ.
Thực tế, tôi cho rằng với khá nhiều công nghệ gần đây, chúng ta đã đi sai đường. Cho đến khoảng năm 2014, mọi thứ dường như đang đi đúng hướng, nhưng sau đó tôi có cảm giác tiến bộ bị thụt lùi và ai cũng bắt đầu dùng cùng những framework được thổi phồng. Khi các công ty ép mọi người dùng những framework này, phát triển phần mềm trở thành một việc kém hiệu quả và làm nản lòng.
Tôi đã tạo một SDK dùng cho dự án cá nhân, và nó giúp tôi năng suất hơn ít nhất 10 lần so với các framework chính thống tôi dùng ở công ty; code cũng dễ đọc và dễ bảo trì hơn nhiều. Đưa cho một junior chưa biết framework này xem thì họ vẫn có thể làm việc hiệu quả. Với SDK này, tôi đã làm một nền tảng no-code BaaS trong 2 tháng làm bán thời gian; còn với các công cụ và framework chính thống, tôi nghĩ tôi hoặc bất kỳ ai khác khó có thể làm xong trong 12 tháng làm toàn thời gian.
Tất nhiên nó có thể có điểm tốt hơn các framework khác, nhưng sự quen thuộc tạo ra chuyên môn, và chuyên môn tạo ra năng suất.
Trước khi vít thạch cao trở nên phổ biến, nhiều thợ lành nghề tin chắc rằng dùng vít chậm hơn và tệ hơn, nhưng chuyên gia đóng đinh lẫn chuyên gia bắt vít đều hoàn thành công việc nhanh và tốt.
Dù là frontend hay backend, đều có lý do khiến chúng ta dùng “những framework này”. Bạn có thể không thích các lý do đó, nhưng lập trình trong doanh nghiệp không chỉ là sự thuần khiết của ngôn ngữ; các yếu tố giúp kiếm tiền như khả năng tuyển dụng, khả năng bảo trì, tính liên tục cũng rất quan trọng.
Nếu công ty dùng SDK tùy biến của bạn rồi bạn rời đi thì sao? Bạn có thể nghĩ nó dễ dạy cho người khác, nhưng các quyết định công nghệ của công ty bao gồm nhiều yếu tố hơn thế rất nhiều.
Câu “nhiều người được gọi là chuyên gia ngày nay chỉ biết cách cấu hình một công cụ đang thịnh hành nào đó, chứ hoàn toàn không hiểu mọi thứ vận hành ra sao ở tầng sâu hơn” thật sự rất thấm.
Ai cũng biết các quy trình học thuộc lòng kiểu “để làm X, hãy thêm dòng này vào file cấu hình”, nhưng khi cần làm thứ gì đó hơi khác X, hoặc một biến thể của X, họ không biết cách bước ra khỏi kịch bản. Tệ hơn nữa, họ còn khiến người khác lãng phí thời gian cố kéo cuộc trao đổi từ not-quite-X quay lại X. Nó gợi tôi nhớ đến ẩn dụ chỉ tìm chiếc ví bị mất dưới cột đèn đường.
Tôi nghĩ việc tạo ra một hệ sinh thái công nghệ, kiểu “techosystem”, nơi người ta vẫn có thể đóng góp chỉ với kiến thức rất hẹp, là điều tuyệt vời. Nói kém tích cực hơn thì điều đó cũng cho phép công ty thuê lao động rẻ hơn, chỉ cần ít kỹ năng hơn.
Trong nhiều trường hợp, tôi tin một giải pháp tầm thường vẫn tốt hơn là không có giải pháp nào. Internet giai đoạn 1995–2005 được xây trên những giải pháp tầm thường, và nó thật sự rất thú vị.
Các chuyên gia đào sâu không phải là loài đang biến mất, cũng không phải là nguồn lực hạn chế nắm giữ tri thức bí mật từ thời trước abstraction. Trái lại, bây giờ họ còn nhiều hơn bao giờ hết. Họ không được định nghĩa bởi việc đã làm từ trên xuống dưới stack hay chưa, mà bởi sự tò mò khiến họ nhìn cả vào những nơi không thuộc tầng của mình.
Bởi vì không chỉ các tầng abstraction phía trên được thêm vào, mà các tầng bên dưới cũng đang thay đổi với NVMe, WebGPU, WebAssembly, QUIC, AVX512, v.v.
Tuy vậy, tôi cho rằng chuyên gia đào sâu là một thứ xa xỉ mà phần lớn đội ngũ không cần, và một trong những năng lực quan trọng nhất của nhà quản lý kỹ thuật là biết khi nào nhất thiết phải tuyển người như vậy.
Sự gia tăng các tầng abstraction là cần thiết. Bộ não con người không trở nên vượt trội hơn nhiều theo từng năm, nhưng số công cụ có thể dùng thì tăng lên, nên để tập trung, ta cần abstraction.
Tôi không nghĩ điều này đồng nghĩa tương lai sẽ u ám. Một lập trình viên xử lý vấn đề kinh doanh có thể rất năng suất trong ngôn ngữ bậc cao mà không cần biết về EUV, compiler, assembly, tập lệnh, kernel, giao thức USB, HTTP, die, substrate, v.v. Phi công cũng không cần biết tất cả về khí động học, độ bền kéo, nhôm, cao su, GPS, v.v.
Tuy nhiên, sự lệch pha về incentive trong xã hội hiện đại là điều rất đáng bàn. Nhìn chung tôi tin phi công hơn lập trình viên phần mềm doanh nghiệp, nhà nghiên cứu hay chủ ngân hàng. Vì nếu máy bay rơi, phi công sẽ là người đến nơi đầu tiên.
Phần mềm cho máy bắn đá cần một cách tiếp cận khác với một ứng dụng CRUD quá tổng quát phơi bày những thứ như số biệt thự bạn sở hữu.
Trên đời có rất nhiều phần mềm ngớ ngẩn, và điều đó cũng ổn. Nhiều “vấn đề thật” cũng khá ngớ ngẩn và không đòi hỏi kỹ nghệ anh hùng.
Trong rất nhiều trường hợp đến đáng sợ, chỉ cần phần mềm tệ hại ghép tạm bợ cũng đủ.
Tôi cũng ghét điều đó, nhưng rồi tôi nghĩ mình chỉ còn cách tự dùng năng lực kỹ thuật vượt trội của mình để tạo một doanh nghiệp, thắng cạnh tranh và chứng minh họ sai, hoặc chấp nhận rằng mình chỉ đang la hét vào mây.
Khi đưa ra quyết định mua sắm, bệnh viện không kiểm tra chất lượng phần mềm vượt quá mức chỉ nhỉnh hơn “nút này không bấm được” một chút.
Cách một bài viết phê phán abstraction lại đặt hyperlink vào câu “ngày nay có những sinh viên thậm chí không biết file và folder là gì” hợp một cách kỳ lạ.
Link đó dẫn đến một thread trên Slashdot, từ đó dẫn tiếp đến một bài của PC Gamer; bài đó viết lại và liên kết đến một bài của Verge, còn bài Verge thì dẫn đến một câu hỏi trên Stack Exchange.
Nói cách khác, đó là lập trình cargo cult. Tôi đã viết về chuyện này 2 năm trước [1], và phản ứng bị phân cực hoàn toàn: hoặc đồng ý, hoặc công kích dữ dội rằng đó là gatekeeping
Giá mà có cách tốt hơn để chữa căn bệnh này mà không chạm vào hệ miễn dịch nghề nghiệp của những kỹ sư đã đầu tư sâu vào công nghệ họ yêu thích
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
Hai người đó không hiểu câu hỏi, nhưng ông ấy cũng không làm rõ câu hỏi hay cân nhắc khả năng vấn đề nằm ở chính câu hỏi
Thành thật mà nói, câu “tôi yêu cầu một chuyên gia React.js so sánh nhiều cách tiếp cận SPA khác nhau như thao tác DOM trực tiếp, template phía client dựa trên MVC, thao tác DOM dựa trên component, cách biên dịch sang vanilla JS” thì tôi cũng không hiểu nghĩa là gì
Tôi không biết “biên dịch sang vanilla JS” là nói về việc biên dịch TypeScript sang JavaScript hay không, và điều đó liên quan gì đến DOM. “Thao tác DOM dựa trên component dựa trên MVC” nghe cũng kỳ. Cảm giác giống một người đã đọc sách về design pattern rồi trừ điểm những ai không dùng cùng thuật ngữ với mình, chứ không giống một người hiểu phát triển phần mềm sâu hơn
Tôi cho rằng những người thật sự tận hưởng cảm giác hài lòng khi làm tốt công việc thường dành nhiều thời gian hơn để thật sự hiểu điều gì đó, so với những người chỉ muốn hoàn thành cho xong
Nhưng sự tò mò đó đem lại gì cho chúng ta? Tôi nhớ đến giai thoại này trong fortune(6), và tự hỏi có bao nhiêu người không tò mò sẽ hiểu được nó
Một người mới học cố sửa một máy Lisp bị hỏng bằng cách tắt rồi bật nguồn. Knight thấy vậy và nghiêm khắc nói: “Anh không thể sửa máy bằng cách chỉ tắt rồi bật nguồn khi còn chưa hiểu điều gì đã hỏng.” Knight tắt rồi bật máy. Máy hoạt động
Nó được dùng như một đòn quyết định kiểu “anh đang gatekeeping, nên tôi thắng”, nhưng đó là một ý nghĩ lố bịch. Không có gì sai khi bảo vệ các tiêu chuẩn chuyên môn cao, và về bản chất đó chính là gatekeeping. Khi đi khám bác sĩ, tôi thấy rất may vì y khoa là một nghề được gatekeeping