SWC tập trung vào việc tạo ra mã JavaScript tương thích như Babel và cả bundling, còn cái này tập trung vào việc chuyển mã TypeScript sang JavaScript hoặc kiểm tra lỗi.
Khi viết những đoạn mã đơn giản nhưng khó nhớ (như xử lý nhập xuất tệp, thao tác với container, v.v.)
Khi gặp lỗi biên dịch hoặc lỗi runtime và cần biết đó là lỗi gì, đoạn mã nào là nguyên nhân
Khi muốn viết lại một hàm có chức năng gần giống với hàm đã viết sẵn nhưng thêm một chút khác biệt
Khi muốn thay thế đoạn mã đang phụ thuộc vào một thư viện nào đó bằng thư viện khác hoặc bằng hàm tự viết
Khi cần hướng dẫn nên phát triển theo cách nào để triển khai một chức năng cụ thể, hoặc làm việc trong một môi trường cụ thể
Trong những trường hợp như trên, tôi đã tiết kiệm được khá nhiều thời gian. Nhiều lúc với tổ hợp Google + Stack Overflow cũng không dễ tìm ra, mà đặc biệt trên Stack Overflow thì hễ có câu trả lời nào là trong phần bình luận cũng luôn có rất nhiều ý kiến phản đối, rồi còn chuyện đó là cách triển khai của phiên bản cũ nên không nên dùng nữa, kiểu vậy, nên nhiều khi thấy khá bực mình...
Nếu chia thành 1-2 tuần thì có vẻ tự nhiên chỉ những người rất hạn chế mới biết được bức tranh về một tính năng. Giống như sự khác nhau giữa process và thread vậy. Vì là giới hạn phạm vi quan tâm để nâng cao năng suất mà.
Ngay cả khi có chia sẻ bức tranh đó, thì đây cũng là tiền đề rằng người ta sẽ đặt câu hỏi về bức tranh ấy; nhưng tôi cũng có vẻ đã tự nhiên mặc định rằng theo định hướng thay đổi chút ít ở mỗi lần sprint planning, người ta sẽ không thể khớp được cách đang theo dõi bức tranh lớn.
Khi bị chia nhỏ thành những tác vụ như vậy, người lãnh đạo nắm bức tranh lớn sẽ có quyền hạn rất lớn. Ngược lại, các kỹ sư làm cùng lại dễ mất động lực và rơi vào cảm giác “rốt cuộc chúng ta đang đi về đâu vậy”. Đây là một nhược điểm điển hình của agile dựa trên sprint.
Có vẻ bài viết này được viết quá nhiều từ góc nhìn của người lãnh đạo, đúng như tiêu đề.
Động lực của kỹ sư cũng chịu ảnh hưởng rất lớn bởi việc người lãnh đạo đang giương ngọn cờ theo hướng nào. Có lẽ cũng cần suy nghĩ thêm về cách trình bày giá trị muốn mang đến cho khách hàng là gì, cũng như output của từng sprint và outcome của việc bàn giao là gì. Tất nhiên đây là một soft skill khó, nên cũng hiếm thấy lãnh đạo làm tốt và cũng không có nhiều bài viết hay về chủ đề này.
Tôi hiểu .NET, nhưng tôi nghĩ Rust ở vị trí tương tự như Go. Có lẽ các dự án và thư viện liên quan đến JS được xây dựng sẵn bằng Go trước đây cũng đã ảnh hưởng đến quyết định này.
Ý tưởng thực sự rất mới mẻ, nhưng giống như các bình luận khác, tôi cũng tò mò không biết họ sẽ giải quyết thế nào khi lưu lượng truy cập đổ dồn vào cùng một lúc.
> Nếu mã TypeScript không còn được viết bằng chính TypeScript nữa, thì về lâu dài nhóm có thể sẽ không còn trực tiếp sử dụng TypeScript, điều này có thể ảnh hưởng đến trải nghiệm phát triển.
Người ta hay nói đến việc “ăn thức ăn cho chó của chính mình”, tức là tự trực tiếp dùng thứ mình tạo ra. Nhưng với ngôn ngữ thì đúng là có chút đáng để suy nghĩ.
Tuy nhiên, để áp dụng công nghệ mới nhất (?) thì JUnit4 khá thường xuyên trở thành vật cản, nên cá nhân tôi cũng có một mong muốn nho nhỏ là nó sẽ được chuyển sang JUnit5. https://docs.gradle.com/develocity/test-distribution/
Dùng junit-vintage-engine thì có thể chạy các bài kiểm thử JUnit4 trên JUnit5 mà không cần sửa đổi nhiều, nhưng overhead là khá lớn. (chậm hơn khoảng 20%)
Là người bằng một cách nào đó đã ổn định với vai trò kỹ sư build ứng dụng Android, nếu để lại chút ý kiến thì..
Build: gradle
Dù rất lớn hay rất phức tạp thì vẫn phải dùng gradle... (nhìn xa xăm)
Để cải thiện hiệu năng build của gradle trong các dự án rất lớn hoặc phức tạp, các dự án dưới đây đang được thúc đẩy, nên nếu đang dùng gradle cho dự án lớn thì tốt hơn là nên chuẩn bị migration từ sớm.
Cá nhân tôi cho rằng không nhất thiết phải phơi bày architecture layer ra build system.
Trong trường hợp ứng dụng tôi đang quản lý, tôi để feature-api / feature-impl được phơi bày ra build system dưới dạng module.
feature-app:
mô hình dữ liệu, hoặc interface liên kết với module khác
feature-impl:
phần triển khai thực tế của feature
Nếu cấu hình như vậy, thay đổi mã trong feature-impl sẽ không ảnh hưởng đến các module khác đang tham chiếu feature-api (cô lập dependency), nên rất hữu ích để cải thiện incremental build và tăng build cache hit rate.
Kiểm thử đơn vị - junit 4
Có vẻ đây là điều mà quyết định của Google đã đóng vai trò lớn.
Dạo này các dịch vụ giới hạn số lần hoặc thời gian sử dụng lại đang thịnh hành, nhưng tôi nghĩ liệu nó có bùng lên rồi nhanh chóng lụi tàn như cái ứng dụng nói chuyện kiểu phát sóng từng nổi một thời gian trước đó, mà tôi không nhớ chính xác tên, không nhỉ.
Một người mong muốn TypeScript được biên dịch để cho ra kết quả là tệp nhị phân ngay lập tức
Cảm ơn bạn đã giới thiệu tài liệu hay.
SWC tập trung vào việc tạo ra mã JavaScript tương thích như Babel và cả bundling, còn cái này tập trung vào việc chuyển mã TypeScript sang JavaScript hoặc kiểm tra lỗi.
Cảm giác này khá giống với trải nghiệm của tôi.
Trong những trường hợp như trên, tôi đã tiết kiệm được khá nhiều thời gian. Nhiều lúc với tổ hợp Google + Stack Overflow cũng không dễ tìm ra, mà đặc biệt trên Stack Overflow thì hễ có câu trả lời nào là trong phần bình luận cũng luôn có rất nhiều ý kiến phản đối, rồi còn chuyện đó là cách triển khai của phiên bản cũ nên không nên dùng nữa, kiểu vậy, nên nhiều khi thấy khá bực mình...
Nếu chia thành 1-2 tuần thì có vẻ tự nhiên chỉ những người rất hạn chế mới biết được bức tranh về một tính năng. Giống như sự khác nhau giữa process và thread vậy. Vì là giới hạn phạm vi quan tâm để nâng cao năng suất mà.
Ngay cả khi có chia sẻ bức tranh đó, thì đây cũng là tiền đề rằng người ta sẽ đặt câu hỏi về bức tranh ấy; nhưng tôi cũng có vẻ đã tự nhiên mặc định rằng theo định hướng thay đổi chút ít ở mỗi lần sprint planning, người ta sẽ không thể khớp được cách đang theo dõi bức tranh lớn.
Chẳng phải là chia sẻ bức tranh lớn, rồi khi mọi người đều đã hiểu thì chia nhỏ công việc thành các tác vụ nhỏ sao??
Cảm ơn bạn về bài viết hay.
Khi bị chia nhỏ thành những tác vụ như vậy, người lãnh đạo nắm bức tranh lớn sẽ có quyền hạn rất lớn. Ngược lại, các kỹ sư làm cùng lại dễ mất động lực và rơi vào cảm giác “rốt cuộc chúng ta đang đi về đâu vậy”. Đây là một nhược điểm điển hình của agile dựa trên sprint.
Có vẻ bài viết này được viết quá nhiều từ góc nhìn của người lãnh đạo, đúng như tiêu đề.
Động lực của kỹ sư cũng chịu ảnh hưởng rất lớn bởi việc người lãnh đạo đang giương ngọn cờ theo hướng nào. Có lẽ cũng cần suy nghĩ thêm về cách trình bày giá trị muốn mang đến cho khách hàng là gì, cũng như output của từng sprint và outcome của việc bàn giao là gì. Tất nhiên đây là một soft skill khó, nên cũng hiếm thấy lãnh đạo làm tốt và cũng không có nhiều bài viết hay về chủ đề này.
Mình không rành phần front-end lắm.. vậy cái này khác gì so với swc?
Bây giờ là 8 giờ 40 sáng, mà tôi vô tình nhìn thấy đúng là 7:40:28 PM EST luôn... thú vị thật
Có vẻ như việc ghé McDonald's sẽ rất dễ dàng. Có lẽ đó sẽ là một trải nghiệm thú vị.
Tôi hiểu .NET, nhưng tôi nghĩ Rust ở vị trí tương tự như Go. Có lẽ các dự án và thư viện liên quan đến JS được xây dựng sẵn bằng Go trước đây cũng đã ảnh hưởng đến quyết định này.
Ý tưởng thực sự rất mới mẻ, nhưng giống như các bình luận khác, tôi cũng tò mò không biết họ sẽ giải quyết thế nào khi lưu lượng truy cập đổ dồn vào cùng một lúc.
Có vẻ như bạn đang nói đến runtime như Node, còn điều đang được nhắc tới ở đây là trình biên dịch của chính ngôn ngữ TS.
> Nếu mã TypeScript không còn được viết bằng chính TypeScript nữa, thì về lâu dài nhóm có thể sẽ không còn trực tiếp sử dụng TypeScript, điều này có thể ảnh hưởng đến trải nghiệm phát triển.
Người ta hay nói đến việc “ăn thức ăn cho chó của chính mình”, tức là tự trực tiếp dùng thứ mình tạo ra. Nhưng với ngôn ngữ thì đúng là có chút đáng để suy nghĩ.
Tuy nhiên, để áp dụng công nghệ mới nhất (?) thì JUnit4 khá thường xuyên trở thành vật cản, nên cá nhân tôi cũng có một mong muốn nho nhỏ là nó sẽ được chuyển sang JUnit5.
https://docs.gradle.com/develocity/test-distribution/
Dùng
junit-vintage-enginethì có thể chạy các bài kiểm thử JUnit4 trên JUnit5 mà không cần sửa đổi nhiều, nhưng overhead là khá lớn. (chậm hơn khoảng 20%)Là người bằng một cách nào đó đã ổn định với vai trò kỹ sư build ứng dụng Android, nếu để lại chút ý kiến thì..
Dù rất lớn hay rất phức tạp thì vẫn phải dùng gradle... (nhìn xa xăm)
Để cải thiện hiệu năng build của gradle trong các dự án rất lớn hoặc phức tạp, các dự án dưới đây đang được thúc đẩy, nên nếu đang dùng gradle cho dự án lớn thì tốt hơn là nên chuẩn bị migration từ sớm.
Cá nhân tôi cho rằng không nhất thiết phải phơi bày architecture layer ra build system.
Trong trường hợp ứng dụng tôi đang quản lý, tôi để
feature-api/feature-implđược phơi bày ra build system dưới dạng module.Nếu cấu hình như vậy, thay đổi mã trong
feature-implsẽ không ảnh hưởng đến các module khác đang tham chiếufeature-api(cô lập dependency), nên rất hữu ích để cải thiện incremental build và tăng build cache hit rate.Có vẻ đây là điều mà quyết định của Google đã đóng vai trò lớn.
Tuy nhiên, plugin screenshot testing được phát hành gần đây lại dựa trên JUnit5.
Có vẻ là Clubhouse nhỉ, đúng lúc tôi cũng nghĩ ngay đến cái đó.
Dạo này các dịch vụ giới hạn số lần hoặc thời gian sử dụng lại đang thịnh hành, nhưng tôi nghĩ liệu nó có bùng lên rồi nhanh chóng lụi tàn như cái ứng dụng nói chuyện kiểu phát sóng từng nổi một thời gian trước đó, mà tôi không nhớ chính xác tên, không nhỉ.
Ồ, thật là một vinh dự cho dòng họ Huh.