计算机专业毕业的学生在学校当中,都读过软件工程这本书,而软件工程的书,都无一例外的,强行规定了一个编码阶段,并且十分严肃的告诉学生,代码在整个软件过程的生命周期阶段当中,只占了1/5左右。需求分析和设计、项目管理,更强于代码。我想对这于刚毕业的学生,是一种思想上的毒害,很多人刚毕业一两年,都耐不住性子,哭着喊着,要做architect,要做PM。
我认为回避代码是可耻的,只要编码显的有意义,我们在任何阶段,都应当投入到编码当中。
最近一个项目,我下面有两个设计人员(GM派过来的),协助我做设计,我做了一个设计的骨架,然后交给他们去迭代细代。下班前,我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板,我对他们说,不要求你们去写文档,我也没有时间去看,我不知道你们以前,是怎么做这设计的,但在我这个组,这样做,不行。做为设计者,首先是自己要理解要做的东西,并且真正知道怎么去设计它才能满足涉众需求,第二步,才是让别人能够理解你的设计。怎么样让别人理解你的设计,文档并不是唯一的途径,对于普通程度员来讲,白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人,我们很多的设计者,总是喜欢用大量的4+1 UML图和文档中生硬、冰冷的词汇来吓唬程序员,恰恰反映出了设计者内心的空虚与胆怯。
以往自身的设计经历,谈一下:
我第一次给另一个组做一个子模块的设计时,心里很紧张,因为我不在它们那个组中,也不参与他们的开发,这个设计对于他们的项目进度来说,又是一个关键路径,我生怕我自己设计的不好,考虑问题考虑的不周到,在项目后期,如果出现问题,自己责任重大。
其实我给他们说,这个设计需要两个星期,其实我只化了三天,就把接口文档写好了,我对着接口考虑来考虑去,还是觉得没有底,我忍不住想写代码,来验证这样做对不对,又怕别人说我的设计能力不强。我就偷偷摸摸的写代码,又和他们的组的主要使用者反复沟通了几次,根据需求,设计了几种不同的案例,来验证我的设计是否有漏洞。
最后,又对接口修复了几次,觉得接口相对稳定和健壮了,就让他们过来看看,提出问题,结果也没有提出什么问题。于是我就交工了。
实事上,这个接口,在开发后期,还是有一点修改,但并没有给他们的项目造成很大的影响,他们本身也认为能考虑的这么全面,已经不易。
做开发这么多年,越来越觉得设计是一个很复杂的东东,他不像建筑工程中的设计一样,可以用工程化的方法去中规中矩的验证,并交给工人进行构造。
这几年,我经历的每个项目,几乎都有评审,需求评审,设计评审等等,但我现在回想过来,我想不出对我的项目有太多的意义,很多人痴迷于通过文档和评审来试图证明设计是正确的,而通过评审,对于PM和Architect,似乎也被当做是一个项目当中非常重大的milestone,直到现在,我的上级和我的同事,似乎从未改变。而我的自己观点的表白在OP会上,迎来的是批判。
文档必须要有,总体的架构设计和模块的详细设计,都是需要的,但是设计者,往往忘记了,文档只是设计者自己对已经构思好的设计的一种反映,这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具,它绝对不是一个证明自己完成一个良好设计的方法。
编码、测试、调试、交付用户UAT,都应当视为是设计的过程,也应当是验证设计是否正确的最好的办法。
尽早的进入代码开发,是敏捷开发中一个很重要的标志,所谓的标志,我认为如果在项目前期的前一两个月,你仍然徘徊在需求分析、文档编写的工作当中,而没有代码产生,你绝对不是敏捷。这个观点是我自己加的,我很难容忍,我的设计、分析人员天天在写文档,开发人员在心猿意马的看长遍大论的需求和设计文档,一句话,越早进入开发,我就越主动。
我验证设计的一些方法:
1.根据以往的设计经验,做一些check list.
2.写代码,做demo。做Demo是我非常喜欢的一个方法,一个可以运行的Demo,远胜过文档了。开发人员一看,直接copy、paste就完了。做汽车、计算机等新产品,都会有样机,对样机做大量的试验后,才能上线,大批量的生产,在软件当中,怎么一做完设计,就大规模的进行开发了呢。
3.做测试案例,TDD是一种方法,有长期开发经验的人很容易吸收的思想,并且愿意在重要的地方使用,来理顺和验证自己思路。
4.对于设计的涉众人员,能够尽早的看到,并充分的沟通,不要把文档写完了,才交给他们,那是一种思想上的强暴。很多时候,在领导的安排下,设计人员与开发人员,在能力上,并差不了多少。所以设计人员要虚心,并且要有责任心。
好的设计应当交付什么:
1. 有简洁注释的代码
2. TestCase
3. Demo
4. 模型
5. 文档
分享到:
相关推荐
不错的资源 1.要养成一个习惯, 经常花时间...3.要注意并重视代码中特殊的非功能性需求, 这些需求也许会导致特殊的实现风格. 4.在现有的代码上工作时, 请与作者和维护人员进行必要的协调, 以避免重复劳动或产生厌恶情绪.
3.要注意并重视代码中特殊的非功能性需求, 这些需求也许会导致特殊的实现风格. 4.在现有的代码上工作时, 请与作者和维护人员进行必要的协调, 以避免重复劳动或产生厌恶情绪. 5.请将从开放源码软件中得到的益处看作是...
LMLPHP在设计之初,作者特别重视代码体积和质量,并保持框架的简单和灵活性;并采用自主研发的代码压缩技术,将源代码压缩至约22KB,纵然如此,它依然是最优秀的框架之一。它遵循MIT(http://mit-license.org/)开源...
最近几年,Web前端的发展非常迅速,并呈现出一片欣欣向荣的景象。...国内Web前端开发者普遍不重视代码规范,以及网站前端性能。很多网站甚至连最基本的前端代码压缩和合并都没有。本书立足于Web前端开发的基础
本书贴近Web前端标准来介绍前端开发相关最佳实践,目的在于让前端开发工程师提高编写代码的质量,重视代码的可维护性和执行性能,让初级工程师从入门开始就养成一个良好的编码习惯。本书总共分五个部分13章,第一...
本书贴近Web前端标准来介绍前端开发相关最佳实践,目的在于让前端开发工程师提高编写代码的质量,重视代码的可维护性和执行性能,让初级工程师从入门开始就养成一个良好的编码习惯。本书总共分五个部分13章,第一...
忍不住想谈谈代码规范的重要性,希望所有人都能够重视起来。而且,我相信,如果我们代码规范能够做好的话,且不说开发水平提高多少,至少我们也会有很多出色开源项目。 一、规范的代码可以促进团队合作 一个项目...
知识管理越来越被大家所重视,源代码也应该做为一种知识资 源,纳入知识管理体系中去。CodeHelp 是为了方便程序员更好的管 理自己的源代码而写的一款免费软件。 利用 CodeHelp,可以方便的管理你的各种技术资料和...
为了提高软件的安全性,常使攻击者难以理解专利软件系统内部的工作机制,代码迷惑技术因其代价低廉而越来越受到人们的重视。代码迷惑技术的提出对于软件保护具有非常重要的意义,代码迷惑技术的使用可以对程序代码及...
随着Ajax的应用普及,JavaScript已经得到了越来越多程序员的重视。但JS不好调试,代码多了也会严重影响速度,当你在为提高了用户体验,做出了很绚丽的效果而欣喜的时候,是否想过优化一下JS的效率,大网站的JS都做了...
知识管理越来越被大家所重视,源代码也应该做为一种知识资源,纳入知识管理体系中去。CodeHelp 是为了方便程序员更好的管理自己的源代码而写的一款免费软件。 利用 CodeHelp,可以方便的管理你的各种技术资料和源...
重视代码的可读性,可维护性,可拓展性 四 个人技能 擅长Java平台开发,喜欢研究前沿技术,喜欢研究JVM,JUC,NIO,NETTY 擅长性能调优,处理多线程高并发场景 关注系统安全,熟悉安全相关知识 熟悉消息队列,SQL/...
不过我们发现很多软件公司在重视代码开发的同时,却没有把代码质量跟上去,忽略了测试在国内软件测试现状近期国家对软件行业也给出了很多鼓励政策,软件及相关行业在中国得到了很大的发展,我们也看到了一大批软件...
源代码抄袭检测技术研究,秦虎,崔宝江,在互联网飞速发展的今天,软件著作权保护越来越引起人们的重视,源代码的抄袭检测技术也就变得越来越重要。本文提出一种基于抽象
作为软件公司,还是得重视保护好本身的源代码。” 若是黑客所述属实,那这将是继2012年1月初,赛门铁克Endpoint Protection 11.0(SEP)和Symantec AntiVirus 10.2源码被泄漏今后,又一个赛门铁克重点产品源码...
面向对象开发中程序员更重视代码的重用性和可维护性,设计模式使人们可以更加简单方便地重复使用成功的设计和体系结构
★ 知识管理越来越被大家所重视,源代码也应该做为一种知识资源,纳入知识管理体系中去。利用CodeHelp,可以方便的管理你的各种技术资料和源代码。 ★ CodeHelp 支持多个数据库文件,能够新建数据库、打开数据库、...
由于二次规划比较简单,便于求解(仅次于线性规划),并且一些非线性优化问题可以转化为求解一些列的二次规划问题,因此二次规划的求解方法较早引起人们的重视,称为求解非线性优化的一个重要途径。二次规划的算法较...