计算机专业毕业的学生在学校当中，都读过软件工程这本书，而软件工程的书，都无一例外的，强行规定了一个编码阶段，并且十分严肃的告诉学生，代码在整个软件过程的生命周期阶段当中，只占了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. 文档
分享到：
相关推荐
3. **注释提取**：重视代码的注释部分，将其完整地保留下来，以展示代码的设计思路和实现逻辑。 4. **文档生成**：自动生成包含代码概述、详细结构、功能描述等内容的文档，满足著作权申请所需的代码说明需求。 5....
总结来说，《代码整洁之道》倡导的是一种专业主义的态度，它要求我们重视代码的质量，通过持续改进和重构保持代码的整洁，利用单元测试确保代码的可靠性，并遵循一致的编码规范以提高团队的协作效率。这份压缩包中的...
SEAY代码审计系统是一款专为IT专业人士设计的软件工具，主要功能是对源代码进行深度分析和安全审计。在软件开发过程中，代码审计是确保产品质量和...对于任何重视代码质量的开发团队来说，这样的工具都是不可或缺的。
《VisualCodeGrepper(VCG)：深度解析代码审计的重要性与应用》 在信息化时代，软件安全已成为企业乃至整个...在当前的数字化环境中，我们应重视代码审计，利用VCG这样的工具，构建起坚实的防线，防范潜在的安全威胁。
《Dreamweaver CS5 CS6 代码格式化与美化插件详解》 Dreamweaver，作为Adobe公司推出的知名网页设计和开发工具，一直备受程序员和...对于那些重视代码质量和开发效率的个人和团队而言，这个插件无疑是不可或缺的利器。
因此，对于任何重视代码质量的Java开发团队而言，这款插件都是一个宝贵的工具。 文件"Alibaba_20Java_20Coding_20Guidelines-1.0.0"可能是阿里Java编码规范的文档，它详细阐述了各种编码规则和最佳实践，是理解插件...
为了提高编程效率并降低错误率，程序员们开始越来越重视代码的复用性。"可重用代码管理器"就是这样一个工具，它专门针对这一需求而设计，旨在帮助开发者有效地管理和利用已有的代码片段，从而减少重复劳动，增加代码...
JavaScript（简称JS）是一种广泛用于网页和网络应用的编程语言，尤其在前端开发中起着核心作用。然而，随着互联网安全问题的日益严重，保护...对于任何重视代码安全的开发者而言，理解和掌握JS代码混淆都是必要的技能。
1. **重视代码整洁**：遵循一定的编码规范，确保代码的可读性和可维护性。 - **命名规范**：变量、函数等命名需准确反映其功能意义。 - **注释文档**：适当添加注释和文档，帮助其他开发者快速理解代码意图。 2. *...
PB代码美化，全称PowerBuilder代码美化，是针对使用PowerBuilder这一编程工具编写的源代码进行格式调整、注释优化以及整体风格改进的过程。...因此，无论是个人还是团队开发，都应该重视代码美化这一环节。
《深入探索：了解 Understand 5 for Linux 64 代码分析工具》 在软件开发过程中，代码质量和可维护性是至关重要的因素。...对于任何重视代码质量的开发团队而言，Understand 都是一个值得信赖的伙伴。
总之，应届毕业生在编写代码时，除了学习具体的编程语言和技术外，还需要重视代码规范，这样写出的代码不仅能提高工作效率，还能减少错误，易于团队合作。通过实践和不断的学习，可以逐步培养良好的编程习惯。
代码混淆是一种安全技术，主要应用于Java、Android等编程语言，用于保护软件源代码不被轻易逆向工程解析。...对于任何重视代码安全性的Java或Android开发者来说，Jocky都是一个值得考虑的实用工具。
重视代码的整洁性，遵循DRY（Don't Repeat Yourself）原则，避免重复代码；以及适时地进行设计模式的应用，使得代码更加模块化和可重用。 《重构：改善既有代码设计》这本书详细介绍了这些重构的技巧和原则，并提供...
**正文** 标题提到的"IDEA代码检视插件Code Review Helper"是针对IntelliJ IDEA集成开发环境的一款强大工具，旨在提升代码审查的效率和...对于任何重视代码质量和团队协作的开发团队来说，这都是一个值得拥有的工具。
在iOS和macOS开发中，Xcode是Apple官方推荐的集成开发环境（IDE），它包含了编写、测试和调试代码所需的各种工具。然而，为了提升开发效率和...对于那些重视代码风格和一致性的开发者来说，这是一款值得尝试的工具。
这些工具虽然可以帮助开发者分析其他应用的实现，但同时也可能被恶意使用，因此开发者必须重视代码混淆以对抗反编译。 在进行代码混淆时，需要谨慎处理库和依赖，因为过度混淆可能导致运行时错误。通常，我们会在...
ASP（Active Server Pages）是一种微软开发的服务器端脚本环境，用于创建动态交互式网页。在ASP源码中，防止SQL注入是至关...在部署和维护ASP应用程序时，务必重视代码的安全性，确保用户数据的安全和系统的稳定运行。
Unity3D是一款强大的跨平台游戏开发引擎，广泛应用于2D和3D游戏...对于那些重视代码安全性的开发者来说，这是一个必不可少的工具。通过合理使用ObfuscatorPro，不仅可以增强应用的安全性，还能降低被抄袭或滥用的风险。