Before you start reading this article, must be psychologically prepared. Because I wrote in 90% complain, only about 10% of the final presentation of best practice CSS techniques. To give you an early warning ahead of it.
Front-end engineer may encounter the following difficulties in career development:
-
Some stage, feel (they were doing) work without any difficulty
-
Create value for the team less and less friends
- Do their own thing, we can do
Agree please raise their hands. If you do so, (congratulations) to show that you are the majority.
And tell the truth, CSS is really quite simple. In addition, I can assure you that even a fool can write the following code:
p {
color: red;
}
web前端开发学习Q-q-u-n： 784783012 ，分享开发工具，零基础，进阶视频教程，希望新手少走弯路
So you have nothing to complain about? Heap pure CSS code, does not require any skill. And only a single element is added to the global style, regardless of other CSS, of course, is very simple.
So in the end CSS Difficulties children?
Back-end development engineer: "Although I have completed the development of new features, but I messed up the front, but do not worry, I've repaired most of, the front end so you only need to fine-tune the details, time should not be more than 30 minutes "
So I open the HTML file, (surprised) found deprecated HTML tags are everywhere, and has not considered responsive design. Take a deep breath, (implying himself), they write CSS will certainly be a little better. However, after I opened the CSS file and found that (same) are everywhere similar fixed (fixed) locate, wipe, left floating, floating right and! Important code, so I slowly put the mouse around the neck. (Do not stop me, let me die)
(Comfort myself), they write code that perhaps would not have been so bad, but (in reality) I almost never seen front-end code can be used to write back-end engineer's. Also okay, would have to write front-end code is not the duty of the back-end engineers. But please do not just write a bunch of back-end engineers front-end code, and then expect front-end engineers to help you wipe.
So good CSS long-sawed?
Organizational structure (the project). Especially when you have done large projects, you will find the organizational structure of the project is really important. For a positive example --Steven Bradley wroteHelp maintain the directory structure of the code , this article is written for the SCSS project, but also apply to ordinary CSS project. It focuses on how the CSS file modular, easy to maintain documented.
规范。这可能是我每天所遇到的最大问题。不幸的是，大部分工程师对CSS规范的理解一知半解，正是因为这样，才导致糟糕的 CSS 代码（如 !important）烂大街。那我们该如何避免呢？下面列出了很多值得参考的命名约定，它们旨在减少写死的（非常依赖文档结构的） CSS 选择器。假设你对此不感冒，我还是要劝你如无必要，避免使用超过 3 层的 CSS 类/元素选择器。
命名约定。恕我直言，对于任何一个大型的 CSS 项目来说，命名约定是标配。没有命名约定，CSS 就会变得既难维护又不可靠。命名约定可以让我们轻松地重用项目中的 CSS，如有必要，还能帮我们剔除项目中多余的 CSS。这里仅列举几种比较流行的命名约定，如：BEM，OOCSS，SMACSS以及我自己写的hiccup。
测试。在这一点上，绝大多数其它工程师可能都没发现当后端工程师有多爽。 因为后端工程师的开发工作只需要让一个环境（网站所在的服务器）正常即可。你知道作为前端工程师最痛苦的事情是什么吗？5 个以上的浏览器以及上千种移动设备……好的前端测试工作其实是个苦差，且耗时很长。我见过很多项目延期，就因为没有把前端测试考虑进去，而通常前端测试花费的时间会超出常人预期。
所以如何扭转这种对CSS的天真看法？
在以后工作中，再也不能让后端工程师们抱有侥幸心理。作为前端工程师，我们不会随便把一堆无响应式的 CSS 代码丢给后端工程师，然后撒手不管。所以凭什么他们就能写无用的烂代码，然后在他们的 CSS 代码失效时让我们去打补丁？我不是说要让后端工程师好好写 CSS 代码，而是我们应该告诉后端工程师，如果觉得写 CSS 很难的话，就不要写。
别让其他工程师觉得前端很简单，前端才不简单呢，我们前端工程师跟其他人一样努力地工作，别让他们看走眼。