标签： 代码
CCleaner恶意代码分析预警
，Piriform出品的CCleaner无疑是最干练、最高效的清理工具，全球安装量已超1.3亿，而且已经被大名鼎鼎的安全公司Avast收购。但是，CCleaner最近却捅了个篓子，公司服务器在8月份的时候被黑客入侵，导致安装文件被感染，大量用户莫名其妙中招。
京东资深架构师代码评审才诗
架构师说, 用20个字描述代码评审的内容， 自省也省人。由于是一字一含义， 不连贯， 为了增强趣味性， 每句都增加对应的歪解。只是对常见评审的描述， 不尽之处，欢迎补充！
如何做有效的代码审查？我有这些建议
往往代码评审过程中，评审者（Reviewer）往往会过于关心旁枝末节，而忽视主要问题，也就是所谓的自行车棚效应。在批准价值百亿的核电站的建设提案中，专家们往往会浪费大量时间纠结于厂内自行车棚（bikeshed）的颜色；因为核电站太大、太复杂，“专家们”未必真懂，但总不能不说话啊，那就从无关痛痒的自行车棚挑毛病吧。
程序员总工会：以后写代码要按行数收费
有人的地方就有江湖，有利益的地方就有冲突。
整洁代码的编码原则
“整洁代码”是我在写代码中一直以来遵循的一条理论。事实上，对于我来说，与其说是一种理论，不如说是一种信仰。他是这么一种理念——你的代码必须够整洁且尽可能接近于完美。如果你所写出来的代码比你所需要的多，那么多出来的那部分代码不应该存在其中。任何的多余都是不可能容忍的，而且一直以来我甚至觉得一个空格都不允许多余。你要让你的代码不仅仅是解决了问题，而是尽可能的有效率、可读性好、易维护。同样，我经常花很多额外的时间去设计我的代码。
代码审查与重构的5个层次
统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护，有利于代码的“集体所有制”。试想，如果团队中每个人都使用自己的一套代码规范，那整体的代码风格就可谓“百花争放”，最后的结果就是代码越来越混乱，且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面：
导致烂代码的35个恶习，看看你染上了几个？
《人月神话》出版以来，IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员，最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”，但是一位普通程序猿如何能够蜕变成代码金刚呢？
程序猿们，在编写和调试程序的时候，你们是不是这样的？
各位程序猿大大们，你们写代码是不是也是这个状态呢？是不是经常遇到明明奇妙的问题呢？是不是在解决一个问题以后，欢呼雀跃呢？
如何评价一段代码
初学者评价代码是不是简单的最朴素的方法就是看代码规模，他们总是觉得代码行数越少的程序就越简单。经常有人在中问为什么我给出的解法要写二十几行代码，而网上的解法却只有十几行。于是就让我讲一下那个十几行的代码。我只能说，那个十几行的代码来自《算法导论》，我需要用4~5个篇幅来讲，还不保证能讲透彻。
烂代码的各种表象以及产生烂代码的原因
你可以说：之前改一个模块要3天，重构之后1天就可以了。但是怎么应对“不就是做个数据库操作吗为什么要3天”这类问题？烂代码“烂”的因素有不确定性、开发效率也因人而异，想要证明这个东西“确实”会增加两天开发时间，往往反而会变成“我看了3天才看懂这个函数是做什么的”或者“我做这么简单的修改要花3天”这种神经病才会去证明的命题。
是什么导致优秀的程序员写出如此垃圾的代码？
我惊奇地发现原作者实际上是一群拥有很高技术水平的资深工程师。是什么导致一群有能力的开发者产出并交付这样一堆垃圾呢？我能想到的原因有很多。这些是我认为连资深的团队都可能会沾染的坏习惯，这些坏习惯会严重地影响你的终端产品，甚至连源码检查或者开发方法论都无法拯救。
那些年我们写过的代码注释，没被打死真是奇迹！
曾经年少轻狂，写了三两行简简单单的逻辑代码，却总要在前头署上自己的大名，然后等到生产版本宕机那天，已经换了三四家的公司的你还是被无情夺命连环 Call 。曾经对面坐着的是个花一般的测试，然后代码的注释里，总是会多出好几排空格。曾经，我们在写代码时，还会有心情写注释。曾经，写注释时，身边还有你。望能博君一笑。
什么样的代码才是好代码
衡量代码的好坏的指标或者维度有很多，比如性能好、架构好、高内聚等，这些指标的侧重点各不相同，不同的开发人员的关注的重点也各不相同。我个人更喜欢简单的可读性高的代码，我主要从以下几个维度衡量代码是否良好：
谁在代码里下的毒
在维护别人的代码时一定要保持平常心， 「烂代码」无处不在，就算是再牛逼公司中再牛逼的程序也会生产出在别人眼里的「烂代码」。 有句话说的好：既然逃避不了被强奸的命运，那就学会享受吧！下面为大家奉上一些另人哭笑不得的代码博大家一笑
关于烂代码的那些事
最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。 这里是上篇，谈一谈烂代码产生的原因和现象。
漫画故事：编写可读代码的艺术
《编写可读代码的艺术》这本书我想程序猿都很熟悉吧。平时不怎么读书的我也是心血来潮将这本书通读了一遍，果然是大师写的书啊，让我感受颇深！下面是我从这本“神书”中摘抄的一些精华，千万不要错过：
如何跟老代码友好相处
面对legacy code的情况有很多，不仅仅在工作中会遇到一些198x年写的代码跟2016年写的代码混在一起的情况，哪怕是开发自己的GacUI也会有。尽管GacUI公开立项是在C++11发布之前不久，但是实际上整份代码是在我读大学的时候造各种轮子的时候，慢慢组合起来的。现在在注释里面还能看到类似Vczh Library ++ 3.0的字样，那1.0是什么呢？
十个有关代码审查和质量的事实
45％ 的开发人员说，“缺少时间”是审查代码的真正障碍，而 34％ 的开发人员则认为是迫于“发布新功能的压力”
没有代码审查和测试驱动的经济成本和时间成本
近些年来，越来越多的人开始向我咨询测试驱动开发（TDD）的好处。所谓TDD，就是在将代码进行部署之前，利用各种自动化测试来确保代码能够正常工作。在进行测试的时候，你需要寻找测试失败的地方，然后不断修改，必要的时候还需要对代码进行重写。实践证明，TDD是软件开发过程中必不可少的一环。而且它还能够帮助企业和员工节省大量的时间。
整洁好看的代码是什么？我们又该如何实现？
他们认为一份整洁的代码能为团队开发，后期维护，重构奠定了良好的基础，其质量也是 可靠的。因此各小组以如何建立并监督编码标准展开了大量的讨论。虽然我同意这类作法确实有一定的作用，但我认为整洁代码最核心的关键并不是这个。因此，以 下内容是我个人对整洁代码的理解与看法。
Fackbook前项目主管：发布代码的正确方式
作者 Jocelyn Goldfein ，天使投资人、前 Facebook 和 VMware 工程主管，她因帮助工程师团队在高速增长期快速扩展业务而久负盛名。在 First Round 公司上次的 CTO 峰会上，她分享了不同环境下发布软件的经验，并在如何构建自己的发布流程方面为初创公司提供建议。
C语言代码评审小结
在实际的软件开发项目中，代码评审是一个必不可少的流程。代码评审，也称之为代码复查，是指通过阅读开发人员所写的代码来检查源代码与编码规范的符合性以及代码质量的活动。总的说来，代码评审的好处有以下几点
如何正确的阅读源代码？
重复一句，工具和方法永远不是最重要的，去读，并在遇到困难的时候，看不明白的时候，咬牙坚持下去，抽丝剥茧，逐个击破。最终，你会在冰冷黑暗 的二进制世界里面看到一张地图，找到一座灯塔，然后去解释和还原这个底层世界里每一个细微方面的语义
谷歌官方HTML/CSS代码风格指南：<HTML><BODY><HEAD>等这样的无用标签应该删掉
Google的HTML/CSS代码风格指南上说，为了减少文件体积和加强HTML标签的被解析能力，建议删除非必需标签。HTML5规范说明了哪些标签是可以删除的。
同事代码写的乱怎么办？
经常有人问我这种看上去很简单，但是实际上非常复杂的问题。“我团队中有一个人写的代码极其纷乱复杂，根本无法维护。我该怎么办？”
