工作心得
文章平均质量分 57
cutesource
这个作者很懒,什么都没留下…
展开
-
在xcode中编译和调试webkit, V8和Nodejs
对于一个c/c++菜鸟如何想去研究一些优秀的框架是件很困难的事情,但如果能把这些框架导成xcode项目,并xode上编译和调试将会使学习这件事情相对容易许多,xcode确确实实是开发人员的利器。最近一直在搞webkit, V8和Nodejs,于是乎找到了把这三个框架导成xcode project的方法,总结如下:WebKitWebKit前文已说过,源码中已包含xcodeproj文件,直接用xcod原创 2013-04-27 09:20:48 · 21409 阅读 · 1 评论 -
如何在面试中发现优秀程序员(转)
<br /><br />我曾在一次面试中要求一个很有经验的嵌入式软件开发人员写出一个反转一段字符串并输出到屏幕上的程序。他在这个题目上挣扎了很久。这个家伙是个很神奇的人。你给他一些没用的零件,他能建造一个机器人,并能用程序控制它在屋里走来走去。他曾经参与过研制卫星,并且这个卫星现在正在轨运行。他只用左脑都比我能干。但是对于这个题目他却从来、从来没机会干过:在屏幕上显示什么东西。<br /> <br />有些人就有这种技能,能在面试中问出正确的问题,发现优秀的程序员。而有些人却害怕提问,畏首畏尾,问一些从网上转载 2010-09-30 11:04:00 · 21052 阅读 · 15 评论 -
关于时间管理的一些沉淀
<br />以前参加过一些时间管理的培训,也学习过一些方法,但没有在日常工作中真正运用起来。近来,组织又给予了更多的职责,使得工作突然多杂了起来,时间也突然变得不够用,于是乎实施了一些时间管理的方法,起到了一些效果,今日做一下小结:目标->计划->工作日程安排免打扰的方法对突发工作的记录和追溯把握效率规律,预设时间小片段勤做记录和总结,使时间最大化沉淀<br />目标->计划->工作日程安排<br />我们都知道工作日程安排是时间管理的基础性工作,每个人都会去做,但如何把杂乱的工作安排得合理可行却是一件难事原创 2010-09-12 18:03:00 · 6521 阅读 · 1 评论 -
开发人员如何了解用户和需求
很多前辈和书上都说开发人员,尤其是架构师和技术经理需要有商业感觉,我一直试图培养自己这方面的能力,可以常常不知所措,一说到感觉,就意味着要么是与生俱来的,要么就是在商业世界里一点一滴积累起来,而对于我们这些整天泡在技术细节里的人谈何容易。其实对我们来说,商业感觉这个词太大了,过于抽象,以至于我们不知如何做起,我觉得不如缩小范围,把我们要服务的用户和要实现的需求搞清楚倒是来得实在些。记得去年被收购的时候,新来的老板骂我们不懂用户不懂需求,做的东西别手蹩脚,磕磕跘跘。虽然感觉有些不爽,但审视自己确实没在用户和需原创 2010-08-29 11:40:00 · 6645 阅读 · 1 评论 -
基于Jupiter建立code review机制
<br />code review是项目过程中一项非常重要的工作,可以有效检查出代码层面的问题,而这些问题常常是QA难以发现的。但在现实工作中code review常常因为无法量化而流于形式,无法形成有效地闭环,很多时候只是在PM提醒下互相看两眼,或是组织大家开code review会议,在会议上大伙一起对着投影做集体review,效果可想而知不会太好。<br />解决以上的问题关键在于形成一个机制并且借助有效的工具去实施,这一点上可以借鉴QA的bug系统,对每一个有问题的点建立问题发现、问题分配和问题解决原创 2010-08-19 17:10:00 · 9151 阅读 · 1 评论 -
PM工作中常见问题及解决方法
如何在一般情况下进行工作量的评估?类比估算法:根据类似的项目工作量进行预估,再对估计值根据具体情况进行调整。参数估算法:我们公司可能缺乏这方面的数据支持,比如通过估计某个项目可能会有的代码行数,配备的成员技能,来进行估计。举个例子,某个项目的代码行估计可能会有10000行,一个一般技能的开发工程师一天可以完成的代码行为500行,那么开发需要的时间可能就是20人日。三点估算法:目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值,最后确定的估算值=(最悲观原创 2010-06-22 10:01:00 · 6819 阅读 · 1 评论 -
认识SaaS的历程
<br />SaaS已在口边说了好几年,当初还在学校的时候就认识了SaaS,以为是个技术新潮流,认定它是一个可以专研的技术方向,毕业论文就以它为题,还闷在家里9个月,做了个号称基于SaaS的在线租赁CRM系统,当时把xtools、800crm当做楷模,认为他们是中国搞SaaS鼻祖。后来去了阿里软件,冲的就是它号称中国SaaS管理软件第一的名号,当时大家把Salesforce当楷模,极力模仿。再后来大家一锅端到了阿里巴巴,延续SaaS之路,但认识和提法有了很大的改变。因此,这几年下来,我对SaaS的认识随着知原创 2010-06-05 11:23:00 · 3620 阅读 · 0 评论 -
架构师的行为准则(一)
最近看了一本书《软件架构师应该知道的97件事》,本来并没对它抱有太多期望和兴趣,毕竟这种讲大道理的书不可能带来什么实际收获,但看的过程中被里面中肯实在的建议给吸引,对于我这种在走向架构师这条路上常常迷失方向的人,实在是雪中送炭。读完后,决定选择其中对我有触动的条目,加上实际工作中的感悟,形成一套自认为正确的架构师行为准则吗,以此来矫正自己的行为。客户需求高于一切不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案,而是应该扎根客户需求,脚踏实地地为客户着想,这样才能更体现技术的价值,不至于迷失方向简原创 2010-07-25 18:02:00 · 16642 阅读 · 11 评论 -
架构师的行为准则(四)
原则大于个人口味很多架构师都有着丰富的经验和个人风格,以至于在平常工作中常以个人口味作为决策的依据,对于普通的开发人员也许是可行的,我们鼓励大家有个人特色,但架构师更应该依据原则办事,需要维护和遵守一套大家公认的原则,以此作为判断是非的工具从“可行走骨架”开始敏捷管理崇尚尽早集成,在架构设计这一块,这个原则也行之有效。架构师在开始阶段无需陷入某些难题或细节里,应该尽快地把各个核心模块串接起来,并能发动开发人员使其简单地运转起来,骨架一旦就绪,再进入健身环节。这样做的好处,一方面可以尽早消除大家之间的误解,也原创 2010-07-27 09:34:00 · 5847 阅读 · 2 评论 -
救火必备linux命令小结(一)------查问题
<br />线上查问题的时候有些命令是必备,有必要把一些常用命令总结一下(这类命令和相关参数相当多,只总结自己常用得到的),查找问题一般可以分为系统参数、性能参数、进程、内存、网络、存储、内存和jvm这么几类:<br />系统参数<br />cat /proc/cpuinfo cpu相关参数<br />cat /proc/meminfo 内存相关参数<br />cat /proc/loadavg 负载情况 <br />性能参数<br />1)top<br />M:按内存使用排序<br />P:按C原创 2010-12-04 20:29:00 · 8827 阅读 · 1 评论 -
ThreadPoolExecutor运转机制详解
最近发现几起对ThreadPoolExecutor的误用,其中包括自己,发现都是因为没有仔细看注释和内部运转机制,想当然的揣测参数导致,先看一下新建一个ThreadPoolExecutor的构建参数:public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime,原创 2010-12-07 17:38:00 · 64104 阅读 · 9 评论 -
重新出发
几经曲折,重新出发。从确定再次寻求机会的那天起,就一直不太平,接触了很多,也得罪了很多,给很多朋友引来了很多麻烦,我只能说声抱歉,我的出发点很简单,仅仅只是想找到一个点能重新出发,重新走向架构师之路。有时感觉自己又回到了起点,有时也吐槽自己:既然如此何必当初。不过,这次的重新出发不至于是对当初的离开全盘否定,起码现在的自己和以前感觉最明显不同是,做技术更加纯粹,没有了后顾之忧后,不会那么势利地去看原创 2013-03-06 18:53:55 · 9799 阅读 · 3 评论 -
心胸有多大事就能做多大
歇了一两年,最近又开始躁动。以前公司的兄弟和领导得知我想动的时候,都向我抛来了橄榄枝,这真有点让我受宠若惊。不过,从这一点上我让深有感悟的是,做一个伟大的公司,或领导一个伟大的团队,一定要有这种心胸,容得下之前出走的弟兄再回来,也得让出去了的弟兄们若干年之后还惦记着你的好,这才是成功之道。这次和老板谈离职,也让我感受到了这一点,老板得知是为了更好的发展而动时,只是帮我分析这个机会的利与弊,而没有带原创 2013-01-09 15:05:38 · 10374 阅读 · 6 评论 -
Chrome extension的manifest_version升级过程几个棘手问题的解决方法
之前基于Jquery mobile做了一个Chrome app,就在要给客户做showcase的时候,chrome强制升级manifest_version到2(http://developer.chrome.com/extensions/manifestVersion.html),而这个version基于安全考虑做了一些限制,导致我的chrome app无法运行,具体限制可见:http://dev原创 2012-11-27 11:39:17 · 8254 阅读 · 0 评论 -
最后一天
<br />今天是在杭最后一天,难得有这个无业游民没人管的状态,本打算再闲两天回去,结果天太热,没什么地方好去,算了买了张晚上的车票,回去吧,早点开始新的生活<br />有意识地看了看以前的日志,回想这几年离职的经历<br />第一次离职发生在兼职做讲师的时候,那天发工资,350元,去他妈的,给推荐我进去的哥们说了声就走了,都难得和老板打招呼<br />第二次离职是在读研一的时候,那时还不能叫正规职业,学校里闲得慌,加入了一个哥们的创业小作坊。离开的那天比较突然,在回家的路上突然对这个事情失去了兴趣,随性立原创 2011-05-19 10:53:00 · 9905 阅读 · 17 评论 -
走向???之路
<br />家庭的原因搞得我近半年都处于比较浮躁的状态,技术博客一直没怎么更新,技术积累也没原来那么积极,很怀恋以前那种专注纯粹的学习状态。我现在遇到的问题估计是大众问题,从学校出来时,积极向上,做啥都激情满满,也不太在乎利益得失,两三年后顾虑就多了起来,家安在哪里?生活和工作如何平衡?怎么样持续得到提升?职业生涯如何规划?这些问题搞得你已不再能够仅凭兴趣去做事情,必须权衡n多因素。<br />工作是需要有“混”的心态的,特别是在大公司,机会不会总是堆在你面前,你需要有在高潮时享受成就,在低潮时享受生活的心原创 2011-05-11 11:17:00 · 5881 阅读 · 13 评论 -
给老板汇报技术规划的一些要点
最近参加公司内一个技术规划评审过程中,通过老板对台上的架构师的质疑,学习到几个做技术规划的要点,规划如下:1)紧扣业务虽然是做技术规划,但如果脱离了业务支撑,是引起不了老板兴趣的2)从实际问题出发老板只会为解决实际问题的技术规划买单。规划的开头最好能从实际问题出发,比较容易引起老板的注意3)重点在落地只有能落地的技术才有说服力,老板不会被天花乱坠的技术词汇给迷惑的,他只会关注最后能落地是哪几项,应该重点谈落地的目标和计划4)突出关键点和关键路径其中一个哥们说了很多,非常丰富,但关键点不突出,结果在老板看来就原创 2011-01-16 19:26:00 · 17557 阅读 · 12 评论 -
迈向架构师的第一步
<br />有一个多月没有写blog,主要原因是受工作所累,公司由于组织变动任命我为部门的架构师,算是真正踏出了迈向架构师的第一步。<br />以前收集过很多有关架构师能力模型的文章,感觉自己离架构师不远,但近一两个月真正把这个title戴我头上时才发现自己离一个合格的架构师还有很远,架构师决不仅仅停留在设计系统和写设计文档的层面,现在感觉到压力和捉襟见肘是因为没有真正回答过以下几个问题:<br />1)是否真正具备扎实的开发功底?而不是停留在满足项目需求<br />2)是否能推动他人去改进系统或提升技术?原创 2010-11-13 21:12:00 · 45456 阅读 · 75 评论 -
在Eclipse里关联Android源码的简单办法
Android SDK没有附带把所选平台的源码下载下来,导致基于Eclipse ADT开发的时候没法链到各API的源码,使得大多习惯基于源码开发的人极不习惯,而通过Android推荐的git下载源码的方式比较繁琐,特别是在网络环境不太好的时候把人搞得很烦躁其实有很多热心的网友已把源码打包放在网上,只需下载下来解压放在android.jar所在目录的sources里即可,比如我是基于android2.1开发,android.jar所在目录为F:/android-sdk-windows/platforms/an原创 2010-12-05 22:31:00 · 14285 阅读 · 3 评论 -
架构师的行为准则(二)
先确保解决方案简单可用,再考虑通用性和复用性系统的复杂性往往是架构师基于通用性和复用性的设计而引入的,很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍,先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时,无需排斥通用和灵活,但是如果过早脱离具体情况,只会迷失在无限的可能性里,被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口,以及存在缺陷的抽象所淹没。先简单满足需求,当重复需求再次发生时,通过重构来达到复用是一种不错的方式架构师应该亲力亲为架构师干久了往往会脱离技原创 2010-07-25 20:11:00 · 7769 阅读 · 4 评论 -
架构师的行为准则(三)
让开发人员自己做主架构师虽然需要为系统的设计负责,但无须包揽所有的设计工作,应该给予团队成员足够的自主权,让他们发挥自己的创意和能力,你的工作是确保大家的工作能很好的组合在一起,帮助他人解决棘手困难。当你发现同事遇到麻烦时,可以主动给出建议,但更可取的做法是创造良好的氛围,让大家主动向你征求意见。控制项目规模架构师要试图避免做那种“超大型”系统,因为这种系统往往难以控制,控制项目规模的办法通常有:抓住真正需求分而治之设置优先级尽快交付原则架构师不是演员,而是管家有些架构师误解了证明自己价值的含义,以为是炫耀原创 2010-07-25 23:56:00 · 6127 阅读 · 3 评论 -
敏捷开发的45个好习惯
<br />今天把《高效程序员的45个习惯:敏捷开发修炼之道》翻了一遍,讲的基本是敏捷开发的一些原则,虽然没有焕然大悟的感觉,但定期来出来提醒自己一遍也不错,这些道理虽然简单易懂,但真正要在项目中实施起来还是很有挑战性的,一些成功的项目总结经验起来也无非出于这么些简单的原则:<br /> 1. 做事 <br /> 2. 欲速则不达 <br /> 3. 对事不对人 <br /> 4. 排除万难,奋勇前进 <br /> 5. 跟踪变化 <br /> 6. 对团队投资 <br /> 7原创 2010-07-18 19:51:00 · 3943 阅读 · 0 评论 -
架构师的沟通方式
架构师是个很需要沟通技巧的角色,需要和老板沟通,使其相信在技术上的可行性;需要和PD沟通,弄清楚商业逻辑;需要和项目经理沟通,使其更科学地安排人员和进度;需要和开发人员沟通,使其理解设计思路,保障设计架构在具体实施中得以落实;需要和QA沟通,使其了解项目的风险点和关键点。因此,架构师需要在沟通上下功夫,这是保障工作顺利进行的关键环节。下面是我总结的几个很常用的沟通方式:挑衅式的沟通方式原创 2009-12-06 20:14:00 · 3864 阅读 · 0 评论 -
分享一些牛人的心得
牛P的经验、经历、感受分享 刘加伟: 1. 做为技术方面的大牛/专家,一路走来,你最大的感悟和收获是什么? 只有努力, 并且相信自己, 你才能获得一点一点技术上的成绩. 2. 因为做技术的平时都喜欢熬夜、加班,在家庭和工作之间时间你是如何分配的?毕业前四时候, 我几乎是全身心的投入技术的学习中, 通过不断原创 2009-11-30 15:32:00 · 10523 阅读 · 4 评论 -
从上至下的学习计划
不可避免地从前端业务开发转向了后端平台建设,方向的变化也对自己提出了新的要求,以前想得最多的是如何满足客户的需求,对技术本身的思考不多,以后则是如何满足前端业务部门的共性需求,对技术的要求是不言而喻的。而技术方面,自己最缺乏的是对底层技术的剖析,大部分的工作都是建立在很高层的技术层面,只需要关注业务逻辑,而对最本质的计算机原理一知半解,因此,为了应付角色的转变,我计划从上至下深入下去,层层剖析,把原创 2009-11-28 09:52:00 · 3985 阅读 · 1 评论 -
架构师的那些事儿
架构师特质:能够帮助团队的同事解决问题,参与项目和产品设计对于公司的产品和项目发展方向有清晰的认知常常思考企业产品和项目的方向对公司产生的价值跟业务人员有良好的沟通,善于发掘需求具备很广的知识面,不一定要很深入大局观、开放心态和善于沟通复杂问题简单化的抽象能力架构师分类:基础平台架构师业务架构师数据架构师架构师的原创 2009-11-29 20:39:00 · 3926 阅读 · 0 评论 -
结构化思维
原本以为像老刀这样的高管对基本技术细节应该不关心,也应该丢得差不多了,结果却恰恰相反,在晚上的闲聊中,他尽然能把操作系统、网络、数据结构等基础课程从头到尾说得清清楚楚,简直让我这个刚从校园出来的学生惭愧得无地自容。分析下来,他能把这些技术细节“记”得这么牢,是因为他抓住了这些基础知识的精髓,在学习和实际工作中用结构化思维来提炼这些知识点,抓住了这些知识点的内在联系,使得学习不再是了解其表面的知原创 2009-11-02 22:17:00 · 6182 阅读 · 0 评论 -
一次架构设计的摸索
最近部门安排我参与一个后台计费系统的项目,作为架构设计人员,这一两周的主要工作就是推演PD的UC和相关的架构设计,一个阶段的工作下来有了些心得。这种非底层技术性项目的架构设计最关键的是业务架构设计,对业务的把握是所有架构因素中最重要的因素。项目最开始我把精力放在了如何用些花哨的模式搭建可扩展性强的框架,可后来逐渐发现这些不是大家最需要的,大家最需要的是通过技术实现的角度把业务上的各种需求整原创 2009-11-02 21:06:00 · 3487 阅读 · 1 评论 -
如何激发思考
越来越发现没思考就没有进步,忙碌的工作非但不能让你沉淀起来,反而会让你因为失去思考而变得空乏。身边不乏拼死工作却没啥突破的例子,也包括自己,问题关键就是与是否学会了思考。最近一直在思考这么一个问题,如何激发思考,如何使自己在千遍一律的工作中找到突破口。找到了一些思路和方法,总结如下:1)when---何时需要思考每天早上工作之前,安排当日的工作每天晚上给自己10分钟安静地想想当原创 2009-09-20 15:24:00 · 4294 阅读 · 3 评论 -
走向架构师之路---开博寄语
一个小手术让我在医院躺了16天,开始几天很烦躁,正是项目大决战的时候,而我却临阵退缩,有力使不上。后来几天,慢慢的开始思考一些问题,回顾了几年来做程序员的历程,回顾了出来工作的两年里的前前后后,也展望一下今后要走的路,感觉有么一个安静的环境和宽松的时间让自己好好思考一下挺好。 也就是这段时间,自己学会了思考,只有思考才能让读的书、写的代码、工作中的点点滴滴成为真正属于自己的东原创 2009-09-12 13:40:00 · 6702 阅读 · 13 评论 -
第一次做项目发布员的一些总结
在以前做钱掌柜的时候就想着做项目发布员,因为做这项工作可以帮助你对整个项目实际运转情况摸得更清楚,但后来还是放弃了,主要是感觉自己比较毛糙,不太适合做这项风险较高的工作。可这次计费中心项目让我没有退路,只有自己可以顶上去。计费中心是个新项目,发布环境和生产环境都为0,难点就在于需要从头开始搭建基础设施。这个项目构建用的是maven而不是以前阿里自制的antx,所以项目结构和构建脚本与以前项目都原创 2009-12-26 10:21:00 · 7505 阅读 · 0 评论 -
由操作系统的存储结构和CAP原则想到架构中的权衡
<br />架构实际上一种权衡的艺术,它的美往往体现在众多矛盾体间的周旋和则中。可以说,没有最好的架构,只有最合适的架构。<br />在一些经典的系统中常常存在多个矛盾因素并存的情况,而这些系统的经典架构就反映出如何解决这些矛盾而相克的因素的方案,比如操作系统的存储结构和分布式系统中CAP原则就是典型的例子。<br />1. 操作系统的存储要达到的目的有以下三个:快速存取大容量单位容量的低成本<br />而这三个目的是相互矛盾和牵制的,存取越快单位容量成本越高;容量越大,存取速度越慢;容量越大,价格越低。既原创 2010-07-18 14:22:00 · 3293 阅读 · 0 评论 -
阿里土话------记录职场经典语录
总是想要证明自己时,就没有了投入工作的心态你感觉不舒服的时候,就是成长的时候自得其乐是一种能力不要太把自己当回事,也别把自己太当回事与其怕失败,不如狠狠地失败一回不要总认为自己比别人聪明心中无敌,方能无敌于天下不要害怕把自己的弱点暴露给他人你自己觉得有,别人感觉不到你有,你就是没有别把沙子放大为绊脚石活力四射是激情,深水静流也是激情快乐和烦恼都是自己给的刚工作几年比谁更踏实,再过几年比谁更有激情不难,要你干嘛?不给失败找理由,要给成功找方向用勇气改变可以改变的事,用胸怀去接受不可改变的事,用智慧去分辨两者的原创 2010-07-12 20:05:00 · 10139 阅读 · 2 评论 -
佳文分享:Refactor and reason for ReArchitecture
经历过大规模架构重构(ReArchitecture)的同学都知道:ReArchitecture是一个极其痛苦的过程,要想将原有的working的代码,彻底地用新的架构,新的技术重新写一遍,其工作量是令人望而生畏的。最复杂的莫过于业务逻辑的梳理,如果你有精力将原有的代码从头读一遍,那是最lucky的事,但大多数情况下,别人写的代码需要你自己重新写一遍,大多转载 2010-05-06 14:56:00 · 2432 阅读 · 0 评论 -
面试别人实际是在考验自己
最近开始参与面试工作,发现面试对于考官而言是个不小的挑战,需要考官在短短一小时之内能引导面试者把其最真实的特点表现出来。一个成功的面试并不是出一些刁难的题让面试者陷入困境,而是通过来来回回的较量和观察,把其最真实的优点和缺点发掘出来。直接问别人优点和缺点是很傻的,面试者大多都会准备这样常规性问题,他的回答也肯定有特定的修饰,他的特点、优点和缺点不是他直接告诉你,而是你在一问一答中发掘出来。原创 2010-04-09 08:45:00 · 3220 阅读 · 3 评论 -
做好PM的几个关键事项
在项目过程中,通过观察,感觉做好PM这个角色需要做好以下几点:对项目关键点的细节要足够了解虽然PM可以不参与具体的编码工作,但并不等于不需要了解具体的实现细节,特别是一些影响项目成败的关键点。有些PM离技术越来越远,远到一些功能是怎么实现的、用的是什么技术、有哪些地方需要特别注意都不清楚,这会非常影响他的决策力和判断力,特别是在处理突发事件时会手足无措。在现阶段,特别是项目规模不大原创 2010-04-03 20:29:00 · 6255 阅读 · 3 评论 -
关于C3P0容错和自动重连特性的研究
最近常有数据库和网络设备升级和搬迁等事情,而各个应用都是基于数据库连接池做的,大部分都是基于C3P0,数据库或网络状况的变动都会导致客户端连接池中的connection失效,如何剔除这些blocked connection就和C3P0的各个配置息息相关。这两天,搭了个实验环境,根据C3P0的配置说明和实验结果,把C3P0关于这块的机制解析了一番。先看看我的结论:1)C3P0容错和自动重连与原创 2010-03-27 11:28:00 · 13681 阅读 · 2 评论 -
文档形式的变化带来的改观
在以前的项目里为了写作方便,总是以word文档的方式提供架构和设计文档,带来的好处仅仅是自己写作起来较为方便,但带来的麻烦却有很多,比如:更新文档较为麻烦。他人浏览较为麻烦,特别当需要从docx转换到doc的时候。很难形成与其他文档的联系。难以协同合作以上的缺点导致很不好的后果:设计有了更新却懒于同步到文档里,他人也不愿看文档,干脆直接来问设计者,文档支凌破碎,写文档成原创 2010-01-09 11:03:00 · 2905 阅读 · 0 评论 -
如何保证架构设计的稳定性------项目前后两次架构设计对比
计费中心一期已做完,今天重新根据已开发的代码画了下类图和时序图,发现和项目开发之前画的有了很大变化,这说明之前的架构设计缺乏稳定性,经不起开发细化过程中的推敲。因此有必要对比一下改动点,吸取经验,争取在下次做架构的时候考虑更全面。下面以周期性批价计费这个场景为例,首先看看开发前的类图:再来看看开发过后的类图:通过对比发现存在以下问题:没有高类聚导致没有低耦合。开发前的设计没原创 2009-12-29 13:39:00 · 7027 阅读 · 0 评论 -
职业方向的选择
在阿里技术人员的发展一般可以有三个方向,项目经理、架构师和专家。每个方向之间不存在好与坏的可比性,每个方向走下去都是一片广阔的天地,关键看自己是否适合,只有适合自己才能走得顺畅。进入阿里后我就一直在思考这个问题,只到最近我才下定决心,准备走架构师这条路。 这三个方向对人的要求是不一样的:1)项目经理需要有很好的项目把控能力,要善于制定目标、协调资源和领导团队,另外需要特别原创 2009-09-12 14:20:00 · 6366 阅读 · 6 评论