闲谈简单设计(KISS)疑惑
忙碌了一年了项目又到了交互了,虽然项目能成功上线(因为还有维护支持的团队)。但是个人从技术上看,这是一个不那么成功的项目,因为后期艰难的修复bug,添加feature。这与简单设计有什么关系呢?在某模块开发起初,由于架构的经验预见性的告诉我这模块开发中会出现什么问题,所以选择了提出某些比较好的解决方案,但是由于团队成员一致的所谓简单设计,通过TDD,重构达到”合适”的”完美”的设计,可是最后的结果如我所料一切的发生。这里插一句,现在在一家敏捷公司,敏捷强调是合作,所以没有一个人同意规划决策,不同之前的公司作为架构师决策一切架构设计。敏捷合作交流我不否认你正确性,因为我也相信软件是人和时间的问题,方法论都是解决我和时间的问题。但是对于一个在成长中团队,成员的设计或者某些预见性或者重构能力,力度相对不足的情形下,这样是不是合理? 回到主题,简单设计英语 Keep It Simple, Stupid。我们常说的KISS原则,保持产品或设计的简单性,同时功能的足够性。我想说的是翻译成为简单这是一个错误的决定,因为这不是绝对的简单,在我看来最简单的系统就是没代码的系统,代码越少,甚至没有就没有...


