短小的迭代,每个迭代只关注一小部分的增量功能。因为每个迭代对应的编码只需要数周,所以功能易于管理并简单。
3. 持续重构代码
编码很像雕刻。要像艺术家一样不断完善自己的作品,软件工程师也要通过可能的最佳方式来持续完善自己的代码,以达到目标。重新塑造代码的原则称为“重构”,Martin Fowler在他的创意书中有相应描述。重构背后的原始思想是:改善代码而不改变其功能,移动调整部分代码以确保系统不腐,还有确保系统完成基于当前需求该完成的事。持续重构可以让开发人员解决另一个著名的问题——“黑盒遗留代码”(这个
问题基本无人想触及)。
几十年的
软件开发文化要求我们,不应该去改变正常工作的东西。然而,随着时间推移,问题是我们成为了老旧代码的奴隶,老旧代码变得不稳定和不兼容。而重构正好可以改变这一状况,因为我们是代码的主人,不是它的奴隶。重构在工程师和代码之间建立起持续的“对话”,并带来所有权、确定性、自信心和系统的稳定性。
千万不要成为老旧代码的奴隶。如果代码是他人所写,或许你可以轻易推脱责任。但大多数时候,那些代码是自己所写,要拿得起放得下,旧代码该埋时,就把它埋了!
4. 使用设计模式
自从所谓的“四人帮”(Erich Gamma、Richard Helm、Ralph Johnson和JohnVlissides)发表他们的著作——《设计模式》后,全世界的软件工程师一直都在讨论模式。在我们所处的世界,不管是自然界还是人类行为,模式无处不在。软件工程自然也不例外。模式就是不断重现的跨语言跨
系统的场景和机制。一位优秀的工程师通常能识别并利用模式,而不是受制于模式。工程师不应(强制)让系统去适应某种模式,而需发现在系统中使用模式的时机(恰当使用模式)。在使用模式来确保正确性时,应借鉴利用前人的智慧结晶,使用以前能正当解决特定工程问题的方法。但请切记:模式不是万灵药;不要为了使用设计模式而使用设计模式。
5. 编写测试
曾有段时间,软件工程师们认为测试不值得他们去做。然而,如果你不做测试,你怎么能确保代码就能正常工作呢?敏捷实践中的“单元测试”已获得普遍认可,因为它注重编写测试来反映代码是否有效。随着系统增大,测试也随之增大。有经验的工程师知道并了解测试的价值所在,因为测试的目的就是创建一个能正常运作的系统。优秀的工程师通常会确保出现过一次的Bug不会再出现第二次。但优秀的工程师也知道,不
应该浪费时间写那些琐碎或多余的测试,而需要专注测试各个组件中的核心部分。
6. 善用现有代码
“重新发明轮子”一直是软件行业中的巨大问题之一。从发明新语言到从写函数库,忽视并重写那些已经存在并已能工作的奇怪驱动力,已经造成大量软件开发的失败案例。一位明星工程师会专注三种基本类型的重用:第一,内部基础架构的重用,相应代码是他自己或同事编写的;第二,使用第三方的函数库,比如JDK。最后,研究使用某些大型
网络服务商提供的相应服务,比如Amazon。总之,正确善用现有的代码,使得软件工程师能真正专注于最为重要的事情上——应用程序本身。
7. 专注可用性
优秀的工程师通常都专注于用户。无论用户是企业还是个人,无论是为消费型的软件公司还是投资银行,需要关注的都是可用性。用户如何和系统交互?系统是否提供一种简单、直接和平稳的操作体验?有种说法,因为软件工程师是技术人员,他/她和“用户如何与系统交互”没有关联,这种说法严重错误。优秀工程师努力工作是为了什么?不正是让系统简单并易于使用。他们无时无刻都会想到用户,不会尝试去发明那些令人费解,只有极客才能理解并欣赏的东西。
有些时候,一些软件工程师过于投入,反而