JZWP离职后总结
没错又被裁员了
真的别去太小的创业公司，真的很不靠谱，话说我运气确实也有点差
JZWP（又名XZ云），来这家公司起初是被老大对于该公司未来的描述和现在立马要做的事情打动，使得自己心中也有一份应该作为创业者打工的激情吧。
先描述下公司内部现状（不论好与坏只说事实），主要是对于 golang 组内。
组内同事间相处：
组长没有小领导的架势，组内较为和谐
这样让组内成员之间很和谐的相处，当然坏处就是决定力和威信力欠佳，可能直接导致会有组员冒头逞能之类的事情。不过这种小组长比较对我的口味（因为本人性格比较好，处事冷静）。
同事之间没有高级和初级的等级鄙视，大家一起学习解决问题
这点要多说下，我们组人少很多事情比较好控制，不会出现某个人分到活过多，即便有人遇见些阻碍性困难，组长也会协调大家一起出力，尽量以最高效率解决问题，保障任务进度。
老大（即管理我们所有人的技术leader）性格温和，技术经验丰富，为人处世也不错
老大经常组织我们组内成员或其他组员工聚餐、打羽毛球等线下活动（即便公司不给经费），大部分吃都是老大直给，感谢老大集体投食~~
组内技术成长：
code review 真的很重要，尤其是对于刚成立开启项目代码时统一风格
我和组长属于go项目建立者，基本上这个项目的所有搭建与后续中间组件封装统一我们都是直接第一手参与开发者。所以在前期 code review 上基本就是我两负责，这才使我体会到了它的重要性。
- 统一整体代码风格写法，使后续代码具有可读性、可维护性
- 初步检查语法漏洞BUG，反复提醒指出问题，避免不必要的错误
- 多次检查讨论可以促进组内技术交流与成长
- 所有组员参与，产生各种思维碰撞，促进相互学习成长
- 形成组内业务工程代码最佳实践方案，便于高效快速开发
每周五的技术分享，精进技术，积累沉淀
非强制性的技术分享，让组员没有过多的思想包袱，老大给每个组员指定分享主题如 redis、消息队列、NGINX等，让组员主动学习融会贯通，这样在分享的时候才能Hold住大家的疑问，也提供大家的语言表达力。
架构与技术选型要根据业务实际情况，而非盲目上非必要中间件，或过于臃肿的架构方案
大道至简，从实际业务情况出发，脱离业务的架构都是扯蛋。多考虑人力维护成本，开发技术难度，系统冗余复杂度问题，从不同角度进行复盘考虑，选出真正适合当前业务以及正确预估出公司未来业务量趋势走向。
没有用户用的功能，做的再好也是白搭，把核心业务功能提高稳定度，减轻不必要的依赖。
对于中小创业公司来说，绝大多数情况只需要 关系型数据库mysql、缓存redis、网关NGINX等一些最主流的基础构件即可，对于微服务分布式集群等问题，那也应该根据公司实际业务使用情况，接口QPS规模来决定。实际微服务分布式对于创业型公司真的可以先避开，线上完整功能看看线上用户反馈。
产品经理与程序员之间的爱恨情仇
我们组内对于 产品经理是两个女生，在问题交流和产品评审会讨论确实存在一些阻断（这里并不是性别歧视）。基本上我们开发人员除了工作上开会交流，私下基本没有任何过多的话语，这也是大家在一个空间内想做好事情的一个阻碍点。
另外来自官方吐槽，产品经理真的不能固执己见，最好是要懂得一些基本的开发流程（表结构字段设计基本前后端接口对应，甚至了解对应架构），当然要是有技术背景那必定很受欢迎。
大厂有大厂的产品设计模式，同一套标准，中小厂可不一定适合。
综合总结：
虽然匆匆半年，对比与以往我也学到了很多，不一定是技术代码上的成长，更多的是解决问题的方式与思维，在技术管理上的组织模式，管理方式。
- 作为老板不能意气用事，多余员工交流，让员工多了解彼此。
- 作为 leader 能给予员工的，应该是较为明确的成长路径空间，尽量放权，在大方向进行监督把控
- 作为员工一名工程师，要对你的任务负责，对你写的代码负责。
什么样的阶段做什么样的事情，程序员不是只代码，而是克服困难解决问题的，代码只是一种方式一种媒介。
创业确实艰难，在各方巨头与资本的强压下，创业是越来越难，如果真要走这条路，一定要做好思想准备。
最后感谢遇见的这些可爱的同事领导们，希望一切都好。