Đã 2 tháng kể từ ngày ban hành điều lệ Front-end. Tối hôm qua, tôi đi khảo sát và lấy ý kiến về việc áp dụng Điều lệ Front-end tác động như thế nào đến hiệu quả code, chất lượng code và khả năng cộng tác nhóm.

Sau 2 tháng áp dụng điều lệ Front-end, hãy chia sẻ cảm nhận của bạn về:

1/ Chất lượng code
2/ Khả năng phối hợp team như thế nào?
3/ Bạn có đề xuất cải tiến phần nào trong điều lệ không?

Team Member:

1/ [Code Quanlity] Về phần này thì em chưa có kinh nghiệm nhìn nhận cũng như ít nhìn code của những anh/ bạn/ em khác nên em cũng không đánh giá được, nhưng về riêng bản thân em thì nó cho mình 1 cái kỷ luật để khuôn khổ rất tốt.
2/ [Collaboration] Về vấn đề này thì rất ổn nhưng nhiều lúc code rải rác mình vào mình support các bạn thì rất khó để theo luồng.
3/ [Suggestion] Về phần này em nghĩ chắc là tách component, khi 1 file có quá nhiều dòng, từng function nằm rải rác thì cũng rất khó theo dõi.

Cảm ơn bạn!
Điều này chứng tỏ khâu [Collaboration] của teammate, chưa tuân thủ điều lệ 2.1/ Kiến trúc Module và 2.2/ Phân bổ Code trong 1 file JavaScript dẫn đến việc khó xác định nơi phân bổ code, và khó hình dung được luồng, khi support cho team member khác.
Ghi nhận đề xuất của bạn: Hướng dẫn tách Component theo cách khoa học hơn.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Về cái thứ 1, thì em thấy code nó ổn hơn, các phân đoạn có vẻ là ổn hơn.
2/ [Collaboration] Còn về cái thứ 2, phối hợp team thì cái này em ko rõ lắm. Tại vì thường em code một mình một phần, nếu có liên quan tới các bạn khác thì cũng không nhiều, đa số chỉ là 1/2 phần bé bé xinh xinh em cũng ko cần phải nghiên cứu code mọi người rõ lắm ạ, chỉ cần xác định chỗ để cắm rễ là xong ạ.
3/ [Suggestion] Còn cái thứ 3, hiện tại thì em còn đang làm quen (tại code front-end hơi ít) nên nếu được em vẫn muốn theo rule thêm 1 thời gian nữa rồi mới đề xuất hay ý kiến gì hơn ạ.

Cảm ơn bạn!
Tôi rất thích chữ "cắm rễ" của bạn, khi Interface được thiết kế hoàn hảo, thì việc còn lại là giao tiếp I/O giữa các Hộp Đen với nhau. Điều này hoạt động cực kỳ tốt khi có được 1 ông Architector thiết kế hệ thống giao thông hoàn hảo.
Nhưng vẫn có 1 chút dependency ở đây: Bạn luôn ngồi ở đó khi chúng tôi cần bạn!
Ghi nhận đề xuất của bạn: Thiết kế Interface kỹ lưỡng

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Dạ sau khi áp dụng điều lệ front-end thì em cảm nhận chất lượng code rất oke.
2/ [Collaboration] Khả năng phối hợp team ổn
3/ [Suggestion] Tạm thời em chưa có đề xuất cải thiện nào hết ạ

Cảm ơn bạn!

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Trong khoảng thời gian trên thì hầu hết các task em thực hiện đều là các task dựa trên nền code cũ (các dự án trước khi có điều lệ) nên cũng chưa được chú ý thực hiện sát sao các điều lệ.
2/ [Collaboration] Em cũng có đọc qua thì thấy nếu có tập điều lệ cho front-end thì sẽ hỗ trợ rất nhiều, tạo một mô hình chung khi implement code cũng như là giúp ích cho việc dò bug.
3/ [Suggestion] Nội dung điều lệ front-end thì em thấy nên bổ sung thêm các ví dụ (bad practices) cụ thể thì người đọc dễ nhận biết (thấy bản thân mình trong đó :D), ngoài ra, trong quá trình xem các code cũ thì cũng có một số trường hợp quy định các array (columnDefs) cứng hoặc json cứng, mình có thể thêm quy định về việc chuyển các biến array hoặc json cứng đó ra một file riêng biệt để dễ quản lý cũng như thao tác

Cảm ơn bạn!
Tôi thích thành ngữ "thấy bản thân mình trong đó" của bạn, chỉ rõ điểm yếu, họ không sửa ngay, nhưng họ sẽ thấm dần
Ghi nhận đề xuất của bạn:

1. Bổ sung các ví dụ Bad Practices
2. Phân ra một vùng riêng hoặc 1 file configuration riêng dành cho Collumn Definition

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Chất lượng code tăng, ít lỗi hơn.
2/ [Collaboration] Khả năng phối hợp team tốt hơn (dễ hỏi và dễ xác định lỗi sai hơn).
3/ [Suggestion] Vì thỉnh thoảng có một số view cần custom CSS lại nên em có đề xuất nên thêm 1 vài quy tắc đặt tên class CSS để đồng bộ, dễ đọc, tránh trùng lặp

Cảm ơn bạn!
Vấn đề CSS này, đúng là chúng ta chưa đầu tư nghiên cứu cho việc chuẩn hóa mô hình Apply CSS cũng như điều lệ dành cho CSS.
Xài riêng quá thì chỉnh nhiều nơi khi có thay đổi
Xài chung quá thì khi chỉnh 1 chỗ phải nơm nớp lo sợ có ảnh hưởng chỗ khác hay không
Nhưng có 1 vấn đề mà tôi thấy cần tìm giải pháp gấp, đó là vì tính chất Override CSS toàn cục, khi tôi qua 1 menu khác, màn hình khác, rendering Engine nó nạp CSS trùng định danh (do mình chưa có Rule), rồi trở về menu trước đó, thì giao diện vỡ toang
Vấn đề này chúng ta phải đối diện, do sử dụng mô hình Single Page Application & Lazy Loading. Chúng ta cần có Rule để giữ được thế mạnh và loại bỏ điểm yếu
Ghi nhận đề xuất của bạn: Bổ sung Rule cho Style Sheet (CSS)

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Dạ! Em thấy khá là ổn.
2/ [Collaboration] Áp dụng vào sẽ giúp dể phối hợp hơn ạ.
3/ [Suggestion] Hiện tại phần front end thì em làm chưa nhiều nên cũng chưa áp dụng rule vào phần code thực tế. Nếu có góp ý gì em sẽ raise lên ạ.

Cảm ơn bạn!

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Member:

1/ [Code Quanlity] Em thấy chất lượng code được tốt hơn, clean code hơn dễ đọc hơn trước nhờ cấu trúc phân bổ code, qui định tên file, biến, hàm... theo cấu trúc của điều lệ.
2/ [Collaboration] Em cảm thấy khá ổn nhờ vào việc áp dụng điều lệ giúp em có thể dễ đọc code của các bạn Dev hơn nhưng vẫn còn một số vấn đề, em sẽ trình bày trong phần góp ý đề xuất.
3/ [Suggestion] Vẫn biết là khi các anh đưa ra nhưng điều lệ, nguyên tắc chắc chắn là sẽ tốt cho dự án khi được áp dụng, nhưng bên cạnh đó em vẫn còn một số chỗ chưa được làm rõ ràng (clear), là lý do vì sao lại sử dụng nó (ví dụ như điều lệ số 7: Bắt buộc dùng Async-Await cho Axios???), em đề xuất nên có một buổi họp để đi qua từng case trong các điều lệ để làm rõ là tại sao lại sử dụng điều lệ đó, sử dụng nó sẽ tối ưu như thế nào so với việc không sử dụng, hoặc viết điều lệ một cách rõ ràng, rành mạch hơn cho từng case khi áp dụng, em tin khi hiểu rõ được lý do phải sử dụng điều lệ vào dự án sẽ giúp cho DEV hiểu được tốt hơn, ý thức hơn khi code chứ không chỉ đơn thuần áp dụng chỉ vì case này nằm trong điều lệ.

Cảm ơn bạn!
Đây chính là thiếu sót của hội đồng trong khâu thẩm định và ban hành điều lệ.
Chúng ta sẽ có tài liệu dẫn chứng và ví dụ cụ thể theo tình huống để người thực hiện điều lệ có được 1 cái lý do thuyết phục.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Sau đây là phần khảo sát đối với Senior Member và Team Leader, họ dường như thấu hiểu được các các thắc mắc của các bạn, và cũng đưa ra 1 số hướng cải cách phù hợp

Senior Member:

1/ [Code Quanlity] Chất lượng và khả năng làm việc nhóm tốt hơn nha OK.
2/ [Collaboration] Lúc trước chưa có chuẩn thì code bị lung tung, khó kiểm soát.
3/ [Suggestion] Chỗ async, await thì chắc cần bổ sung thêm xem khi nào sử dụng, khi nào không nên sử dụng để các bạn áp dụng chuẩn hơn, tránh bị ảnh hưởng tới lỗi data và nâng cao Performance hơn

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Senior Member:

1/ [Code Quanlity] Về chất lượng code thì em thấy có cải thiện hơn, vì trong đó toàn đúc kết kinh nghiệm của các anh em nên sẽ hạn chế được 1 số lỗi thường mắc phải.
2/ [Collaboration] Khi đi quan sát chung thì thấy đa phần các anh khác có thể đọc hiểu được code của nhau dễ hơn.
3/ [Suggestion] Cái này thì em nghĩ là nên đưa thêm vài cái ví dụ vào mỗi rule. Cái tài liệu kia thực tế đọc vào mà chưa code gặp trường hợp đó hoặc chưa tìm hiểu về mấy case đó sẽ khó mà hiểu được. Với lại em nghĩ không nên ghi bắt buộc trong tài liệu. Chỉ nên ghi hạn chế thôi thì sẽ có 1 số case đặc biệt cần đến cách xử lý riêng.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Leader:

1/ [Code Quanlity] Nhìn chung có cải thiện, code nhìn đỡ rối hơn, phân chia code rõ ràng và gói gọn trong component. Tuy nhiên các bạn mới viết còn vội và chưa có kinh nghiệm nên các component viết chưa tái sử dụng được nhiều.
2/ [Collaboration] Nhìn chung thì các bạn làm tốt phần component của mình, nhưng chưa xử lý tốt cho các tình huống Conflict Code
3/ [Suggestion] Có thể sưu tập các component chuẩn và post lên đâu đó cho mọi người tham khảo, giải thích sơ qua sao phải viết vậy, để các bạn rút kinh nghiệm.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Leader:

1/ [Code Quanlity] Do mình áp dụng mà chưa thấy chế tài hoặc thời gian review cụ thể nên lợi ích mang lại chưa cao. Chưa có ví dụ rõ ràng cho các case nên các bạn còn khá mơ hồ
2/ [Collaboration] Khả năng phối hợp team thì ở mức cao hơn 1 xíu trước khi ra luật. Nhưng hiệu quả mang lại chưa cảm nhận rõ ràng.
3/ [Suggestion] Các điều lệ nên có ví dụ rõ ràng. Cơ chế áp dụng cụ thể vào dự án. Sẽ có người chịu trách nhiệm review trên nội dung code các dev của dự án đó (Tech Leader).

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/

Team Leader:

1/ [Code Quanlity] Component lồng Component rất nhiều. Async-Await rất nhiều. SetState mọi lúc mọi nơi. Render 1 page rất chậm.
3/ [Suggestion] Cần phải đưa thêm tình huống và ví dụ vào các Rule

Cảm ơn các Senior Member và Team Leader!

Kết luận

1. Cần phải bổ sung ngay các hướng dẫn, ví dụ cụ thể cho từng tình huống
2. Nâng cấp tài liệu lên bản mới nhất
3. Thêm điều lệ cho Style Sheet (CSS)
4. Cụ thể hóa điều lệ & tình huống sử dụng cho Async-Await
5. Cụ thể hóa cách dùng các file Configuration
6. Bổ sung các Bad Practices để biết đường tránh
7. Tận dụng sức mạnh của Interface trong lập trình