他们为什么说面向对象有问题,探讨面向对象的一些缺陷 最近跟某位朋友讨论了一些工作上的事情,他目前就职于某世界500强IT公司,在他们现在做的一个项目中,整个系统构架(基于Web)是完全面向对象的(非基于jQuery的传统WEB,完全OOP,到处都是class,extend, override),而且他对这种框架极其推崇,不过他们经常加班到深夜,打开他们开源框架的GitHub主页,一个知名IT公司做的纯OOP前端框架仅仅有100多个Star(关注),笔者当时从直觉上觉得这里有问题,回去之后仔细反思,搜索了一些资料,算是找到了他们为什么这么累的原因吧。
面向对象(Object Oriented,OO)是当前计算机界关心的重点,它是90年代软件开发方法的主流,不过随着时代的发展,很多人对OO编程方法的看法也出现了一些变化;
面向对象的可维护性
面向对象从一开始就要求我们完全了解各个子类的不同,并将他们的“共性”提取到父类里,从而实现代码复用, 在这个过程中自然形成了一种最强的耦合关系。这种设计方法在需求非常确定的情况下是有效的,但在实际生活中我们发现需求总是在开发过程中不断提出的,而且也总在变化,甚至跟之前完全相反,当你看到你精心设计的框架成为你需求变更的障碍时,你做何感想?
入静和入世 人有两种思考状态,我将一种称为入境,另一种称为入世。
入静 程序员和作家需要的是一种入静的状态。他们需要整段的,不被打扰的时间才可以工作。一个下午三点钟的会议,哪怕仅仅持续15分钟,一个下午就会因此 废了。问题不是会议占据的时间,关键问题是会议把一个下午分成了两块,让每块都不够大,都不足以入静。因为对于下午废掉的担心,上午的工作也受到影响,不 太敢开始解决真正困难的问题。所以整天都在一种心神不宁的状态。
在足够长的思考这件事情的空余,或许要上一下厕所,在路上遇到同时打招呼,但脑子还在那个状态,打招呼的是谁不记得了,也不想去注意,以免思路被打 乱。然后回到座位上,脑子里其实彻底没有去过厕所的记忆,而继续思考。。。中午吃饭的时候,如果一个人最好,接着在那个状态里。。。或者随便聊点轻松的话 题,并没有大碍,只要不是动脑筋的东西。这样下午可以相对容易的回到短暂离开的状态。因为我们的明意识在放松,潜意识其实还在连续的工作。
这种入境的状态就像睡觉。需要足够长的时间才能进入状态。我想大家都能理解凌晨三点的一个电话对于睡眠意味着什么吧。
信仰是如何毁掉程序员的 我对自己有了新的发现——上天给了我神奇的能力,让我总能做出正确的技术选择。
有些夸张,但的确很神奇。
回首我的开发生涯,我认为我使用的任何一种编程语言都是在当时那种场景下最好的。
同样的,我选择的框架,甚至操作系统也是最好的。
是的,我有这样惊人的能力,就是从技术的海洋中挑出最好的。这些技术我甚至不用亲自试一遍,但我却极力捍卫我的选择。
可能当你在阅读本文的时候,你已经发现了你也有这种神秘的能力。
大多数开发者有技术信仰
这是真的。
不要不好意思,你不是一个人。我,几乎每一个人,都与你同在。
我们有些人已经从这种自我洗脑中清醒过来。另一些人则还非常幸福地并没有意识到我们所处的困境。但是我们中的大部分人至少拥有一个为自己信奉的技术信仰。
谈谈公司内部的技术分享 这段时间,为了促进程序同事间技术氛围,在公司内部组织开展技术分享 会。形式很简单,每两周也就是半个月,进行一次技术分享;分享人由组员顺序安排;题材不限,可以是自己熟悉的技术,比如说服务端的开发者,分享后端定时 器,消息队列等等,前端的开发者分享加载的模式,MVC模式等等,可以是一些通用的技术,比如数据结构,算法,代码风格,Effective 系列,调试技巧等,甚至可以是经典书的读后感等等,抑或是最近大家在研究一个开源的项目,也可以跟大家讲一下这个开源项目的框架;或许有些人利用业余时间 做了一个小软件,也可以拿出来分享。
所谓技术分享,可能很多人觉得是为了让参与者提高技术,对方方面面的技术有一个了解,提高一个广度上面的认识;其实我认为对于分享者的提高会更大。
如何开发不可维护的软件? 我从别人遗留的的技术性债务中获得报酬。在我的日常工作中,我见到了很多难以维护的代码,并且我一次次地看到了很多相似的并可以避免的问题。
我专门从事调试、修改、维护、扩展遗留软件系统这类工作,我的典型客户一般都有一个或多或少可以运行的网站或者软件,但是其开发者都因为各种原因不 再维护了,因为商业需求改变导致软件无法跟上需求;或者我的客户有一些“几乎快要完成”的软件,但是因为预算用光或者计划有变与开发者分道扬镳。通常这种 软件会缺少一系列的功能并有一坨bug。
我那些客户通常被其他程序员告知,需要废弃已有的所有代码从头开始。大部分程序员不喜欢维护代码,尤其不喜欢维护别人开发的代码。当程序员写代码 时,当他们谈论到可维护性时,程序员经常会问一些错误的问题——想了解这种情况是如何发生的,请参看Matt Duvall的文章《可维护性的神话 | The myth of maintainability》。
以下是一些你可以在你自己的软件工程中做的“好”事,因为这些事可以帮我找到活干。
为何程序员完成最后20%的工作需要的时间跟之前的80%一样多? 听过行百里者半九十吧。这句话在程序员的工作中同样适用,到底是为何呢?Matija用一个精巧的比喻揭示了个中道理。
其实这就好比在高峰期从郊外开车回市中心。前 80% 的路程很顺,高速嘛,可能两小时就走完了,但是到了城里,就走不动了,红绿灯,人行道,各种环线和菜鸟司机,可能两个小时还不够用的。
编程也是如此。最开始你要设计框架,给整个项目打基础,然后开始开发,几周或者几月之后,你完成了整个项目 80% 的工作,各种关键模块开始起作用了。
但是好戏才刚刚开始,当你准备好好打磨这款产品时,就会发现许多奇怪的 bug 冒出来了。比如:“喂,你知道这个程序在读取文件时拔掉 USB 线会崩溃么?”,“看起来是程序不想下载文件名里有感叹号的文件...”
做个犀利的码农:如何持续培养/更新自己的开发技能
当你的开发技能到了一定水准,你会偶尔遇到拦路虎:一些短时间内搞不定或理不清头绪的问题。
这是个好事,真的!如果你从不尝试新东西,那当然会发现已有东西对你来说都毫无挑战,这也意味着你没有真的在“求学”。最好的/有价值的学习经历正 是那些拼命搞定某一问题的时光。你极尽所能尝试各种方法并最终找到了解决方案,这就好像你在黑暗中探索,努力拼接出一条成功之路,这种能力在日后也会陪伴 着你。
编程名言名句 下面是一些迄今为止最好的关于编程的名言名句。阅读它们时相信你会有几分愉悦,你可以在一些会谈场合引用它们,一定能为你的团队吸引到不少的好程序员。
UNIX很简单。但需要有一定天赋的人才能理解这种简单。
–Dennis Ritchie
软件在能够复用前必须先能用。
–Ralph Johnson
优秀的判断力来自经验,但经验来自于错误的判断。
–Fred Brooks
‘理论’是你知道是这样,但它却不好用。‘实践’是它很好用,但你不知道是为什么。程序员将理论和实践结合到一起:既不好用,也不知道是为什么。
–佚名
当你想在你的代码中找到一个错误时,这很难;当你认为你的代码是不会有错误时,这就更难了。
-Steve McConnell
在创业型软件公司的收获 我在两家创业公司工作过。A公司,由3人发展到20人;B公司,由20人发展到60人。这两家公司都不算成功,因此,要讲收获,更多的是经验与教训。就如同教材一样,反面教材更加有教育意义。我针对创业公司面临的重要问题,谈谈我的想法。
灵活性
相对于大公司,小公司的灵活性是核心竞争优势。小公司的灵活性,是指小公司船小好调头,能够快速地响应用户。我在B公司时,公司刚好处于创业扩张期(20→60人)。公司也就是在这个时候失去它的核心竞争优势的。
初到B公司,公司的情况是:已经做出了产品,有一些铁杆用户,有投资者表示愿意入股,希望在两三年能够上市。上市,则要求公司在人数上,管理上发生一些改变。我们公司实施了如下举措:
幸福和成功的十条诫律 生命短暂,无可浪费,这我们都知道。然而,大多数人都处中一种缺省状态的生活中,逼迫自己去认为很幸福——虽然事实上不是。为什么?因为我们让社会 来指定该如何的去生活、什么才是成功和什么才是幸福。像金钱和名誉这样的东西被赋予太大的分量,成为祸根,阻碍了我们寻求生活的真正本质:活出自我,做有 价值的事情。
如果让我给一个新生命(比如我未来的孩子)一点建议,我将衷心建议他遵循下面这10条诫律: