过度工程,最初我知道这个词是在Rod Johnson的《J2EE Development without EJB》,随着阅历地增长,渐渐发现书中熟悉的场景也在身边再现了。
敏捷、还有设计模式,给一个团队带来了什么?
我之所以把这两个词放在一起讲,是因为我要说一件显而易见的事情,可是这样一件事情很多人又不愿承认。
团队,是有风格个性的;团队,也是有能力强弱的。不管你承认不承认,整体来说,我们都还不是精英团队,因此相对于某些公司成功的案例来说,我们有很多事是不适合做的。
敏捷强调了主动性,强调了沟通,事实上并不是身边所有的团队都能做好敏捷管理的,譬如一支过于年轻化的团队、一支基本由外包人员构成的团队,甚至一支连转SDV版本都要熬一个通宵的团队,我认为是不适合实施敏捷流程的,至少,大部分所谓的敏捷实践,都是走样的。
关于设计模式,我要说什么?
我可以在板书上用Java和C++写出GoF 23种设计模式中的每个例子,也学习过J2EE Core Pattern,可即便这样,我依然在实际的软件开发中的某些情况下,避免使用它们。因为即便一个设计再过精巧,它依然是要和团队的风格和接受能力想匹配的,我们都是工程商人,公司也不以追求完美的代码为己任,需要的是一个一个项目坚实地交付,可以踏踏实实地赚到钱。
我觉得,“某一些精巧的设计,恰恰是以降低代码的可维护性为代价的”,当然这一句话在不同的团队场景中是不尽相同的。举例来说,一些回调方法、闭包的使用,还有庞大的职责链,都给代码的识别和单步调试带来困难。成熟的开发者,能够克服总想要引入新技术的冲动,并且不会在项目中去写只有少数人才能理解的奥义代码。
我相信会有很多人不认可我的观点,不过我相信并不一定要谁说服谁,有不同的想法经常是好事。
分布式对象,我们遇到了什么问题?
为什么使用分布式对象?看起来根本似乎是因为整个解决方案过于庞大了,软件工程中一切不好解决的问题都是由问题复杂引起的。分布式对象在SOA架构中有着不可替代的作用,也许遗憾的是我并不在这里强调问题的严重性,然后“啪”扔出一个传说中的最佳解决之道。
不过开发人员天生的本事就是善于抱怨,分布式对象确确实实带来了许许多多的麻烦,最典型的“阻抗不匹配”,是说无论是人力成本还是性能成本,都把精力耗费在传输对象和领域对象之间的数据交换,甚至数据同步上面。
我还记得Martin Fowlor提到:“分布式对象的第一条准则:不要使用分布式对象”。
举一个产品的例子,我们所有的产品处理逻辑全部都要通过SOAP接口中调用别的部件来实现,本地是没有持久化了的产品对象的,随着这一堆的接口愈加复杂和庞大,许许多多开发人员都希望有一天产品能够同步到本地来,落到存储中,一些流程上的接口性能问题就迎刃而解了,而这些问题,都是自己给自己造的绊脚石。
是否有过度的架构和过多的框架代码:
架构的价值在于为常见的问题找到好的解决方案,而不是一心想要解决更复杂也更罕见的问题。
这里遇到一个矛盾,产品的发展过程中,系统架构确实是在不断调整的,这些事情现在就是由开发人员完成的。问题是这过程中,到底应该分析到怎样的粒度?
问题不是分解得越细致、考虑得越多越好。在细节上挣扎得越久,就越难以设计出简洁和清晰的方案来。复杂,是软件的唯一天敌。可是简单的设计,又会令人不住地担心,是否会带来不易解决的问题。
这是一个不可调和的矛盾。其中一个好的办法是做纵向切面,设计一个系统架构时,做一个合适位置的纵向切面,能发现一些潜在的问题,作为可行性分析的重要依据。最典型的例子是性能问题,这些问题到了项目中后期很容易就能将一个工程陷入挣扎的境地。
框架代码是没有净生产力代码的一种。产品的代码,就像一只羽翼丰满的鸟,当这只鸟儿的骨架过于庞大,便难以飞远、飞高。简单的框架代码,意味着较高的可理解性,整个工程对新员工来说,是清晰的,易于业务技能的传递。
糟糕的可选性功能:
我们经常听到这样的对话:
——请确认这个功能需要实现吗?
——这个功能目前需要实现,但必须考虑到未来xxx的情形,保持灵活性,请做成配置项:1表示开启;0表示关闭。
于是,我们就有了漫山遍野的配置项。
我认为,这是最糟糕的回答了。我们不是在做一个刚好交付的产品,而是在做一个超级“灵活”的变形金刚,代码里面布满了配置项判断逻辑。
又是框架、又是平台……
框架、平台,这是很多学习J2EE的朋友最害怕听到的两个词语。身边似乎有无数这样的东西,产品能不能简单一些?使用硕大的框架和平台确实能够具备一些便利的功能……可是,我真的需要那么多吗?
开始理解代码了,有数种不同格式的模板、不同类型的标签,甚至连会话,都经常需要操作多种类型的会话获取接口。一个问题出现,我们从一个模块定位到另一个模块,从一个抽象层定位到另一个抽象层,最后吐血地发现,不是我们的代码问题,是框架或者平台的问题……
另一个同类产品,就开始尝试采用简洁的框架来实现,也不打算搬迁到什么复杂的平台上了。框架和平台的使用,一定要评估好必要性和影响,能简化的实现就不要作茧自缚,软件的本身,WEB应用的本身,是否就该追求简单的美?
文章系本人原创,转载请注明作者和出处
分享到:
相关推荐
【大型临时设施和过渡工程】是建筑工程中必不可少的一部分,它们主要服务于施工过程,同时也保障既有线的正常运营。这些设施的建设和费用涉及到多个方面,包括铁路、公路、通信、水电供应等多个领域,对于大型工程...
2. **适度工程与生态保护**:在实施工程改造时,应考虑其对生态环境的影响,选择对环境友好且能保持乡村特色的解决方案,避免过度工程化,保持乡村的生态平衡。 3. **深度挖掘与展现文化**:景观设计应注重挖掘和...
开发者可能过度工程化,编写出冗余、难以理解和维护的代码。这不仅增加了开发时间,还可能导致软件性能下降,增加后期维护成本。因此,遵循简洁、模块化和可扩展的设计原则,如KISS(Keep It Simple, Stupid)和DRY...
总结起来,模型驱动开发在提升软件开发效率和质量方面具有巨大潜力,但要克服误解和挑战,包括方法的可用性和实施,基础设施与工具的适应性,以及过度工程化的风险。通过持续改进方法论,定制开发过程,以及优化工具...
SRE是Google提出的一种运维模式,它将软件工程的思维引入到传统运维工作中,旨在确保服务的高可用性、性能和效率,同时避免过度工程化。该书详细阐述了Google如何运用SRE原则和方法来管理和维护其庞大的在线服务。 ...
度量有助于软件开发者明确目标,优化设计,但过度依赖某一种度量可能会导致“过度工程”或忽视其他重要因素。 在设计调用和返回结构时,如果模块的扇出(fan-out)或扇入(fan-in)过多(简答题2),可能导致模块间...
matlab的素描代码自动驾驶汽车 Aalto AS-0.3200项目工作:遥控模型车的控制系统和UI。 包括用于Atmel AVR微控制器的车载计算机代码(最初为Arduino草图),包括用于在Matlab中模拟所有这些的概念验证模块,用于...
选择适合项目规模的框架,避免过度工程。 六、慎用System.out.println和字符串连接 在开发过程中,System.out.println常用于调试,但过度依赖会影响性能,且不易于长期管理和收集日志。考虑使用正式的日志记录工具...
这并不意味着完全摒弃文档,而是主张在必要时才进行文档化,避免过度工程化。 3. **客户合作重于合同谈判** - 敏捷开发强调与客户的紧密合作,通过持续反馈和迭代改进,确保最终产品符合用户的真实需求。合同条款...
【某省总工会干校过度食堂工程施工组织设计】 本施工组织设计详细规划了某省总工会干校食堂改造工程的各个环节,旨在确保工程高效、安全、优质地完成。首先,设计涵盖了施工现场的平面布置,通过合理布局以优化施工...
【某省总工会干校过度食堂工程施工组织设计】是关于建筑工程管理与工程安全的专业文档,主要涵盖了施工项目的规划、组织和实施。以下是对该文件主要内容的详细解析: 1. **施工组织设计**:施工组织设计是工程项目...
《某省总工会干校过渡食堂工程施工组织设计》是针对房建建筑工程施工的一种详细规划和实施方案。这份设计旨在确保工程的高效、安全、质量和进度得到充分保障。在房建建筑工程施工组织设计中,通常涵盖以下几个核心...
在工程实践中可能出现的伦理问题包括决策过程中的利益冲突、忽视公众权益和社区关怀,以及企业过度追求利润导致的安全和环境问题。例如,怒江水电开发案就揭示了决策过程中的伦理盲点,未能充分考虑当地居民的生存...
虽然逆向工程简化了工作,但也要注意不要过度依赖,对于复杂或特殊的业务逻辑,可能还需要手动调整生成的代码。 总的来说,MyBatis逆向工程工具是Java开发中的利器,能够极大地提高开发效率,减少繁琐的手动编码...
早期,由于科技限制,人们更多地是听天由命,随着工业革命,人类开始尝试征服自然,但过度开发导致环境问题日益显现,如伦敦的“雾都”事件,提醒人们必须考虑工程活动对生态和社会的影响。现代工程理念倡导天人和谐...
同样,过度强调主体的意识、激情或意志也会导向唯心主义,如贝克莱的感觉主义、黑格尔的观念论和叔本华的意志主义。 工程思维作为一种重要的思维方式,其特点在于它关注思维形式与内容的统一,以及它们在实际问题...
如果资源分配不当或过度负荷,可能会影响项目的进展。 6. **满意度晴雨表**:这包括客户、用户以及团队成员的满意度调查,以确保项目满足所有利益相关方的期望。 创建和维护工程晴雨表的过程涉及收集数据、分析...