2011年12月13日
摘要：
SaaS已在口边说了好几年，当初还在学校的时候就认识了SaaS，以为是个技术新潮流，认定它是一个可以专研的技术方向，毕业论文就以它为题，还闷在家里9个月，做了个号称基于SaaS的在线租赁CRM系统，当时把xtools、800crm当做楷模，认为他们是中国搞SaaS鼻祖。后来去了阿里软件，冲的就是它号称中国SaaS管理软件第一的名号，当时大家把Salesforce当楷模，极力模仿。再后来大家一锅端到了阿里巴巴，延续SaaS之路，但认识和提法有了很大的改变。因此，这几年下来，我对SaaS的认识随着知识的积累和环境变迁有了好几个阶段的变化：软件搬到互联网上，租户间相互隔离可供第三方定制化的平台软件和 阅读全文
摘要：
如何在一般情况下进行工作量的评估？类比估算法：根据类似的项目工作量进行预估，再对估计值根据具体情况进行调整。参数估算法：我们公司可能缺乏这方面的数据支持，比如通过估计某个项目可能会有的代码行数，配备的成员技能，来进行估计。举个例子，某个项目的代码行估计可能会有10000行，一个一般技能的开发工程师一天可以完成的代码行为500行，那么开发需要的时间可能就是20人日。三点估算法：目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值，最后确定的估算值=(最悲观的估算值+最乐观的估算值+4*最可能的估算值)/6。Delphi法：由一组专家对项目进行 阅读全文
摘要：
ode review是项目过程中一项非常重要的工作，可以有效检查出代码层面的问题，而这些问题常常是QA难以发现的。但在现实工作中code review常常因为无法量化而流于形式，无法形成有效地闭环，很多时候只是在PM提醒下互相看两眼，或是组织大家开code review会议，在会议上大伙一起对着投影做集体review，效果可想而知不会太好。解决以上的问题关键在于形成一个机制并且借助有效的工具去实施，这一点上可以借鉴QA的bug系统，对每一个有问题的点建立问题发现、问题分配和问题解决等生命周期，并且记录在案，使每个code reviewer担当起类似QA的职责。code review机制code 阅读全文
摘要：
很多前辈和书上都说开发人员，尤其是架构师和技术经理需要有商业感觉，我一直试图培养自己这方面的能力，可是常常不知所措，一说到感觉，就意味着要么是与生俱来的，要么就是在商业世界里一点一滴积累起来，而对于我们这些整天泡在技术细节里的人谈何容易。其实对我们来说，商业感觉这个词太大了，过于抽象，以至于我们不知如何做起，我觉得不如缩小范围，把我们要服务的用户和要实现的需求搞清楚倒是来得实在些。记得去年被收购的时候，新来的老板骂我们不懂用户不懂需求，做的东西别手蹩脚，磕磕跘跘。虽然感觉有些不爽，但审视自己确实没在用户和需求上下多大功夫。因此，开发人员要培养商业感觉应该从用户和需求开始。读了下苏杰的《人人都是 阅读全文
摘要：
以前参加过一些时间管理的培训，也学习过一些方法，但没有在日常工作中真正运用起来。近来，组织又给予了更多的职责，使得工作突然多杂了起来，时间也突然变得不够用，于是乎实施了一些时间管理的方法，起到了一些效果，今日做一下小结：目标->计划->工作日程安排免打扰的方法对突发工作的记录和追溯把握效率规律，预设时间小片段勤做记录和总结，使时间最大化沉淀目标->计划->工作日程安排我们都知道工作日程安排是时间管理的基础性工作，每个人都会去做，但如何把杂乱的工作安排得合理可行却是一件难事。检验一个工作日程安排是否合理很简单，日程周期过后check一下实际工作中和先前安排的出路有多大，并 阅读全文
摘要：
我曾在一次面试中要求一个很有经验的嵌入式软件开发人员写出一个反转一段字符串并输出到屏幕上的程序。他在这个题目上挣扎了很久。这个家伙是个很神奇的人。你给他一些没用的零件，他能建造一个机器人，并能用程序控制它在屋里走来走去。他曾经参与过研制卫星，并且这个卫星现在正在轨运行。他只用左脑都比我能干。但是对于这个题目他却从来、从来没机会干过：在屏幕上显示什么东西。有些人就有这种技能，能在面试中问出正确的问题，发现优秀的程序员。而有些人却害怕提问，畏首畏尾，问一些从网上拷贝下来的问题，自己没主见，只会跟随其他面试官的意见。但面试对于大多数开发人员来说是一项很基本的技能。一次失败的招聘会给一个组织造成很严重 阅读全文
摘要：
线上查问题的时候有些命令是必备，有必要把一些常用命令总结一下（这类命令和相关参数相当多，只总结自己常用得到的），查找问题一般可以分为系统参数、性能参数、进程、内存、网络、存储、内存和jvm这么几类：系统参数cat /proc/cpuinfo cpu相关参数cat /proc/meminfo 内存相关参数cat /proc/loadavg 负载情况性能参数1）topM：按内存使用排序P：按CPU占用排序1：显示各CPU的使用情况k：kill进程o：更多排序规则回车：刷新数据2）ulimitulimit -a：显示本用户的系统限制参数ulimit -Hn <num>：更改最大Hard 阅读全文
摘要：
最近参加公司内一个技术规划评审过程中，通过老板对台上的架构师的质疑，学习到几个做技术规划的要点，归纳如下：1）紧扣业务虽然是做技术规划，但如果脱离了业务支撑，是引起不了老板兴趣的2）从实际问题出发老板只会为解决实际问题的技术规划买单。规划的开头最好能从实际问题出发，比较容易引起老板的注意3）重点在落地只有能落地的技术才有说服力，老板不会被天花乱坠的技术词汇给迷惑的，他只会关注最后能落地是哪几项，应该重点谈落地的目标和计划4）突出关键点和关键路径其中一个哥们说了很多，非常丰富，但关键点不突出，结果在老板看来就是个零。在表述规划的整个过程中，一定要紧扣关键旋律，让老板用最短的时间理解你的意图5）少 阅读全文
摘要：
原则大于个人口味很多架构师都有着丰富的经验和个人风格，以至于在平常工作中常以个人口味作为决策的依据，对于普通的开发人员也许是可行的，我们鼓励大家有个人特色，但架构师更应该依据原则办事，需要维护和遵守一套大家公认的原则，以此作为判断是非的工具从“可行走骨架”开始敏捷管理崇尚尽早集成，在架构设计这一块，这个原则也行之有效。架构师在开始阶段无需陷入某些难题或细节里，应该尽快地把各个核心模块串接起来，并能发动开发人员使其简单地运转起来，骨架一旦就绪，再进入健身环节。这样做的好处，一方面可以尽早消除大家之间的误解，也可以带来正朝着正确方向前进的信心数据是核心数据为王是大家深知的道理，只要这个系统拥有有价 阅读全文
摘要：
让开发人员自己做主架构师虽然需要为系统的设计负责，但无须包揽所有的设计工作，应该给予团队成员足够的自主权，让他们发挥自己的创意和能力，你的工作是确保大家的工作能很好的组合在一起，帮助他人解决棘手困难。当你发现同事遇到麻烦时，可以主动给出建议，但更可取的做法是创造良好的氛围，让大家主动向你征求意见。控制项目规模架构师要试图避免做那种“超大型”系统，因为这种系统往往难以控制，控制项目规模的办法通常有：抓住真正需求分而治之设置优先级尽快交付原则架构师不是演员，而是管家有些架构师误解了证明自己价值的含义，以为是炫耀技术才华，甚至是***难开发团队，把自己放在高高在上的位子，试图让别人来崇拜你。其实架构师的 阅读全文
摘要：
先确保解决方案简单可用，再考虑通用性和复用性系统的复杂性往往是架构师基于通用性和复用性的设计而引入的，很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍，先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时，无需排斥通用和灵活，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口，以及存在缺陷的抽象所淹没。先简单满足需求，当重复需求再次发生时，通过重构来达到复用是一种不错的方式架构师应该亲力亲为架构师干久了往往会脱离技术本身，迷茫在抽象之中，这是很危险可怕的。架构师要取得其他同事的信任，应该比业务人员更懂 阅读全文
摘要：
最近看了一本书《软件架构师应该知道的97件事》，本来并没对它抱有太多期望和兴趣，毕竟这种讲大道理的书不可能带来什么实际收获，但看的过程中被里面中肯实在的建议给吸引，对于我这种在走向架构师这条路上常常迷失方向的人，实在是雪中送炭。读完后，决定选择其中对我有触动的条目，加上实际工作中的感悟，形成一套自认为正确的架构师行为准则，以此来矫正自己的行为。客户需求高于一切不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案，而是应该扎根客户需求，脚踏实地地为客户着想，这样才能更体现技术的价值，不至于迷失方向。架构师首先不要把自己当做技术人员，而是业务人员，把实现业务需求作为至上的目标，学会拒绝成本 阅读全文