最近抽时间将走出软件作坊一书读了一遍，很是震撼，书中描述的很多现象和问题在我的工作中也遇到过。
书中提到的解决问题的一些方法有些我们团队和公司都已经在使用了，并且解决了很多存在的问题，但是有些问
题却还是没有得到很好的解决，可能还是因为我们所处的实际环境及公司的政策制度不一样，造成了解决这些问
题的困难。
其中有一个明显的问题就是开发团队的不稳定，人员流失比较严重，好不容易组建好一个团队，通常一年
后就会流失一半人，原因有很多，有的是因为公司目前给予的薪资水平不满意，跳槽跑路了，有的是和同事关系
不和谐走了，还有的是觉得进了一个坑人的项目的同时遇到一个坑爹的项目经理也跑路了，还有就是对公司的发
展方向有疑虑，觉得前景不乐观，走人了。
开发团队人员更替频繁也造成了很多不良的后果，比如由于人员流失过多，交接工作时也不可能做到面面
俱到，所以出现知识的断层，即有些离职同事做的项目中涉及的业务和技术文档没有能够传承下来，甚至在系统
运行出现问题时，没有人清楚导致这个问题的原因是什么，要怎么修复，因为以前的业务逻辑没有人理的清楚了。
所以后期的维护成本就这样不断增加，坑越来越多，越来越大，而且随着系统运行时间的增加，代码量和数据量
都不断增大，业务逻辑也是越来越复杂，往往牵一发而动全身，所以现在的维护和开发都是很头疼。
前面欠下的技术债，现在要换上了，但是怎么还，需要多久还清还真不是那么容易确定的。而且作为一个
已经运行了多年的生产系统，将其停掉，重新开发一套一次性替换掉也是不现实的，因为已经推广到了全国经销
商，而且要考虑历史数据问题，实施运维的问题，不能够一下子全部打破重来，得一步一步走。老系统继续维护
升级，只是不做大的改动，新系统也逐步开始开发，然后一个模块一个模块逐渐替换，同时要针对老系统进行一
些优化，比如数据库就要做数据归档，性能调优，否则即使新系统上线也起不到应有的效果。工作方向现在明确
了，但是人员更替的问题还是没有很好的解决，因为我们不是专业的软件公司，实际上更像一个部门，所以灵活
性有限，所以如何留住能够干活的人，招募一些高级人才还是一个比较难解决的问题。
因为光有一些规范和政策是不行，做软件还是需要人来做，人不是机器，所以解决不好人的问题，特别是
开发人员的问题那就比较难做了，特别是业务比较复杂的系统。