求索

PWA是最近一个热门话题，很多开发同学都在尝试落地，其中也有些还在犹豫。这篇文章主要阐述对几个问题的看法，包括iOS支持的问题等，供大家参考。 注: 这不是一篇介绍PWA的文章。

组件(Component)和模块(Module)又是一对容易混淆的名词，也常常被用来相互替换。个人总结，从设计上来看，组件强调复用，模块强调职责(内聚)，或者说组件是达到可复用要求的模块。

自我驱动或者自组织团队是现在软件公司努力建设的方向，自我驱动也常常挂在嘴边。但以我的观察，自我驱动或自组织团队建设并没有带有真正的团队生产力提升，反而很易遇到发展瓶颈！自组织团队的困境问题在哪里？ 我今天终于恍然大悟。这也许也是敏捷在中国一直处于困境的原因之一。简而言之，在自我驱动团队建设上缺少方法和执行力！思想是别人的，而做法仍然是自己的。可以简单地通过几个方向来审视

在项目管理:计划、进度和控制的系统方法>>里作者讲述到领导生命周期理论在项目管理环境下的应用。领导生命周期理论(Life-cycle Leadership)模型指出，存在4个基本的领导风格，而且要想有效运用它们需要使用领导风络与被领导者的成熟度相适应。这里成熟度的定义是：与工作相关的经验，接受工作任务的意愿及完成任务的愿望。它不只是与做好工作有关，还与"想"做好工作有关。最重要的是，它

When an old idea is a good idea that improves to become a better idea, we should all want to benefit from that evolution. Software Inspection was a good idea when started in 1972. Inspections have c

这项研究部分基于NSF制定的EIA-0113539 ITR/SY+PE：“提高软件测试者的教育。” 材料中表达的任何观点、发现和结论或者评论都属于作者，不代表国家科学基金会（NSF）的观点。摘要     设计好的测试用例是一门复杂的艺术。其复杂性有三个原因：       1.测试用例能帮我们发现信息。不同类型的测试对不同类型的信息有效。       2.

单元测试很棒。在假定一些数据的环境下，能顺利通过测试的系统就可算是一个好系统。不过，现在可以直连外部资源的集成测试才让程序更有价值。谁知道那些内容商(供应商,vendor)会做出什么傻事来！很多人一直尝试着让测试达到100%的代码覆盖率，这是很棒的想法，但我倒觉得它有些基本概念上的问题。LosTechies, Ryan Svihla 提出了"反模式(anti

人绝不是一种资源。一方面我们不可能因人设岗，另一方面也不能忽略人性的差异。面对问题时，不要总是单纯地从人的态度或品德上查找问题，而是要反思人事安排和流程建设上的不足。奢望一个人改掉他的缺点，还不足充分发挥他的优点。前言MBTI将人区分为16类人格特质，我无法断言是否真得能表达出人的真实一面，毕竟只是统计性的结果。我的思考并不在于它归类的结果，而在于它的归类方法。

RP是所有设计原则最简单的，但也是最难运用的。现实工作中，关于一个类是否符合SRP，或者是否有必要符合SRP的讨论是经常发生的。争论的关键在于职责的定义，但我理解SRP真正的核心是关注于变化。

讨论设计时，专业词汇满天飞，每个人的技术背景、工作经验上的不同都会导致在理解上存在着差异。无论是SEI的定义、OMG UML的定义、还有各路大神的定义，都有从不同视角带来的差异。准备后面关注这些定义的差异，摊开来大家一起来讨论。关于’业务逻辑’, 国内国外争论了很多年了(这篇在07年就说没有清晰的定义)，其中几个比较详细的讨论见附录(一定要看评论)。我总结为两类: 一类是逻辑处理论，一类是数据操作论。

在一个软件开发组织里，若干职能单位负责各个业务模块，然后就是大小各种专项。专项可以横向拉通各个单位，但专项一多，或者有点泛滥，各个业务单位的职责就会有所淡化，目标也有模糊的地方。专项就像是东厂、西厂，可以四处横行，而业务单位却不断要进行各种配合。利也? 弊也?
所谓专项一般为攻关，拉通多个沟通不畅的团队而设。如果团队之间配合无间，规划和执行也都到位，又何来专项！

从局外人的角度的确可以清晰的发现问题，但很难得到一个合适的解决方法。** 只有将自己融进公司，融进团队，才能更清楚了解问题的本质，才能有好的应对方案。

Google C++ Style Guide并不是一个百科全书，也不是一个C++使用指南，但它描述适用于Google及其开源项目的编码指南，并不追求全面和绝对正确，也有许多人置疑它的一些规则。但作为一个最具影响力的编码规范，它里面有许多内容值得我们研究学习。以下主要摘自GSG负责人Titus Winters在CppCon 2014上的演讲。

书中第六章 隔离。 主要在撰述什么需要定义在头文件？什么应当移到编译单元中？ 核心仍然是先区分接口定义与实现细节。实现细节的改变会导致客户代码的重新编译，从逻辑上也表示与客户代码间可能存在着强耦合。实现细节与隔离主要考察以下实现细节，它们会在接口中引入实现细节，也是需要考虑进行隔离的内容：继承分层 简单的说就是类的成员中有另一个类的实例时，如Foo mFoo. 这个类就会依赖于Foo的定义。

智能指针使用上的问题智能指针的使用太普遍了，它让程序员摆脱了内存管理的恶梦，但实际上智能指针本身也可能引入另一个恶梦。主要包括两个问题点:1.性能问题。因为需要引入一些变量(bookkeeping)，甚至在多线程下的一些互斥操作，它所带来的性能开销往往比想像的要高。2. 对象释放的时机不明确。比如std::auto_ptr，总让人感觉不明不白，从而引入一些隐晦的问题。

什么是软件设计的复杂度软件技术发展的使命之一就是控制复杂度(Complexity)。从高级语言的产生，到结构化编程，再到面向对象编程、组件化编程等等。本文介绍通过分解、改善依赖关系，以及抽象的方式来降低复杂度。

使用一个抽象的接口隔离变化，既提高了各层的内聚性，又降低它们间的耦合。符合OO原则中的: 1. 封装变化 2. 针对接口编程，而不针对具体的实现。 3. 降低交互对象的耦合度。

适配器模式常常与桥接模式相比较，两者最大的不同在于解决的问题不同。适配器用于对接两个不同的接口，而桥接则主要为了隔离变化。从应用上来说，一个是被动的，一个是主动的。 所谓被动的，就是当前的接口的差异是无法轻易改变的，必须引入一个中间层来解决。而中间层的引入往往带有性能、以及不必要的数据拷贝等开销，详细参考关于层的反模式讨论。如果接口是可控，就要尽量避免接口不一致的情形。而不是等待使用Adapter来处理。

相对于软件公司中的开发团队，维护团队似乎常常默默无闻，做事相对于保守，远没有开发团队那样常常让人有新鲜感。这是一种很普遍的现象，也就是维护团队的价值常常被有意或无意地降低了。 事实上，维护团队的建设和管理比开发团队所应对的挑战大得多，而运行得当的话，可以同项目团队或开发团队形成互补，发挥驱动力。软件维护团队的目标和流程软件维护团队被赋予维护已交付产品的职责，主要工作内容是分析修复新

模块化是一个"发现"模块化(Modularity)这个概念与其说是一种创新，不如说是一个"发现"。这正是人们在解决问题时常用的行为方式和思维过程。它不是单纯的技术问题，更深深地影响着整个社会生活。可以读读>, 在>第4章也提到了这本书！我们获取知识有两个重要的方式:归纳(conclude)和演绎(deduce)，不用多解释。它们其实就是自下而上和自上而下的差别。人类有与生俱来的抽象

软件项目管理中的风险管理像是把瑞士军刀，高效全能。它是项目全面管理的一部分，风险管理应该与关键的项目实施过程紧密相连，贯穿项目始终。风险管理风险管理工具只是辅助，关键是在项目中要有风险意识。我们习惯于处理问题(issue)，但却疏于应对风险(risk)。关于风险和问题如何区别的讨论，不单在国内，在国外也一直没有定论，在英文两者都是problem。一般认为问题(issue)是已经存在

谦逊的长者——Edsger Wybe Dijkstra，1930年出生于荷兰阿姆斯特丹，2002年逝世于荷兰纽南。他在祖国荷兰获得数据和物理学学士，理论物理博士学位，2000年退休前 一直是美国Texas大学的计算机科学和数学教授。以发现了图论中的最短路径算法（Dijkstra算法）而闻名于世，1972年因为ALGOL第二代编 程语言而获得图灵奖。“Go To Statement Consid

转载请注明来源:http://blog.youkuaiyun.com/horkychen 解bug应当是修复代码中的缺陷，而不只是隐藏起来!(译注 ：解Bug时常发生分析时总感觉快找到答案了，而后面却一再陷入僵局。比如，将线程同步问题引起的一些时而有，时而没有的问题。分析时可能会认为这是个典型的线程同步问题，A线程没有按照预期的方式改变某个变量，导致了B线程处理出错。这样的分析结果如果没有调试(Deb

转载请注明出处:http://blog.youkuaiyun.com/horkychen  (之前在世界经理人的博客文章)我们每天都在面对各式各样的问题，有时电话一响或者一个新邮件提醒都可能让人紧张。特别是遇到一些突发状况，猝不及防！问题一出现，人就垂头丧气。如果一段时间没有问题，就觉得很是幸运，不免偷偷一乐。这样的情景经常发生！"问题"就像是达摩克利斯之剑，人人唯恐避之不及。其实

转载请注明出处:http://blog.youkuaiyun.com/horkychen  (以前写的资料，不准备翻了。)Index1. Introduction2. Purpose3. Basic concepts of Unit Test3.1 Suite3.2 Test Case4. Target programming languages5. Target Unit T

转载请注明出处:http://blog.youkuaiyun.com/horkychen1. 多人修改同一份代码Lock/Unlock为了防止多人同时修改一份代码，就加把锁吧！右击文件或目录->TortoiseSVN->Get Lock加锁右击文件或目录->TortoiseSVN->Release Lock加锁2. 统计功能(Statistics)以此查看开发者提交频率。

转载请注明出处:http://blog.youkuaiyun.com/horkychen*笛卡尔:普遍的怀疑第一：绝不把任何我没有明确地认识为真的东西当做的加以接受，也就是说，小心避免仓促的判断和偏见，只把那些十分清楚明白地呈现在我的心智之前，使我根本无法怀疑的东西放进我的判断之中。第二：把我所考虑的每一个难题，都尽可能地分成细小的部分，直到可以而且适于加以圆满解决的程度为止。

面向对象度量简介原文地址:http://agile.csc.ncsu.edu/SEMaterials/OOMetrics.htm2 度量分析以面向对象度量来分析代码时，经常使用CK(Chidamber Kemerer)度量集[8] 和MOOD [1，2]度量集。 在本节中，我们将列举和解释度量指标的具体运用。2.1  耦合1974年，史蒂文等人在结构化编程的背景下首

软件开发过程中的审查 (Review) 希望别人做些什么->定义出流程希望别人做出正确的结果->定义出审查制度  软件开发项目中包括很多的审查动作,贯穿于整个开发过程。个人认为审查主要有以下目的：1.尽早排查出潜在的问题(Potential Risk/Issue)   经过其他人的参与，以不同的视角提出不同的看法，会有类似头脑风暴的效果，集思广议来查找工程师未能注意的问

原文地址: http://managementhelp.org/staffing/screening.htm  Copyright Carter McNamara, MBA, PhD你面试时的整体性和专业性，可以对候选人形成一个强有力的积极印象。它也传达了如果他们被聘请了也要这样做事。准备为所有基本符合资质要求的候选人安排面试。基本资质都被指定在职位描述中。这种做法有助于确保你

下次当你听某人谈到生产力时，仔细听一听说话的人是否用了“人员调整”一词，很大的可能性是他或她没有提到这个词。多年来从听到的关于生产力的讨论或看到的数以百计的关于这方面的文章中，我们从没有遇见一个专家谈到有关人员调整这个主题的任何事情。然而只谈论一个而不谈论另外一个有什么意义呢？下面评价一下公司在改进生产力方面要做的一些典型的事情：.  强迫人们加班加点.  产品开发过程的机械化

如果风险止于发现者则不能称为有风险管理，必须是在规范的流程之下，有计划的采取行动，这才算是风险管理的起步阶段。1. 培养风险意识(Risk Awareness)需要在开发的各个阶段，训练团队成员能主动发现出风险，然后报告出来并同相关人员进行沟通。整个过程可能缺少流程定义，还没有约束，但它是团队风险文化建立的起点，也是建立风险管理的基础。2. 初级风险管理  从风险意

看到Stack Exchange上对于在Bug Report中加入"Person to blame"栏位的讨论，这的确是一个很好的题目，这里面包含了很多的东西。该不该加这个栏位且不说，其实最重要是看动机和目的。为什么管理者要加这个栏位呢？ 自然是可以方便地统计出哪个组、哪个伙计引入的Bug状况。这可是绩效考核中一项非常有效的KPI(核心绩效指标)，一定能符合SMART原则，随后的奖惩也

2010-12-21 14:13 宗子城每次我们看敏捷开发Scrum都是从技术角度，今天我们尝试从管理角度来看这个问题。ScrumScrum近几年已经成为最有影响的软件开发过程，从Forrester 关于敏捷模式的调查报告我们可以看出一些倪端,而且微软也推出了更Scrum的模板，相信.Net平台下越来越多的团队会采用这一过程。 图1： Forrester 关于敏捷模

设计，似乎有点高深莫测！ 一堆的模式、模型，让人无所适从。学了记不住，记住又用不上。我觉得设计应当是自然而然的事，从实际问题出发找出实际的解决方案就可以了。其实难点在于能不能看到问题。回想起12年前的2000年，当时刚进入一家ERP公司，被安排为一家灯饰公司"客制"(所谓客制就是定制的意思!)人事系统。当时系统总被客户抱怨薪资结算太慢，四千人的工资要跑一晚上。下班时开始结算，第二天

《人月神话》发表了近30年了，柏油坑依然在那里。如果软件零缺陷是个神话，为什么我们还始终将陷于Bug修复视为常态？为什么普遍认为软件是解Bug解出来的？ 虽然以前微软总被嘲笑补丁打不完，而我们也常常是在打补丁。 一个问题发生了，我们运用智慧的大脑先分析，再找方案！ 大部分情况想到的是以最小的代价修复Bug，从而新方案反而引入新Bug。如此往复，构成了程序员工作的主要内容。为

在整个流程改造过程中，公司高层的支持必不可少。敏捷开发模型带来不单单是纯粹流程和方法上的变化，也会带来公司制度层面，甚至是文化层面的改变。只将流程改造限制在项目级别，只能产出一个勉强而来的结果，并不是真正的敏捷开发。上一篇:X公司的流程改造之路 (一) 开端 Beck为团队进行了两天的培训，并逐一解答了大家的问题。在随后的团队的启动会议上，总经理Drucker亲自出席鼓励团队，

起点X公司是一家中规中矩的公司，从事软件开发二十多年，一直使用传统瀑布开发模型，开发流程和相关的制度都已经完善。最近两年因为市场的变化，考虑到公司长远的产品线的竞争力，决策层决定推动新产品领域开发。但是传统的瀑布模型无法满足高层快速进行产品试水的需要，市场部的需求一改再改，并极力打造大而全的产品，虽然他们并不承认。两个项目(A, B)下来开发团队和公司高层都非常不满，团队士气低落，离职频繁

转载请注明出处:http://blog.youkuaiyun.com/horkychen来源 Check In, Don't Check Up (照看而不是介入!)我从来不是微观管理者(micro-manager)，特别是应用agile和Scrum之后。初入职场时，要不是太忙于和别人搅和在一起处理问题，我很可能就会成为一个微观管理者。但是当尽量避免同大家一起检讨细节问题时，仍要认真地照看(chec