解惑

解己之惑,解人之惑

标签:开发 (第1页共2页)

智能化和极简化

曾几何时,企业级软件是一个非常高大上的名词,而难用是后面的潜台词,从部署到配置到使用,非常的受诟病,但是没办法,在软件开发不那么成熟的时代,能够有能力组织开发出如此复杂的软件的就那么几个公司,能够做出来已经很不错了,加上采购者和使用者完全是两拨人,使用者的话语权太低了,所以以用户为导向的重要性虽然在产品开发的过程中被重视,但是视角完全是错误的,重点完全在功能的完整性、多样性和灵活性上。当互联网真正崛起,SaaS被广为接受,服务化被广泛采用后,我们才发现他们的玩法不一样了,因为直接面对的是最终使用者,最终使用者的口碑传播效应得到了极大提升,以使用者作为真正用户的视角才被纠正,所以各种讨好最终使用者的特性才被重视起来了,早期一个很重要的概念就是傻瓜化,这个,乔布斯的iPhone也是居功至伟的,但是我更愿意叫这个为智能化,伴随而来的还有极简化,核心思想就是尽最大可能减少用户的思考和使用门槛,上手就能够用而且用的比较顺畅。由于我以前也搞过自己的社区,深深知道这个有多么的重要,而很不幸的是这么多年都在大公司,很多思想并不被接受,终于,从前几年开始,这些风终于刮到了企业级这个漆黑的领域。从3年前做的一键升级整个集群,使得原来一个40台节点集群的升级时间从7天缩短到8个小时(大部分其实是升级准备及数据库,服务器升级半个小时内就可以搞定,并行的),而且基本不需要人工干预(除非客户有自己的定制化配置),为此Support的头头还专门写信表扬过,到现在,新的产品的一个极大的重心也是在智能化和极简化上,包括安装和升级,总算开始和自己一贯的思想理念一致了,特此纪念下。。。

提升项目组的开发效率

通过几年的实际工作,也参与了规模不一的多个项目,但是项目组的开发效率一直不高,一直都在思考这个问题的症结,最近换了一个公司,由于刚刚去,也不能修改比较核心的代码,就给他们修改bug,在修改其中一个比较有共性的问题时接触了很多他们原来写的代码,发现代码中充斥着很多完全相同或者几乎完全相同的代码,最典型的就是获得数据库连接以及关闭数据库连接的代码,有的类会封装一个自己用的方法,有的就是干脆每次重复,有的更是有相关的方法但是代码的其它地方却没有用,这个现象给了我比较大的触动,现在仔细想想,其实影响一个项目组的开发效率的很大的因素就是代码共享和知识共享太缺乏了。但是代码共享和知识共享又确实是比较困难的事情,共通的功能如何使用,需要什么约束条件,能够完成什么功能等等都需要有比较完善的文档,而一旦这样的功能多起来以后你要从这些功能中找到需要的功能有时候确实是比较困难的,特别是有些功能去查是否有现成的代码所花费的时间可能比自己写一个还多。

根据我的经验,有几个地方注意一下就可以比较好的解决: 
 
共通的内容要易于使用和理解,例如定义的方法名要比较贴切。 
要写比较详细的说明文档,例如给大家发邮件或者发布到内部使用的论坛系统中。 
在公布之前经过充分的测试,否则使用的时候总是有各种问题会导致大家不敢再用共通的代码。 
对于类似的功能有其共通的代码,例如使用struts的系统有自己的系统的顶层的BaseAction,在这个BaseAction中定义系统中的子类需要实现的业务逻辑方法入口,而BaseAction要实现structs要求的execute方法,并完成所有的共通任务,例如是否登录的检查,session是否超时等 
业务功能要比较少的关心杂项共通功能,例如定义logger,获取数据库连接,关闭数据库连接,异常处理等,这些功能都可以定义在BaseAction或者是系统的顶层基类中。 
  而且通过使用共通功能也可以很大程度提高系统的质量,因为通过这些年的实践发现,很多新人由于开始不理解系统的要求,很多地方就是先抄袭别人甚至完全拷贝别人的代码,如果别人的代码是有问题的,那么在没有出问题之前是很难被自己发现的,而到了发现的时候已经积重难返了,而通过顶层类的封装,底层的类的空间就狭窄了,犯错误的可能性就小多了,因为很多系统的共通要求在顶层类中已经实现了。

不能浮躁

拿到一个新的任务的时候我们往往马上就开始干,特别是曾经接触过的内容,只要是自己感觉可以做,往往就不管三七二十一开始写代码,现在想想很不应该,拿到新的任务,先要研究一下难度,有没有难点和可能的潜在问题,什么样的方案比较好,灵活性、通用性以及可扩展性方面,另外就是看看系统中是否已经有其它的现成的代码。
每个项目我感觉应该有一个公共的功能库,不光是减轻开发的工作量,对于程序的稳定性,可维护性也是莫大的提高,但是往往有两个问题:
 一、不愿意用别人写的代码,自己总觉得自己的代码比别人好。
 二、不知道怎么用,因为没有文档,这个确实是开发人员的一个通病,喜欢写代码不喜欢写使用文档或者说明文档。

加班的日子结束了

这段时间加了不少的班,开始只是周末加班,一周加一天,加了四周,前天晚上又加到很晚,我是到两点才走的。不过平时我还是走得比较早的,基本上6点半或者7点走,只是保证每天工作8个小时。
项目经理告诉我们的是接下来的一个月会比较轻松,不会马上有下一个版本的计划,应该会做一些自动发布的东西,另外我可能会提议把单元测试框架搭好,其实Oneal已经有一个雏形,可以做很多类型的单元测试了。这样我们下个月的日子以至以后的日子都会好过得多。
进这个公司也快两个月了,这次是我感觉技术最复杂的项目,所以也是我找到感觉最慢的一次,原来的公司都是进去后一个星期基本上就可以放开手脚做事情了,这次足足花了一个多月才找到感觉,一个是用到的技术比较多,LDAP,SQL Server, WorkFlow,DB2,Web Service,ESB都是第一次用,另外就是比较杂,后台的EJB2,EJB3,Hibernate混合使用,老的系统使用的老的技术,新的代码慢慢的过渡到新技术,加上AOP在其中穿插使用,最后就是遗留系统集成,我们这个项目是核心项目,原来的一些合并过来的公司的老的项目都要把数据集成到这个里面,所以集成的很多BUG很麻烦,因为我们搭一个完整的环境需要至少六台服务器,而其它的系统我们自己是不能搭的,只提供给我们开发和QA各一台,这样我们在开发的时候往往就存在冲突,可以说一天可能有很多的时间是在等待中度过的。而我们开发的环境因为使用的人多,经常有人修改配置,搞得很不稳定,后来和QA混熟了借他们的服务器直接打一个Hot Fix,也就是把我编译好的几个类替换下,然后在他们的环境里面验证,验证完了再还原回去,而这个要等他们QA都去吃饭的时候做
唉,这个阶段告以段落了,下个月要好好的想办法让这个项目的日子更加的好过一点了,这样我就可以恢复原来不用加班的生活了

保持开放的思想

今天突然发现自己原来对Ruby和RoR的抵触是完全没有道理的,因为自己理想中的Java开发框架和RoR的很多思想其实是相同的,可能是太喜欢Java,使用的时间也太长,任何对它可能构成威胁的东西都会有本能的反应了?
其实Java语言本来也是吸取其他语言的精华而创建出来的,每当有一种新的语言诞生的时候,也同时意味着它必定有什么优势,否则是很难被人接受并被广泛使用的,如果本着学习的精神,我们其实可以从这些新兴的语言身上学习和借鉴这些优点,并努力借用到Java的开发中,除了语言本身的限制,我们应该是可以借鉴很多。
我想如果一个掌握OO设计的高手去使用汇编或者C语言做开发,那么他在OO中学习到的一些东西肯定可以借用到这些语言中。

PS:Java世界一直没有出现我期望的框架,我自己也在尝试做一个,需要研究研究RoR了,很多规则或者思想可以借鉴过来

软件开发的最大困难其实在于消除重复代码

这个并不是我一时兴起的胡言乱语,而是我的肺腑之言。如果你仔细的审视一下你所在的项目的代码,你可能会发现其中60%以上的代码是何其的类似,充斥其中的都是类似的判断和循环,在项目的框架或者架构稳定下来以后,项目的工作就是每天重复类似的工作,然后就是这些类似的代码的比例越来越大。如果项目的架构或者框架代码不够好,而某一天有一个需求导致这些代码都要进行某种简单或者复杂的更新,那么你的噩梦就来了。
软件开发的最大困难也就随之出现,如果你的框架足够好,共通的需求只会导致一个或者有限的几个地方的修改,如果框架不好,那么你就准备把那个修改重复几十遍或者几百上千遍吧。衡量一个软件的设计是否足够好,我想最重要的标准就是它能多大程度上消除这样的情况。仅仅有了好的架构其实也不够,开发人员可能会复制一段类似的代码,导致超出框架设计的代码重复,这个就是检验项目管理是否足够好了。

设计一个简单易懂、易于扩展、易于维护的框架并不是很难的,结合OO设计的原则和一些设计模式就可以做到,但是问题并没有结束,如何消除业务代码中存在的类似代码结构才是真正的问题所在。
我没有解决方案

当然,软件开发也并不是只有消除重复代码这一个问题,但是我感觉,如果能够较好的消除代码重复,那么软件的开发效率和质量以及可维护性将更好。
PS:我并没有说完全消除重复代码,代码的重复性是不可避免的,典型的例子就是单元测试代码。

没有命名规范的代码是开发人员的地狱

我们已经开始了一个新的阶段,这个阶段的开始并不顺利,因为我遇到了一个原来并不是很常见的问题,我竟然找不到合适的API供我使用,而且是我们系统的基础服务的API,原因不是别的,就是因为命名规范,第一是方法名,原来的很多API的方法名就是开发人员随意取的(我们没有编码规范或者说命名规范),一个公共的Session Bean的Proxy的方法名竟然叫getAll,而它仅仅是返回一个特定的对象的集合,一般这样的方法都应该叫getAllXxxx,第二是有些术语修改了,但是只是把界面上用户可以看到的文字修改了,后台的API的方法名和类名都没有修改,如果你不是相关的开发人员,你怎么可能弄清楚呢?而原来为什么没有修改方法呢?很简单,一些少数的地方使用反射调用,所以用IDE的重构方法可能会漏掉一些地方,所以他们不敢改,举一个真实的例子说明这个命名的修改导致了多么大的问题:
app group-> app
app template -> component
app -> component instance
说实话,在这一点上,我们的产品实在是失败,因为自从我做开发依赖,所去过的公司还没有说哪个公司没有命名规范的。

CVS开发方式是软件维护性的杀手

呵呵,不要误会,这里的CVS不是指版本管理的CVS,而是指程序员们最熟悉的三个快捷键:CTRL+C(复制)CTRL+V(转贴)CTRL+S(保存),一个软件产品中的很多代码都是这么得来的,以我们公司产品为例,最典型的莫过于Action的execute方法的前面对session是否过期的判断,以及调用后台的Session Bean的时候的异常处理,以及JSP中的大段类似代码。一旦需求发生变化,这些相关的代码可能都需要修改,我到这个公司的时候就发生过一次这样的事情:一个简单的修改要在百十几个Action中重复进行。
以我这些年的开发经验,我更加倾向于给开发人员提供一个受限的开发环境,可以供选择的接口很少,只有在必要的情况下才增加接口供开发人员使用,共通的功能只能通过共通的接口进行,否则你的工作量可能是使用正确的接口的十几倍。当然,这个开发方式比较适用于产品开发,因为项目的情况差异太大,而且开发周期相对比较短,这样做反倒延缓开发进度,增加成本。
至于如何提供那些接口,就是一个渐进的过程,开始的框架是一个宽泛的接口集,如果一段代码被重复三次,并且以后可能还会重复或者有类似的片断,那么就要马上对原来的代码进行重构,这样在第一个版本出来之前,我们就会得到一个比较好产品。在每个版本的开发前期、中期和后期都做一次代码检查,发现类似这样的代码重复问题并及时修改。

软件开发必备的因素

现在的软件开发流程(或者是开发方法,例如CMM,RUP,XP等)有很多,但是对于很多小公司而言,不会完全去照搬一套流程,但是大公司肯定会选择一套标准的流程或者根据自己的情况定制一个合适的流程。我也在各种类型的公司都做过,因此也接触了很多种开发方式,对于一些小公司,揉合这些开发方法,提取切实可行又灵活的开发方法是一个不错的选择,就我而言,下面这些是一些容易做到也对公司对开发团队都很有利的一些内容:

  • 必须有源代码管理机制,推荐使用CVS或者Subversion
  • 一个项目或者产品的开发团队必须至少是三层的,最上面的就是PM,PSM,架构师或者总技术负责人之类的,负责总体的协调和管理,第二层就是小组长,必须对产品或者项目比较熟悉,可以解决小组成员60%以上的问题,然后就是开发人员,小组的结构应该是很小的,四个人为宜,一个组长加3个组员
  • 必须有内部的知识共享机制,可以选择论坛或者WIKI,搜索功能必须强大好用
  • 有IM可以及时的沟通,无论是否是分布式开发,即使在一个办公室里面也要有,如果为了防止外部的干扰,可以搭建内部的IM 服务器
  • 重要的讨论一定要通过邮件或者及时记录下来,把QA小组相关的人员也包含在内
  • 必须有单元测试,最好是全面的自动测试,但是QA小组的验收性测试依然是必不可少的
  • 要培养开发人员高质量的源代码意识,鼓励他们学习设计模式、重构,要求他们的源代码要便于维护、易读、格式统一、消除重复代码等(这个很多小公司最容易忽视,然后就是后面接手的人骂前面写那些代码的人)

全乱套了

台湾海域的地震导致的余波到现在还没有接触,到北美的互联网还没有完全恢复,甚至情况更加的糟糕了,上周前两天还能够收到邮件,上周末开始,邮件也收不到了,SCARAB服务器只能登录进行,一到详细页面就不行了,现在到好,连CVS也不行了。我们现在只能在本地工作,而我们之间的工作是有依赖的,特别是我,这段时间的任务都要依赖别人的结果,只能等待了。
如果不是这次地震,真的不会意识到互联网是如此的重要,这种分布式开发是如此的脆弱。

更早的文章

© 2019 解惑

本主题由Anders Noren提供向上 ↑