想要做软件开发必须知道的几条铁律

想要从事app开发行业，从软件开发小白到大神，总有几条必须牢记于心的定律。像大家熟知的诸多领域一样，在软件开发的世界里也有一些你不得不知道的定律。

聚梦软件开发

不管是开发人员、管理人员还是架构师，都经常挂在嘴边，若不想被人家视为开发小白或新手被看轻，那么布鲁克斯Brooks、摩尔Moore，康威Conway这些大佬你就必须来好好认识一下了。

墨菲定律

墨菲定律(Murphy's Law)——一定要提到的一条定律

墨菲定律告诉我们：凡是可能出错的事就一定会出错。所以做事情是一定不要抱着模棱两可的态度，任何事都没有表面看起来那么简单，凡事绝不能将就，尤其是软件开发中一旦不小心弄错了一个小地方，那么迎接你的会是无休止的加班排错。

不过如果你做了防御性编程、版本控制、测试驱动开发、模型驱动开发等等预防措施，那么恭喜你墨菲定律会很大几率的远离你。

布鲁克斯定律(Brook's Law)——大多数开发人员都会经历过的一条定律

布鲁克斯定律告诉我们：在项目开发过程中，如果向一个延期的项目增加人手只会让它变得更加糟糕。

布鲁克斯说过，任何软件的开发都有所谓的"关键路径"，软件开发总有一些制约因素。因此，任何一个软件的开发都需要有一个最少时间，你无法仅用增加人力投入去妄想缩短它。

而如果你将提高编程效率、审查软件开发方法和技术架构是否合理这些事情做好了的话，将会比单纯地去增加人力带来更好的效果。

聚梦软件开发

康威定律 (Conway's Law)——最近非常火热的新概念微服务架构的理论基础

康威定律告诉我们：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构；大的系统组织总是比小系统更倾向于分解

也就是说现在有许多公司都根据个人技能来划分团队：前端开发、后端开发和数据库开发组建团队。但是这会导致一个很严重的问题是当有人想要修改一个不属于自己领域的东西会很困难。所以最好是按照有边界的上下文(bounded context)来规划团队。也就是说像微服务这种架构围绕服务边界取代孤立的技术体系去划分组织团队——你想要什么样的系统设计，就去架构什么样的团队。

聚梦软件开发

摩尔定律(Moore's Law)——IT从业者听说过最多的定律

摩尔定律和我们讲：IT领域的各种硬件设备，每隔18个月，性能就会提升一倍。但是，虽然你的产品可能在按照摩尔定律不停的变化，但这些变化出来的增量却不断地在被别的软件所吃掉。

学习如逆水行舟，不进则退。如果你不保持学习是一定要被时代所淘汰的，严重点说即使不断的学习都不一定能够赶上时代发展的脚步。

想要抓住颠覆关键，就是要找到那个能带来“质变”点。了解知道这些定律的名称，让你告别软件白痴，而学会且能熟练地运用这些规律则能让你在软件开发中快速成长。