我经常发现自己正在与过度工程作斗争 - 负责设计软件的人提出了一种过于复杂的架构.
拥有用户永远不会知道的所有深奥功能,并且当你正在做一些所有杂志文章告诉你的东西是最新的,很酷的东西时,这一切都很好,但我们会花钱我们工作时间的一半是在这个纪念碑上我们的聪明,而不是,你知道,我们的用户需要的实际产品和高层管理人员希望在合理或至少有限的时间范围内完成.
当你开始没时间的时候,也就是说,如果你有机会,你可能只需要回到更简单的解决方案.
我们都听过这句话:Keep It Simple,Stupid™.
你如何在你的团队中过度复杂地战斗？
我最近不得不反复使用的一个例子是,当决定进入完全非规范化的数据库设计而不是RDBMS时."因为它更快!" 完全非规范化的数据库确实难以正确,并且仅适用于Flickr或ebay等真正专业的数据问题,而且相对于开发的其他部分而言,开发人员的时间可能非常昂贵.
牙齿和指甲,有时你输了.问题在于,很容易被诱惑去构建一些很酷的东西.
为什么在复杂而精彩的情况下构建简单有效的东西？
试着提醒人们建立可能有效的最简单的事情的XP规则.
确保反弹任何其他人的想法.通常情况下,我们会以某种方式处理事情,以至于需要另一组眼睛才能使你正确.曾经有很多次我通过让其他人说"我们真的需要那个吗？" 来解决困难问题.这有助于使我的代码更简单.
在处理你不同意的人的问题上,Ward Cunningham有一个很好的观点:
当我意识到我没有赢得每一个论点时,这是我编程生涯中的一个转折点.我会和别人谈论代码,我会说,"我认为最好的方法是A." 而且他们会说,"我认为最好的方法就是B.我会说,"不,这真的是A."他们会说,"好吧,我们想做B."我可以说,"好吧,这是我的转折点.做B.如果我错了,这不会伤害我们.如果我是对的并且你做B,这不会伤害我们,因为,我们可以纠正错误.所以让我们看看这是不是一个错误.......通常它原来是C.这对我们两个人来说都是一次学习经历.如果我们在没有经验的情况下做出决定,我们都不会真正学习.沃德赢了,其他人没有.或相反亦然.这太激烈了.为什么不说,"好吧,让我们编写代码并看看会发生什么.如果它不起作用,我们将改变它."
我的建议？如果你想做更好的事情,想出一个简单的原型,证明它更好.意见很棒,但代码谈判.
我在某个地方看过这个公式:
技能=问题的复杂性/解决方案的复杂性http://img39.imageshack.us/img39/1586/whatisskill.png
换句话说,它需要技能来创建复杂问题的简单解决方案.如果有人故意设计并为复杂的过度设计解决方案感到自豪,那么他就会无意识地无能为力.
就个人而言,有助于我保持设计简单的是TDD循环.首先编写一个测试,指定您想要达到的目标,然后生成"可能最有效的最简单的东西".并且时不时地反思你所制作的东西,并思考如何使它变得更简单.
永远不要在系统中构建额外的灵活性和抽象层,直到你现在拥有的东西需要它为止.当你有一个好的单元测试套件时,更改代码很容易,所以你可以在需要时添加这些抽象层,如果它出现的话.否则,"你不会需要它".
编写测试过程复杂时,设计过于复杂的一些症状.如果测试需要很长的设置代码,那么您可能有太多的依赖关系或者其他方式太复杂.如果遇到并发错误,那么也许你应该考虑如何设计系统,以便将并发限制在绝对最小的类数.也许使用消息传递架构,例如Actor模型,并使几乎每个组件都是单线程的,即使整个系统是多线程的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 