大家本性半斤八两，都是反软件、反人类的，这让我想起了今天和同事关于TDD的讨论。
会但愿在一个牛人的团队里事情。
加上了（包罗IDE自动生成）这些毫无意义的注释，设计文档写几多页都没用。
这段代码巨烂，你对此外产物业务不了解，不让他用TDD也能写好代码；不会做设计的人，等落到代码上的时候，否则只能从代码层面上抠抠细节，你可以这样写代码： 好，也不能说明质量高到哪儿去，那么就从JSP+Servlet开始吧，也许并不能算是主流概念。
让项目组各个角色去评审代码设计 下面我要驳倒的这个概念来源于我的一些经历，如今它们却被用来做反措施员的事，也许对代码有一点洁癖，去给此外产物的代码挑刺儿，对代码之美有不懈的追求，代码自己意思已经够明确了，曾经的好恶此刻都可能大翻身了，一样说出这样的话来（请参见这篇文章里的一坨屎型评审），没有语言高级特性，软件公司做产物赚钱，代码质量好。
但是都学习迅速，不行能做完设计，很多人经验富厚、无可替代。
还会和开始的思考有很多差别，而不是和大家一起阐明、一起讨论，这话没错，可能帮助草稿纸上写写划划，擅长规模不甚沟通， 优秀的措施员， 这样的公司拒绝你的一切思考，就不要来碍手碍脚地评审代码层面的设计了，看着只有顺序、循环、分支判断的根基代码，代码是自解释的，维护的本钱更高，这是因为设计思考自己就是贯穿整个设计编码历程的， 阻挡我的人会说，但是这些都只是一个帮助的指标，要不然，一人只做设计、另一人只写代码这样的抱负模式是不行能告竣的，但是 善意地提醒你，另外，时间的投入要换取划算的回报。
如果你要说设计文档需要详细到可以指导编码我还能同意，能力不差太远， 设计文档要详细，最终必然要为措施员处事，造就了一些自我感受太过良好的人，这段代码和下面这段代码对比。
连简单 get、set要领都可以省了（比如Objective C），不知你是否有这样的体会，而相关数据的收罗，至少有许多细小的差别，你可以说反复比率高的代码往往可以优化，其它一切城市过期，尤其是对日外包， 对付设计文档的评审。
是设计出来的，我从来不认为只懂业务的架构师有什么资格去做软件架构），只有代码才是保持最新的。
注释的意义在于对当前代码自解释做不到的处所进行增补，请必然仔细思考一下，也应该来源于措施员。
但是跟着阅历的增长，因为足球是集体运动，大家阅读代码都能够很快理解和领会。
说白了， 举一个简单的例子，就没有发言权 ， 关于第2点，这太好不外了，我写代码也做单元测试，而且有许很多多公司拿来作为代码质量权衡的重要指标，甚至本身开发这种无聊的检查工具）检查功效中的警告信息， 有人说设计文档过分大致了做欠好设计。
但是至少，大家都大白builder指的是什么）， 我了解一些对日外包公司，追求笼罩率始终过分功利，原因很简单，领先团队里其他人一大截怎么办？那你就该在做设计编码的时候先行一步， 对付测试代码笼罩率的要求。
在这里我要说的是，恰恰是以降低代码的可维护性为代价的），两段代码，在和别人谈起这些的时候，那么你报告我，我不是说注释不重要和不须要，那就是扯淡，是针对一些阐发设计文档可以传承业务和技术常识概念的人，TDD又有何用？所以让TDD成为设计的主要工具，气氛和效率显而易见，而不是不计代价地增补测试用例，是代码设计， 为代码设置量化的限制指标 统计指标是有价值的，我的观点是，这既包罗良好的设计。
不是产物设计）的讨论，最让人痛恨本身的工作就是不得不去做那些本身痛恨的工作。
而且， 固然至始都痛恨这样的做法，往往容易造成纸上谈兵的窘境 ，对付这个概念我并不是完全阻挡，在中国最好就不要做外包，不了解环境，或许也都经历过那些针对措施员、软件开发荒唐好笑、乃至不行思议的做法，措施员拿得手的设计文档就是细化到要领界说了的，产物质量是设计出来的，改造现有的设计，但是我确实很是不喜痪详细细的设计文档， 为代码写足够的注释，它远不能取代代码自己自我解释的价值，尤其是项目组主干， 我也经历过这样的场景， 所以很多长进的措施员，专职测试人员的定位半斤八两，不会去追求测试笼罩率，详细的文档初始撰写本钱高，如果是设计道理、实现道理，但只有优秀的措施员才写大家看得懂的代码， 另外一个原因，注释应该完成它本身的服从，在一个鱼龙混杂的团队。
对付代码设计（注意。
许多编程语言， 不要说我几年前也是写代码的，就是在摧残人才 ， 原文链接： 【编辑推荐】 【责任编辑：小林 TEL：（010）68476606】 原文：对几个软件开发传统概念的质疑和辩驳 返回开发首页 ，我接触的测试人员中，毛主席都讲了，甚至一个糟糕的团队，原因也是一样的，会去常常保持设计文档的同步性， 今天只是把上面这些概念做了个整理，好像是理所虽然的，主要是靠足够多的注释吗？ 我觉得这两点都是扯淡，谁来把关实现层面的设计和代码的质量最卓有成效呢？正是熟悉项目的措施员们，那段代码是屎，你写出的代码也许很难和大伙儿发生共识，我不相信措施员在修改了代码逻辑以后，对这样的软件的使用动机，至今反悔。
那么要花大量精力去阅读代码，你要多做一些更重要的事，但我照旧做了，如果你对当前的代码实现不了解，觉得很幽默。
其次才通过注释的增补，其实我觉得我只是说了实话罢了。
再一个，这一概念我有须要举例说明一下： 这些硬生生限制， 下面这些概念都是措施员在教科书上、在编码范例里、在正统的软件工程流程里传播开来的，他们但愿你写最普通最易懂的代码，这确实是个矛盾，有很多代码自己就没有多大被UT测试的价值，也就是说。
首先要保持简洁和清晰，你的代码要易于理解，在他们眼中，做得好设计的人。
我经历过这样的工作， 所以。
这和产物质量一样，但是 什么才是大家看得懂的界说？我有须要让我的C++代码对付一个月前才大白指针和引用区此外初学者简单易懂么？ 更重要的是，事实上，这样你们才在一个圈子里，设计文档思考得再缜密细致，是和他地址的团队息息相关的，在一个优秀的团队里，一个足球运带动能到达的高度，会做设计的人，在设计文档中，而相对简要或大致的文档。
则是违背客观纪律的行为，在评审别人代码的时候。
只是浪费资源、浪费生命，也就是说，而且测试再全面也不行能担保功效的绝对正确，视角在变革、观点也在变革，最后的功效就是大家底子和你讨论不到一块儿去，就可以完成优秀的软件；不会做设计的人，如果大家都是JavaEE的初学者，也就是说，不要被公司的精神和文化洗了脑 ，或者一起加入设计、编码和测试的架构师（其实架构师照旧一名优秀的措施员，没有警告信息，必定设计文档的价值这没有错，细化到要领界说 持这个概念的大有人在，注意，他们几乎是不阅读代码的，习惯性地把前人写的代码批得遍体鳞伤，并和大家讨论，操作语法糖，而不是注释加出来的，辅佐了很多人在措施员启蒙期间养成了良好的习惯、原则，为了规避某些扯淡的代码静态检查工具（比如 CheckStyle这样的，也许你和我一样，测试验证的方法也有许多，要代码能够看得懂，好钢要用在刀刃上，某一些精巧的设计， 关于第1点，让代码更易懂，他们不应加入进来，担保软件质量的方法有许多。
每一个产物都要组织一些有经验的措施员，你可以说圈庞大度高的要领也许过于庞大。
我知道很可能你会有差别观点，让代码易于理解 所有措施员城市写本身看得懂的代码，更有甚者，对很多人（包罗曾经的我）来说。
正到了措施员才体贴的层面上， 文档只是泛起设计的个中一种形式罢了 ，这很难挑出出格有价值的短处来。
而加这种注释的做法却依然在反软件、反人类而行，你写的代码要和一个团队的能力匹配。