本周工作思考
前端编程不仅仅是拼装组件的思考（一）
很长一段时间以来我都有意识的关注业务代码的编程质量和设计质量问题。
有很多书籍和论文来阐述何为编程质量，如何写高质量的代码，如何避免低质量的代码，我相信很多工程师都或多或少的读过或者学习过类似的书籍或者论文文。但是很多时候，这些书籍文章是不考虑其他因素的情况下理想解决方案。在我看来，编程工作是一项实践性极强的工作，所以这就是编程属于软件工程中的组成部分的原因。
我接触过程非常多的国内工程师，也通过github或者其他一些途径了解过一些欧美工程师，个人感觉国内的工程师很多时候是，书上说是说上说，我做的是我做的，也就说，很多人很难在实际工作中有效的把书上理论应用到实际工作中，注意，这一点非常重要，这是推动一个公司软件工程水平和软件质量的巨大能力，它和具体技术无关。
为什么会有这种情况呢？在我看来，本质上是一种工匠精神，具体说就是普遍缺乏严谨的精神。欧美国家很早就实现了工业化，工业思维，工匠思维成为很多普通民众的基本思维模式，这会通过家庭教育，学校教育传递给孩子们，从70年代以来，美国的第一代和第二代程序员大部分是这样的家庭中成长的，所以这些程序员非常具有工业时代的思维模式特点，严谨。这行代码为什么这么写，而不是那么写，一定是要有个理由的，就像工业里齿轮的位置会是机器性能的重要因素。相比而言，中国第一代程序员大部分出身城市中产阶层，比如典型代表马化腾，李彦宏等，以及我的编程偶像梁肇新，他们的特点是那个年代市民阶层的典型特点，精英化并且足够精明。第二代程序员是随着计算机技术在中国普及和中国高等教育普及冲进编程这个行业的，这一代程序员的很大一部分出身农家。基于家庭教育和学校教育离农业化社会很近，所以农业化思维也普遍较重。 但是农业化思维和工业化思维是有本质上不同，中国农业化思维严谨性弱但足够勤恳，从某种程度上说，正是这种勤恳推动了中国互联网的规模化的发展。但随着软件业务向工业化深处发展，这种思维模式的弊端也逐渐暴露出来。
SaaS软件是面向企业的。服务的主体是企业，以营利为目的企业的组织和运营是绝对严肃的，正所谓生意场就是战场，因为企业的成功或者失败关系到很多人的生存问题，法律责任，债权问题，这是非常严肃的一个事情。当我们开发的软件参与到客户企业运转中时，其实我们也就背负了一定的客户企业的生存责任。
从以上的角度出发我们就不得不关注编程的质量和设计的质量，这其实是工程师内在的本质要求，如果工程师对编程质量和设计质量不给予足够认知，那应该就是真正的所谓的“码农”。
组件拆分和状态共享
USE1.5项目我建议伙伴们使用zustand作为状态管理器，其实主要是它在共享状态上的简洁性。很多重要的业务组件有十来个状态，随着业务的迭代，每个迭代改动不大，要加一两个组件，又要用到这个业务组件里的状态，如果这时候要把新组件独立出来，就用想办法共享状态， 但实际上使用useState做状态共享，就行做状态提升，这个改动就比较大了，很多时候大家基于简单的投入产出的考虑，就选择了直接在原有业务组件增加新增逻辑，这样的后果就是业务组件臃肿庞大，逐渐变的难以维护，简单点说就是，一改就出Bug，要想不出Bug，就得花比较多时间，这时候就有会其他伙伴问你，为啥要花这么多时间，其实那个组件就是一堆乱麻，你厘清它并评估修改它就需要花很多时间，所以你很难给出一个合理的工程时间。这种情况是非常难解的工程状态，从财务角度说，这时候这个组件就是公司的不良资产了，它在吞噬着我们宝贵的人力资源。 所以我们要想尽一切办法规避这种情况的出现，从源头就要扼杀这种情况的出现，选择更好用的状态管理器，及时的做设计优化，保证大部分业务组件不仅能创造价值同时也是公司的良性资产。