Không có con chó nào bị hại trong quá trình làm ra ứng dụng này
(shmck.substack.com)- Năm 2016, đã mất một tuần để lần theo một lỗi trong tính năng tải ảnh có thông tin vị trí của ứng dụng di động React Native: lỗi chỉ xảy ra trên bản beta Android, còn Android cục bộ và iOS thì không tái hiện được
- Bản beta Android không đưa ra phản hồi lỗi dù việc tải ảnh thất bại, và mỗi lần đưa bản build mới lên Play Store đều mất khoảng 1 giờ, khiến việc kiểm chứng giả thuyết diễn ra chậm chạp
- Khi so với các trường hợp trong hệ thống nhúng, phần cứng, hóa học và thú y, có thể thấy việc gỡ lỗi phần mềm nhanh hơn rất nhiều và khả năng quan sát cũng cao hơn
- Nguyên nhân thực sự là sai khác một ký tự khi ghi MIME type của ảnh là
"jpg"; dù phần mở rộng tệp là.jpgthì MIME type phải là"jpeg" - Môi trường phát triển nơi có thể dùng log, quan sát thời gian thực, debugger và thí nghiệm lặp lại với chi phí thấp gần như là một đặc quyền lớn nếu so với vòng phản hồi của nhiều nghề khác
Tải ảnh chỉ thất bại trên bản beta Android
- Tính năng geolocated photos của ứng dụng di động React Native tưởng như đã sẵn sàng phát hành vào thứ Hai, nhưng sau khi triển khai bản beta Android thì ảnh không thể tải lên
- Các bài kiểm thử Android cục bộ và bản beta iOS đều hoạt động bình thường, nên nguyên nhân thất bại không lộ ra ngay
- Dù đã tải lên lại một phiên bản cải thiện xử lý lỗi, việc tải ảnh vẫn tiếp tục thất bại mà không có phản hồi
- Mỗi lần đưa một bản lặp mới lên Play Store mất khoảng 1 giờ, nên phải vừa chuẩn bị giả thuyết tiếp theo vừa chờ bản build được phát hành
Vòng phản hồi dài hơn ở những nghề khác
- Một kỹ sư hệ thống nhúng từng gặp tình huống sau khi triển khai bản cập nhật firmware cho thiết bị từ xa thì node không còn phản hồi
- Muốn tìm ra nguyên nhân phải thu hồi thiết bị về để phân tích
- Có trường hợp mất vài tháng mới biết chuyện gì đã xảy ra
- Một kỹ sư phần cứng cho rằng phần cứng mới triển khai ở xa có thể chỉ bộc lộ lỗi thiết kế sau khi đã trải qua nhiều mùa
- Họ nhận lại thiết bị cũ qua đường bưu điện rồi đưa bản sửa vào thế hệ sản phẩm tiếp theo
- Có trường hợp thêm lỗ thông gió để giảm nhiệt, nhưng lỗ lại đủ lớn để ong bắp cày làm tổ, biến thành một lỗi còn tệ hơn
- Có thể thử nghiệm trong phòng lab, nhưng việc kiểm chứng cuối cùng rốt cuộc vẫn diễn ra ngoài thực địa
Cách chấp nhận thất bại
- CEO nhớ lại thời còn là nhà hóa học chuẩn bị luận án tiến sĩ, ông đã làm thí nghiệm bằng khoản tài trợ lớn để mua các hóa chất đắt tiền, nhưng vài tuần sau kết quả trông như đã thất bại do lỗi thí nghiệm
- Ông không thể tìm ra điều gì đã sai, và cũng không thể trả lời câu hỏi rằng sẽ làm gì khác đi để tránh lặp lại cùng lỗi đó
- Vậy mà ông vẫn nhận được khoản tài trợ thứ hai, và trải nghiệm này trở thành một ví dụ về lãnh đạo giàu đồng cảm giúp người thất bại có thể đứng dậy lần nữa
Trường hợp thú y cho thấy mức rủi ro cao hơn
- Một người bạn là bác sĩ thú y khám cho một con chó già đang đau bệnh và khuyên chủ đưa nó đi chụp X-ray, nhưng bị từ chối vì chi phí
- Điều tốt nhất có thể làm khi không có X-ray là sờ nắn bụng con chó từ bên ngoài, và đã cảm nhận được một vật lớn
- Thứ được lấy ra bằng phẫu thuật là lõi bắp ngô, nhưng vì không có X-ray nên không thể chắc đó có phải toàn bộ vấn đề hay không
- Ngày hôm sau con chó qua đời; khác với sự cố phát hành ứng dụng di động, thất bại trong những nghề khác đôi khi thực sự liên quan đến sinh mạng
Lỗi một ký tự và đặc quyền của công cụ gỡ lỗi
- Sáng thứ Sáu, người ta nhận ra sự không khớp giữa tài liệu Android và codebase, và nguyên nhân tạo ra vấn đề suốt một tuần chỉ là một ký tự
- MIME type của ảnh được đặt là
"jpg", nhưng thực tế phải là"jpeg", dù tệp được lưu với đuôi.jpg - Lập trình viên phần mềm có thể nhìn sâu vào các quy trình phức tạp, theo dõi hành vi thời gian thực, ghi log, và dừng chương trình bằng debugger để kiểm tra
- Những khả năng này rẻ, nhanh, và cho phép lặp lại thí nghiệm nhiều lần trong ngày chỉ với vài cú nhấp chuột
- Phần mềm cũng có thể quan trọng và có ảnh hưởng lớn như các nghề khác, nhưng nhà phát triển đang làm việc trong một môi trường đáng để biết ơn vì có sẵn các công cụ gỡ lỗi như hiện nay
1 bình luận
Ý kiến trên Hacker News
Đây gần như là một câu chuyện ngụ ngôn cho thấy kỹ nghệ phần mềm khác với các nghề khác, nói đùa là các nghề “thật”, như thế nào
Tôi cũng thích phiên bản ngắn hơn và dí dỏm hơn: một kỹ sư phần mềm, một kỹ sư phần cứng và một trưởng bộ phận đang trên đường đi họp ở Thụy Sĩ thì trên một con đường núi dốc, phanh bị hỏng, chiếc xe đâm vào lan can và lao xuống, rồi kỳ diệu thay dừng lại được
Trưởng bộ phận đề nghị tổ chức một cuộc họp để đặt ra tầm nhìn, sứ mệnh và mục tiêu, rồi giải quyết vấn đề cốt lõi bằng cải tiến liên tục; kỹ sư phần cứng thì bảo hãy dùng dao đa năng Thụy Sĩ tháo phanh ra sửa
Kỹ sư phần mềm nói: “Trước khi làm gì, hãy đẩy xe trở lại lên trên và xem nó có tái hiện lại được không”
Đồng thời, nhược điểm lớn của kỹ nghệ phần mềm cũng là nó xử lý trừu tượng hóa. Mọi thứ, kể cả nền móng, đều dịch chuyển
http://thecodelesscode.com/case/154
Việc có năng lực như vậy không có nghĩa là kỹ sư phần mềm lố bịch hay phi thực tế
Kỹ nghệ trong không gian số cho ta khả năng gỡ lỗi gần như phép màu trong các lĩnh vực vật lý. Nếu muốn tạo 10 món giống hệt nhau và thử theo 10 cách, thì đúng nghĩa chỉ cần CTRL+C, CTRL+V. Tôi muốn thấy thợ máy làm được như vậy
Tôi thật sự chán ngấy những lời phàn nàn kiểu kỹ sư phần mềm không phải là “kỹ sư thật”, và rằng chỉ cần có thêm nhiều cuộc họp thiết kế trước quy mô lớn cùng kế hoạch khổng lồ là sẽ giải quyết được
Các ngành kỹ thuật khác làm việc như vậy không phải vì họ chuyên nghiệp hơn chúng ta nhiều, cũng không phải vì cách đó tốt hơn, mà vì với họ không còn cách nào khác. Sau khi xây xong khách sạn, nếu nhận ra trần cần cao thêm 6 inch, người ta không phá hết rồi xây lại
Nếu họ có thể chạy
ceilingHeight += 6rồi bấm “Rebuild” để khách sạn được xây lại, các unit test tự động kiểm tra cả khả năng tiếp cận, và tổng chi phí là 2,82 đô la, thì chắc chắn họ cũng sẽ làm như vậyHãy bỏ mặc cảm tự ti đi. Chúng ta đang làm kỹ thuật bằng những công cụ mà kỹ sư xây dựng/cơ khí ngoài đời không dám mơ tới, và vì thế quy trình khác đi rất nhiều là điều đương nhiên
Dĩ nhiên cũng có lúc ta không áp dụng đủ quy trình cho vấn đề. Nhưng nếu bạn nghĩ đó là vấn đề riêng của lập trình, tôi muốn kê đơn cho bạn xem https://www.imdb.com/title/tt4788946/ vài giờ
Đây không phải là cảm giác ưu việt; nếu thiếu bất kỳ tiêu chuẩn nào trong số đó, thì bạn không đang làm kỹ nghệ. Theo kinh nghiệm của tôi, phần lớn phát triển phần mềm thiếu cả bốn điều. Điều đó không nhất thiết là xấu, nhưng phần lớn phát triển phần mềm không phải là kỹ nghệ
Hoàn toàn không có ý rằng kỹ nghệ cao cấp hơn phát triển
Giống như khác biệt giữa điêu khắc đất sét và điêu khắc đá cẩm thạch. Nếu sai trên đất sét thì có thể nhanh chóng nắn lại, nhưng nếu đục bỏ phần không nên bỏ trên đá cẩm thạch thì phải đặt một khối đá mới
Mang cách điêu khắc đá cẩm thạch vào thế giới đất sét chỉ khiến bạn thành một nhà điêu khắc đất sét tệ, hoặc ít nhất là cực kỳ kém hiệu quả
Tranh xem điêu khắc đất sét hay đá cẩm thạch có giá trị hơn cũng không có nhiều ý nghĩa. Cả hai đều có chỗ đứng riêng trong xã hội
ceilingHeight += 6trong thế giới thựcHôm nay tôi cũng vừa mô hình hóa và in một món đồ, rồi nhận ra một phần nên dày thêm khoảng 1mm. 30 giây sau, phiên bản 2 đã được gửi tới máy in
Thật sự tuyệt vời. Tôi khó mà chờ được đến khi thứ này phổ biến như máy in giấy
https://www.youtube.com/watch?v=NPVT2lvMvOk
Trong suốt sự nghiệp, không biết bao nhiêu lần đã có chuyện gì đó lỗi mà hoàn toàn im lặng, khiến mọi người bế tắc. Không có output lỗi, không có gì cả
Trong khá nhiều trường hợp như vậy, nguyên nhân là một thư viện bên thứ ba ở tầng thấp đang
catch (e) {}. Trường hợp đầu tiên tôi gặp từ sớm là một bài học hay, và giờ tôi không bao giờ bỏ qua bất kỳ lỗi nào như chuyện hiển nhiên. Ít nhất cũng phải ghi logPhần mềm bạn viết bây giờ có thể được dùng sau 5 năm, trong một môi trường mà bạn hoàn toàn không tưởng tượng được
30 năm sau:
/* X systems I modul body I 14.09.1990 */void xxvcda(int *addr, int sizeof)Người đó cũng không biết tới tính năng ngôn ngữ cho phép nâng ngoại lệ mới từ ngoại lệ cũ để giữ ngữ cảnh của stack trace. Vui thật. Ít nhất đây không phải code công việc chính, nhưng công việc chính thì cũng có những cái vui riêng của nó
DRF nuốt lỗi xác thực và chỉ trả về lỗi chung chung nên không có manh mối nào; cuối cùng tôi phải tự lần xuống và thêm logging để tìm xem chuyện gì đang xảy ra
Một người bạn là nhà vật lý của tôi thường trích câu của Rutherford: “Mọi khoa học hoặc là vật lý, hoặc là sưu tầm tem”
Ý anh ấy là vật lý, khác với toán học hay khoa học máy tính, có cách được kiểm chứng bởi thực tại vật lý
Lĩnh vực của anh ấy là từ trường cực hạn: họ chế tạo những cuộn dây đồng khổng lồ, cho dòng điện chạy qua đến mức sắp nóng chảy, rồi kích nổ thuốc nổ quanh cuộn dây để trong một khoảnh khắc rất ngắn tạo ra từ trường ở tâm mạnh nhất mà con người từng tạo được, sau đó đồng lỏng ở nhiệt độ hàng nghìn độ bắn tung tóe và toàn bộ thiết bị bị phá hủy
Trong môi trường làm việc như vậy, lỗi hay tính sai có nghĩa là con người có thể chết rất nhanh và rất khủng khiếp. Vì thế anh ấy không đồng tình khi các nghiên cứu sinh tiến sĩ toán, những người mà thiệt hại lớn nhất chỉ là áo len dính bụi phấn, tự gọi mình là nhà khoa học
Nói cách khác, hoặc là cố hiểu động lực học của đối tượng, hoặc chỉ dừng ở việc thu thập các sự thật thú vị và đặt tên cho đối tượng quan tâm
Nói cho những ai muốn theo nghiệp siêu phản diện nhưng chưa biết bắt đầu từ đâu: EMP thật sự được tạo ra như vậy
[1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
Sau những chuyện như thế này, tôi luôn mong có biện pháp khắc phục ở thượng nguồn. Nếu có logging và báo lỗi phù hợp thì đã không mất đến một tuần để sửa
Thư viện nhận MIME type
image/jpgsai lẽ ra phải ném ngoại lệ, crash, hoặc ít nhất là ghi log thật rõ. Tôi tự hỏi liệu tác giả gốc có gửi bug cho thư viện đó khôngAnh ấy có quyền truy cập để xác nhận hoặc bác bỏ việc server có thật sự nhận được upload ảnh không? Vì sao trong môi trường test thì upload được nhưng bản phát hành của app thì không? Môi trường test khác gì?
Về lý thuyết, Shawn lẽ ra phải có đủ quyền truy cập để trả lời khá nhanh câu “upload thành công nhưng vì sao không thấy ảnh”, dù là tự vận hành server hay nhờ người có thể chẩn đoán lý do upload thất bại trong im lặng
Theo tôi, bài học quan trọng hơn nhiều so với “MIME type của ảnh là
jpgnhưng đáng ra phải làjpeg” là vì sao test thì chạy còn production thì không. Quan trọng hơn bản thân bug là vì sao môi trường lại khiến bug khó tìm đến vậyTrong trường hợp của tôi, một app desktop bị lỗi nặng nhưng lỗi không được ghi vào log. Mãi vài ngày sau tôi mới biết là file handle đã cạn, và log4net cũng không thể ghi log nếu không lấy được file handle. Cách xử lý bằng việc revert một bản sửa bug nhỏ thì đơn giản, nhưng bản sửa thật sự là tùy biến log4net để luôn giữ file log mở sẵn. Như vậy dù app dùng hết file handle thì lỗi vẫn được ghi lại
Im lặng không phải là mục tiêu. Quá nhiều lập trình viên nghĩ im lặng là mục tiêu, nhưng mục tiêu thật sự là tính đúng đắn. Nếu không có lỗi thì nên yên lặng, nhưng nếu có lỗi ảnh hưởng đến người dùng thì phải có một hộp cảnh báo đỏ thật nổi bật
Tôi nghĩ các lập trình viên nên học cách yêu thích thông báo lỗi. Một thông báo lỗi viết tốt sẽ nhanh chóng chỉ ra nguyên nhân và tiết kiệm rất nhiều thời gian cho mọi người
Nếu lập trình viên này từ nay học được cách hiển thị thông báo lỗi thường xuyên hơn thì đó là một kết quả rất tốt
Tôi nhớ một đồng nghiệp cũ thường nói: “Có phải chúng ta đang làm hệ thống kiểm soát không lưu đâu.” Ý là nếu mắc lỗi thì cũng không liên quan đến sinh mạng
Khi đó chúng tôi đang làm game, nhưng câu ấy cũng áp dụng cho gần như mọi ứng dụng CRUD mà tôi từng viết
Riêng một chuyện khác, tôi thường hỏi các lãnh đạo kỹ thuật cấp cao khác, đặc biệt là Director, VP, CTO: “Sai lầm đắt giá nhất anh/chị từng mắc là gì?” Nếu là kỹ sư junior thì một ngày nào đó rất nên hỏi câu này
Nhiều lãnh đạo kỹ thuật cấp cao có thể kể những câu chuyện ở quy mô 100 nghìn đến 1 triệu đô la. Tôi cũng từng thấy người làm bay hơi vài triệu đô trong một dự án rồi được thăng chức ngay. Hiểu vì sao chuyện đó có thể xảy ra, và thậm chí vì sao nó có thể là điều tốt, là rất quan trọng
Sự bực bội vì một game có bug có thể dẫn đến trả đũa khi lái xe ngoài đời hoặc những cuộc cãi vã lớn tiếng. Có người đã tự tử vì máy tính gửi hóa đơn sai. Cũng có công ty phá sản vì phần mềm làm mất dữ liệu quý giá
Người ta từng bị sát hại vì những ứng dụng mạng xã hội tưởng như nhỏ nhặt, và Twitter từng được dùng để tổ chức kích động thảm sát. Cũng có người bị theo dõi và hành hung do thông tin Pokemon Go làm lộ
Phần mềm có sức mạnh thật sự. Nếu không thì chẳng có lý do gì để viết phần mềm
Tôi từng làm phần mềm có thể làm mất dữ liệu quý giá, và hiện giờ đang làm phần mềm mà nếu trục trặc có thể gây ngập nước
Nên có thêm một chút tự hào về công việc của mình
Là một kỹ sư phần mềm, tôi khá thích gỡ lỗi. Vì nó khiến tôi dùng một bộ kỹ năng và lối tư duy khác với việc tạo thiết kế rồi triển khai
Tất nhiên, điều đó không có nghĩa là gỡ lỗi không gây căng thẳng. Khi phát triển phần mềm tổng đài điện thoại 5ESS của AT&T, chúng tôi có một buổi demo, và trong phòng lab kiểm thử chỉ có đúng một đường dây điện thoại được cấu hình cho tính năng của chúng tôi
Dù thử bao nhiêu lần phần mềm vẫn không chạy, và tôi bị căng thẳng khi kiểm tra mọi thứ có thể, trong khi vẫn tin chắc rằng phần mềm không có vấn đề. Cuối cùng tôi nhờ kỹ thuật viên phòng lab kiểm tra đường dây, thì hóa ra đường dây duy nhất được cấu hình ấy bằng cách nào đó đã bị ngắt kết nối. Một vấn đề phần cứng ngớ ngẩn
Gỡ lỗi các hệ thống phân tán trên cloud kinh khủng hơn theo cấp số nhân so với khi có thể chạy tất cả dịch vụ trên máy local; mà hệ thống phân tán local đó cũng tệ hơn rất nhiều so với khi có thể gỡ lỗi vấn đề trong một chương trình duy nhất
Trình gỡ lỗi thực sự cũng làm việc gỡ lỗi tốt hơn rất nhiều. Tôi chưa bao giờ hiểu những người chỉ khăng khăng chọn một trong hai: gỡ lỗi bằng
printfhoặc dùng debugger thật. Dùng cả hai thì lợi ích khổng lồ cơ mà. Khả năng tracing tốt, nếu có, cũng đáng được nhấn mạnh ở đây vì nó tốt hơn nhiều so với gỡ lỗi bằngprintfHồi mới lập trình, tôi từng gắn rất nhiều cảm xúc không cần thiết vào trạng thái không biết vì sao chuyện này xảy ra; dần dần tôi chấp nhận vòng lặp “Khoan, sao lại thế này? Không biết nữa… à, khoan… ôi, lý do nó không chạy hóa ra lại hợp lý thật!”, và cũng thấm rằng đi đến tận cùng thì cảm giác rất tốt
Giờ đây bản thân trạng thái không biết chỉ có thể bị làm hỏng bởi kỳ vọng và hành vi của người khác. Theo thời gian, tôi học được rằng phải quản lý rất dứt khoát việc chọn ngôn ngữ, lựa chọn kiến trúc, v.v. để làm quá trình này dễ và nhanh
Ở thời điểm này trong sự nghiệp, thuyết phục trước rằng AWS Lambda là một lựa chọn không tốt về hiệu năng, tổng chi phí, khả năng gỡ lỗi và tốc độ phát triển dễ hơn nhiều so với việc sau này thuyết phục rằng có lý do chính đáng cho câu hỏi “sao sửa mỗi vấn đề đó mà lâu thế”
Tôi đã bật cười ở đoạn cuối. Mới hôm qua thôi, ở công ty tôi vừa giải quyết một vấn đề đã hành hạ chúng tôi suốt 3 năm, và nguyên nhân là chữ A
Trong 3 năm qua, có một người đã thực hiện thủ công việc chỉnh sửa dữ liệu vào ra, và nó trở thành một phần công việc của anh ấy. Anh ấy còn đặt lịch lặp trong calendar để dọn dẹp định kỳ. Hàng triệu khách hàng đang phụ thuộc vào một người này để đường dây di động của họ được áp dụng đúng gói dữ liệu
Có thể tưởng tượng được sẽ hỗn loạn thế nào nếu anh ấy quên hoặc đi nghỉ
Cuối cùng nguyên nhân là
if $line->status == STATUS_ACTIVE, trong đó một bên làActive, bên kia làactive. Không có chú chó nào bị thương, nhưng trong nhiều năm đã có một khoản tiền không thể tính được biến mấtNgười đáng thương đó không còn là nhân vật không thể thiếu nữa. Nửa đùa nửa thật thôi. Phần mềm là để làm công việc hiệu quả hơn, nhưng tôi cũng hay xem xét động cơ của con người
Đặc biệt tôi đã rất khổ sở khi điền các trường HL7 trên Mac. Có vẻ ký tự
’nhập từ bàn phím Mac không tương thích với mọi phiên bản HL7, hoặc không khớp với hệ thống nhận HL7 được chuyển sangKý ức đã lâu rồi, nhưng sự khác nhau giữa các từ như
o’clockvào′clockđã làm hỏng việc phân phối báo cáo X-quang. Nó kéo dài nhiều năm trước khi bị phát hiệnHN đang hiển thị
’khác với thứ tôi đã nhập, nhưng vẫn là cùng một ký tự. Khá buồn cười, vì một nửa vấn đề là khi gỡ lỗi không nhìn thấy sự khác biệtSTATUS_ACTIVEđược định nghĩa sai ở một phần nào đó của code không?Luôn có nguy cơ ai đó “tốt bụng” sửa lỗi chính tả
referertrongHttpHeader::REFERRERthànhreferrer. Nhưng lỗi chính tả đó đã bị đóng đinh trong chuẩn HTTP, nên làm vậy sẽ khiến phần mềm hỏng hoàn toàn. Trách nhiệm thuộc về Phillip Hallam-Baker thời CERNGiai thoại về tổ ong bắp cày nghe chẳng xa lạ gì
Chủ cho thuê tòa nhà văn phòng của chúng tôi lắp một giao diện màn hình cảm ứng bên ngoài tòa nhà để có thể gọi tới từng quầy lễ tân và mở cửa. Họ làm vậy vì không có nhân viên tiếp tân nào nhìn thấy được cửa
Thiết bị đó trụ được 6 tháng rồi bắt đầu trục trặc nặng. Nguyên nhân là giao diện, về cơ bản là một chiếc tablet Android màu đen lớn, được lắp ở mặt phía đông của tòa nhà
Đến giữa mùa xuân, mỗi ngày nó nhận đủ nắng để quá nhiệt, làm hỏng mạch cảm ứng và một phần phần cứng màn hình
Với loại phần mềm tôi làm, tôi không phải lo về tải nhiệt
Công ty đường sắt đăng trên Twitter rằng “đã có ùn tắc nghiêm trọng ở khu vực đi qua Lewisham do vấn đề khởi hành gây ra bởi ánh nắng mạnh”
Họ cũng nói rằng mặt trời mùa đông thấp chiếu vào màn hình khởi hành khiến lái tàu không thể nhìn thấy
Tin nhắn “Cuối cùng cũng giải được. Là do chữ ‘E’” thật hài
Những bug đơn giản và nhỏ nhất thường lại là những bug khó tìm nhất. Sáng nay tôi cũng mất một hai tiếng để tìm một lỗi off-by-one
Nguyên nhân là một chỗ
index + 1mà tôi quên thay đổi khi refactor