Làm cách nào tôi có thể viết HTML, CSS và JavaScript để giúp các nhà phát triển phụ trợ làm việc dễ dàng hơn?

Khi tôi nhận được một thiết kế từ một nhà thiết kế, tôi nhận nó dưới dạng tệp PSD (Photoshop). Tôi luôn mong đợi tên lớp và thư mục thích hợp, về cơ bản là một PSD sạch và được quản lý. Từ desigbn này, tôi phát triển HTML, CSS và JavaScript và cung cấp nó cho các nhà phát triển back-end. Để họ dễ hiểu, tôi

• viết mã ngữ nghĩa,
• giữ JavaScript và CSS trong các tệp bên ngoài,
• thêm ý kiến ​​hữu ích trong các tệp HTML, CSS và JS,
• sử dụng các họa tiết CSS (mặc dù các nhà phát triển không thích nó),
• sử dụng tấm nồi hơi HTML5,
• sử dụng jQuery cho JavaScript,
• cố gắng sử dụng các thẻ HTML5 và CSS3 mới bất cứ khi nào có thể và
• đã gửi một tệp Zip chứa HTML, CSS, JS và hình ảnh.

Tôi hy vọng rằng nếu những thay đổi nhỏ sẽ cần phải được thực hiện cho bố cục, các nhà phát triển có thể xử lý điều đó.

Tôi muốn nghe ý kiến ​​từ các nhà phát triển back-end và các ninja CSS khác về những gì người ta có thể làm về mặt tổ chức các tệp và đánh dấu để giúp việc tích hợp với các hệ thống back-end dễ dàng hơn (ví dụ như các công nghệ back-end, PHP, .NET , Ruby, v.v.) Khách hàng khác nhau sử dụng các hệ thống khác nhau.

Rất nhiều trong số những câu trả lời này sẽ bao gồm rất nhiều ý tưởng, nhưng đây là những ý kiến ​​cá nhân của tôi:

• Để lại phòng trong thiết kế mẫu cho các thông báo lỗi.
• Đừng để nhãn vào hộp đầu vào!
• Đặt CSS và JavaScript của bạn vào một tệp riêng biệt, trừ khi bạn biết bạn đang làm gì và cảm thấy tồi tệ về nó.
• Giữ các yếu tố thiết kế giống nhau giữa các trang. Thật đáng giận khi một thành phần thiết kế (như hộp "được xem gần đây") có đánh dấu khác nhau trên mỗi trang.
• Đừng làm những gì dễ dàng cho bạn, hãy làm những gì đúng. <button>thẻ hút. backround-imagecho những thứ thực sự nên là <img>thẻ hút.
• Đảm bảo rằng nếu bạn đang tạo một thành phần trang, nó có thể chia tỷ lệ. Tôi biết hầu hết các nhà phát triển front-end giỏi làm điều này, nhưng tôi đã có rất nhiều trường hợp trong đó ai đó đã sử dụng một hình ảnh duy nhất trong tình huống đáng lẽ phải là đỉnh / đáy. Các lập trình viên không thích mở Photoshop.
• Đọc mẫu của bạn. Lập trình viên (những người tốt) là những người tận tâm, chi tiết. Nếu họ bắt đầu thấy các vấn đề trong thiết kế của bạn (có thể điều hướng chân trang có lỗi chính tả hoặc chính tả không nhất quán), điều đó sẽ khiến họ đặt câu hỏi và làm chậm công việc của họ.

Cuối cùng, và có lẽ quan trọng nhất:

• Tìm hiểu các quy ước cơ bản của ngôn ngữ đang được phát triển ở phần cuối. Có thể nhìn vào một mẫu PHP và hiểu được cú pháp cơ bản đằng sau một foreachhoặc một iftuyên bố và làm thế nào để định dạng một echotuyên bố hoặc di chuyển một <?php ?>thẻ xung quanh sẽ làm tăng đáng kể giá trị của bạn như là một nhà phát triển front-end - Tôi yêu khi một front-end nhu cầu phát triển để thực hiện một thay đổi đơn giản và có thể thực hiện trong mẫu thay vì đưa cho tôi một zip mới của tất cả các tệp của họ.
• Là một phụ lục, tìm hiểu để sử dụng phần mềm kiểm soát phiên bản. Bạn không cần phải là một chuyên gia, nhưng nếu tôi có thể nhìn vào một khác biệt thay vì phải cố gắng tìm ra những gì đã thay đổi giữa hai tệp zip, công việc của tôi sẽ dễ dàng hơn gấp trăm lần.

Đó chỉ là một vài - tôi chắc chắn còn nhiều điều nữa, nhưng nếu bạn hoàn thành tất cả những điều này, bạn chắc chắn sẽ nhận được sự tôn trọng và đánh giá cao của bất cứ ai đang biến các mẫu của bạn thành một trang web.

Những điều hiển nhiên mà tôi có thể nghĩ đến sẽ giúp cuộc sống của một chàng trai trở nên dễ dàng hơn là sự đơn giản trong cách cư xử. Khi thiết kế các yếu tố của trang web có nhiều hành vi khác nhau (cuộn, menu, v.v.), tất cả các hành vi này phải được chuẩn hóa theo cách thông thường để nhà phát triển không phải liên tục quay lại biểu đồ nào đó để xác định chức năng nào cần phải gọi để có một trang cư xử.

Các lưới không nên yêu cầu một ô bằng cách thao tác dữ liệu hoặc chức năng của ô. Các phần tử khối của các trang phải dễ dàng được xác định là các phần tử phổ biến để chúng có thể dễ dàng được phân đoạn theo mã phía sau. Điều này sẽ giúp nhà phát triển sử dụng lại mã và / hoặc tạo điều kiện giao tiếp giữa các khía cạnh khác nhau của trang.

Các khu vực của trang không nên vượt qua ranh giới thiết kế cụ thể. Các mục từ một phần tử không được xâm nhập vào các mục từ phần tử khác.

Tuy nhiên, có một điểm, nơi bạn chỉ đơn giản là không thể tránh làm cho các nhà phát triển nhảy qua các vòng đốt. Một số yếu tố giao diện sẽ trở nên khó khăn để xây dựng bởi bản chất của chúng.

Lưu ý rằng đôi khi, bạn phải lựa chọn giữa việc giúp dễ dàng sửa đổi giải pháp cho nhà phát triển phụ trợ và làm cho một cái gì đó được tối ưu hóa.

CSS spites bạn trích dẫn là một ví dụ tốt. Tôi không hiểu làm thế nào ai đó có thể tạo trang web khi khả năng mở rộng và hiệu suất và có liên kết đến 100 hình ảnh, 5 tệp CSS và 15 tệp JavaScript từ mỗi trang. Mặt khác, các họa tiết CSS không dễ bảo trì và những thay đổi nhỏ trong thiết kế có thể đòi hỏi nhiều công việc.

Ví dụ: nếu bạn có ba biểu tượng trạng thái, bên dưới một biểu tượng khác và bạn phải thêm trạng thái thứ tư, bạn có thêm biểu tượng thứ tư vào dưới cùng của hình ảnh, tách biệt với ba biểu tượng khác không? Hoặc bạn thêm nó sau biểu tượng thứ ba, di chuyển mọi thứ khác xuống phía dưới để có một khoảng trống cho nó?

Điều tương tự cũng đi kèm với việc kết hợp và thu nhỏ các tệp CSS và JavaScript. Bạn phải làm điều đó cho một trang web ở một số quy mô, nhưng nó sẽ đòi hỏi nỗ lực thêm.

Đó chính xác là điều tương tự đối với CDN. Bạn phải sử dụng nó cho các trang web lớn, nhưng thay đổi sẽ khó thực hiện hơn. Ví dụ: nếu bạn đã thay đổi tệp CSS, bạn phải buộc các trình duyệt tải xuống tệp mới, bằng cách sửa đổi URI thành tệp cdn.example.com/g.css?r=2, sau đó cdn.example.com/g.css?r=3, v.v.

Ngoài ra, "dễ dàng hơn" là tương đối . Xem, ví dụ, hướng dẫn viết mã CSS: cá nhân, tôi thích một kiểu trên mỗi dòng, không có khoảng trắng:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

trong khi hầu hết mọi người sẽ ghét cú pháp này và thích cái tôi ghét và khó đọc (không, tôi không điên):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

Theo cùng một cách, sử dụng jQuery không có nghĩa là bạn sẽ giúp nhà phát triển back-end dễ dàng sửa đổi các tệp của mình hơn, bởi vì một số nhà phát triển có nhiều kinh nghiệm hơn với Prototype hoặc các khung công tác khác.

Trong mọi trường hợp, một tài liệu chi tiết là hữu ích, nếu nhà phát triển muốn đọc nó (hầu hết trong số họ không). Bạn cũng có thể làm cho cuộc sống của nhà phát triển dễ dàng hơn bằng cách hỏi chính xác cho nhà phát triển cụ thể cách anh ta thích những việc cần làm và bắt đầu làm việc cùng nhau ngay từ đầu, trong khi xây dựng một khung (ví dụ: thiết kế quy trình công việc để sử dụng để giảm thiểu và kết hợp các tập tin).

Điều tốt nhất trong tất cả các thế giới là khi nhà thiết kế không ném tệp zip lên tường và thực sự đang làm việc trong dự án với tư cách là một trong những nhà phát triển. Yêu cầu một chút nắm giữ để thiết lập, nhưng nó thực sự tuyệt vời khi không có bất kỳ bản dịch nào giữa thiết kế và dev và mọi người đều có thể tham gia vào các lần lặp giống nhau. Nếu bạn có một quy trình nhanh nhẹn không ma sát sẽ không quá khó để thực hiện.

Tôi sẽ giải quyết trong hầu hết các trường hợp cho các nhà thiết kế làm việc theo cách được kiểm soát phiên bản và sử dụng điều đó làm cơ chế phân phối. Tôi thực sự không muốn đối phó với một tệp zip lớn chất béo mỗi khi có một thay đổi nhỏ.

Linh hoạt cho bạn là linh hoạt cho họ điển hình. Tất cả những thực tiễn tốt nhất mà bạn đang theo dõi là chiến thắng trên cả hai mặt của ứng dụng.

Tuy nhiên, một điểm quan trọng và thường bị bỏ lỡ là viết UI mạnh mẽ. Quá nhiều thành phần UI được neo quá mức vào một ngữ cảnh hoặc một bộ HTML chính xác quá mức và chúng có CSS ​​được thiết lập để thất bại.

Ví dụ, nếu bạn có một danh sách thả xuống, thì nó sẽ hoạt động rất ít để neo một thành phần thả được định vị tuyệt đối bên trong một thùng chứa được nhấp vào tập hợp tương đối (không cần coords) so với kéo ra búa JQuery và lấy tọa độ để di chuyển nó trên các yếu tố và chỉ cần dán nó vào vị trí. Nó cũng ít có khả năng bị hỏng trong trường hợp trang dịch chuyển hoặc một số tính năng trình duyệt mới loại bỏ thông tin định vị. Bạn càng dựa vào các kỹ năng HTML / CSS để tránh công việc JS, giao diện người dùng của bạn sẽ càng mạnh mẽ hơn.

Theo nguyên tắc chung, tôi cố gắng đảm bảo rằng điều duy nhất các thành phần UI của tôi cần là thẻ HTML để tồn tại với một ID hoặc lớp thích hợp. Càng nhiều thứ bạn có thể làm với container đó mà không bị UI phá vỡ hoặc với container thực sự có khả năng như mở rộng / thu hẹp để phù hợp khi thay đổi kích thước của container, nó có thể được thực hiện dễ dàng hơn trên bất kỳ phần nào của ứng dụng mà không cần phía khách hàng chuyên gia. Tất cả những gì họ phải làm là dán một lớp lên nó.

Thích phân quyền sự kiện trên các thùng chứa ui để gán người nghe trực tiếp vào các nút điểm cuối như các nút. Thành phần UI đó có thể hoạt động với HTML tĩnh ngay bây giờ nhưng bạn không bao giờ biết khi nào ai đó sẽ muốn có thể trích xuất và viết lại HTML bên trong bằng InternalHTML hoặc một cái gì đó. Nếu thùng chứa còn nguyên vẹn và tất cả các sự kiện được ủy quyền (xem phương thức 'trên' của jquery), bạn không phải lo lắng về điều đó và họ có thể không bao giờ học được cách khó thay thế HTML cho người nghe.

Vì lợi ích của việc giữ ủy quyền xung quanh như một tùy chọn, đừng sử dụng stopPropagate ở bất cứ đâu trừ các nút điểm cuối và gửi thư ghét cho các nhà phát triển khung ngốc, những người spam nó khắp nơi.

Theo như bố cục, hãy giữ HTML tối thiểu, ngữ nghĩa và tránh các trình bao bọc div. Càng ít HTML, các vấn đề bố trí dễ dàng hơn cho các tân binh bố trí để chẩn đoán.

Sử dụng tên lớp tự giải thích cho CSS tiện ích. Một lớp "hàng" có thể rõ ràng hơn đối với các noobs CSS hơn là "Clearfix".

Luôn cung cấp các yếu tố duy nhất, ID duy nhất. Nó giúp việc xác định nơi cụ thể của một phần đang diễn ra dễ dàng hơn nhiều, việc ghi đè nội dung dễ dàng hơn và đó cũng có thể là một chiến thắng về hiệu suất và mức độ hiệu quả của JS.

Rõ ràng đó là tin xấu khi có quá nhiều với sơ đồ lớp nhưng càng nhiều nhà phát triển phía sau có thể thiết lập đơn giản bằng cách thêm các lớp phù hợp vào mọi thứ, họ sẽ càng dễ dàng thay đổi trang hiện có.

Và tất nhiên khi bắt đầu dự án khiến họ đồng ý ít nhất một điều này: Back và front end chỉ kết nối thông qua HTML và JSON. Đừng để họ sử dụng công cụ "viết JavaScript cho bạn!" Đó là một mớ hỗn độn đẫm máu và một cơn ác mộng bảo trì.

Như với tất cả những thứ liên quan đến phát triển, thích DRY và tối giản.

Nó vẫn không cho phép tôi bình luận (thật ngu ngốc) nhưng như một ghi chú cá nhân, tôi sẽ đề cập, tôi làm việc trở lại với một lập trình viên PHP hàng ngày (cũng như hỗ trợ công việc của anh ấy) và công cụ đơn giản nhất mà chúng tôi đã tìm thấy là để sử dụng hộp công cụ của Komodo và liệt kê các biến "được chuyển" của từng chế độ xem / bộ điều khiển / mô hình trong hộp công cụ, để bất cứ lúc nào, nếu tôi đang xem xét việc thiết kế một trang xung quanh một tập hợp dữ liệu được gửi đến trang đó, tôi có thể nhìn vào hộp công cụ và xem chính xác dữ liệu nào đang được gửi và "loại" "nó đang được gửi đi, cũng như ngược lại ở phần cuối của anh ấy. Chỉ là một mẹo.