小公司项目开发记录

• 开发脚手架的必须条件

1. 一只稳定的团队
2. 一个有相对的开发经验的技术lead。(或者是从稳定的团队中进行自我选拔)
3. 有一个稳定且成功运转的一个项目

• 开发脚手架的过程。

脚手架的本质上对于一个项目而来，就是一套规范，一套基础架构，一些常用的工具类。

那么势必开发脚手架的本质是从一个项目中抽离出元素。

确定元素开发项目本质上是本末倒置，是从一个项目中抽离规范，如果是确定规范，那其本质也是确认这从之前经历的项目中抽离出来的项目技术规范。

1. 从现今运转的项目中确定命名规范、确定项目的资源放置的位置。
2. 从项目中开始抽离共有的开发的工具类，这个过程必须确定1这个工具类没有替代，2这个工具类没有重复3这个工具类没有较大的BUG

比较常用的办法是通用的工具类，比如时间、线程池、字符串拼接等都使用现在的hutool，然后继承扩展它。

1. 不断的维护现有的项目，并且维护现有的项目的前提下，如果有改动那么立即维护这套脚手架，形成自己的一套规范，形成自己公司开发的一套流程。
2. 维护主分支，开放次分支。

让技术人员自己在开发中摸索哪种开发流程合适，哪些工具类合适，哪些需要修改，让技术lead去掌握主分支，然后让其它开发人员去尝试其它的开发模式，哪些加入主分支，哪些剔除，那些可以先试试，每周归纳，每周总结，这些就是需要维护的东西。

1. 直到维护的这套东西形成一个可以进行开发一个新项目或者其它项目的流程，那么这个脚手架就完成了。

• 技术中台。

实际上我也不是很理解技术中台到底是什么。

在我看来，技术中台就是一堆的实现类，一些基础的完善的实现的服务。而这套服务可以很好的融入项目中。

技术中台对于多项目开发来说是一个很重要的事情，因为技术中台可以减少很多重复且冗余的代码。而且可以快速敏捷开发，实际上敏捷开发就是有一套基础的架子，然后有很多相对完善的技术中台，有很多工具类。然后只要业务清晰就可以很快的入手。

实现技术中台：

1. 抽离业务

技术中台尽量不要涉及到业务模块，尽量不要涉及到对业务的开发。

1. 精炼写法，完整注释。

技术中台必须写的很精炼，而且性能需要比较高，最好在代码里面尽量留好扩展空间。注释必须完成，必须完整的标明每个方法是做什么用途的。

1. 维护，以及切割。

维护就是代码总是有BUG的，特别是中台运用的场景都不同，很难说有哪种场景会引发一些BUG，所以中台必须经常维护。而且在之后增加各种功能各种特性。

切割就是给中台设立标准，不要把任何代码都往同一个设置的中台里面丢。