背景随着业务/人员越来越多，需要在团队内pickcodingreview环节。因此，在新老项目中都进行了选择性抽样分析和审核（在选择上，考虑可塑性和后期迭代）。确实，暴露了一些问题。这篇文章就是分享这些问题，语言参考不限于JavaScript（有共性的可以参考）。这里有一些大方向的工程架构/设计思路，编码标准，各有特点，技术栈问题，乱七八糟的工程设计思路。产品架构设计/细节审查完成后，即项目项目开始编码前，大部分存在于架构设计阶段。.而往往设计阶段会花很长的时间来做这部分工作（架构师，或者teamleader把控全局）。也就是说，为这个项目注入设计灵魂，让大家朝着共同的目标发展。在后续人员拓展、功能拓展、产品落地拓展……但现实往往不如人意。项目开发过程中总会出现一些意想不到的情况：周期性中断、间歇性开发（半死不活的项目）、相互任务。清晰度（相互模块互不认可）团队中对设计思路的片面认可/非编码工作（如CI/CD）人员更换（人员组织架构调整问题）未达成共识。..一些个人的意见也是目前正在做的一些工作：文档输出，不仅是必要的文档输出，阶段性的结束阶段设计也必须是可追溯的（有人会说没时间写，不是必要的写...请相信我，文档会帮助你减少很多后续工作）项目规模和人员规模导致模块化分工和开发彼此的工作，至少相互理解。尽可能多的分享（请记住你们是一个团队，不要每次别人写的时候都说，我不是很懂...请大家“卷起来”）设计思路的实现对于开发者来说，这部分更多的是团队负责人的职责。请努力工作并分享给每一位参与者（我一直认同领导力不是由个人决定的，而是由你团队中的每个人决定的。嘻嘻，我也在进步，这主要是提醒我）。非编码工作的部分有点难Howtosayit?如果技术团队比较成熟，就会涉及到部门之间的分工。最好实现每个部署细节。如果人员更换问题可以参考以上几点。我相信这不会那么痛苦。如果大家有什么希望补充的，欢迎留言，我会改进的。2.编码标准。团队比较大的时候会有一个我个人觉得非常有必要的环境。请记住，代码是供人们阅读的。请给后人一片绿荫！拿JavaScript举几个简单的例子：1.变量/常量声明避免缩写，使用有意义的名字。（好头疼）2.不要只污染全局作用域。Let可用于多种用途。既然有了现成的babel，还怕什么（而且还是ie的时代）？不改全局不改！重点是什么？你在函数内部也会被释放（不要高估内存什么的，不够那个资格..）参考下图3.一个函数只做一件事避免影响是什么意思。函数一定要纯，并没有说你写得多么刻意。但是不要使用带有一段逻辑的函数。不是闲的吗？请保证是单一的4.限制函数传入的参数个数。我想知道是否真的需要这么多参数。.可读性非常差。如果选项较少且数据缺失怎么办？如有必要，您可以转换数据类型。objectorarray可以吗？5、多使用现成的API。以JavaScript为例。如需添加，请留言。3、解决技术栈混乱问题最直接有效的方法就是定期进行codingreview。说大家完全信任问题是不靠谱的。简单说几点：不能叫review，应该share（大家主动sharecoding，哈哈，太亏了）。简单来说，即使是很小的库/框架/工具组件，也需要想出为什么要使用它们的理由。必须有一个过程。不然大家介绍一堆东西就烦了。有一个被团队技术负责人认可并信服的老大来领导这个问题的推进（非常重要，非常重要）。如需添加，请留言。最后，这篇文章是按日收入写的。如果喜欢这类文章，请关注我的codingdailybest专栏。真心希望大家关爱小家（团队），为大众创造神话！
