Có thể làm được (2003)
(multicians.org)- Trong quá trình cải tổ hệ thống tệp Multics tại Honeywell Cambridge, André Bensoussan phụ trách VTOC manager, một hệ thống con cốt lõi, và thực hiện từ thiết kế đến kiểm thử
- Mô-đun này phải chuyển thông tin mô tả tệp giữa đĩa và bộ nhớ, đồng thời quản lý cả buffer pool lẫn không gian đĩa, nên trên thực tế nó gần như là một trình quản lý bộ nhớ ảo cỡ nhỏ
- André không viết mã trực tiếp trước terminal mà dùng bút chì để trau chuốt sơ đồ và mã, cố gắng tạo ra một thiết kế đối xứng vừa chứa thông tin trạng thái vừa hài hòa
- Sau khi nhập bản thảo cuối cùng, các vấn đề xuất hiện ở lần biên dịch đầu tiên chỉ là 3 lỗi gõ sai
- Khi bind vào hệ thống, chương trình chạy thành công ngay từ lần thử đầu tiên
- Về sau chỉ phát hiện một lỗi duy nhất do Tom Van Vleck đã truyền đạt sai thứ tự gọi của thủ tục xử lý lỗi, cho thấy mức độ hoàn thiện của chính chương trình là rất cao
Công việc với Multics VTOC manager
- André Bensoussan đã làm việc trên hệ điều hành Multics tại Honeywell Cambridge cùng với Tom Van Vleck
- Một thay đổi lớn trong hệ thống tệp đòi hỏi một hệ thống con tên là VTOC manager
- Di chuyển thông tin mô tả tệp giữa đĩa và bộ nhớ
- Quản lý buffer pool trong bộ nhớ dùng chung
- Quản lý không gian đĩa dành cho thông tin tệp
- Vì vai trò đó, VTOC manager phải hoạt động như một trình quản lý bộ nhớ ảo cỡ nhỏ
- André phụ trách thiết kế, triển khai và kiểm thử mô-đun này
Chương trình được hoàn thiện bằng bút chì
- André trước hết ngồi tại bàn và vẽ rất nhiều sơ đồ
- Ông muốn một hình thức vừa chứa đầy đủ thông tin trạng thái, vừa đẹp mắt và đối xứng
- Thậm chí mọi người xung quanh còn lo rằng tiến độ viết mã đang bị chậm lại vì lịch trình
- Việc viết mã cũng được thực hiện bằng bút chì chứ không phải trên terminal
- Ông từ chối sự hỗ trợ gõ máy
- Ông viết lại một số phần, chép lại, xóa đi và sửa tiếp để tạo ra bản thảo cuối cùng
- Sau khi nhập toàn bộ bản thảo bút chì cuối cùng vào terminal, lần biên dịch đầu tiên thất bại, nhưng sau khi sửa 3 lỗi gõ sai thì biên dịch thành công
- Khi bind vào hệ thống để chạy, nó đã hoạt động ngay từ lần thử đầu tiên, và sau đó VTOC manager tiếp tục hoạt động hoàn hảo
- Lỗi duy nhất được phát hiện là do Tom Van Vleck, khi André hỏi về thứ tự gọi của thủ tục xử lý lỗi, đã đoán và trả lời mà không kiểm tra
- Khi đường đi lỗi đó lần đầu tiên được kích hoạt, hệ thống đã bị crash
- Ngoài điều đó ra thì chương trình không có vấn đề gì
1 bình luận
Ý kiến trên Hacker News
Tôi cho rằng lý do chính ông ấy làm được như vậy là vì yêu cầu được xác định cực kỳ rõ ràng
Một lý do lớn khiến phần mềm ngày nay nhiều lỗi và chậm là vì không ai thật sự biết mình đang xây dựng cái gì, hoặc nếu biết thì nó vẫn liên tục thay đổi vì “Agile”
Nếu đưa cho lập trình viên một API rõ ràng và các tiêu chí được định nghĩa tốt, đa số họ sẽ viết ra mã chạy rất ổn
Yêu cầu không phải là việc xếp danh sách và ticket lên bảng Kanban, mà là thật sự học miền nghiệp vụ của thứ cần xây dựng
Bạn vẫn có thể xây dựng một lĩnh vực mình không hiểu, nhưng sản phẩm rất dễ thành rác; và nếu coi quá trình viết thứ rác đó là một bản nháp để học bài toán miền nghiệp vụ cùng các lời giải khả dĩ thì cũng ổn
Không có đường tắt nào cho chất lượng
Nếu là bên liên quan, bạn cần có khả năng tiếp cận người xây dựng ứng dụng và xác nhận rằng họ hiểu miền nghiệp vụ. Có thể làm được điều đó mà không cần liên tục quấy rầy họ
Hãy cẩn thận với những kẻ ba hoa chỉ biết tuôn ra buzzword
Nếu là nhà thiết kế và lập trình viên, bạn cần đảm bảo rằng bên liên quan và chuyên gia miền nghiệp vụ đang chủ động và thực sự tham gia. Nếu không, việc moi yêu cầu và hiểu biết ra sẽ khó như nhổ răng
Một số bên liên quan thậm chí có thể không muốn giải quyết vấn đề, hoặc vốn muốn một hướng hoàn toàn khác, hoặc đang khó chịu vì lý do chính trị. Không gì làm dự án chìm nhanh bằng một bên liên quan lười biếng hoặc thờ ơ
Bên liên quan không biết mình muốn gì nhưng vẫn đòi thêm tính năng hoặc thay đổi lớn một cách gần như ngẫu nhiên
Cuối cùng phải xử lý vô số ngoại lệ vì cố ép công cụ này làm cả những việc nó không nên làm
Nhà thiết kế thường tạo ra thiết kế mâu thuẫn với các chức năng cần có, cách hệ thống hiện tại vận hành và yêu cầu của bên liên quan; còn các nhóm phát triển từng phần của hệ thống thì làm trong silo mà không giao tiếp đàng hoàng
Một quy trình “Agile” được thiết kế tồi sẽ cố nhồi mọi thứ vào một khoảng thời gian nhất định dựa trên cách chấm điểm đáng ngờ
Rốt cuộc, những vấn đề này khiến hệ thống không hoạt động như dự định hoặc biến nó thành một đống lỗi
Nếu tạo được môi trường nơi yêu cầu rõ ràng và không thay đổi, các thành viên dự án giao tiếp tốt và có thể kiểm soát hoàn toàn quy trình, mọi thứ sẽ ổn. Trường hợp trong bài gốc trông cũng như vậy
Tôi chủ yếu làm ở các công ty lớn, và 90–99% công việc đi vào là các trường hợp trung bình
Nhưng có vô số trường hợp đặc biệt kiểu kỳ lân, ba năm mới xảy ra một lần, lại đúng lúc nguyệt thực và nhật thực xảy ra cùng lúc còn các phù thủy đang đọc thần chú trong rừng
Vì phải triển khai những trường hợp này trong code thay vì xử lý thủ công, lỗi sẽ phát sinh, và lượng code cần review cũng như bảo trì tăng lên rất nhiều
Đừng bắt đầu nói về bảo trì. Đó là chỗ đau đấy
Yêu cầu luôn thay đổi. Nó giống như một lực tự nhiên, và không có thế giới nào nơi mọi người ngay từ đầu đã biết cần xây gì, nhận được một API được đặc tả hoàn chỉnh rồi chui vào hang chỉ việc triển khai
Thực tế tuyệt đối không vận hành như vậy, và nếu bạn cần những điều kiện đó thì kỹ nghệ phần mềm không phải nghề phù hợp
Nếu không có người dùng thì phần mềm của tôi đã hoàn hảo rồi ;)
Tôi từng làm việc với một người đào tẩu khỏi Liên Xô. Ông ấy nói lý do các lập trình viên Liên Xô giỏi là vì khả năng tiếp cận máy tính rất hạn chế
Nếu phải lập trình bằng bút chì và giấy, bạn sẽ muốn nó chạy được ngay lần đầu
Tình cờ là lúc đó chúng tôi đang làm ở Honeywell
Vậy đây là một phương pháp đào tạo tốt, hay là một bộ lọc tốt để loại những người ít động lực hơn?
Ở trường chúng tôi không thể dùng máy tính trong giờ học, nên đã quen lập trình và thậm chí debug trên giấy
Tôi về nhà, nhập vào và chạy thử, tò mò không biết mình có tái hiện được giai thoại về Multics từng đọc trước đây không
Lần biên dịch đầu thất bại, nhưng sau khi sửa một tên biến thì nó chạy hoàn hảo
Tôi nhớ trong vài năm, ở vòng lặp sửa→biên dịch→in ra, bản listing in tốt hơn terminal nhiều. Vì rất khó xem, di chuyển và chỉnh sửa code một cách hiệu quả
Cuối cùng mọi thứ được cải thiện nhờ các trình soạn thảo trực quan tốt hơn, terminal lớn hơn, biên dịch và chạy nhanh hơn
Ví von thì giống như súng thời kỳ đầu. Giống giai đoạn chuyển tiếp khỏi cung dài kém hiệu quả vì thuốc súng bị ướt, cơ chế đánh lửa bằng đá lửa không ổn định, và mọi thứ đều phải nhồi vào nòng súng
Trong thread HN trước đây của bài này có một bình luận hay từ tài khoản jrd259, người từng làm việc với André: https://news.ycombinator.com/item?id=18415231
Nội dung liên quan đến tầm quan trọng của một chiếc bàn rộng và không gian làm việc riêng không có thông báo
Tôi nhớ đến hai lần trong đời mình đã lập trình trên giấy
Lần đầu là khi khoảng 10–12 tuổi. Tôi đến nhà ông bà, nơi không có máy tính cũng không có smartphone, nhưng có một chiếc máy đánh chữ cơ học có thể chuyển giữa màu đen và đỏ bằng công tắc
Sở thích chính của tôi lúc đó là Turbo Pascal, nên tôi đã dùng máy đánh chữ để viết một chương trình Pascal, để sau này về nhà nhập vào PC và chạy
Vì ở nhà ông bà một tuần, tôi có đủ thời gian để suy nghĩ kỹ, debug bằng tay và gõ lại những chỗ sai
Lần thứ hai liên quan đến ngôn ngữ lập trình khó hiểu Ziim do tôi tạo ra (https://esolangs.org/wiki/Ziim) và hàm cộng nhị phân trên trang đó
Hàm đó rất lớn, phức tạp và có lỗi. Vì đã chạy thử trong interpreter nên tôi biết nó có bug, nhưng không biết lỗi nằm ở đâu hay sửa thế nào
Đúng lúc tôi có chuyến xe buýt đường dài khoảng 6 tiếng, và đó là cơ hội hoàn hảo để debug
Tôi chép hàm cộng của Ziim bằng bút chì lên giấy kẻ ô rồi thực thi từng bước bằng tay trên xe buýt. Tôi đã tìm ra và sửa được bug, và phải bố trí lại toàn bộ hàm
Có vẻ bài học là đôi khi, nếu cố tình hạn chế khả năng làm theo cách dễ dàng, ta có thể viết ra mã được cân nhắc kỹ hơn
Dù vậy bình thường tôi không làm thế. Tôi cũng sẵn sàng viết đại một snippet rồi lặp lại, hoặc chạy từng dòng bằng debugger. Có lẽ tôi nên nghĩ lại
Nhưng nếu làm mọi thứ trên giấy, cuối cùng nó cũng chẳng khác mấy so với làm trực tiếp trên máy tính. Ta sẽ ghi hết mọi thứ ra, và đánh mất sự trừu tượng hóa cùng sự thận trọng đó
Khi tôi bắt đầu, đó là giai đoạn cuối của thời kỳ “máy tính lớn”
Ngày xưa, “lập trình viên” thường gần giống nhân viên nhập liệu hơn, và thường là phụ nữ
Những người viết phần mềm thì viết chương trình trên giấy trong những văn phòng đầy khói thuốc
Thời gian dùng máy tính đắt đỏ và khan hiếm. Nếu gặp bug khi chạy, bạn không có cơ hội sửa cho đến khi lại đặt được lịch nhập liệu và thêm một lượt thời gian CPU nữa
Vì vậy cách tiếp cận đo hai lần, cắt một lần được khuyến khích
Phần lớn phần mềm thời đó cũng khá đơn giản so với những gì ngày nay ta xem là đương nhiên, nên làm vậy dễ hơn. Ngoài ra, input/output của phần mềm bị giới hạn cực kỳ nhiều, thậm chí chưa có khái niệm UI, còn kết nối thiết bị ngoại vi là chuyện lớn
Ngày nay khi viết phần mềm, ta thường theo kiểu “ném lên tường xem cái gì dính”. Viết mã nửa vời rồi debug trong IDE thì dễ hơn
Quá trình phát triển phần mềm của tôi khá lặp đi lặp lại, và tôi từng viết về điều đó ở đây: https://littlegreenviper.com/miscellany/evolutionary-design-...
Tôi nhớ một bài tập đại học yêu cầu viết một kernel hệ điều hành đơn giản
Tôi không rành C, và cũng chỉ biết kernel làm gì ở mức lý thuyết, nhưng phải viết vài trăm dòng C để quản lý tác vụ
Tôi nghĩ nếu chương trình này không chạy, thì vì là mã song song nên gần như không có cách debug, và bug sẽ xuất hiện dưới dạng những race condition không xác định
Tôi suy luận toàn bộ hệ thống, rồi trong vài ngày viết rất nhiều hàm nhỏ, độc lập sau khi suy nghĩ rất kỹ
Sau đó tôi compile và chạy, và sau khi sửa lỗi compile hiển nhiên kiểu “thiếu dấu chấm phẩy”, nó chạy ngay từ lần đầu
Mỗi khi có một thành tựu ấn tượng được đăng lên, phần bình luận nhìn chung lại bắt bẻ. Mong là dừng lại đi
Họ không phải là người thiết kế trình quản lý bộ nhớ ảo cho một hệ điều hành mới, mà chỉ là bánh răng trong cỗ máy biến truy vấn SQL thành HTML để hiển thị quảng cáo cho trẻ em và người già
Không thể không trở nên hoài nghi và cay đắng
Thật ra không nên dừng. Tranh luận vốn phải như vậy
Ở mức nào đó thì đúng, nhưng câu hỏi tốt hơn để xoay theo hướng tích cực là: trong môi trường công ty ngày nay, làm thế nào để đạt tới trạng thái mà một thành tựu tương tự là khả thi?
Mỗi khi thấy phản ứng kiểu này thì phần lớn là như vậy. Cái rây điều chỉnh của người dùng chỉ cần một chút thời gian để đẩy các bình luận tốt hơn lên trên
Nếu người này đối mặt với thử thách mà tôi đã trải qua, chắc hẳn đã gục ngay tại chỗ
Phần mềm thời đó nhỏ hơn nhiều
Ngày nay, chỉ cần lớn hơn một chương trình đồ chơi một chút thì đa số dự án đã tính bằng megabyte, và việc “viết ra” thành một tệp duy nhất là bất khả thi
Cái này lớn và phức tạp hơn những gì phần lớn chúng ta làm ngày nay. Nhiều công việc hiện nay gần như là mã keo phóng đại để ghép các thứ như CRUD/REST lại với nhau
Nó có thể nhỏ hơn tổng số dòng mã của cả dự án, nhưng lớn hơn đơn vị mà mọi người thường xử lý. Hơn nữa, đây cũng chỉ là một phần của toàn bộ mã hệ điều hành
Đây là toàn bộ “trình quản lý quản lý thông tin mô tả tệp”. Nó phải vận chuyển thông tin tệp giữa đĩa và bộ nhớ, quản lý vùng đệm bộ nhớ chia sẻ, và còn phải quản lý cả không gian đĩa cho thông tin đó
Thử yêu cầu phần lớn lập trình viên hiện nay viết ngay hôm nay, bằng ngôn ngữ họ chọn, một thứ có cùng yêu cầu và ngữ nghĩa như vậy xem sao
Đa số sẽ lạc lối ngay từ giai đoạn tưởng tượng ra nó. Chưa nói đến việc viết ra giấy rồi nhập vào để chạy được còn khó hơn nhiều
Một phần nhỏ trong đó là URL linh kiện điện tử, nhưng gần 90% chỉ là văn bản tiếng Anh. 10% nữa là trích dẫn từ bài viết của người khác, trang web, application note của nhà sản xuất, sách, v.v.
Nó là một tệp duy nhất, và có lẽ sẽ tiếp tục là một tệp duy nhất không chỉ trong phần còn lại của năm nay mà còn lâu hơn. Nếu tiếp tục với tốc độ đó thì sẽ thành 12 megabyte. Hoàn toàn không phải điều bất khả thi
Nếu quan tâm, bạn có thể git clone http://canonical.org/~kragen/sw/leatherdrink.git
Hiện tại tôi đã commit cả toolchain avr nên nó gần 200 megabyte, và cũng có những thứ như ảnh, video, sơ đồ mạch
Nếu là ngôn ngữ lập trình thì số byte tăng thêm mỗi tháng sẽ ít hơn, nhưng có lẽ chênh khoảng năm lần
Mã do André Bensoussan viết nằm ở đây: https://multicians.org/vtoc_man.html
Khi ngồi vào bàn để bắt đầu làm việc và chuẩn bị hoàn thành việc mình đang ngại làm, tất nhiên là tâm trí tôi lại xao nhãng và muốn lên reddit hay HN xem tin tức
Mở HN ra thì tiêu đề đầu tiên là cái này
“Bạn có thể làm được”
Thế là có động lực
Tái bút: tất nhiên là tôi cũng đã đọc bài :)
“André đã làm việc này thế nào khi không có công cụ nào ngoài cây bút chì?”
Khi tôi vào cấp ba ở tuổi 14, trong lớp lập trình, phần lớn mã chúng tôi viết trên giấy
Tôi là một đứa trẻ nghèo ở một đất nước nghèo, không chỉ không có PC ở nhà, mà vài cái “máy tính” trong phòng máy của trường cũng là các bản sao ZX Spectrum, không chạy được Turbo Pascal, ngôn ngữ lập trình chúng tôi dùng lúc đó