风式幽助 风式幽助
多多益善，
关注数: 166 粉丝数: 288 发帖数: 30,552 关注贴吧数: 21
《软件开发的201个原则》第5章 第五章讲述了编程相关的一些规范： ================================ 阅读内容如下： 底线：避免编写使用特殊技巧的代码，以向世界展示你有多聪明！意思是需要提高代码可读性。减少代码理解成本。 避免使用全局变量。如果访问全局变量发现取值不正常。很难排查出问题的模块。可以封装到具体的模块中。需要暴露的时候再提供接口。 提高代码可读性。使用结构化的思想去编程。 注意代码上的命名。良好的命名规范可以减轻一定的注释成本。 使用最优的数据结构。我理解下来是觉得在写代码之前需要先思考下代码的结构。如何更好的将自己想要表达的东西给展示出来。 代码要写注释。良好的注释能够减少阅读成本。对问题排查也能起来很好的效果。 先写文档后写代码。需要先思考代码的接口设计、代码结构封装等等。 写完代码之后要自己去自测对应的功能。 减少代码嵌套层级。一般来说，嵌套超过三层会严重降低可理解性。 编程语言不是借口。这个理解不了。虽然有些不同的语言在编程思想上是一样的。但是毕竟是一门新的语言。一定是需要学习成本的。 “如果你是一个好的程序员，对任何一种编程语言你都应该是个好程序员”。不太适用。对自己来说太过于理想化了。 ”编程语言的知识没那么重要“。不太理解。一个好的框架。再细化到最底层的，那就是使用的对应的语法、语义等。你语言知识都不重要。那基础都没法保证。 提高代码的格式化规范。 ============================== 思考： 目前我们有自己的OC代码规范。所以目前自己在写代码与提交代码的时候都是会去先检查下自己的代码规范。包括格式化、注释、结构功能等。提交完之后自己现在icode上检查一遍。当然有一种情况需要注意的是，我们都会有复制代码的时候。这个时候，一定要再检查下复制过来的代码。做好CR。
《软件开发的201个原则》第四章 第四章讲的是设计原则，主要是针对方案设计层面给到的一些原则： 从需求到设计，中间也需要有设计(UI)评审。 设计，也需要先产出文档。 不要重复造轮子。软件工程师经常一次又一次地重新发明组件。他们很少修补已有的软件组件。 个人理解就是不要一上来就是觉得自己的需求设计、自己的代码写的更好。就不用去看之前的。 当以前的组件已经无法满足当下的需求时，再考虑去做扩展和重构。 保持概念一致： 对应的场景就是当方案设计完成时，需要去按照方案去做具体的补充。这期间，可能会偏移当初的方案设计。在这过程中，如果是提升系统的一致性、优雅性、简单性或性能。是可以接受的。如果仅仅为了确保某个设计者在设计中留下自己的印记，这个是不可取的。 代码层面，我们要追求低耦合和高内聚。 在设计过程中，需要考虑到变化与维护成本。 完整的设计是需要包括层次依赖、调用关系等。这就要求我们在方案设计阶段尽可能的考虑到里面的逻辑关系、功能点等。 还有比较重要的一点是可复用。在设计阶段就需要能做好充分的考虑。
《软件开发的201个原则》第三章 第三章讲的是需求工程原则，大致内容如下： 造成低质量成本估算的原因都是在需求前的一些准备工作。频繁的需求变更、不充分的需求分析等。这个我们需要在需求前期做好准备工作。包括需求分析与理解。 先确定问题，再写需求： 需要从不同的用户角度去考虑问题。这样也能 确定好我们需要做的事，这个应该是从产品层面，需要明确要做的功能点。 尽量在需求前期，能够解决需求中的一些问题、比如需求不明确、逻辑错误等。 需要尽可能的提供原型图。 要做好需求前的准备与调研工作。包括需求背景、预期收益、需求评审、以及技术方案等环节。这个很重要。 要学会确定需求优先级。通过打分、加上后缀 M、D 或者 O 来表示必须（Mandatory）、期望（Desirable）、可选（Optional）等方式。 要学会对需求编号。对需求分门别类打上对应的标识符号。便于查找。 学会提高需求的可读性、需要考虑到对各种边界case的处理。 ============ 以上，大部分都是讲的如何做好需求前的一些准备工作。一个合理的需求开发流程个人看来应该是这样的，应该是有需求评审前的理解、理解过程中列出自己的一些问题、需求(预)评审、需求过程中的问题解答以及需求评审后的问题确认。再到rd这边的技术方案设计。 对需求而言，自己在产出需求的时候需要做好更加充分的准备、包括严谨的需求背景、逻辑、功能点、涉及范围、预估收益等等。这样才能更好的对应着需求的结果产出。
《软件开发的201个原则》第2章 第二章从内容上叙述了以下"一般原则"内容： 原则一：质量第一 原则二：质量在每个人眼中不同 "质量"的定义不同，可能是优雅的设计或者代码。也有可能是响应的时间，更有甚者是低开发成本。我觉得这个放在现在是适用的。所以这个原则好像说了什么东西，又好像什么都没说。但是从开发角度上说。我觉得质量其实就是大家写的代码过程质量与线上质量。这就是红线。 原则三：开发效率与质量密不可分 强调开发效率会导致质量的降低。 原则四： 高质量软件是可以实现的 对应白话："都可以做，就是需要时间"。 原则五：不要试图改进质量 不太理解。现在咱们都在重构。如果从可维护性、可靠性、适应性、可测试性、安全性等等方面想提高。那为啥不能算是提高过程质量与线上质量了。 原则六：低可靠性比低效率更糟糕 哪怕你效率高点，但是你的代码可靠度得高点，不然后面一些问题的修复成本都会耗费较多的成本。 原则七：尽早把产品交给客户 "将这个原型交付给客户，收集反馈，然后编写需求规格说明、并进行正规的开发。"。理解上就是给客户先把大饼画好。 原则八：与客户/用户沟通 好建议。把我们自己当作客户。能足够的熟悉这个产品的功能，就能打磨出更好的产品。 原则九：激励开发者与客户对齐 意思就是跟客户谈好交付事项与细节。尽可能的双方都能够妥协一点。 原则十：做好抛弃的准备 就是要做好随时推倒重来的准备。但是我们可以把主要框架设计的更前沿一些。 原则十一：开发正确的原型 说的就是前面给客户的是原型，后面给的才是真正的实现。步骤不能乱。 原则十二：构建合适功能的原型 构建合适的原型，如果前面交付给客户的原型更偏向于"原型图"的话，这里指的是应该是项目框架设计的原型。 原则十三：要快速的开发一次性原型 赞同！在原型设计阶段没法做到太具体的细节实现。所谓的知行合一。我更倾向于先快速的有一次性原型。后面实现过程中再优化补充。 渐进地扩展系统； 看到越多，需要越多； 开发过程中的变化是不可避免的； 只要可能，购买而非开发； 让软件只需简短的用户手册： 每个复杂问题都有一个解决方案； 记录你的假设：学会去试错。 不同的阶段，使用不同的语言； 技术优先于工具； 使用工具，但要务实； 把工具交给优秀的工程师； CASE工具是昂贵的； “知道何时”和“知道如何”同样重要； 实现目标就停止； 了解形式化方法； 和组织荣辱与共； 跟风要小心； 不要忽视技术； 使用文档标准； 文档要有术语表； 软件文档都要有索引； 对相同的概念，用相同的名字； 研究再转化，不可行； 要承担责任； ========================= 自己对于重构的一些思考～ .....
《软件开发的201个原则》第一章有感 接触到该本书籍，我已经对这些原则对于软件开发的重要性已经有了一定的认知。无论是从我们自身的开发经验，还是对于书中后续提到的一些原则内容。我相信这些不仅可以提供了解决问题的思路和方法，还能强调软件开发过程中的团队协作和持续学习的重要性。每个原则应该都是基于实践经验的总结，值得我们细细阅读，慢慢体味。
1 下一页