Theo Harry Roberts, nhà phát triển giao diện người dùng cao cấp tại BSkyB, các nhà phát triển nên sử dụng một khái niệm có tên là shame.css để khắc phục nhanh mọi sự cố 'hack' CSS trong các dự án.
Roberts đã giải thích trong một bài đăng trên blog rằng điều này có khả năng ngăn các nhà phát triển nhìn thấy các bản hack xuất hiện trong CSS và do đó nghĩ rằng những thứ như vậy có thể chấp nhận được theo mặc định.
Ngoài ra, bài báo lưu ý rằng cách tiếp cận như vậy, nếu được ghi chép đúng cách và đi kèm với các phương tiện để lặp lại, có thể cho phép tiến triển nhanh hơn tới CSS sạch hơn trong các dự án sử dụng hack (vì bất kỳ lý do gì).
.net đã nói chuyện với Roberts (HB) về việc hack CSS và những lợi thế tiềm ẩn mà shy.css có thể mang lại nếu được sử dụng đúng cách.
.net: Bạn có nghĩ rằng một số người trong ngành có xu hướng không thực tế về nhu cầu (hy vọng) hack ngắn hạn để trang web hoạt động không?
Nhân sự: Thời điểm trọng đại. Nếu bạn làm việc trên một trang web hoặc sản phẩm kiếm được hàng triệu bảng Anh mỗi năm, thì bất kỳ lỗi, sự cố hoặc lỗi nào đều cần được sửa càng sớm càng tốt. Chủ sở hữu sản phẩm của bạn không quan tâm đến việc CSS của bạn có hoàn hảo hay không - họ quan tâm rằng trang web đó có hoạt động tốt hay không và đánh dấu vào doanh thu đó. Mã tốt Là quan trọng và hack không còn là lý tưởng, nhưng bạn nghĩ rằng bạn luôn có thể ngăn chặn hack và các bản sửa lỗi ngắn hạn / nhanh chóng là điều cần thiết.
.net: Vì vậy, bạn sẽ nói rằng họ chỉ là một điều ác cần thiết trong kinh doanh?
Nhân sự: Khi một khách hàng khó chịu - hoặc một tính năng bị hỏng trên một trang web đang hoạt động - bạn cần đảm bảo rằng bạn đang giữ cho các bên liên quan phù hợp hài lòng. Nếu bạn dành một giờ để viết bản sửa lỗi hoàn hảo cho thứ mà bạn có thể sửa một cách hời hợt trong vòng hai phút, tôi muốn nói rằng bạn đang giữ cho người sai hạnh phúc - tức là chính bạn!
Trong công việc của riêng mình, tôi nhận thấy 'nhu cầu' về các bản hack tăng lên khá tương xứng với quy mô của dự án, nhưng điều tốt về điều đó là sau này bạn cũng sẽ có nhiều thời gian dành cho dự án hơn để sửa các bản hack đó.
.net: Đâu là nơi xuất hiện của shame.css. Với khái niệm đó, bạn xem cụ thể là hack CSS là gì?
Nhân sự: Điều gì đó có thể được thực hiện tốt hơn nếu có thêm thời gian. Thật khó để nghĩ ra các ví dụ ngoài ngữ cảnh, nhưng tôi nghĩ bạn sẽ thường biết khi nào đó là một vụ hack. Bạn đã viết một điều gì đó mà bạn cảm thấy xấu hổ khi giải thích với đồng nghiệp? Đó có lẽ là một vụ hack!
Do đó, shame.css là về việc tạo ra một tập tin về những điều bạn có thể đã làm tốt hơn và bạn có thể làm tốt hơn khi có thời gian xem lại chúng. Đó thực sự là một danh sách việc cần làm do bạn tự viết - một tập tin gồm các bản hack mà bạn đặt sang một bên để suy nghĩ khi có thêm thời gian.
.net: Trong bài viết của mình, bạn có đề cập đến việc ghi lại các vụ hack, nhưng không có lập luận rằng các nhà phát triển thường nên ghi lại CSS nhiều hơn, thay vì chỉ dành cho các vụ hack?
Nhân sự: Đúng! Nếu có một điều mà tất cả các nhà phát triển nên làm nhiều hơn, đó là viết bình luận. Bạn nên nhận xét bất cứ điều gì không rõ ràng ngay lập tức từ mã. Ghi lại mã của bạn để nếu bạn bị xe buýt tông trên đường về nhà, đồng nghiệp của bạn có thể tiếp nhận vào ngày hôm sau.
.net: Về việc tích hợp shame.css, bạn đề xuất điều gì?
Nhân sự: Nếu sử dụng bộ xử lý trước, @import các xấu hổ. [scss | less | etc] lý tưởng là tập tin ngay ở cuối. (Điều này luôn có thể dẫn đến các vấn đề về tính cụ thể và thứ tự nguồn, vì vậy số dặm của bạn có thể thay đổi.)
Nếu bạn không sử dụng bộ tiền xử lý, nhưng có một quy trình xây dựng tốt, tất cả CSS của bạn nên được nối và rút gọn trước khi triển khai, vì vậy, một lần nữa, shame.css có thể hoàn thành điều đó.
Nếu bạn không sử dụng bộ xử lý trước và bạn không có quy trình xây dựng, thì một, bạn có thể nên sửa điều đó, và hai, phần hack ở cuối bảng định kiểu có lẽ là lựa chọn tốt nhất của bạn. Shame.css không nhằm mục đích xem công khai, vì vậy đừng bao giờ có một biểu định kiểu riêng biệt được gọi bởi một phần tử liên kết trong đánh dấu của bạn. Bạn chỉ nên phân phát một biểu định kiểu được nối và rút gọn.
.net: Nếu một khái niệm xấu hổ thực sự thành công, bạn nghĩ nó có thể thay đổi quy trình thiết kế và các trang web nói chung như thế nào?
Nhân sự: Shame.css chỉ hữu ích khi các nhà phát triển triển khai nó. Tất cả đều tốt và tốt khi cô lập và ghi lại các bản hack, nhưng nếu bạn không bao giờ sửa chữa hoặc xem lại chúng, bạn sẽ chỉ ở cùng một con thuyền như trước đây.
Đối với tôi, shame.css báo hiệu một sự thay đổi lớn hơn trong quá trình phát triển; nó không cần giới hạn trong CSS. Khái niệm này chỉ đơn thuần là 'nhận ra, ghi lại tài liệu và chỉ ra các điểm hack của bạn'. Bạn có thể áp dụng suy nghĩ đó cho mọi thứ.
Công việc thực sự liên quan đến shame.css là đưa nhóm trực tiếp của bạn (các nhà phát triển) tham gia và sau đó làm cho doanh nghiệp / PMs / scrum master / BAs / product owner (v.v.) nhận thức được thực tế rằng một sản phẩm đôi khi sẽ bao gồm ít hơn mã -than-theory, nhưng mã này tồn tại để đáp ứng các yêu cầu kinh doanh.
Nói với họ rằng bạn đang cô lập và ghi lại các vụ hack và dành thời gian phát triển để sắp xếp mọi thứ. Sẽ dễ dàng hơn để tạo một trường hợp kinh doanh để thu dọn cơ sở mã nếu bạn có thể định lượng nó. Chỉ cần nói với người quản lý dự án của bạn, "Tôi có một số thứ cần thu dọn trước khi tôi có thể chuyển sang Tính năng X" sẽ không phải lúc nào cũng cắt được! Đưa danh sách những việc đến PM của bạn và cố gắng dành nửa ngày thời gian chạy nước rút để dọn dẹp.
Ý tưởng đằng sau shame.css chỉ đơn giản là làm cho các vụ hack của bạn trở nên minh bạch hơn, có thể định lượng và cô lập hơn. Bạn sẽ làm gì với thông tin đó!
