`
OneEyeWolf
  • 浏览: 105137 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

重视代码

阅读更多

 


   计算机专业毕业的学生在学校当中,都读过软件工程这本书,而软件工程的书,都无一例外的,强行规定了一个编码阶段,并且十分严肃的告诉学生,代码在整个软件过程的生命周期阶段当中,只占了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. 文档

   

 

 

 
分享到:
评论
11 楼 yiding_he 2007-07-13  
mvmouse 写道
设计,不管是用什么形式(UML、DOC...),最终的目的是为了帮助开发人员更好更快的实现业务需求。应该设计到什么程度?是把流程描述清晰,还是进而把接口描述完备,甚至写出关键实现代码?
我遇到过这样的情况,我和A做的设计,交给开发人员C做实现,结果C对某些环节没想明白,也没和我们讨论,就实现出了一个和原来设计相差很多的东西。结果最终又由我把C的实现翻写了一遍才完。
所以我认为设计要根据开发人员的具体情况具体分析,做出以开发人员的能力足以实现的设计,才是好的设计。

设计应该到一个什么程度,首先可以参考制造业的做法。比方做设计一种新客机,不但要有完备的设计图纸,还需要做出模型出来做各种测试,甚至要做一个样机。这些测试都通过了,设计才算完成。而做软件项目,设计的产出同样是文档,却没有经过任何的实际构造和测试,总是大家一边讨论一边猜测(美其名曰“评审”)。这样的设计算是真正的设计吗?这样的设计到底有多少把握?正是因为没有把握,所以才会出现“应该设计到什么程度?”这样的问题。而实际上,验证设计的正确性的唯一途径就是编码。更加深入的讨论,请参考《源代码就是设计》。
10 楼 mvmouse 2007-07-13  
设计,不管是用什么形式(UML、DOC...),最终的目的是为了帮助开发人员更好更快的实现业务需求。应该设计到什么程度?是把流程描述清晰,还是进而把接口描述完备,甚至写出关键实现代码?
我遇到过这样的情况,我和A做的设计,交给开发人员C做实现,结果C对某些环节没想明白,也没和我们讨论,就实现出了一个和原来设计相差很多的东西。结果最终又由我把C的实现翻写了一遍才完。
所以我认为设计要根据开发人员的具体情况具体分析,做出以开发人员的能力足以实现的设计,才是好的设计。
9 楼 yiding_he 2007-07-11  
能否认识到项目与项目之间的巨大差异,是公司管理者能否接受敏捷的关键因素。如果他们只信奉“最佳实践”、“成熟过程”,那么楼主的观点在公司内受到驳斥也就不难理解了。
8 楼 抛出异常的爱 2007-06-11  
引用
struts+jsp -- 让我想起了万恶的旧社会

万恶的旧社会,也可能发展出台湾一样发达的地区,只要合适就好
先进的社会主义民族党也能发展出。。。。只要合适就可以

种下什么不重要,重要的是种这个过程不是在第一天就结束了。。。
7 楼 dongbin 2007-06-09  
luckliang 写道
抛出异常的爱 写道
如果对业务与类的理解差的话,用仙丹也不行。
你们的项目应该是已完成阶段了。。。。
如果想引用框架也可以
但是要保证两边的不沾连代码非常的难。。。。
如果沾连多了之后
就是一个城市的破窗子了。破败下去。。。

如果对业务分离的够清楚
每次都小心不沾连代码。
那么不用新架构一样可以完成清爽的程序。
非常感谢:抛出异常的爱出的解释!!

今天好好的把公司的低层框架整理了一遍!发现了很多的好东西。

实现方法是struts+jsp,低层实现了对数据库的连接和简单的操作!如果能和hibernate连接持久层,那就更好了!!

struts+jsp -- 让我想起了万恶的旧社会
6 楼 抛出异常的爱 2007-06-06  
如果对业务与类的理解差的话,用仙丹也不行。
你们的项目应该是已完成阶段了。。。。
如果想引用框架也可以
但是要保证两边的不沾连代码非常的难。。。。
如果沾连多了之后
就是一个城市的破窗子了。破败下去。。。

如果对业务分离的够清楚
每次都小心不沾连代码。
那么不用新架构一样可以完成清爽的程序。
5 楼 yiding_he 2007-05-07  
部门经理在不同的时候跟俺说过下面的话:
1、我们公司写程序的最多 3000 块一个月,还想加薪的话,就去做项目经理。
2、我们部门员工平均月薪 3000 块。

所以所谓“哭着喊着当 PM”,与其说是教科书教的,不如说是现实情况催的。
4 楼 OneEyeWolf 2007-05-06  
   几年前,我在一个项目组中,做一个工控项目,当时,商业内存库太昂贵,我们决定自己开发实时数据库,不求大,满足项目需求就行。
    但对我们来说,技术仍然是很复杂的,当时,我们是自己做了一个内核的模型(可以运行的Demo),并做了初步的测试,才然后决策的上马的。
    越是简单的,一看就明白,就不用写了。
    复杂的,就必须要验证,特别是需要重大决策的,风险巨大的。
3 楼 抛出异常的爱 2007-05-05  
有的同意有的不同意....
如:哭着喊着要去作PM这句话我这叫一个笑....

现代人总以为给了你帽子就能当这个官?
真作起PM而负责的说,每个我认识的作PM的都在内心里骂娘.
想回去作CODE的不在少数.
但一个公司不可能给一个CODE一个很高的价.
而且每个公司能负责担起这事的人少之又少.
绝不会让他回去作CODE.
每个PM都是在作决不可能完成的工作.一点也没有成就感.

第二句: 冰冷的词汇来吓唬程序员
真形象.用别人不懂的东西来吓唬他们...
事实上我们总是用冰冷的词汇吓唬客户,不自觉的又这样去吓唬程序员.

第三句: 几乎都有评审,需求评审,设计评审等等
评审的作用就如同辨论.
目的不是输赢,
而是在大脑中形成模型来测试其应变的可能
而天天想怎么过评审的人如同鬼辨论者.....
他们破坏模型的完整性.

但以下几点有问题
2.写代码,做demo。
3.做测试案例,TDD是一种方法,


十分不解:
2我也写DEMO但我一直认为这是小的系统或没什么技术含量的系统常用方式.
3做测试案例但与TDD的方向有背,TDD是指写程序的人由于理解需求而作的测试,你改变为作出测试来考查工作.我认为还是由程序员去写测试代码才叫TDD
2 楼 leondu 2007-05-05  
引用
我们很多的设计者,总是喜欢用大量的4+1 UML图和文档中生硬、冰冷的词汇来吓唬程序员,恰恰反映出了设计者内心的空虚与胆怯。

呵呵,非常赞同。越是没料,越是拉大旗扯虎皮吓唬人。

引用
   2.写代码,做demo。做Demo是我非常喜欢的一个方法,一个可以运行的Demo,远胜过文档了。开发人员一看,直接copy、paste就完了。做汽车、计算机等新产品,都会有样机,对样机做大量的试验后,才能上线,大批量的生产,在软件当中,怎么一做完设计,就大规模的进行开发了呢。


我觉得哪怕是使用html制作一个模拟运行的demo,也好过空洞无物,只能用来扯皮的用例文档好。一个是可以让用户形象的感觉到将来运行的系统是什么样子的,二是可以在做的过程中针对这个原型和用户不断探讨具体的需求。

1 楼 liping 2007-05-05  
<p><font>       其实每个阶段都是有代码产生的,只有涉及到用户的前期需求是不能要求其提供代码,其他的时候都是有代码的,只是他们的比列是比较小的。每一个迭代是一次具体化过程,我们老总是学校里教软件过程课程的,很喜欢印度Infosys的那套(具体不知道怎么样),在需求上花大部分时间,设计出一个东西让下面的一帮人去编码,说时间是3:1。效果是编码的时间比设计的时间多的更多。反复的修改设计,反复的推到重来。<br/>
我觉得软件最总的目的是可以运行的代码。当然是良好的代码。文档的功能是指导约束帮助理解代码的。好的文档不一定对应好的代码。我不太了解敏捷的开发方式,但是使用单元测试来替代一部分代码我觉得是很好的。毕竟用户是不要看代码的。而是代码产生的效果。</font></p>

相关推荐

    软件著作权代码整理工具

    3. **注释提取**:重视代码的注释部分,将其完整地保留下来,以展示代码的设计思路和实现逻辑。 4. **文档生成**:自动生成包含代码概述、详细结构、功能描述等内容的文档,满足著作权申请所需的代码说明需求。 5....

    代码整洁之道读书分享.zip

    总结来说,《代码整洁之道》倡导的是一种专业主义的态度,它要求我们重视代码的质量,通过持续改进和重构保持代码的整洁,利用单元测试确保代码的可靠性,并遵循一致的编码规范以提高团队的协作效率。这份压缩包中的...

    SEAY代码审计系统下载

    SEAY代码审计系统是一款专为IT专业人士设计的软件工具,主要功能是对源代码进行深度分析和安全审计。在软件开发过程中,代码审计是确保产品质量和...对于任何重视代码质量的开发团队来说,这样的工具都是不可或缺的。

    VisualCodeGrepper(VCG)-代码审计.zip

    《VisualCodeGrepper(VCG):深度解析代码审计的重要性与应用》 在信息化时代,软件安全已成为企业乃至整个...在当前的数字化环境中,我们应重视代码审计,利用VCG这样的工具,构建起坚实的防线,防范潜在的安全威胁。

    Dreamweaver CS5 CS6 代码格式化、美化插件

    《Dreamweaver CS5 CS6 代码格式化与美化插件详解》 Dreamweaver,作为Adobe公司推出的知名网页设计和开发工具,一直备受程序员和...对于那些重视代码质量和开发效率的个人和团队而言,这个插件无疑是不可或缺的利器。

    阿里代码审计插件

    因此,对于任何重视代码质量的Java开发团队而言,这款插件都是一个宝贵的工具。 文件"Alibaba_20Java_20Coding_20Guidelines-1.0.0"可能是阿里Java编码规范的文档,它详细阐述了各种编码规则和最佳实践,是理解插件...

    可重用代码管理器

    为了提高编程效率并降低错误率,程序员们开始越来越重视代码的复用性。"可重用代码管理器"就是这样一个工具,它专门针对这一需求而设计,旨在帮助开发者有效地管理和利用已有的代码片段,从而减少重复劳动,增加代码...

    JS代码混淆软件(小巧实用)

    JavaScript(简称JS)是一种广泛用于网页和网络应用的编程语言,尤其在前端开发中起着核心作用。然而,随着互联网安全问题的日益严重,保护...对于任何重视代码安全的开发者而言,理解和掌握JS代码混淆都是必要的技能。

    驯服烂代码-2013.03.22.pdf

    1. **重视代码整洁**:遵循一定的编码规范,确保代码的可读性和可维护性。 - **命名规范**:变量、函数等命名需准确反映其功能意义。 - **注释文档**:适当添加注释和文档,帮助其他开发者快速理解代码意图。 2. *...

    pb代码美化

    PB代码美化,全称PowerBuilder代码美化,是针对使用PowerBuilder这一编程工具编写的源代码进行格式调整、注释优化以及整体风格改进的过程。...因此,无论是个人还是团队开发,都应该重视代码美化这一环节。

    代码分析工具 understand 5 Linux 64

    《深入探索:了解 Understand 5 for Linux 64 代码分析工具》 在软件开发过程中,代码质量和可维护性是至关重要的因素。...对于任何重视代码质量的开发团队而言,Understand 都是一个值得信赖的伙伴。

    应届毕业生代码规范

    总之,应届毕业生在编写代码时,除了学习具体的编程语言和技术外,还需要重视代码规范,这样写出的代码不仅能提高工作效率,还能减少错误,易于团队合作。通过实践和不断的学习,可以逐步培养良好的编程习惯。

    代码混淆Eclipse插件Jocky

    代码混淆是一种安全技术,主要应用于Java、Android等编程语言,用于保护软件源代码不被轻易逆向工程解析。...对于任何重视代码安全性的Java或Android开发者来说,Jocky都是一个值得考虑的实用工具。

    ASP源码—360通用ASP防护代码(防sql注入).zip

    ASP(Active Server Pages)是一种微软开发的服务器端脚本环境,用于创建动态交互式网页。在ASP源码中,防止SQL注入是至关...在部署和维护ASP应用程序时,务必重视代码的安全性,确保用户数据的安全和系统的稳定运行。

    代码大全高清版电子书

    - **软件质量和编程思想**:《代码大全》强调了软件质量的重要性,不仅仅关注功能实现,更重视代码的可读性、可维护性和扩展性。通过讨论各种编程思想,如面向对象设计、函数式编程等,帮助读者构建更加健壮和灵活的...

    重构-改善既有代码设计

    重视代码的整洁性,遵循DRY(Don't Repeat Yourself)原则,避免重复代码;以及适时地进行设计模式的应用,使得代码更加模块化和可重用。 《重构:改善既有代码设计》这本书详细介绍了这些重构的技巧和原则,并提供...

    Xcode 插件:用来简化代码格式.zip

    在iOS和macOS开发中,Xcode是Apple官方推荐的集成开发环境(IDE),它包含了编写、测试和调试代码所需的各种工具。然而,为了提升开发效率和...对于那些重视代码风格和一致性的开发者来说,这是一款值得尝试的工具。

    Unity3D+ObfuscatorPro v3.9.4中文版+代码混淆

    Unity3D是一款强大的跨平台游戏开发引擎,广泛应用于2D和3D游戏...对于那些重视代码安全性的开发者来说,这是一个必不可少的工具。通过合理使用ObfuscatorPro,不仅可以增强应用的安全性,还能降低被抄袭或滥用的风险。

    代码混淆,及反编译

    这些工具虽然可以帮助开发者分析其他应用的实现,但同时也可能被恶意使用,因此开发者必须重视代码混淆以对抗反编译。 在进行代码混淆时,需要谨慎处理库和依赖,因为过度混淆可能导致运行时错误。通常,我们会在...

    一款IOS开发中用于代码整合的小工具

    在iOS开发过程中,代码管理是项目协作中至关重要的一环,它确保了团队成员之间的代码同步和版本控制。本文将深入探讨一款适用于iOS开发...对于那些重视代码审查和手动控制的团队来说,这样的工具可能是理想的解决方案。

Global site tag (gtag.js) - Google Analytics