让我们谈谈你已经知道的。
这是我关于哈布雷的第一篇文章，我不是作家。 但是，看看
Frontend 2018：这一年的结果，人们的手得到了升华并开始写作。
任何困难的任务都由简单的任务组成。
正确进行分解的能力是必须的 。
我将从个人经验出发，以大多数项目为例进行讨论。
我敢肯定，你会说：“
但是我们根本没有它，而且反应快速，逻辑和可读，使用js生成样式不是某种附加组件，它很时髦，但是不需要前端开发人员，因为我们的后端提供者Feofan在php中造就了出色的形式 “但仍然。
代号G1 可以例外的天才是一个特殊的宏伟案例。
M *。 思想
这无法读取
因此，让我们开始吧！
M1。 配音代码不好。M2。 您应该始终思考100步。例如，在项目开始时，我们考虑了5年后的状态。
显然，启动社交网络后，我们可以立即说，除了Web版本，还将有移动应用程序，桌面应用程序。 从这里...
M3。 服务器部分应只写入一次。 （M1）而且由于我们拥有网络版，移动版，台式机，因此...
M4。 服务器端处理数据。服务器端不应该决定绘制哪个按钮以及应该使用哪种颜色。
当加载页面以供搜索引擎建立索引时，[可以]加载的信函模板或html文件也正在处理数据。 las，您必须在那里操作html（例如，由于编制索引的要求），但这是另一个问题。
实际上，可以传输一组初始文件（html，js，css）和数据。 即 而且这里的背面不参与布局。
这里发生了项目的第一个故障：服务器部分坏了。 我不会争论用哪种语言编写，如何安排体系结构（我还记得MVC）。 这不是我的事...
M5。 每个人都必须做自己的事。全栈覆盖了一些项目，在这一点上您可以并且肯定会争论，但是参考（M2），我在这里的职位已经形成：在您的领域拥有两名专业人员比一年内重写项目要便宜。 当然，有天才（G1）随处可见，但是有这样的单位，这意味着您不能在“应有的状态”中使用它们。
我还将从这个分支中脱颖而出，成为Designer，Usability和co的分支。
正确理解，普通的前端供应商可以独立部署一个里程碑，专注于百万个类似物和他的想象力，但是根据（M2），我们正在谈论的是严肃的项目，所以不要自欺欺人:)（G1）
好吧，我们有数据（API，所有必要的方法等），我们有布局-让我们开始吧。
鉴于现代现实，我将介绍另一个分支。 las，但是很大一部分现代前端供应商要么不知道如何使用布局，要么不知道js。 我进行了大量的采访，很奇怪。 因此，前沿可以分为“布局设计师”和“非布局设计师”。
M6。 开发必须在多个文件中告诉我，显然吗？ 是的，显然！
M7。 前面分为两部分：处理数据的部分和显示数据的部分。我们可能没有这个或那个部分。 例如：仅显示（静态页面）或仅数据（控制台中的脚本等）。
我在这里建议摘要和介绍：您是比萨店人。 您会接到电话，将奶酪布置精美，然后将其带给买方。 逻辑表明您并不特别有效（M1）。 但是，如果再有2个人与您一起工作，那就太酷了！ 一个接听电话（处理数据），第二个接听电话（演示），第三个精美地布置奶酪：）（演示的样式化）
我已经很明显地听到了2012年的“ CEP”消息，但让我们再次...
M8。 JS正在处理数据。他打电话给后端，接受订单，对他来说如何放置奶酪都无关紧要。 也许根本不存在披萨，也许他只是对本年度的披萨进行了调查？
M9。 HTML表示向客户显示比萨饼，并接受反馈（金钱，评论）并将其传递给管理员（JS）。
M10。 CSS-演示样式在两片奶酪之间缩进。
请注意，电话上的管理员没有说出如何堆积奶酪，而比萨饼不包含有人在电话上交谈。 任何使用js操纵样式或使用html操纵js的尝试最初都是一个插件，最初是很糟糕的。 发明类和事件处理是有原因的。
您可以上一堂课：意大利辣香肠，意大利腊肠，但是决定如何撒上意大利辣香肠奶酪并不是您的能力。
您可以放下绑定：如果您被踢了，没有付款，请告诉管理员。 但是不要把管理员塞在披萨里。 他一个人，有很多披萨！ 如果您有与操作员一样多的比萨饼，则为M1。
因此，负责js，css和html的事务-我们已经弄清楚了。
现在，您可以问所有问题：如何烹饪比萨饼，如何更快更方便地交付比萨饼以及如何通过电话与客户交谈。
我想以某种方式定义现在流行的单词“
Component ”。 实际上，即使是常规按钮也已经是“组件”，但是我将通过显而易见的示例重新定义它。 按钮是按钮和组件：
1.发布预览
2.评论
3.文件预览
4.投票选举
5.阻止“空缺”
6.帖子的HTML文本，评论，在线研讨会
等
M11。 一个组件在任何地方都应该看起来一样。无论您在何处张贴发布预览，在哪个页面上打开它，其外观都应该相同。 三种颜色的规则。 用户必须能够识别所有内容。
修改-必要时进行强制更改。 使用CSS制作。
还是其他组件
（例如，右栏中的帖子预览可能与页面底部的帖子预览不同）。
M12。 该组件由[html]，[js]和[css]组成。每个部分都是可选的。
M13。 无论相同组件的实例数量如何，其样式都应该仅注册一次例如，右侧的帖子预览，下方的帖子预览，通知中的帖子预览以及样式仅注册一次。
M14。 只有基础应该在js组件中注册例如，单击按钮时的事件处理程序，即显示所需的数据。 其他所有内容都必须渲染。
M15。 组件可能包含组件例如，帖子列表。
M16。 样式在单独的文件中取出这些文件被缓存，此外，没有诱惑将它们内联写入，这意味着可以重复。
M17。 组件样式必须仅通过父类进行绑定任何站点的页面都像许多大小不同的盒子，就像彼此嵌入的嵌套娃娃。
盒子是一个组件。
您有一个带有盒子和物品的盒子。 您无需考虑如何描述嵌套框的内部。 仅描述此。
他们在这里发明了一堆自行车，但是先生们，只要您自己确定零件组，名称就不会有问题。 如果您打开VKontakte并计算那里的组件数量，那么您就算了30件。 （不要指望facebook，只有痛苦）。
无法提供30个班级名称？ 没错，没有什么可提出的：
M18。 其他人将阅读您的代码。所以自然的名字是最好的名字
举个例子
1.帖子列表
2.评论列表
3.新闻列表
4.后预览
5.评论预览
6.新闻预览
7.后期细节
8.评论细节
9.新闻详情
难以置信，是吗？ 最主要的是难以理解且难以维护
而关于“阅读他人”的人也退订：
M19。 HTML，JS，CSS应该分开存放！如果需要将它们组合在一起，请提供不同于将它们写入一个文件的解决方案。
就可读性而言，React是最令人恶心的！“盒子”上的页面被划分，讨论了如何存储文件。 还有什么
M20。 几乎没有特殊情况而且，如果发生这种情况，那么明天您的经理会来上班，说：“有必要根据客户的要求修改实施方案。” 尽可能广泛地解决任务。
例如，在我们的工作中，无论项目如何，我们都会立即分离一些任务：日历，输入表单，弹出窗口，不同填充的菜单，查看文件以及与用户交互的其他小部件。 可以这么说，“字符功能”
M21。 风格写作需要分解世界不仅给了我们精彩的LESS，SASS。
您的项目有一组固定的字体，颜色，阴影，几乎所有严肃的项目都有配色方案，因此在编写样式时，所有这些都已参数化。 这里重要的是
M22。 如果要更改字体颜色（等），则只能在一个位置进行编辑最后，我想提到一个重要的问题。
M23。 问题的正确表述导致正确的解决方案。也许那时就没有CSS-js，facebook和不应调用的东西了。
祝大家有美好的一天！