Những suy nghĩ đã thay đổi
- Sự đơn giản không tự nhiên mà có, mà là yếu tố đòi hỏi nỗ lực liên tục
- Tôi nhận ra không có lý do gì để tự hào về việc quản lý hay hiểu được sự phức tạp
- Trong một nhóm có trình độ kinh nghiệm pha trộn đa dạng, ngôn ngữ typed là điều bắt buộc
- Java là một ngôn ngữ tuyệt vời chính vì nó nhàm chán
- REPL không hữu ích như một công cụ thiết kế, nhưng lại hữu ích cho việc khám phá
- Việc lập trình thực sự gần như phải hoàn thành xong trước cả giai đoạn viết mã
- Phát triển frontend đã trở thành một lĩnh vực như cơn ác mộng Kafkaesque và không còn vui nữa
- Khái niệm về sự tao nhã không thể trở thành một chỉ số đo lường thực tế
- Quản lý đúng nghĩa là một sự hiện diện vô cùng quý giá (trong sự nghiệp dài của tôi, tôi gần như không thấy nhiều quản lý đúng nghĩa)
- DynamoDB là một cơ sở dữ liệu tốt nếu nó khớp chính xác với một workload cụ thể
- Hướng đối tượng là một cách tiếp cận xuất sắc trong những lĩnh vực phù hợp. Mù quáng tin chỉ có Functional mới đúng là điều ngớ ngẩn
Những quan điểm mới có được
- Cốt lõi của kỹ thuật là giao tiếp
- Không nên áp dụng khái niệm Monad quá cực đoan trong Java
- Query Planner là một sự tồn tại khắc nghiệt
- Khoảnh khắc bạn cảm thấy thứ gì đó là 'dễ' thực ra là dấu hiệu cho thấy bạn chưa hiểu nó đúng mức
- Cần cho lập trình viên mới đủ không gian để khám phá và mắc sai lầm
- Cần chủ động phát triển soft skill. Hiệu quả đầu tư xuất hiện gần như ngay lập tức
- Trong phát triển ứng dụng thông thường, gần như không có thứ gọi là 'trừu tượng thực sự tổng quát'. Tốt hơn hết là chỉ viết phần mã cần thiết
- Ngược lại, phát triển thư viện là công việc thiết kế trừu tượng. Cần dành thời gian để tìm ra cấu trúc đúng đắn (dạng đại số)
- ORM có quá nhiều vấn đề ở mọi ngôn ngữ và mọi cách triển khai. Tốt hơn là cứ viết SQL trực tiếp
- Vấn đề của lập trình Functional thường nằm ở chính những người sùng bái nó
- Sau đủ nhiều thời gian, bạn sẽ cực kỳ hối hận vì đã xây hệ thống trên Serverless Functions
- Type là những khẳng định mà chúng ta đưa ra khi nhìn nhận thế giới
- Distributed lock vẫn là một bài toán cực kỳ khó
- Khả năng mô hình hóa và phân tích hình thức là năng lực bắt buộc phải có
- Thuộc tính quan trọng nhất của bộ kiểm thử tích hợp là tính cô lập
- DynamoDB cũng có thể là lựa chọn tệ nhất cho phát triển ứng dụng thông thường
- Phần lớn mọi người không quá quan tâm đến 'tinh thần thủ công' trong code. Hãy trân trọng những người có quan tâm, nhưng với phần còn lại thì hãy cộng tác với họ ngay từ vị trí họ đang đứng
- Tôi nghĩ ngôn ngữ gradual, dependently typed là tương lai
- Tôi tin rằng có bao nhiêu chú thích trong mã kiểm thử cũng vẫn là chưa đủ
Những quan điểm không thay đổi
- Tôi vẫn nghĩ những người ám ảnh với các vấn đề vụn vặt như code style, quy tắc linting, v.v. là một nhóm khá kỳ lạ. Nên tập trung vào những điều quan trọng hơn
- Tôi vẫn giữ quan điểm rằng code coverage không liên quan đến chất lượng mã (trong nhiều trường hợp thậm chí còn có xu hướng tỉ lệ nghịch)
- Tôi vẫn xem monolith là một lựa chọn ổn
- Tôi thừa nhận rất khó để đánh bại lượng nghiên cứu và cải tiến đã được tích lũy suốt hàng chục năm trong RDBMS
- Nếu muốn áp dụng micro-service thì nhất thiết phải có lý do chính đáng (tôi thấy đáng tiếc khi dạo này nó ngày càng bị xem là điều hiển nhiên)
- Phần lớn các dự án (ngay cả dự án nội bộ của AWS cũng vậy) thực ra không cần 'scaling', và trong nhiều trường hợp việc thiết kế với giả định phải scaling từ đầu còn gây hại
- Tôi nghĩ 93%, thậm chí có thể là khoảng 95.2% project manager có biến mất thì cũng không ảnh hưởng mấy, hoặc thậm chí hiệu quả còn tăng lên (tỷ lệ này đã tăng so với 4 năm trước)
- Tôi dự định sẽ tiếp tục xem đến mốc 15 năm thì mình còn thay đổi thế nào nữa
20 bình luận
Hầu hết đều là những câu chuyện dễ đồng cảm.
Hầu hết các dự án либо sẽ không bao giờ đến lúc cần mở rộng quy mô, либо sẽ biến mất trước khi điều đó trở nên cần thiết...
Ngôn ngữ kiểu phụ thuộc, tiến hóa dần là gì vậy..?
Nghe loáng thoáng trên podcast thì đây là kiểu hệ thống kiểu mà giá trị ảnh hưởng đến kiểu. Thấy tác giả bài này nhắc đến ngôn ngữ hàm nên chắc là đúng chuyện đó.
Vì phía ngôn ngữ hàm đang nghiên cứu và xây dựng mảng này mà...
Ví dụ, kiểu
List... nếu các giá trị đều đã được sắp xếp thì sẽ thànhSortedList...Nếu có tính chất như vậy thì khi biên dịch, kiểm tra kiểu sẽ có thể chứng minh được nhiều thứ hơn.
Nếu có hàm nhận
SortedListvà trả vềSortedList... nhưng nếu trong mã có bug làm phá vỡ trạng thái đã sắp xếp, thì lúc biên dịch sẽ phát sinh lỗi kiểu.Đương nhiên... chi phí của việc kiểm tra kiểu chắc sẽ khá đắt...
Còn mức độ thực dụng của nó hiện đã đến đâu thì tôi cũng hoàn toàn không hình dung được.
À ha, cảm ơn. Nghe thật kỳ diệu...
Được hiểu là các ngôn ngữ có thể linh hoạt chuyển đổi và áp dụng giữa kiểu tĩnh và kiểu động.
Java nhàm chán nên ngược lại lại là một ngôn ngữ tuyệt vời
Ý là gì vậy?
Có lẽ ý là dù ai viết thì cũng na ná nhau nên dễ bảo trì hơn.
Có lẽ ý họ là nó không có điểm gì đặc biệt cần bận tâm thêm hay khiến lập trình viên phải ngạc nhiên, và chính điều đó tự thân mang lại cảm giác ổn định.
Những thứ liên quan đến code style hay linting phần lớn có thể được giải quyết bằng công cụ, nên ngược lại, khi gặp những người không để tâm đến chúng thì tôi thấy không muốn làm việc cùng.
Tôi đồng ý. Tôi đang thêm kiểm tra style vào CI để chặn không cho merge nếu không tuân thủ style.
> Tôi vẫn cho rằng những người ám ảnh với các vấn đề vụn vặt như code style, quy tắc linting, v.v. là một nhóm khá kỳ lạ. Cần tập trung vào những thứ quan trọng hơn.
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Nhưng cũng có ý kiến cho rằng không nên cứ thế bỏ qua, vì đó là những yếu tố khiến con người khó tập trung, nên tốt hơn là giải quyết chúng rồi tiếp tục.
> Phần lớn mọi người không quá quan tâm đến sự 'thủ công tinh xảo' trong code. Hãy trân trọng những người có quan tâm, nhưng với những người còn lại thì cần cộng tác với họ ngay tại vị trí của họ
Đồng cảm..
Từng là một người hối hận vì đã xây hệ thống trên serverless.
Cold start vẫn chậm,
đến một lúc nào đó lưu lượng tăng đột biến khiến nó gần như chẳng khác gì on-demand,
dù đã huy động đủ mọi cách thì việc triển khai vẫn quá chậm.
Tôi nghĩ code coverage chỉ không liên quan đến chất lượng mã trong các trường hợp sau:
Có lẽ chỉ có hai trường hợp đó.
Theo tôi, test code chỉ thực sự có ý nghĩa khi vừa có coverage cao, vừa kiểm thử cùng một phần nhiều lần với các đầu vào khác nhau thông qua nhiều kịch bản đa dạng có thể gây ra lỗi.
Tôi thấy cách hiểu theo nghĩa sau thuyết phục hơn. Con số độ bao phủ mã cao không đồng nghĩa trực tiếp với chất lượng mã, vì điều quan trọng là phải lấp đầy bằng các test case có ý nghĩa.
> Java nhàm chán nên ngược lại lại là một ngôn ngữ tuyệt vời
Nghe buồn cười thật đấy haha
Đồng cảm.
Sau 6 năm làm trong ngành, những chủ đề về phát triển phần mềm mà tôi đã thay đổi quan điểm
Ý kiến trên Hacker News