开发团队的汇海

。

　　我在微博上说过下面的话，（各人可以体会一下保姆和服务的差异）

　　运维要用“云服务”的思绪去做。若是一个公司内的运维团队开发出一堆工具，让做应用开发团队可以很容易地申请机械、存储、网络、中心件、宁静等资源，并很容易治理、监控和部署应用，并提供运维资询。而不是帮应用开发团队干活擦屁股当保姆。那么，这个公司就会不经意地做出一个云盘算平台来了。

　　“WatchDog式”软件开发

　　什么是WatchDog？就是说——为相识决某个系统的问题，我要用一个新的系统去看着它。

我的系统架构太庞大，出了问题欠好查找。咋办？那就搞个专门的特殊的监控系统吧……我的系统设置太庞大，容易配错了。咋办？那就加一个设置校验系统吧……我的系统设置和真实的情形有时间可能会纷歧性。咋办？那就加一个巡检系统吧……我的系统测试情况和线上情况有时间会搞混了。咋办？那就为线上情况加一个权限控制系统吧……我的系统有单点，那就加个负载平衡器吧，负载平衡器的单点呢？那就再加个等价路由器吧……

　　做加法谁不会？就不想去简化一样系统吗？就不能不拆东墙补西墙么？这些了系统加的越来越多，我看你以后怎么运维。

　　一最先没有想清晰就放到线上，然后，出了故障后，也无法重新设计和沈阳小程序定制重新架构，只能以打补丁地方式往上打，这就似乎一个原来就有缺陷的楼没有盖好，你要拆了重盖是不行能的，也只能一直地打补丁了。字是一只狗，越描越丑。

　　【解决方案】

　　1）设计想好了再做，多评估几个设计没坏处，简化，简化，简化。

　　2）残酷无情地还债，就算是CEO来了，也无法阻止我还债的脚步。

　　“故障驱动式”软件开发

　　WatchDog式的软件开发通常来说都是“故障驱动式”软件开发的产物。这种开发方式实在就是在讲明自己智力和能力的不足。以上线为目的，上了线再说，有什么问题出了再改。

　　上面的老大或是营业方基本上会说，没关系，我们纷歧最先并不需要一个完善的系统，你先上了再说，先解营业的渴，我们后面有时间再重构再完善。而有的手艺职员也会用“架构和设计是逐步演化出来的”这句话来证实“故障驱动”开发是值得的。

　　我赞成逐步迭代以及架构演化论，可是，我以为“系统迭代说”和“架构演化论”被彻彻底底地成为那些能力有限甚至不学无术的人的超级捏词。

　　你们有没有搞错啊？你们知道什么叫迭代，什么叫演化吗？你们知道，要定位一个线上的故障需要花多大的气力吗？（看看这篇文章你就知道了）你们知道，随随便便去应付局部上你会快，但总体上来说你会慢。

　　虽然，我看到那些系统在一个又一个的故障后获得一点又一点的改善，可是我想说，为什么一最先不认真不严谨一点呢？我从来就没有见过一个良好的系统是靠一个一个的故障和失败案例给堆出来的，就算是Windows 95/98这样史上最烂的操作系统，若是没有设计良好Windows NT的补位，Windows也早玩完了（看看IE的下场就知道了）。

　　【解决方案】

　　1）基础知识和理论知识很是主要。多多使用已有的成熟的方案是要害。

　　2）对手艺要有一颗严谨和敬畏的心。想清晰了再干，坚持高尺度，Design for failure! 许多事情都急不得。

　　其它开发方式

　　实在，这样的事情另有许多。好比：

　　1）设置治理上的问题

　　对于源代码的设置治理，实在并不是一件简朴的事情。设置治理和软件和团队的组构的结构很是有关系。我看到过两种很是没有用率的设置治理，一种是以开项目分支的方式来做项目，同时开许多分支，分支开的时间还很长，导致merge回主干要花大量的时间去解决种种冲突，另一种是N多的团队都在一个代码库中做修改，导致泛起许多庞大的问题，好比某团队的改动泛起了一个bug，要么所有的团队的功效都得等这个bug被修复才气被公布，要么就是把所有的改动回滚到上一个版本，包罗其它团队开发的功效。很显着，软件模块的结构，软件的架构，以及团队的组织形式都市严重影响开发效率。

 3/4   首页 上一页 1 2 3 4 下一页 尾页