Another Java Geek

其实我不是geek,我和你一样,我是凡客

正在浏览 未分类 里的文章

在NodeJS的API文档中对process.memoryUsage()描述得比较简略: Returns an object describing the memory usage of the Node process. 返回对象如: { rss: 13496320, vsize: 63582208, heapTotal: 3897728, heapUsed: 2912788 } 这几个字段的含义如下: rss —— Resident set size, 进程当前占用的物理内存的大小(单位bytes,下同) vsize —— Virtual memory size, 进程当前占用的物理内存和硬盘交换区大小之和 heapTotal —— V8引擎的堆内存总大小 heapUsed —— V8引擎正在使用的堆内存大小 这几个字段的关系: rss < vsize heapUsed < heapTotal < vsize 从左至右被包含。 当使用top查看进程信息时,VIRT相当于vsize,RES相当于rss。实际上,rss和vsize是调用系统的 /proc/[pid]/stat 得到的。 [...]

周日拿同事的卡去听了上午场和下午的互联网产品研发改进之路。其中上午前两场:领域驱动设计(Domain Driven Design)和Ceylon语言,和我们关系不大。着重说说“Twitter性能优化原则”和“互联网产品研发”的感受。由于是回去后根据记忆写就,想到哪写到哪,某些细节可能跟现场有出入。 来自Twitter的总工程师和架构师、Ruby牛人Evan Weaver分享了Twitter在性能优化方面的经验。Twitter从最初一个小规模的应用快速流行,用户规模呈指数级增长,网站吞吐量也相应地不断增加,然而其硬件规模的增长幅度要缓慢得多。Evan指出,Twitter系统吞吐能力的提升不是通过添加更多的硬件来达成,而是靠性能优化来实现。有以下几条性能优化原则: 1.Just do less. 做得越少越好。 当然这不是教人偷懒,而是非常明智的tradeoff原则。这不仅适用于性能优化,也适用于产品演进。在面临众多候选的产品特性时,拒绝大而全的诱惑,将精力聚焦于那些关键的功能特性上,做到少而精。Twitter自始至终坚持140字的短消息,没有扩展到1000字、10000字用于写长篇博客,用户关系是简单的follow和被follow的关系,没有扩展成SNS那种复杂的关系。Twitter的成功也说明了这条原则的正确性。 2.Focus on memory. 关注内存的使用。 由于Twitter所有计算的开销都不大,而包括对象分配、Cache等都要占据内存,因此内存成了关键资源,Twitter的很多努力都花在内存的使用上。Twitter的技术方案是基于Ruby on Rails,关于Ruby的GC,Evan讲了很多,Twitter内部自己实现了一个Ruby的垃圾收集器(Garbage Collector),名叫kiji好像。其垃圾收集算法跟Java的类似,不过似乎比Java的简单,堆内存分为Longlife Heap和Eden Heap,Longlife Heap相当于Java的Old Generation或Permanent Generation,Eden Heap相当于Java的Young Generation中的Eden Space。 3.Let code make informed decision. 让代码去做假定。 关于这一点,我的理解是让代码在访问数据之前对各种可能的情况先做假设,而不是等到所有数据收集齐备再做决定,这样能够更快得做出响应,进而提高吞吐量。 4.Explicitly access bulk data. 以明确地、批量方式访问数据。 除了这几条原则,Evan讲了Ruby垃圾收集器和Twitter的数据存储层。GC刚才已经提了,数据存储用的是MySql,分为4块:Twitt按照id分区;索引按照user分区;Cache采用memcached;还有timeline pool(这个没搞明白)。这4个部分是通过Rails框架来进行衔接的,看来Ruby on Rails还是满强大地。 ——————————————————————– 来自淘宝的芷薰讲述了互联网产品发展过程中的问题和应对策略。芷薰是过程改进专家,关于过程改进,我们尚没有这种职位,似乎淘宝(阿里)有一个很大的部门在做这项工作。感觉这些内容都是我们似曾相识,和我们的工作息息相关的。 关于如何保持团队的持续创新问题,淘宝的办法是让团队感受到使命感和危机感。淘宝产品相关的数据,如PV、活跃用户数、交易金额、社会价值等,让每个员工每天都能够很容易地见到,而且淘宝在一开始就在全公司推行一种以业务(business)为中心的思考问题的方式。 在产品研发进化方面,芷薰分享了淘宝的10条策略,分别应用于3个不同阶段,由于信息量比较大,我记不太清了,有些理解得不是很透彻,根据印象简单记一下: 产品初期 (在某个产品线的一开始,是没有产品、研发、运营等职能区分的,所有成员都在一个开发团队中工作) 策略一:采用Scrum快速迭代。 策略二:包容原则——缺陷容忍和一票否决。不要求零BUG,某个版本哪怕还有很多BUG没解决,由所有团队成员共同评审,只要评审通过就可以上线;只要有一个人对某个BUG提出反对意见,就取消上线。 (随着产品演化和团队规模扩大,会从开发团队中抽调人员组成产品团队和运营团队,团队保持10人规模,如果超过10人则继续拆分) 策略三:资源协调。随着产品需求不断增加,要开发这些功能,会造成对各种资源的争用。因此每月会召开资源PK会,各个项目经理PM对要实现的功能需求及资源占用进行PK,确定优先级。 产品发展期 策略四:自动构建、持续集成。虽然自动构建越早越好,但是根据经验,在产品初期,很多东西面临快速变化,一开始就推行自动构建,则团队成员修改压力非常大,效果不理想。所以到了一个相对稳定的阶段再推行自动构建、持续集成。 策略五:培养项目经理PM。在产品快速发展阶段,团队规模膨胀,一个产品经理要和N个开发团队打交道,沟通成本非常高。因此培养一批项目经理来分担沟通协调职责。 [...]

写下这个标题,绝非危言耸听,实际上,更准确地说,应当是:我们制造的问题和我们解决的问题一样多,甚至更多,然而许多人却把制造新问题当成了问题的解决方案。以下是几个例子。 场景一:在某服务端程序里,由于性能的至关重要性以及程序执行效率的低下,cache成了支撑系统正常运转的最后一根救命稻草。面对这个问题,你会怎么办?很可能你会说改善程序的执行效率。然而cache不正是改善效率的一个常用手段么?正是这样,由于严重依赖cache的既定事实,每一次升级,无论是修改代码还是部署上线,整个团队所有人都必须对cache关怀备至、照顾有加,以便在升级切换的过程中,新版本程序必须能够读取老版本写入cache的数据,否则系统就有瘫痪的危险。也许你已经看出来了,这个问题的规程解决方案就是确保它一直存在(从而推迟灾难的爆发)。 场景二:某产品特性在现有的系统架构下难以有效实现,而且以后还会增加更多类似的新特性。解决这个问题的方案有:1.调整系统架构,从而一劳永逸地为以后的升级提供方便,但这是个伤筋动骨的活儿,成本大收效慢;2.改变需求,以某种权变方式来实现,见效快但会在系统中留下长久的硬伤。也许你会选择方案1或者结合两个方案采取某种折衷方式。但在实际中,人们倾向于采用2,并且一旦实现新特性,就会忽略并遗忘硬伤,且此后会如法炮制。于是在浑然不觉中伤疤变得越来越大,严重影响系统的健康状况和组织的工作效率。 场景三:前人的一个临时决定,历经传承,被后来者当成理所应当的规范加以执行。由于种种原因,后来者已难以(也没有意愿去)弄清前人当初的意图,只好把前人的成果当成黑盒,面对日益暴露的诸多问题,后来者使用了一系列手段——其中不乏临时决定——对黑盒的外在表现加以纠正。又历经传承,这些成果被“后后来者”接手,同样,“后后来者”已弄不清后来者当初的意图,于是……此后的结果想必你已经能够猜到。子子孙孙无穷匮,冤冤相报何时了! 这些场景也许不具有普遍性,但在我们生活的日常环境中也绝不罕见。每每思虑此等现象背后的原因,似乎总能归结为人的愚昧、短视和懒惰。但,怎样才能走出这种困局呢?

在winxp系统上chrome浏览器中使用google,搜索结果页底部的翻页区,赫然多出了<b>…</b>标签,留个纪念: 另外,还是在winxp系统的chrome浏览器,使用智能ABC输入法,在任一网页的文本框中输入,会导致chrome崩溃。 PS: chrome版本是 7.0.517.44

又到了一年一度的校园招聘高峰期,广大莘莘学子们也开始为找工作而忙碌了。遥想五年前这个时候,我也在经历着同样的过程。记得刚开始找工作时,最郁闷的是,许多企业招聘的职位都要求有工作经验,而这对应届毕业生来说多少有点强人所难。无怪乎网上有人讽刺说“招聘应届生要求有工作经验”如同“娶媳妇要求新娘有生孩子经验”一样荒唐(工作久了才发现比这更荒唐的事多了去了)。诚然,一定的工作经验,是胜任某些工作必不可少的条件。可笑的是,许多用人单位简单地把“工作经验”等同于“工作经历”或“工作年限”,比如JD上常见“至少2年Java开发经验”、“1年以上销售工作经验”等这样的任职要求。把工作年限作为胜任工作的一项硬性指标,反映了某些企业选才制度的盲目性。 我们知道,有很多人在没有经验的情况下从事某项工作,却取得了不凡的成就。罗伯特·鲁宾就是一例,他原是高盛的资深合伙人,曾做了美国克林顿政府的财政部长,后加入花旗集团。他的自传《在不确定的世界》讲述了他职业生涯的历次转型:当他刚加入高盛公司时,“在不清楚一个从事套利活动之人会做什么的情况下开始了第一天工作”,此后一度成为一名出色的套利商人。他刚加入克林顿政府时,在没有任何政界工作经验的情况下接受了新成立的经济委员会主席一职,他干的很棒,此后当了财长。从他的经历可以看出,没有相关工作经验同样可以胜任一项工作。然而还应当注意,他在职业转型初期,虽然没有相关领域的直接经验,却具备很高的专业水平和素养。 在有些情况下,已有的工作经验反而会成为新工作中的障碍而不是助力。尽管这一事实普遍存在,但却并不是显而易见的。因为人们倾向于认为那些经验更多(换句话说工作年限更长)之人的所作所为更加有道理,假如那些有经验的人刚愎自用,那么往往在造成很严重后果的情况下,容易得到别人的谅解而不会受到谴责。若非具备充分的自省和警觉,大部分人在面临新情况、新问题时,都会受到既有思维定势的影响,从而做出不合时宜或完全错误的判断和决定。 说了这么多,并非想证明工作经验无关紧要,只是指出职场和社会对“工作经验”的误解和过分强调。工作经验是一个人在从事某种工作过程中,自身所形成的解决特定问题的智慧和素养。这些“智慧和素养”的形成因人而异,它对于解决相同领域、乃至不同领域的问题非常有帮助。由于对这种“智慧和素养”的判定难以量化,所以人们通过“工作经历”和“工作年限”来间接考查这种素质。遗憾的是,由于缺乏智慧,不少企业、不少招聘者只注重“工作经历”和“工作年限”,而忽略与此相关的“智慧和素养”。

发现一个很好玩的网站,可以将任意一段文字转换成读音,包括中文。网址如下 http://www.sitepal.com/ttswidgetdemo 可以选择Language为Chinese,随便复制一段文字贴到右边的文本区,点”SAY IT”,几秒钟后就可以听到纯正的普通话发音,cool! 在Voice下可以选择不同的声音,其中有粤语等不同地区的发音。还可以改变声音的效果。 这个免费的demo限定只能输入200字符以内,中文我数了下最多50个字。

上午去听了下易观移动互联网年会,听了一半,忘了一半,还有一半没听懂。趁着还有些印象,做一下总结,只听了上午场,下午没参加不甚明了。 1.按照日程安排,8:00签到,9:45开场就有抽奖,为此我还早起了一小时,但赶到会场已经快8:30了,原定的开场时间和抽奖,主办方以工作人员在路上堵车而推迟,不守时永远是普遍现象啊。好在有报纸和一些宣传资料打发时间,通过这个也了解到移动互联网的范围和从业者远远大于自己所了解的范畴…坐进观天了一把,呵呵。 2.先是主办方易观国际的致辞和移动互联网的一些数据报告和分析,基本格调是移动互联网形势一片大好,前景乐观之类。 3.接着是一个日本人演讲,用的是英文,我基本没听懂。大意是拿日本和中国的移动互联网各方面对比,今天的中国就是5年前、10年前的日本,日本的今天就是中国的明天。日本的移动互联网现在已经全面超越有线互联网。 4.创新工厂的汪华自称是移动互联网的信徒,演讲内容很是全面,把移动互联网的各个方面都分析了一遍。只记得这些:a.目前中国互联网用户是3亿多,而手机用户有8亿,所以移动互联网的潜在市场是很庞大的。b.互联网的发展分为三个阶段:基础设施的完善,系统、平台、浏览器等;用户的娱乐需求,音乐、游戏等;生活方式转变,电子商务等。这个过程,有线互联网经历了10年,而移动互联网预计3年多就可以完成。目前移动互联网尚处于第一阶段。c.HTML5能够通过游览器完全实现客户端功能,天然跨平台,其普及将会消除各种手机系统平台的差异,大大降低应用开发的难度和成本。 5.蔡文胜的演讲颇为搞笑,除了其闽南话的发音,说话方式也很有趣,并时不时地提到汪华。他认为未来移动终端是多样化的,像ipad就是一例,移动应用也应该支持这类终端。他讲了一个观点:大家一定要省吃俭用去买一个ipad,亲自用过了那种感觉是不一样的,那样有可能找到一些灵感和突破口(——这话不无道理)。还特别强调自己的使用体验:ipad能够1秒钟关机,无须等待。现场有不少人通过微博拿蔡文胜开涮,并且在汪华演讲时,多条微博力挺他上场,这也看出他的粉丝众多,不过我却是第一次知道此人(和很多其它嘉宾),汗。 6.联想的演讲感觉很差劲,我基本没听(也许我不该这么说,出于支持国产的理由)。 7.上午最后一个环节是互联网专家刘兴亮主持的问答,参与嘉宾有3g门户、TCL、数字天堂和新浪无线的老总。我比较感兴趣的话题有两个:一个是数字天堂董事长提到无线中间件(手机中间件?),就是在移动终端操作系统和应用程序之间增加一层,在不同的终端上对应用开发提供统一的API,屏蔽终端的异构性。二是个人开发者在移动互联网大潮中的创业机会,对这个问题,几位嘉宾的观点都很实在,认为个人开发者要想赚钱,机会是有,但能够成功的毕竟是少数。而这个机会基本就是要借助大公司的平台,诸如App Store以及Android Market之上的应用。另外,主持人问“无线互联网产业能否最终超过有线互联网”时,几位嘉宾的回答也很耐人寻味:3g门户的张向东认为1年半之内用户规模将会超越,相当乐观,当然这一点也比较符合实际;TCL的肖锋认为永远也不会超越,这也比较符合TCL传统企业特点;数字天堂王安似乎也不认为能够超越,有点意外;新浪的王高飞认为5年后可以超越,介于激进和保守之间,正如新浪的媒体企业定位介于3g和TCL之间一样。刘兴亮本人认为最终可以超越,但是不知道得等到何时。 8.在会展期间,现场有发微博抽奖活动,奖品是手机还有阅读器。禁不住抽奖的诱惑,也为了跟上移动互联网的潮流(做移动互联网却不用微博,又土鳖了一把),我在现场用手机试用了一把新浪微博,不过登录过程中发现,新浪微博的密码框输入的字符竟然是明文,不是用**隐藏,在会展场合下也太不安全了。

几乎所有的软件系统都有这样那样的Bug,如同几乎所有的组织机构都存在这样那样的问题和矛盾一样,很自然地,修改Bug对程序员来说是家常便饭。改Bug最主要的困难不在于如何修改,而在于去查明Bug产生的原因。有时候,我们花了好几天时间来跟踪调试某个Bug,而最后仅仅用几行甚至一行代码就可以搞定。所以,程序Bug,一旦查明原因,解决起来便是顺理成章。而当跨组织跨部门的Bug出现时,情况便截然不同。 假定在一个IT公司,有系统组、数据组、应用组等几个组(或部门),分别用S(System)、D(Data)、A(Application)来代替。用户U在使用过程中遇到了一个问题,反馈到A组。A组一查,发现是某条数据存在问题,于是反馈到D组。D组一查,发现是由于一个系统错误导致数据有误,于是反馈到S组。S组一查,发现这个系统错误是正常现象,无法预测。于是A、D、S几个组僵持不下,陷入拉锯战:A说这是数据问题,应该由D组确保数据正确无误;D说这是系统错误引起的,应该由S组解决;S说这个错误无法避免,应该由D、A组自行检测异常,剔除错误数据。 我们可以看到,在这个例子中,问题的原因是显而易见的,而要解决这种跨组织的“Bug”却非常困难。这跟单个程序员解决程序Bug时难查错易解决的情形形成鲜明对比。 遇到这种情况,我们总是把问题归结为相互推卸责任,并倾向于指责别人。可事实是,我们自己也处在这种怪圈之中,当我们在指责别人推卸责任时,自己又何尝不是如此呢?遗憾的是,很多人都把目光聚焦在别人身上,对自身的问题却视而不见。《技术领导之路》作者温伯格在书中指出,“看不到自己”(self-blindness)是解决问题的第一大障碍,“不能从旁观者的角度认识自己是个人发展的第一大障碍”。 在刚才的例子中,如果A、D、S组能从旁观角度审视一下局面,并首先在本组力所能及范围内对既已发现的问题进行修复,那么将会出现另一幕情形:当S组查明那个系统错误时,发现不能预测,但在出错时,却能够检测和报警,于是制定检测报警方案,着手实施并告知D、A组;D组得知S组的检测报警需要一定时间才能生效,于是增加数据合法性校验机制,并将已经出错的数据清理掉,告知A、S组;A组在应用层增加一个小特性,当用户使用中再次出现同样的问题时,给出一个友好的提示,并通知D、S组,将问题及处理方案记录到Bug系统以供其它人查阅。 不过这是理想状态,现实环境远比这要复杂得多,也并非“看不见自己”能够完全解释。即使我们能看见自己,又怎能保证别人也同样能看见自己呢?

工作至今,算下来已满四年,在企业软件和互联网行业各做了两年。从事一个行业,2年时间太短,也许只能算是入门,甚或连门儿都没入。不过,我仍然想来对这两个行业做一番比较。因知识经验不足,难免失之偏颇,贻笑大方。 1.企业软件的服务对象是各行各业的大企业或中小企业客户,比如电信业、金融业、医疗业、零售业等等。而互联网一般是服务于普通个人用户,用户群通常并无显著的行业特征,比如使用搜索引擎、社交网络的用户,你很难把他们归入某一行业或职业。 2.企业软件公司的发展过程一般较为平坦,很少听说哪家行业软件公司一夜暴富,而互联网上的创富神话依然在继续。 3.正因为企业软件的成功很难一蹴而就,所以在各个行业的企业软件领域,市场地位一般都是由少数几家巨头牢牢把持,小公司短期内难以撼动。在互联网行业,虽然也只有那少数几家明星公司位于聚光灯下,但今日的霸主明日很可能会衰败,昔日的小弟今天俨然已气象万千。这可以从三大门户的沦落,开心网的异军突起中可见一斑。 4.所以某个行业的企业软件,如果能坚持做下去,基本上处于一种饿不死,也轻易发不了大财的状态。而互联网行业,除了少数几家功成名就的大公司,其它的基本上都可以算作创业型公司,一将成名万骨枯,成功了,要啥有啥,不成功,生存维艰。 5.互联网公司,一般是技术驱动型的,相对于企业软件,其技术革新是比较快的。而企业软件公司,在技术方面,一般多是采用业内比较成熟稳定的方案,技术的更新换代相对缓慢。 6.企业软件公司的产品(或产物),由于通常最终需要交付给客户,主要由客户来运行维护,且其发展历程相对较长,从而容易形成一套比较规范的开发流程和方法。所以我们有时看到某某公司通过CMM5级认证(是否真的达到另当别论),基本都是企业软件公司。互联网公司的开发和运维一般都是内部搞定(可能是由不同的团队执行,但都在同一家公司),且发展历程相对较短,所以其开发过程的规范性比较差。不过话说回来,大部分互联网公司都是startup,生存尚难,要是也搞规范,效率势必受损,如何干得过大公司,活得到明天?即便大公司如百度、腾讯等,也没听说哪个通过CMM*认证(反正我不知道,有知道的跟我说一声)。互联网公司是结果导向的,对这种认证并不看重。 7.互联网应用的数据和用户规模一般都是海量的,数据量动辄过亿,用户数动辄百万千万,且要7×24小时提供服务,所以,对性能和稳定性的要求比较高。企业软件的数据和用户一般仅限于一家企业内部,关键业务数据量达到千万级算是比较高了,典型企业的员工数少则几十人,多则数万人,几十万人以上的企业非常少,所以性能通常不是太大问题,企业软件更加关注的是安全性和可靠性。 8.企业软件最典型的应用形式是MIS系统,此外也会借鉴和吸收一些互联网的应用形式,比如论坛、IM、blog、wiki等这些曾经属于互联网的应用也逐渐被企业软件所采用,这些作为点缀能为企业软件增加一些卖点,不过其实用性值得怀疑。在互联网公司,也许其产品和服务具有不错的用户体验,但是在公司内部的信息化方面反而比较滞后,甚至一套供内部人使用的、像样的MIS系统也比较少见,形成一种反差。 9.在企业软件行业,PM通常是项目经理(Project Manager)。而在互联网公司,PM一般是指产品经理(Product Manager)。在我看来,这两种角色的地位和职能大致相当,只是在不同的公司可能会不一样。 10.企业软件的盈利模式基本还是卖拷贝、卖服务。而互联网的盈利模式基本还是以免费吸引用户形成规模效应,而后依靠流量来卖广告,新的盈利模式基本还处在探索阶段,像app store这种成功的模式又很难被复制。 11.企业软件和互联网的融合,就形成了SaaS,这方面的著名厂商是SalesForce(言SaaS必谈SalesForce),国内的阿里巴巴也是SaaS的代表。

作为程序员,不可能一直开发新系统、编写新代码,维护老系统在所难免。因为新系统开发完了,总要有人来维护,不是自己维护,就是别人维护。从维护的角度看,我们不是维护自己的代码,就是维护别人的代码。 维护工作在软件产品的生命周期中占据了绝大部分时间。可实际上,维护工作时常陷入困境。相信很多维护人员曾遇到过维护工作难以进展的局面:代码难以理解,BUG无从调试,坏味道四处弥漫,系统故障频频,一个小的逻辑改动要扩散到很多个模块, 新功能需求的开发让本已遍体鳞伤的系统雪上加霜。 不少程序员在这种情况下苦苦挣扎并逐渐习以为常,初临此境的人试图通过重构扭转局面,最终发现势单力孤而放弃一腔热情。 为什么会形成这种局面?我觉得最主要的原因是,在系统开发和维护的各个阶段缺乏良好的设计所致。设计并非只发生在系统开发的初期,在上线以后,每一次的功能扩展和需求变更,都伴随着某种设计决定,不论是有意识的还是无意识的。不良设计的产生可能有两种情况:一种情况是开发人员和技术负责人不知道什么是好的设计或误用设计原则,从而在无意间做出糟糕的设计决策。另一种情况是在任务进度压力下,开发人员选择了短期内易于实现但对长期有害的设计方案。而组织架构层面的问题也是滋生这些弊病的土壤:一些中小型IT公司没有训练有素的架构设计人员,设计决策完全是由经验相对丰富的开发人员或技术负责人做出;没有QA及例行的代码复查机制使得隐藏的问题长期得不到暴露和纠正的机会。 不良设计是一种技术债务,如同真实债务会产生利息一样,技术债务问题如果不能及时改善,会持续增加后期维护工作的成本。 技术债务在实际工作中是难以避免的,就连在ThoughtWorks这样一个面向对象、重构、敏捷思想领袖们的聚集地,也同样存在令人忍无可忍的代码。 虽然无法避免,但也并非毫无办法。很多人希望通过重构来改善烂代码,但重构应当是常态,而不该是特例。系统每一次升级维护,都意味着对原有设计的改变,这正是适合重构的时机,也许早期的设计适应当时的需求,随着功能扩展和新需求的开发,如果设计不能与时俱进,那些缺陷代码会像散落在角落里的垃圾一样慢慢腐烂变质,腐蚀周遭的环境。与其等到代码破败不堪、臭味不断时才进行重构,为什么不提早在日常维护中通过小的重构来分散负担减轻成本呢? Martin Fowler在一书后面说明了开发人员不愿进行重构的几个可能原因: 1.不知道如何进行重构 2.如果重构的效益是长期的,到时我可能已走人了从而分享不到好处,现在干嘛要付出努力! 3.开发新功能已令人很头疼了,我才懒得重构,老板又没要求,只要功能实现就行 4.重构可能会破坏现有的功能,做好了也没好处,可万一出问题谁来扛? 重构难以开展的原因也可以看看这里。 重构并非银弹,当代码已腐朽不堪时,进行重构的难度和成本也会大大增加。 有句话说出来混尽早要还的,程序员如果不能加强手艺而进行有益的工作,早晚会尝到有害工作的恶果,并在与其斗争中精疲力尽。