团队管理（7）
项目管理（7）
一、项目代码问题现状
二、代码问题原因分析
三、何为代码质量
四、质量提升之策
五、部门实施之路
六、代码保障的辅助工具
一、代码问题：
1、没有代码注释；
2、没有代码相关的设计或者结构文档；
3、函数代码行太多；
4、类、函数功能不单一；
5、内存泄露风险较大；
6、逻辑混乱，很难看懂；
7、硬编码较多；
8、接口定义不清晰，输入输出界定不清楚；
9、垃圾代码较多；
二、原因分析
1、项目成员技能不足；
2、项目时间比较赶；
3、项目代码走读、代码评审控制效果不好；
4、代码规范未统一；
5、设计原则认识不统一、不深刻；
6、对质量重要性认识不足；
7、新人、项目中途加入等；
8、依赖于测试人员发现bug；
三、何为代码质量
&三性：可读性：
&&&& 1、注释；
&&&& 2、拒绝大段大段代码；
可维护性：
&&&& 1、不能硬编码；
&&&& 2、避免平台相关调用
可变更性：
&&&& 1、代码复用，公共函数；
&&&& 2、设计模式
代码质量评价的关键指标：低耦合，高内聚
四、提升思路及策略
1、代码质量指标化，纳入绩效考核；
2、讨论确认代码规划标准；
3、构建代码质量控制组织，师徒结对，师傅对代码质量进行控制；
4、开展代码评审会议；
5、研讨设计原则；
6、应用成熟的代码检测工具；
五、实施监控
1、保障项目设计阶段进行代码规范学习活动；
2、开发人员自查互查，检测工具检测；
3、产品代码提交的同时提交对应的模块接口测试代码；
4、提交结对编程过程的代码走读记录，作为项目过程的重要活动；
5、代码评审会议，评定每个成员的代码质量，作为项目考核基础数据；
6、项目每轮测试，测试提供开发人员对于的代码缺陷率；
六、辅助工具
VS分析工具
Xcode自带分析工具
Instruments
boundschecker
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：13144次
排名：千里之外
原创：16篇写代码是一种创造性的劳动，是现在社会中少数的纯手工的工作之一。程序员就像手工艺人，代码就像手工艺品。手工艺品有自己独特的魅力，但是也缺乏流水线产品的严谨和一致性。所以代码审查(Code Review)就像是把玩鉴赏手工艺品一样，通过审查代码来体会编码者的思维逻辑，同时相互学习取长补短。代码审查是提高个人和团队的代码质量的一个很有用的方法。提高代码质量之代码审查个人对自己的代码可以进行代码审查，因为今天的你已经不是昨天的你，你可以站在不同的角度和不同的层次来审查自己过去的代码。子曰：温故而知新。所以对于自己的代码应该定期做Code Review。可以用好日程安排工具，比如Google Calendar之类。在自己做到觉得需要日后来审查一下的地方，就可以在日程安排上记录一笔。到时候就可以按照记录去审查了。作为一个想不断进取和自我提高的程序员来说，这是很高效的方法。自己的代码审查很好进行，只要你有毅力。相比之下团队的代码审查就不是那么容易实施了。但是代码审查在团队中能体现出更大的促进作用。除了可以让团队成员之间相互学习进步、激发思考、统一编程风格之外，代码审查还能发现一些系统的潜在问题和QA测试不到的问题，从而提高代码质量。但是在团队内进行代码审核的时候，也要注意方式方法，才能发挥其积极作用。否则还有可能产生负面的影响。1. 引导团队成员对代码审核的正确认识引导团队成员对代码审核的正确认识代码审核并非是给某人挑错，也不是瞻仰膜拜牛人的奇技淫巧，而是大家泡一杯咖啡端一杯茶，一起来鉴赏品玩代码而已。目的是为了促进团队成员的成长和提高。如果在代码审查的时候发现bug，不要过于责问，而是应该从技术层面加以分析、建议和讨论。如果你是Manager, 一定要注意不要炫耀自己，低调一点，重点在做好组织工作。初期一定要引导好团队成员对代码审核的认识，不要变成个人代码秀或者挑错大会和批斗大会了。2. 要让团队成员看到代码审查的好处在组织Code Review的初期，一定要用心去挖掘一些可以让大家学到东西的代码段。让大家体会到，可以从别人严谨的逻辑和优雅的编码学习经验技术，也可以从自己和别人的脏代码以及疏忽大意来吸取教训。尝到了甜头，这么有好处有意思的事情，大家肯定乐意再来一次了。3. 平等轻松的纯技术讨论代码审查之头脑风暴在做代码审查的时候，只能有组织者，不能有CTO、Manager、权威、叫兽砖家。这是一个平等的轻松的技术讨论会，可以佐以饮品和零食哈哈～要激励大家勇敢地说出自己的看法，置疑其他人的看法。这样才能激发出大家的参与热情和不断地思考。这种讨论其实就是一种头脑风暴。4. 针对项目的热点和难点进行代码审查针对一次代码审查进行选题的时候，可以多从项目的热点和难点入手，比如框架是怎么工作的？数据库是怎么封装的？缓存是怎么处理的？内存占用高的地方是怎么优化的？一些复杂的算法是怎么实现的？某个bug为什么会反复出现？————走进科学将带你走进代码审查的世界～～哈哈回到正题，代码审查的选题一定要对事不对人。记住！要避免针对某个程序员的代码审核。。。除非你想炒了他。5. 少而精代码审查是一项很激烈的脑力运动，而且在多人参与的时候尤其如此。和头脑风暴的本质差不多。不但自己要理清别人的代码，还要去审视和判断，还要说出自己和看法，还要听懂别人说出的看法。所以每次代码审查的内容和时间要少而精，否则大家疲劳之后，讨论就会变得冗余而无趣。6. 发现问题由编码者自己去修正或者重写当我们在审查时发现了问题、讨论了修正和改进的方案，我们肯定需要一个人来讲这些方案实现出来。这个时候就应该由造成问题的程序员来做了。因为只有真实去改动代码的时候，才会将问题最真实的原因暴露出来。这个程序员才能去彻底修复这个bug。同时在他也会从自己的错误中得到提高，在之后的职业生涯中应该不会再犯同样的错误。7. 做好讨论记录和问题跟踪在大家的思想相互撞击的时候肯定会有很多灵光闪呀闪，如果不记录下来就太可惜了，丧失了讨论的意义。所以每次代码审查一定要有专人来负责做记录。讨论之后将记录整理并email给所有人。PM和Manager之类的就可以根据讨论记录来分配改进任务。每个团队都应该有自己的项目管理系统，或者说是bug追踪系统吧。如果没有，赶紧去搞一个。推荐开源的Redmine (Ruby on Rails)和Mantis (PHP/MySQL)，以及提供在线服务的Lighthouse。特别要说一下Redmine，支持中文，功能强大且简洁，跨平台使用很舒服，而且也支持多种数据库(MySQL, PostgreSQL or SQLite)，同时可以和git集成使用（在git push时自动更新ticket状态）。8. 使用适合自己团队的代码审查工具现在很多团队都转向了使用GIT，那么就可以利用Github来作为代码审查的工具。在Github里面可以针对某个branch的某个commit提交评论，然后Github会给项目的参与者发送一封邮件。通过这种在线的评论来进行代码审查，让大家可以利用零散时间去看一些小的代码段，就像在论坛发帖回帖一样，不用一定要坐在一起，不会打断正常的工作，同时也完整地保留了讨论的过程。总之XXXX是一把双刃剑，代码审查也是如此。进行代码审查对于组织者的能力要求比较高，要多思考和调整，激发大家一起来做好代码审查，发挥其最有益的效用。避免如此审核代码原文链接：
fancy的最新日记
······
&(4人喜欢)
&(5人喜欢)
······
你论文写完了吗？ · 106条内容
就是那么简单几句我办不到 · 2209条内容
博物馆讲述难以言说的历史 · 349条内容
纪念汪老逝世二十周年 · 154条内容
以赤子之心澄澈映照世界 · 115条内容
你是一本读不完的书 · 879条内容
推荐这篇日记的豆列
······近期看到一篇。大致的意思就是网管将原本混乱不堪的交换机整理整齐了，起初交换机是图2那样的，由于越来用的人越多，操作的人越来越多。终于成为了图1那个样子。这不禁让我想到了项目中的代码。原先在刚上线的时候谈不上是完美的，但它总归是整齐的。可是由于中间人员流动，bug改动等等原因吧，终于的结果就是代码一团糟。为什么会出现这种情况呢？& & & & &&图1 & & & & & & & & & & & & & & & & & & & & & &图2权限（权利）拿交换机来说，当自己的网络不通畅的时候自己能够随便进出机房对交换机进行操作，插拔自己的网线的时候仅仅要能让自己的网络通常，那么网线乱一些那又有什么关系呢？第一个人是这样想的同一时候也是这样做的，紧接着第二个、第三个……久而久之就成了图1的样子，混乱不堪。同理代码也是一个道理。自己须要实现一个功能，在原来代码的基础上进行改动，仅仅要自己的功能好使代码之间的耦合大一些又有什么关系呢？刚入职的第一个新人是这么想的也是这么做的紧接着第二个、第三个……久而久之仓库中的代码就变成了如今的这个样子。慘不忍睹。没有权限的人能够操作本不该操作的东西，终于一定会一团糟。由于的人们在自己焦头烂额的时候才顾不上会不会影响他人，尽快将自己手头的棘手的问题解决掉才是重中之重。对于权限管理最经典的一句话就是：权限越低犯错的机会就越少。所以新人直接提交代码到代码库是欠妥的。责任出现这种情况是由于大家仅仅关心自己的一亩三分地。“各扫自家门前雪。休管他人瓦上霜”是每一个人的不变信念，问题是“他人”并非别人，是自己人。他人“瓦上霜”事实上就是以后自己的“门前雪”。事实上责任这个词就是自私的放大版。胸怀有多宽广责任就有多重大。记得读过一篇关于代码质量的文章，当中说到一个理论叫破窗理论：一个房子假设窗户破了，没有人去修补，隔不久。其他的窗户也会莫名其妙地被人打破。一面墙。假设出现一些涂鸦没有被清洗掉。非常快的，墙上就布满了乱七八糟、不堪入目的东西；一个非常干净的地方，人们不好意思丢垃圾。可是一旦地上有垃圾出现之后。人就会毫不犹豫地抛，丝毫不觉惭愧。非常多情况下代码晦涩难懂并非一下子就变成这个样子的。冰冻三尺非一日之寒。从第一个不负责任的人開始代码变得越来越难以维护。假设在提交代码之前有人（几个人）去review要提交的代码，相信出现故障的可能性就大大减小。试想自己的代码是要被全世界程序猿读的，相信你会提高自己的代码质量。行动发生了这种事情，终于是要解决的，假设希望永远不发生这种事情。这是一种理想状态，仅仅有说前面的工作我们尽可能的做好来减少这种事情出现的概率。可是。一旦发现了问题还是须要解决的。并且是立马解决。否则错误会随着时间的推移解决成本也就越来越大。不要借口说如今没时间，等有时间了怎样怎样吧。如今没时间以后更没时间，由于以后仅仅会比方今更忙。(什么？项目紧没时间，那么请跳槽，对于一个没有规划急功近利的公司是须要被社会淘汰的，所以你的不离职就是在姑息整个软件行业的不良风气)Review初期是能够避免非常多低级错误的，可是到了后期就流于形式了，由于一直负责review的负责人已经疲惫了。况且非常多严重的bug并非review就能发现的，Review仅仅能找出显而易见的错误。所以，第一、负责review代码的人决不能固定，并且一份代码能够多人review第二、不放过不论什么一个Bug，尤其是由于改动或者新用例带来的bug。这些bug后面就藏着不整洁的代码，须要整个团队耐心的将其挖掘出来解决掉。&都说高质量的代码须要高水平的开发人成员，事实上高质量的代码，需要的是关怀开发商
版权声明：本文博客原创文章，博客，未经同意，不得转载。
阅读(...) 评论()}