Chúng ta đang phá hỏng phần mềm

• Chúng ta đang phá hỏng phần mềm khi không còn cân nhắc đến độ phức tạp mỗi khi thêm tính năng hoặc tối ưu một phần cụ thể
• Chúng ta đang phá hỏng phần mềm bằng những hệ thống build phức tạp
• Chúng ta đang phá hỏng phần mềm khi khiến mọi thứ phình to và dễ tổn thương bằng những chuỗi phụ thuộc phi lý
• Chúng ta đang phá hỏng phần mềm khi nói với các lập trình viên mới rằng “Don’t reinvent the wheel!”. Nhưng việc tái tạo lại bánh xe là cách để học cách mọi thứ vận hành, đồng thời là bước đầu tiên để tạo ra những bánh xe mới và khác
• Chúng ta đang phá hỏng phần mềm khi không còn quan tâm đến tính tương thích ngược của API
• Chúng ta đang phá hỏng phần mềm khi thúc ép việc viết lại những thứ vốn đã hoạt động tốt
• Chúng ta đang phá hỏng phần mềm khi lao vào mọi ngôn ngữ, mô hình lập trình và framework mới xuất hiện
• Chúng ta đang phá hỏng phần mềm khi luôn đánh giá thấp độ khó của việc xử lý các thư viện phức tạp sẵn có so với tự triển khai trực tiếp
• Chúng ta đang phá hỏng phần mềm khi cho rằng tiêu chuẩn thực tế của XYZ lúc nào cũng tốt hơn thứ ta có thể tự triển khai cho trường hợp sử dụng cụ thể của mình
• Chúng ta đang phá hỏng phần mềm khi khẳng định rằng chú thích mã là vô dụng
• Chúng ta đang phá hỏng phần mềm khi lầm tưởng phần mềm chỉ là một bộ môn kỹ thuật thuần túy
• Chúng ta đang phá hỏng phần mềm khi tạo ra những hệ thống không còn khả năng thu gọn thêm nữa: trong bất kỳ hệ thống nào, điều đơn giản phải có thể được thực hiện một cách đơn giản
• Chúng ta đang phá hỏng phần mềm khi cố tạo ra mã nhanh nhất có thể mà không nỗ lực làm ra mã được thiết kế tốt nhất có thể
• Chúng ta đang phá hỏng phần mềm, và thứ còn lại sẽ không còn mang đến niềm vui của việc hack nữa

[dohyun682]

Phát minh lại bánh xe <-> phát minh lại thứ đã được viết sẵn

Hai điều này chẳng phải là hai khái niệm hoàn toàn đối lập nhau sao?

[roxie]

Cơn bùng nổ của chú thích đang đến

[tujuc]

Đúng là thấm thật haha Mỗi lần các bạn hậu bối mới vào là tôi lại nghĩ phải chỉ cho các bạn ấy thế nào đây... Có vẻ đây sẽ là một cách hay..

[ilikeall]

Làm ơn đừng đánh nữa TT

[bus710]

....thôi mình sẽ cứ im lặng vậy...

[laeyoung]

Có khá nhiều điểm chồng lấn với “10 dấu hiệu một đất nước suy vong” mà Hàn Phi Tử từng nói.

[GN⁺]

Ý kiến trên Hacker News

• Gợi nhớ đến bài nói chuyện của Jonathan Blow. Phần mềm, nếu không được bảo trì, sẽ suy tàn như mọi thứ khác

  • Kỹ nghệ phần mềm trông có vẻ đang tiến bộ, nhưng thực tế lại đang suy thoái
  • Sự cải thiện của phần cứng và machine learning tạo ra ảo giác về tiến bộ, nhưng độ vững chắc và độ tin cậy cốt lõi của phần mềm thì đang xấu đi
  • Việc phát triển phần mềm hiện đại đã trở nên phức tạp một cách không cần thiết, khiến cả những việc đơn giản cũng trở nên khó khăn
  • Sự phức tạp này làm giảm năng suất của lập trình viên và cản trở việc truyền lại tri thức giữa các thế hệ
  • Xã hội dần chấp nhận phần mềm nhiều lỗi và không đáng tin cậy như một điều bình thường
  • Nếu không đơn giản hóa các hệ thống phần mềm ở mọi tầng, từ hệ điều hành đến công cụ phát triển, nền văn minh có nguy cơ đối mặt với sự thoái lui công nghệ tương tự các cuộc sụp đổ trong lịch sử

• Gợi nhớ đến "10 nguyên tắc của thiết kế tốt" của Dieter Rams

  • Thiết kế tốt là đổi mới
  • Thiết kế tốt làm cho sản phẩm hữu ích
  • Thiết kế tốt mang tính thẩm mỹ
  • Thiết kế tốt làm cho sản phẩm dễ hiểu
  • Thiết kế tốt là không phô trương
  • Thiết kế tốt là trung thực
  • Thiết kế tốt có độ bền lâu dài
  • Thiết kế tốt kỹ lưỡng đến từng chi tiết cuối cùng
  • Thiết kế tốt thân thiện với môi trường
  • Thiết kế tốt là thiết kế ít nhất có thể

• Chia sẻ trải nghiệm làm việc tại một công ty vào những năm 2000

  • Thực hiện công việc với vài chục máy tính, xây dựng phòng máy chủ và triển khai SAN để lưu trữ 3TB dữ liệu
  • Điều phối công việc giữa các máy tính bằng scheduler viết bằng VB6 do nội bộ phát triển để chạy các script Object Rexx
  • Dùng load balancer nội bộ, web server, mail server, FTP server để gửi nhận tệp và sử dụng phần mềm tự phát triển
  • Giờ đây có thể tái tạo toàn bộ thiết lập đó trong vòng một tuần bằng các tệp yaml và dịch vụ đám mây
  • Kiến trúc máy chủ đã được "trừu tượng hóa"
  • Chỉ trích khả năng tương thích ngược, coi đó là một trong những vấn đề của Windows
  • Apple đã phá vỡ khả năng tương thích ngược, chuyển qua 5 thế hệ bộ xử lý và loại bỏ khả năng tương thích mã 32-bit trên chip ARM

• Có nhiều ý kiến trái ngược

  • Cần duy trì khả năng tương thích ngược nhưng vẫn tránh được sự phức tạp
  • Cần tránh các cây phụ thuộc khổng lồ và tự tái tạo bánh xe
  • Cách duy nhất để đáp ứng mọi yêu cầu là không để tất cả mọi người đều viết code
  • Mỗi ngày đều có lúc mong điều đó thành hiện thực, nhưng không thấy tự hào về điều đó

• Chia sẻ trải nghiệm ở công việc đầu tiên

  • Viết phần mềm bằng C, và đó là ngôn ngữ duy nhất khi ấy có thể thực tế để viết phần mềm thương mại
  • Chỉ có một người có thể build, dùng công cụ build thương mại, và cũng là người duy nhất có thể sử dụng công cụ đó
  • Mỗi lần build mất vài giờ
  • Khi đó chúng tôi nghĩ mình đang làm rất tốt

• Ý kiến về lý do chúng ta đang phá hỏng phần mềm

  • Chúng ta phá hỏng phần mềm khi luôn cho rằng tiêu chuẩn thực tế của XYZ tốt hơn thứ được tùy biến cho chính nhu cầu của mình
  • Cách tiếp cận chung có thể dễ dàng chuyển đổi giữa những lời giải nông cho nhiều vấn đề khác nhau
  • Giới kỹ sư thích cách tiếp cận này, nhất là vì họ thường xuyên đổi việc nên có sẵn vài thứ như vậy
  • Nhưng các giải pháp tùy biến thường cho hiệu năng tốt hơn rất nhiều so với giải pháp chung chung

• Mọi phát biểu đều là một sự đánh đổi

  • Trong mọi trường hợp, ta hy sinh thứ này để đổi lấy thứ khác
  • Đôi khi không tái tạo bánh xe là điều hợp lý
  • Đôi khi cần tái tạo bánh xe để học hỏi
  • Nhìn tổng thể, chúng ta đang tạo ra nhiều hơn là phá hủy
  • Không cảm thấy cần phải giữ một lập trường tiêu cực

• Tôn trọng antirez, nhưng cho rằng bài đăng này đầy những phát biểu ngắn nghe kêu nhưng khó trụ vững trong tranh luận

  • Ví dụ: người mới không nên tái tạo bánh xe
  • Họ nên dùng những công cụ sẵn có trong bối cảnh được giao
  • Nếu họ muốn thử nghiệm, họ nên tự viết compiler của riêng mình
  • Nhưng không nên dùng nó trong môi trường production
  • Tính tương thích ngược của API trong đa số trường hợp là một quyết định kinh doanh
  • Bắt đầu mọi câu bằng "chúng ta đang phá hỏng phần mềm" thì không giúp ích gì
  • Nó khiến mọi thứ nghe u ám hơn nhiều so với thực tế

• Ý kiến về đồ thị độ phức tạp/đồ thị phụ thuộc

  • Đồ thị độ phức tạp/phụ thuộc của một ứng dụng ngẫu nhiên là điên rồ một cách tuyệt đối
  • Nó không bao gồm firmware và OS, nhưng cũng đã đủ gần rồi
  • Cần giải quyết vấn đề phụ thuộc bắc cầu
  • Coi OS (Win32 API, Linux syscalls) là phụ thuộc cứng duy nhất của mọi thứ được viết bằng C
  • Nếu chuyển sang Java/Python thì không thể kiểm soát được lớp này
  • Có những tình huống cần tự viết vài trăm dòng code phù hợp thay vì phụ thuộc vào đủ loại thư viện
  • Gánh nặng bảo trì sẽ tăng lên, nhưng bản thân các dependency cũng cần được bảo trì
  • Chúng có thể có API tệ, phá vỡ tương thích một cách ngẫu nhiên, bị bỏ hoang hoặc trở thành malware
  • Giới hạn số dòng cá nhân tối đa cho một dự án hữu ích là 5-10KLOC với Java/JS/Python
  • Có thể review trong vài giờ và dễ dàng chỉnh sửa sau nhiều năm

• Những yếu tố đang phá hỏng phần mềm

  • Phỏng vấn Leetcode, phát triển dựa trên CV, nhảy việc thường xuyên, trò lừa đầu tư tăng trưởng, chơi trò số liệu, săn thăng chức, kịch diễn sprint, và sự ba hoa ở mọi tầng của sơ đồ tổ chức, cùng với sự thờ ơ của toàn ngành