Samuel 软件(物流), 生活...Less is more

清除沟通障碍

samuelray — Fri, 16 May 2008 11:05:17 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/193569 发表时间: 2008年05月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近在与刚成立的需求组沟通时困难重重，他们认为我始终是在质疑他们，而我则认为他们的需求随意性太强。于是大家的沟通越来越困难，常常在交谈的一开始就陷入不愉快。但就目前的情况来看，还有更糟糕的事：说一套，做一套。在会议上，大家一致认为应该只满足共性的需求，个性化的需求暂时不考虑。但在实际做的时候，需求组自行判断需求是共性还是个性的，有时甚至没有考虑过这回事。于是我们会就某些需求展开讨论，结果往往是不愉快。具体的原因我还在寻找，当我对需求提出更多细节上的问题时，通常都是不清楚或者很含糊，有时甚至没想到过，现场就开始猜测可能的情况。

我认为这不是个很困难的事，毕竟沟通是工作中不可缺少的一部分。如何沟通是没有正确答案的，我们都要努力寻找最有效的沟通方式。基于目前的状况，我也不急于改变现状，即使我很不满意。工作总是要一步步做的。

第一步，减少磨擦，并寻找沟通的障碍。如果任由这种情况发展，对双方都没有好处。暂时把磨擦保护起来，尽量减少对立。同时双方就沟通方式进行讨论，积极寻找造成沟通不顺的原因。原因找到了，离解决的地方就不远了。

第二步，主动做出妥协。妥协在某种程度上可以称之为失败，但如果在失败之前就做出一些妥协以挽救项目，那么妥协也可以在某种程度上称之为成功。虽然我们确实浪费了一些时间和精力，开发出一些没有必要的东西。但是，从长期来看，为了改变现状，暂时的妥协会带来更多的收益。开始的时候，主动往往比被动要困难一些，一旦做起来，就会容易得多。我们是主动做出妥协，大家都不会有挫折感，士气没有受到太大的影响。同时，我们也取得一定的主动权，要求在下一版本中提高对需求的评审。

第三步，帮助需求组。从行政的角度讲，这不是我们的工作。但从整个团队的角度讲，这也是工作的一部分。需求组工作不得力，必然会影响到我们的工作效率和成效。帮助需求组获取更真实准确的需求，也是在帮我们自己节省时间提高效率。这么做，也从实际行动上对团队精神做了很好的诠释。没有谁可以脱离团队，独自取得成功。

从目前的进展来看，我们的做法确实收到了一些成效，沟通已经比较顺畅。现在最大的问题就是，上头认为做需求不需要软件开发的背景，只要懂业务就行了。这是典型的外行领导内行。我尝试了几次，最终还是没有说服他改变自己的观点。大家有什么建议吗？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

解析运输系统之四 --报表打印

samuelray — Mon, 12 May 2008 14:13:33 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/192224 发表时间: 2008年05月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

业务应用系统都有大量的打印需求，包括交接用的单据，内部使用的作业单，各类报表。Web报表从来都不是一项轻松的活，有时可能会要求更高。就我本身的经验来看，做报表是一件体力活，吃力不讨好。然而，在掌握了一些技巧之后，报表就会变成纯粹的技术问题.我只用过JasperReports做web报表，其它的工具还没有深入研究过，所以这里只以此为例。同时也向大家推荐JasperReports--一款强大的web报表打印工具.

首先就是格式的问题，就算我们只有一个客户，格式的变动也足够频繁了。每一个报表从初稿到最后稳定下来，至少要经过三个回合的沟通。虽然前两个回合的工作有一定的意义，但无疑存在一定的浪费。有人认为这是一个必经的阶段，如果没有前两个回合的半成品，就无法到达最后的成品。开始我也认可这种观点，后来考虑可以用其它的方式来完成前两个回合的任务。第一个回合用纸和笔来与用户沟通，迅速展示和反馈用户的想法，同时推动用户考虑更多细节。第二个回合用Excel做一个报表的原型，包含有模拟的数据，图形，并与用户再次交流。有了具体的原型，交流会非常高效。在这个阶段，90%的问题会被覆盖到，剩下的10%可以通过第三阶段开发时发现并快速解决。

其次是文件格式的问题。有的客户希望是用pdf格式打印，有的客户希望用Excel，有的则更离谱：我两种都要。还要，JasperReports提供了多种格式的报表，把它们封装得很好。现在的问题只是如何处理需求多样性的问题。在跟客户进行沟通之前，我已经有一些方案了。所有打印的地方都有两种格式的打印图标，产生的问题是有些客户只使用一种格式，另外一种格式对他来说就是一种困扰。或者做一个下拉菜单，用户可以选择自己想要的格式打印，同时又不会占用太多的页面空间。这也有一个问题，用户打印的时候必须点两次，而且每次都要点两次。或者就像我们的文本编辑器上的工具栏一样，把PDF图标和提示下拉菜单的图标都做小一点，放在一起。如果用户要打印PDF，只需要直接点PDF图标就可以了，如果想要另一种格式的打印，则要点两次--点一下下拉菜单，在下拉菜单中再点一下打印。这种方式最后被很多客户接受了。其间有一个客户甚至启发了我们把第二种方案做出改进，当鼠标放在打印的下拉菜单图标上时，自动下拉，无须多点一次。

托运单的明细内容。有些客户的托运单只有一条明细，有的有三条。我们最初设计的是不限条数，打出来最少占一张A4纸。客户自然而然会提到成本核算，一定要改成打印半张A4（A8）。我们在做了大量调查后发现，只对格式稍做调整就可以在半张A4纸在可以打印三条明细的托运单，而且可以满足几乎所有的需求。唯一的问题就是如何说服客户接受我们的打印格式，这个确实很困难，不过还是要做。

抬头和企业logo。不同的企业打印出来的托运单都希望带有自己企业的logo和抬头。这一点看起来不难，其实陷阱很多。各个企业的logo大小不同，存储的图片格式不同，企业名称的长度不同，抬头的要求也不同。最后大家都要做出妥协，用户可以修改企业名称在托运单的抬头，不一定非要跟企业名称完全一样。图标的大小限定在一定范围内，存储格式也只限定在三种。而且我们承诺将来做提供更宽松的限制。

套打。这是最麻烦的事！想起来头都是痛的。我们按照单据的普通打印格式提供了相应的套打功能，如果有企业要求我们做出改动，就另外收费，在程序中hardcode。这是我唯一感觉无法接受的地方，即使客户愿意付费，但对我们来讲，产生的价值是非常低的。

关于报表打印的故事还远远没有结束，你也一定遇到过这样或那样的需求，请与我们一起分享，一起进步！

推荐阅读：
解析运输系统之一。
解析运输系统之二。
解析运输系统之三。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

规划职业生涯

samuelray — Thu, 08 May 2008 12:01:37 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/191001 发表时间: 2008年05月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我已经工作了差不多七年，常常会发现自己在过去的职业生涯中规划不足，错失了不少机会。“如果重头再来，一定会做得更好。”这种想法时不时地在敲打着我，我也希望那些刚刚开始工作的同学们能汲取教训，包括工作了好几年的，好好规划自己的职业生涯。

做感兴趣的工作。兴趣是首要条件，可以激发你更多的热情，并长期保持这种热情。如果只是为生存，恐怕很难把工作做好，更不要说再上层楼。

认真负责。我想这一点不需要再多说了，无论对自己还是对别人，认真负责是最基本的要求。没有人喜欢跟不负责的人一起合作，做事不认真只会浪费你和他人更多的时间和精力。

积极主动。这一点的重要性是不言而喻的，积极做好各项工作，并主动承担更多的职责。多做一些是好事，不去计较当前的得失。斤斤计较的人没什么前途。承担得更多，做得更多，更容易得到机会的青睐。

注意经验的积累。经验是向上发展的踏脚石，工作的同时也是在不断的吸取经验。不要轻易转行，那样可能会使你以前的经验贬值。保持经验的不断积累，不断增值。

确定自己的目标。以目前自身的条件和所处的环境为基础，问问自己到底想要什么。每个人都有自己的理想，每个阶段的目标都是你的理想的基石。长期和短期的目标都不可或缺。不要定得太高，那会让你觉得设立目标没有任何意义。但每次都要比上一次的目标要更难以达到，不断挑战自己的潜力。

不断调整自己的目标。在向你的目标前进的时候，有时会发现目标不符合实际，或跟目前的环境有冲突。及时调整目标，让目标变得更现实可行。有时可能偏离了你的最终目标，但只要是向前的，走一些弯路是不可避免的。不要为一时的挫折而沮丧，人总是在经受挫折后才会变得更强。

制定长期计划。在确定你的短期目标之后，一定要制定长期计划。很多人实现自己的目标之后，不知道下一步该做什么，于是随波逐流，浪费时间和生命。长期计划让你始终对自己的行动有明确的目标，同时有效地利用时间和精力。

保持清醒。任何时候都要保持清醒，知道自己做了什么，在做什么，将要做什么。无论是得意还是失意，都是一时的，确保不会因此而失去目标。有时进展非常顺利，以为自己已经打通了任督二脉，于是把目标定得遥不可及。有时又困难重重，觉得永远无法完成任何，于是自暴自弃，彻底放弃自己的目标。这些行为都不可取，保持清醒让你可以继续坚持向目标前进。

爱惜健康。做这一行一定要有健康的身体，就像职业运行员一样爱惜你的身体。有时健康状况就可以决定你还有多大的潜力，多高的斗志。我不建议为了工作长期熬夜，一定要注意饮食，休息，合理的工作强度。

最后，请大家分享一下自己在这方面的心得。分享即共赢！

推荐阅读：
现在就开始。
提高你的效率。
找到你的位置.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

现在就开始

samuelray — Mon, 05 May 2008 11:54:26 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/189655 发表时间: 2008年05月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

千万不要把今天能做的事留到明天。 —— 本杰明·富兰克林

我们总是习惯于让行动晚于计划，不管是工作还是生活。我们总是有这样或那样的借口，让自己的行动一再的拖延，甚至取消。不到最后关头，不愿意去做。为什么现在就要开始呢，总觉得前面重重困难，再看看吧，也许还有别的办法。实际上恰恰相反，很多事情并没有我们想象得那么困难。一旦开始行动，一切都变得简单起来。

拒绝一切借口。推迟行动的理由往往看起来都那么充分：

条件还不成熟。永远没有万事具备的时候，条件还不成熟通常就是你要立刻开始行动标志。比别人先走一步比什么都重要，行进中开火，不断调整目标，你会比预想中更早到达目标。而不是干坐着等待，奢望目标会自动来到眼前。

晚一天也无所谓。一天真的无所谓吗？那么两天又有什么所谓呢？于是，日子一天天过去，而事情并没有减少，反而会越来越多，压得你举步唯艰。那时你就更不会开始行动了。时间总是有限的，晚一天就代表着你失去了生命中宝贵的一天，失去了比别人早一天的机会。一天，足以造成千差万别。

可能会失败。失败是不可接受的吗？比现在就行动更为重要吗？不行动，就不会失败，但也失去了成功的机会。可能会失败表明你现在就要开始做一些工作了。
太困难了。事上无难事，只怕有心人。心理上的障碍远比事实中的困难要大得多，一件简单的事也会因为想得太多而变得复杂。从简单的事情开始，一件件解决，困难的事也会变简单。

这些事很烦。每个人都有不喜欢做的事，但这些事不会因为你不喜欢而减少。你不喜欢做家务，不喜欢购物。但家务事不会减少，反而会越积越多，必须要买的东西也一样，你就会越来越不喜欢这些事，到最后什么也不想干。但如果一开始就行动，事情不会积得太多，及早把这些事做完反而会更有效率。你就会大量的时间来做其它的事。

现在就开始行动。时间有限，不需要考虑得太多。

确定你的目标。明确你要做的事情，把它们一项项清清楚楚列出来，发现有遗漏就立刻补上。这样你所有要做的事情都在你眼前，不会有其它的事来打扰你，也不用担心有什么事会被忘掉。
标记优先级和期限。为每一项事情都标上优先级别，让你很清楚什么事先做，什么事后做，什么事一定要在期限内完成。让你的大脑不必记忆和分析太多的事情。
开始行动。现在就开始做，按照优先级，一件件完成。完成一件，从列表中划掉一项。一天之后，你会发现原来以为很困难的事都已经完成了，而且并没有什么困难可言。

还在等什么？拒绝一切借口，现在就开始！全力以赴，不要给生命留下遗憾。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

解析运输系统之三

samuelray — Wed, 30 Apr 2008 10:40:56 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/188311 发表时间: 2008年04月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

每个业务系统都不可避免要涉及到计费需求，如何解决计费问题总是没那么容易。做得少了满足不了用户的基本需求，一些费用登记不了。做得多了变成一个不专业的财务系统，被使用的可能性极小，通常各企业都有自己的财务系统，财务人员不可能再到业务系统里去做一遍数据。

最常见的托运单都是把费用填在单据中的，而不是单独计费的。例如，运费、送货费、提货费、保费等，五花八门。而单据的明细条目则通常在三条以内，有些甚至只有一条。而费用则是由各个明细条目一起计算出来的，只有一条当然好算，如果是多条的话，就稍微有点麻烦了。因为有些情况下是按整单计费的，没法精确知道各个条目所分担的运费。或者先是按各条目计费，然后把合计的费用再打个折扣或去掉零头。

付款方式多，现付、回付、提付、月结，每个客户可能不同就算了，问题是一个客户可能都有几种付款方式。还好，我们确定下来，一单只有一个付款方式。

怎么处理对账单是一个大问题，处理是不好，就会引发更多的需求漫延。我们决定只做最少的功能--统计对账单。用户按照不同的查询条件把对账单列表显示出来，如果这些都已经对完账了，就直接一次性销账，或者剔除没有销账的记录，把其它的对账单一次性销掉。具体的金额我们不管，你没收到款也好，收不足也好，由你的财务系统来解决。

实际上，这并没有完全解决客户的需求，但是，如果再提供更多的功能，风险是非常大的，往往得不偿失。

总体来讲，运输系统其实并不难开发，最主要的因素还是在人的身上。理解问题的深度，解决问题的技巧，开发实力，跟客户的沟通，这些都是影响项目成败的要素。

推荐阅读：
解析运输系统之一。
解析运输系统之二。
解析运输系统之四。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

解析运输系统之二

samuelray — Fri, 25 Apr 2008 14:24:43 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/186763 发表时间: 2008年04月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

运输公司常常要求我们的系统能够提供一些实时查询的功能，方便他们跟踪客户的货物。例如，客户的某一票货现在在哪辆车上，车大概到了什么地方，是否可以准时到达。而我们的设计则不能直接发映出这些功能，运输公司跟客户交接用的是托运单，司机则拿的是配载单，上面列有详细的货物信息。我们的方案基本能满足他们的需求，但做起来就发现问题多多。

首先，托运单和配载单是多对多的关系，如果你直接去建立他们之间的关系，无疑会复杂化实现。采取折衷的方案会更好，我们把配载单的明细记录和托运单的明细记录进行关系，形成多对一的关系，间接解决了前在提到的多对多关系。再把每次配载的数量写到托运单明细记录中，记录已经配载了多少数量，而不直接关系到配载单明细。

其次，当托运单被配到多辆车上的时候，其状态难以跟踪。一票货被安排在三辆车上，他们的发车时间也许不一样，甚至都不在同一天，到达时间也存在同样的问题。那么在第一辆车开始启程的时候，托运单的状态是否发生变化呢？第一辆车到达的时候呢？好吧，我们只采用最后一辆车的状态来触发托运单的状态，问题又来了：你怎么知道哪一辆车是最后一辆呢？最后我们只好采用最初级的办法，在车辆状态发生变化的时候，判断托运单的每个配载单车辆是否都已经完成了此次状态的变化。都完成了，才改变托运单的状态，否则不做变化。

第三，干线运输完成之后的送货/提货。如果是客户自提，这还好办。送货就麻烦了，一票货分三次运到，运输公司为了减少仓库成本，会送三次货给客户。我们的系统如何处理呢？最后我们决定不处理，由用户自行保管每次送货的收条，送货后再签收回单。当然，这实在不是个好办法，更好的方案可能是由系统根据每次送到的数量生成一张送货单，运输公司打印出来拿着去送货。我们这么做的原则是：如果需求不确定或没有很好的方案，宁可暂时不做也不要乱做。

第四，运输公司的客户对回单的及时性要求很高。运输公司往往在收到回单后用EMS快递回来，然后与客户进行结算。要知道，一旦业务量大，EMS的费用会直线上升。本来我也不想处理这个问题，因为我始终不清楚为什么传真就不行？后来我们决定用附件来解决这个问题，运输公司在各个分站点放置一部扫描仪，把回单扫描进电脑再上传到系统里，他们的客户就可以马上看到回单的影印件，在月底结算的时候再对一次原件。运输公司就可以在月底的时候把一个月的回单打包让自己的车辆拉回来，不再存在EMS费用。

第五，运输公司发货的时候常常会搞错托运单的内容，他们也解释不清楚原因到底在哪。有时候客户都已经收货了，托运单的内容还是要改。这个需求太奇怪了，我们唯一可以做的就是把原来的业务流程开放出一个入口，让用户随时可以修改托运单的内容。这个需求严重影响到我们分析问题的严谨性和逻辑性，真想让这个需求去见鬼！嘿嘿，怕是鬼见了也发愁。

第六，第七。。。问题多得数不过来。每次的需求分析都是在斗智斗勇，不容易哇！

推荐阅读：
解析运输系统之一.
解析运输系统之三。
解析运输系统之四.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

解析运输系统之一

samuelray — Mon, 21 Apr 2008 10:25:02 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/184754 发表时间: 2008年04月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我曾经参与过几个运输公司系统的项目开发，基本上大同小异。他们的业务模式主要分为两类，一类是做干线运输，只做点到点运输。他们的自有车辆比较少，覆盖面窄。如果客户的业务要求运到他们无法到达地方，直接转包给别的运输公司--他们的二级承运商。这种模式的优点是成本较低，运送到达准时率、货物完好率比较高，同时有时间保障。这类公司通常认为中途的装卸会导致破损率升高，且耽误时间。缺点是车辆满载率无法保证，对车辆的调配要求比较高。同时外包业务也存在一定的风险。

另一类是做干线中转业务，他们的车辆比较多，线路覆盖比较广，基本上不会把业务转包出去。通常他们的车辆都是装有多个城市的货物，在中途也需要卸货/装货。这种模式提高了车辆的利用率，覆盖面广，客户的信任度比较高。缺点是成本比较高，对时间的利用率比较低，货物的破损率也相对比较高。

这两种模式都各有优缺点，相信各自的经也不好念。相对来说，第一种模式更有竞争力，这类企业保持了一定的灵活性，转身很快，业务调整迅速，对客户的响应很及时。其实采用哪种模式更好取决于企业的策略，根据自身的特点选择合适的模式，遇到问题时迅速采取相应的对策。

还有一种观点将运输业务分为零担运输和整车运输。根据我们与客户的交流，这两类业务在实际运作中已经没有明显的区分。

开发系统的时候自然要兼顾这两种模式，前者很好处理。难点在于配载单如何处理，配载单中的货物可能是要运到两个或更多城市的多条记录。实现的时候要关注在单点运输的时候不会对用户造成操作上的困扰，在多点运输的时候使用也很方便。我们最初的方案是通过配载单来做中转的装/卸货，先找到配载单然后再对货物记录直接操作。还有一种方案是直接找到要中转装/卸货的记录进行操作。两种方案都可行，关键是实现的时候要让客户更方便快捷。但我认为还有更好的方案，希望这方面的专家与大家一起分享。

在这里我们遇到的最大困难就是无法做到通用的软件，要么各种规则都要兼容，要么就是强制用户遵循少量的规则。有人会说，提供配置选项，根据不同的规则由企业做定制。这个观点看似可行，其实有潜在巨大风险。一旦提供了配置功能，软件的复杂度是一个问题，更严重的问题是需要为客户提供更多的培训和服务，成本无形之中就增加了。

唉，软件，不好做呀。

推荐阅读：
解析运输系统之二.
解析运输系统之三.
解析运输系统之四.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

依赖倒置(DIP)

samuelray — Tue, 15 Apr 2008 14:53:53 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/182917 发表时间: 2008年04月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

所谓依赖，指代码中的耦合。依赖倒置，是相对于传统的面向过程的设计结构而言，面向对象的结构把依赖关系倒置了。

DIP原则：
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。首先高层模块和低层模块都要抽象出来，高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于低层的抽象。高层的实现独立于低层模块不应该依赖于低层模块，而是依赖于低层抽象。同时，低层的抽象和实现也只依赖于高层的抽象.为什么要依赖于抽象呢？因为抽象/接口都是相对稳定的，不会被频繁改动的，依赖是可以信任的。如果都依赖于具体的实现，想想吧，改动一小块代码是多么的困难。试试吧，你会一再地品尝崩溃的感觉甚至开始厌恶软件开发。

抽象不应该依赖于细节，细节应该依赖于抽象。我想面向接口编程已经向大家证实了这个观点，不用过多的解释为什么了吧？难道你吃的亏还不够多！

一些辅助原则可以帮助你更好的运用DIP：

任何变量都不应该持有一个指向具体类的引用。
任何类都不应该从具体类派生。
任何方法都不应该覆盖它的任何基类中已经实现了的方法。

重申一点：任何原则都不是绝对的。有些情况下上面三个原则都是可以违反的，只要你保持足够清醒。例如你依赖于String，我想不会有任何问题。

问题接着来了，如何抽象？
抽象反映高层策略，就是应用中那些不会随着具体细节的改变而改变的规则，常用的词语就是隐喻(metaphore).仔细分析需求，先找出那些业务规则，然后把它们抽象出来形成你的接口。层次化你的设计，常见的方式就是划分出显示层，业务层，持久层，再在每层做抽象。这是最粗糙的层次化，你可以在每层再根据需要划分更细的层次。在实现的时候始终遵循前面提到的原则：只依赖于接口。谁也无法在开始就做到最好，因此要不断迭代，精化设计。

推荐阅读：
开闭原则。
单一职责原则。
OO设计原则。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

大公司与小公司

samuelray — Fri, 11 Apr 2008 14:17:30 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/181762 发表时间: 2008年04月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近常常会听到有人在讲如何如何研究某某大公司的行政制度，薪酬制度，然后再断章取义，把其中的某一部分照搬过来开始在自己的小企业内部实施。虽然遇到了重重困难，但给别人和自己的理由都是非常冠冕堂皇：某某公司就是这么做的。最后就是画虎不成反像猫，吃力不讨好。

我们也常常会看到大公司的管理层常常在谈如何才能像小公司一样灵活敏捷，好像Welch在他的自传中也提到过这一点。

看到了吗？小公司拼命想学大公司，希望变得更死板僵化。大公司则千方百计地希望能变得更灵活小巧，迅速做出反应。

这很有趣，不是吗？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Salesforce与Google App深度合作

samuelray — Tue, 08 Apr 2008 13:40:43 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/180435 发表时间: 2008年04月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Salesforce是一家提供SaaS服务的企业，大概有十年历史。他已经与Google开展了深度合作，同时向他们的客户出售Google Docs服务，当然是集成在他们的系统中使用。现在就有可能存在双方之间的交易--Google会收购Salesforce。

一方面，Google希望把他们的应用出售给一些企业客户，另一方面，salesforce也已经使用了大约41000个Google的应用。如果交易成功，对双方都是有利的。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

浅析技术领导

samuelray — Tue, 08 Apr 2008 10:10:20 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/180351 发表时间: 2008年04月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

关于领导的概念理解有许多不同的解释，这里我要谈的是技术领导。

技术领导的概念不同于管理，通常我们所说的领导就是指管理一组人来完成一项任务，而实际上技术领导是营造一种使他人可以更富有成效，更有效率工作的环境(出自Weinberg)。并不是只有管理者才可以领导，事实上每个人都有领导的才能并发挥着领导的作用。

首先，帮助他人就是帮助自己。对于一个团队中个体来讲，你只有更好的帮助别人完成工作，才会使自己的工作的价值最大化。如果整个团队失败了，个体的任务程度的成功都会变得没有意义。这样的例子我们常常会看到，拥有明星级的开发人员，却开发不出明星级的产品。不只是项目经理要认识到这一点，团队中的每个人都要理解这个概念是非常重要的。

其次，工作侧重点有所不同。由于在团队的角色差异，可能你所关注的重点会有不同。如果你是项目经理，你的重点就是帮助（而不是管理）他人完成工作，这基本上是你的全部工作内容。对团队的开发者，你的重点是把手头的工作完成，同时能更好的帮助他人（这时你也在充当领导的角色）。另一种观点认为团队中任何人的首要任务都是帮助他人完成工作，我始终持怀疑观点。在一些情况下，确实需要如此，但更多的情况下，我们需要平衡。现实中，由于性格或心理上的某些因素，有些人确实不适合帮助他人，同时有些人也确实不适合接受他人的帮助。更有效的做法是依据团队的状况来决定怎么做。先是在团队中推广技术领导的概念，把帮助和接受帮助看做工作中不可或缺的一部分。如果整个团队中的成员都对技术领导有了深刻的理解，心态都比较开放，自然而然，帮助他人就成每个人的首要任务。

最后，勇于面对自我。每个人都有缺点，一些人选择视而不见，聪明人则知道如何面对它。自嘲是我讫今为止面对缺点最有效的方式（你有什么更有效的方式吗），也许我不够聪明。自嘲让我不至于迷失自己，拒绝别人的帮助。如果你总是拒绝，那么你会被拒绝的机率要高很多，这会妨碍你在团队中的领导作用。正视自己的缺点，寻找有效的方式和别人的帮助来改正它，至少要让缺点的伤害减到最低。面对缺点改正它是一件非常困难的事，同时也是非常有影响力的。

关于最后一点，我还想补充的是，可能你永远都不知道别人是怎么看你的，这里有几个选项：
A.不知道
B.知道
C.我不关心

让我知道你的答案！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

开闭原则(OCP)

samuelray — Tue, 01 Apr 2008 15:52:26 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/178463 发表时间: 2008年04月01日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

开闭原则(OCP)是OOD常用的基本原则之一.这个原则首先由Mayer在其著作中提出.

软件实体,包括但不限于Classes, modules, functions,应该对扩展是开放的,对修改是封闭的.换句话说,在极端的情况下,你不需要修改现有的代码,新功能通过子类,重载或通过代理来委托现有代码来完成.这样会防止你向现存的代码中引入bug,因为现存的代码不会被改动就不会产生新的问题.

首先要澄清的一点是:没有100%封闭的代码.封闭一种设计上的策略,并不是指具体的代码.代码体现并趋向于你的设计策略,这不代表代码就是策略.

此模式的关键点在于"抽象".以接口为例,接口应该是稳定的,对修改也应该是封闭的.而具体的实现是开放的,根据需要可以提供不同的实现.这要求设计的时候就要清楚了解用户地需求,判断可能的变化,确定在何种情况下使用及如何使用OCP.

用抽象来实现显式的封闭.接口属于客户程序,而不是实现,它就由客户程序来决定应该是什么样子的.具体的实现规则是相对变化的,但不应该影响到接口的变化.因此,客户程序也不会发生变化.这样就达到了封闭的目的--对接口的修改是封闭的,只要提供不同的扩展就行了.

用数据驱动的方法达到封闭.用数据驱动的方式使各个实现类不必被强制修改从而达到封闭的目的.

一些建议.
所有的成员变量都要设成private.
杜绝全局变量.
减少RTTI(Runtime Type Identification).

推荐阅读:
单一职责原则.
OO 设计原则.
开闭原则。
依赖倒置。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

使用To-Do List

samuelray — Mon, 31 Mar 2008 16:23:33 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/178088 发表时间: 2008年03月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

以前做项目的时候,常常会用MS Project来安排任务与进度.后来改用Excel,记录每天要做的事情,不断地修改它,增加一些条目,删除一些条目,更新一些条目.先是一个人用它,然后有越来越多的项目组成员开始使用它.你可以根据你的项目和团队的情况决定使用哪类工具,小项目通常用Excel就够了,如果比较大的项目,涉及的成员比较多,你更应该选择使用To-Do List.

为什么要用To-Do List?整个团队都在辛苦工作,每个人都很忙,但产品总是无法完成;重要的Feature被遗忘了,需求没有被完全覆盖到,一些人在等着另一些人的代码.有些人不知道接下来该做什么,干等着.这些情况你遇到过吗?To-Do List帮助你解决这些问题.

产品的To-Do List.找个人,项目经理也行,要把所有的Feature用列表记录下来,标上优先级,团队成员从列表中找到他的工作.首先做优先级高的工作,把所有的高级别的工作先完成,在优先级为1的工作分配完之前,不要动优先级为2的条目.这个列表也提供了一个很好的项目视图,每个人,开发人员,项目经理,市场人员,都了解项目当前的状态,随时可以提出自己的疑问或找到答案.这个列表也限制了各个成员不会脱离整个团队的节奏,因为他做的事情是大家都知道并认可的.列表包含有任务时间的评估,大家都知道某个Feature会在大概什么时候完成,不用有事没事都要找人问问.清晰的列表也容易让大家发现潜在的问题,关键任务遗漏的可能性大大降低.列表提高了大家工作的目的性,不会让无关紧要的事困扰.列表也可以反映出需求的变动,列表的改动让需求人员知道他的需求已经被排上日程.对团队也好,整个组织也好,列表让所有人都知道产品现在发生和最近要发生的事情,不会有意外(通常都是头痛的事).

对于个体来讲,列表让开发人员和项目经理更容易沟通.每个人可以制定自己的列表,并与团队的列表保持一致.每天早晨开发人员与项目经理一起回顾列表,看看哪些工作已经做了,哪些是今天要做的,哪些是接下来要做的,并适时反应到团队列表中.对开发人员来讲,你首先要确定自己手头的工作,形成一个列表,与项目经理一起确定任务的优先级.从优先级最高的任务开始工作.如果优先级发生变化,更新列表.工作完成后,把它放在"完成"列表当中.在"任务"列表中添加新任务.如果你是项目经理,列表也同样适合你,只不过多了一项任务--关注团队成员的列表.

有了To-Do List,沟通效率会迅速提高,开发效率也不例外.最重要的是大家都会对建立起信心.至于To-Do List工具,我的建议是选择适合你的团队的,而不是最优秀的.

ATNotes:我最初使用的一款小巧的工具,可以设置显示在桌面上.缺点是功能点太少.
Excel:我用得比较多,可以满足多数情况下的需求.
Google Calendar:Google总能带来惊喜,但不适合不能上网的朋友.

还有很多很好的工具,问google吧.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

做专业开发者

samuelray — Wed, 26 Mar 2008 12:59:08 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/176252 发表时间: 2008年03月26日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

软件开发是一项工作,还是一份事业?它取决于你的态度.以专业的态度对待工作,那么它就是你的事业.你为这之付出,并获得回报.如果你不愿意付出,那么你只能收获痛苦.

不要以为工作只是简单的堆砌代码,完成今天的工作.代码可以从一个侧面反映出一个人的性格和态度.我们都喜欢与专业的人士合作,从而获得更高的效率.你希望与专业的同事一起工作吗?那么就做得更专业一些吧,因为专业的人更喜欢与专业的人合作.

如何判断你是否"专业"呢?

专业的态度.首先是开放的心态,其次是谦虚,还是对事不对人.在团队中大家的目标是解决问题,而不是追究责任.通过彼此合作,相互承诺来共同完成工作.出现问题首先要分析问题出在哪里,如何解决,怎样避免再出现同类的事情.而不是去推卸责任,相互指责,这很没有意义.团队的利益始终放在首位,只有团队的成功才能体现个人的价值.

专业的代码.不要小看代码,它们是企业的生命线,也是你事业的一部分.回头看看你这些年写的代码,如果没有什么值得称道的地方,你现在就要开始加倍努力了.连你自己都不重视你的代码,那么就更没有人重视它们了.
每一段代码都是你专业态度的写照,我想你也不喜欢与代码写得一踏糊涂的人合作吧.怎样写出更专业的代码是一个高深的课题,太多的知识要去理解.OO原则,设计模式,重构,重构与模式都是非常出色的主题.当然Beautiful Code也不例外.

专业的工具.有效地使用工具,不要被工具束缚,它只不过是实现你想法的手段.选择适合你的工具,同时也要注意与他人的工具尽量保持一致.只会使用一种工具可能会妨碍沟通.如果你认为真正的高手是用记事本来写代码的,我要告诉你这也没有意义.真正的高手不在于使用什么IDE,而在于如何选择合适的工具并高效地解决问题.尽可能地使用工具的快捷键.

专业的方法.解决问题的方法有很多种,你知道得越多,选项就越多,通常解决的效率就越高.同时分享你的想法,促进整个团队的进步.

专业的理论.理论与实践是密不可分的,专业的理论升华你的实践,拓展你的思维.通常我们可能都是通过实践或经验找到解决办法,而这些解决办法都是有一定的理论依据的.通过理论来指导实践,实践来验证理论,那么你已经达到了另一个高度.

专业的用语.跟队友沟通要使用专业用语,不需要太多的解释,一个简单的词语就表达出你的观点.跟用户沟通也是一样的.不要故意用一些生疏的词语表现你的所谓的高深,也不要对一件简单的事长篇大论.

专业的工作环境.工作的机器干净整齐,有你需要的工具并且随时可用.良好的目录结构,可以迅速找到你想要的东西.各种快捷方式可以立刻打开常用的软件,IE的收藏夹里有你常去的技术网站(Google应该是你的首页).工作台不一定要整齐,但你知道你想要的东西在什么地方,并可以随手拿到.

如果你还没有做到这些,而又想做得更专业,那么你还有很多事情要做.

推荐阅读:
OO设计原则.
提高你的效率.
找到你的位置.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

点滴乐趣-笑话

samuelray — Thu, 20 Mar 2008 12:51:37 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/174068 发表时间: 2008年03月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

两个犹太人和两个法国人一起坐火车去度假,两个犹太人只买了一张票,那两个法国人感到奇怪,"难道你们不怕查票?"犹太人摇摇头,不再言语.
开始查票了,两个犹太人一同钻进厕所里,然后锁上了门.砰砰砰!厕所门开了个缝,一只手伸了出来,递过一张车票.查票员没有想到里面会有两个人,又把票还给了犹太人.
四个人度完假要回去了,法国人觉得犹太人的办法不错,决定也只买一张票.然后问犹太人这次是不是还准备买一张票,犹太人说:"不,这次不准备买票了."
又要查票了,两个法国人赶忙起身,占领了厕所.砰砰砰!厕所门开了个缝,一只手伸了出来,递过一张车票.犹太人一把抓过车票,向下一节车厢的厕所跑去.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

单一职责(SRP)

samuelray — Mon, 17 Mar 2008 13:17:41 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/172958 发表时间: 2008年03月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Single Responsibility Principle(SRP) 单一职责,是OO原则中的基本原则之一,也是最重要的原则之一.
一个类承担一个职责的全部内容,而且只承担一个职责(Once and only once),并且要做得很好.

每个职责都应该是独立的类,因为每个职责都是变化的中轴.
一个类应该只有一个原因引起变化.
业务规则的变化所导致的类的改变,这个类不应该被数据库,GUI或其它部分的变化强制改变.

怎么去定义职责呢?通常我们称之为类所承担的职责,其实就是引起类变化的原因.如果一个类被两个以上的原因改变,那么就要重新审视这个类的职责,把不同的职责拆分到不同的类里面去.你可能会质疑,这是不是会产生太多的类?类的数量从来都不是个问题.唯一的可能是对代码的理解变得困难.实际上这是假像,分散的代码让你更容易关注自己应该关注的代码,不会使你陷入沼泽.

单一职责就是降低设计上的耦合,这是自然而然的事情.通常一个类太多方法,太多代码,或者太容易变化,都有可能是违反了SRP.

以简单的银行帐户为例,它的职责只包括增加余额,减少余额,获取余额的职责.而余额的增加是通过现金存入,还是转账或是其它方式,都不应该影响这个类的职责,也就是它不会因为现金存入方式发生变化而变化,也不会因为要把余额显示在不同的终端上而变化.

如果发现你的代码违反了SRP,也不要惊讶,重构代码,去除代码中的bad smell.

推荐阅读：
依赖倒置。
开闭原则。
OO设计原则。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

阅读与生活

samuelray — Wed, 12 Mar 2008 17:21:05 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/170595 发表时间: 2008年03月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在我的生命当中,阅读一度占据着重要地位.去年(2007年),我刚出世孩子击败阅读成为我生活中最重要的部分.最近,它好像又要重新站起来了.我喜欢这种感觉.

有些人阅读是为了找工作,有些人是为了打发时间,有些人则纯粹是为了娱乐.这些原因都不重要,重要的是你在阅读.但是才工作或即将要工作的朋友们常常搞错了方向,以为抓紧时间阅读可以更好的提高自己的(面试?)水平.

记住:阅读与思考是孪生兄弟,阅读的时候要不断思考.不要为了阅读而阅读,读完之后完全不知道这本书的核心内容或思想,过几天全忘了.

不要想着抓紧时间阅读,这个念头会打乱你的思绪,只顾着去阅读而忘记了阅读的最终目的是什么.你的目的不是为了读完这本书,而是想捕获作者的思想.同样的表述会产生不同的想法,运用扩展思维,不要被眼前的表述局限.

阅读是乐趣,在不同的环境下阅读合适的书籍则需要一定的技巧.精力旺盛的时候阅读需要大量记忆的书籍,疲惫的时候则阅读可以让你放松的书籍,睡前阅读一些散文.不要让阅读成为一种负担,阅读是随时都可以开始也可以随时停止的事情.

阅读是升华,不断思考使你的抽象思维能力得以提高,从而可以阅读更深奥的书籍,更深奥的阅读可以不断帮助你思考得更深入.阅读可以开阔你的视野,更容易站在巨人的肩膀上放眼世界.

阅读帮助我看清了许多问题,了解得更多更深入,有时会一边阅读一边感吧自己的肤浅,同时也庆幸自己在不断进步.

还有一点,不要把时间浪费在没有意义的书籍上,毕竟人的生命是有限的,而烂书的数量是无止境的.

多读书,读好书. 今天你阅读了没有?
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

OO 设计原则

samuelray — Wed, 12 Mar 2008 11:04:06 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/170463 发表时间: 2008年03月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近在审查(review)代码时,常常发现一大堆代码充满了各种bad smell.即使工作了三五年的同事,也不会例外.沟通时往往发现他们对OO的理解只是表现出简单的概念理解.对OO的一些原则不甚了解,或者写代码也是跟着感觉走.

我最初做开发的时候也是跟着感觉走,初次听到OCP如天外来物.使用Java或C#不代表你就是在做OO开发,熟练使用OO语言不代表已经对OO非常了解.感谢Uncle Bob的经典巨著,坚持阅读的习惯让我接触并努力理解OO原则.一旦对这些原则有了深入的认识,写代码时就已经从更高的角度来分析问题,解决问题,力争写出优雅的代码.

我对OO的了解也不算多深刻,只在这里抛砖引玉.因为原则比较多,用一个系列来介绍会让大家更容易沟通.

同时,原则是死的,人是活的,不要被这些原则束缚,有一些原则在特定的情况下才会有效.

Single Choice Principle(SCP)
所有的判断只在一处进行.违反此原则的典型情况是不同的方法中充斥着相同的if ... else ...或类似的语句.

Linguistic Modular Units

Few Interfaces

Small Interfaces

Explicit Interfaces

Behavioral Completeness
一个完整的类必须包含完整的方法.如果类没有完成它的职责,或者没有完成其父类需要完成的工作,那么它就是不完整的类.

Law Of Demeter
只与直接协作的类交互.

The Principle of Essential Representation(PER)
类应该包含而且只包含其本质的定义和表现,与SRP比较接近.

Single Responsibility Principle(SRP)
一个类只承担一项职责,只能有一个发生变化的理由,那就是它的职责变化了.(扩展阅读)

Open-Colse Principle(OCP)
类应该对扩展是开放的,对修改是封闭的.

Liskov Substitution (LSP)
子类必须可以替换父类.

Dependency-Inversion Principles(DIP)
高层应该不依赖于低层,双方都应该依赖于抽象.抽象不依赖于细节,细节应该依赖于抽象.

Interface Segregation Principles(ISP)
接口属于客户程序.

---------------------------------
Reuse Release Equivalence Principle(REP)
重用的粒度等于发布的粒度.

Common Reuse Principle(CRP)
包中的类应该是共同重用的.

Common Closure Principle(CCP)
包中的类对同一类变化共同封闭的,一个类发生变化,可能所有的类都要发生变化.

---------------------------------
Acyclic Dependencies Principle(ADP)
包之间的依赖结构不应该存在环依赖.

Stable Dependencies Principle (SDP)
包应该依赖于比它更稳定的包.

Stable Abstractions Principle(SAP)
包的稳定程度与抽象程度成正比,越抽象的包越稳定.

---------------------------------
开发时应该避免的bad design smell:
僵化(Rigidity) 一处变化会影响系统中的很多地方.
脆弱(Fragility) 一处变化会影响系统中不应该被影响的地方.
牢固(Immobility) 很难被重用.

还有一些原则可能被遗漏掉,如果你发现了,请及时提醒我.

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

提高你的效率

samuelray — Fri, 07 Mar 2008 09:25:16 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/168945 发表时间: 2008年03月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我们常常被一些琐碎的事情困扰，不能有效地利用时间和精力．一不小心一天就过去了,偶然抬起头,一个月已经过去了.过春节了，要放大假了,原来一年已经过去了．回头一看,这一年竟然不知道在做些什么,值得一提的事实在太少.我们需要一些方法来提高我们的效率,不要让时间在不知不觉中渡过.

定义你的目标. 如果你准备阅读一本书,想想你准备从书中获得什么东西,看看这本书是否适合你的目标.读的时候不断思考你的问题,看答案是如何变化的.读完之后问问自己,你的目的是否达到.如果没有,还需要做哪些事情.如果你准备提高沟通能力,方法也是一样的.在整个过程中,你始终不会远离你的目标.不存在迷茫,不存在遗忘.

建立良好的习惯. 首先要形成一些习惯.要知道习惯的力量是巨大的,想想看你曾经为改变某个习惯所付出的努力就知道了. 其次,要形成良好的习惯.无论做什么事,良好的习惯会让你事半功倍.建立良好的习惯,精益示精,不断改进做事的方法(这也是一个良好的习惯).Kent的话是很有说服力的:I'm not a great programmer, but I'm a good programmer with great habits.

不要重新发明轮子. 已经有人在做的工作通常不需要你去再做了,你只需要把已经做好的工作拿来用就可以了.已经有了很多的开源工具,框架,库,方法论,不要再自己发明一套,在前人的肩膀上会让你看得更远.

乐于帮助别人. 我始终相信帮助别人就是在帮助自己,分享自己的收获,会得到更大的收获.不要担心帮助别人会降低你的效率,相反,这么做会让你得到更多的帮助,从而提高你的效率.不愿意帮助别人的人是很难得到别人的帮助的.

保持乐观主动. 不要放大畏惧心理,很多事做起来没有那么困难,至少没有你想像得那么困难.遇到挫折也不要灰心,任何人都会遇到这样的事,没什么大不了的.挫折会让你变得更强大.主动去解决问题,而不是等到最后才去解决,你会拥有更多主动权,更有效的分配自己的时间和精力.

定期回顾 如果你已经有了目标,那么就要定期回顾,看自己取得哪些进展,还需要在哪些方面继续努力.既给自己更多信心,也会提醒自己不要离目标太远.这时就要抬起头看看昨天和今天,想想明天,考虑是否要适当地调整目标.不要始终忙于手头的事,留出一些时间思考,将方向控制在手中.

提高效率的方法有很多,不一定全部都适合你.选择那些对你有用的方法,同时分享你的收获,让我们一起进步!

补充阅读:
找到你的位置.
使用To-Do List.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

找到你的位置

samuelray — Tue, 04 Mar 2008 12:39:31 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/167658 发表时间: 2008年03月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

每个人都有自己的特长和特不长,一些人会为自己的特不长而苦恼,花费大量时间和精力做出改变.其实完全没有必要.每个人都擅长和不擅长的事情,没有例外.不要奢望去做一个全才,没有任何意义.如果你希望让自己更有效率,花费同样的时间和精力取得更多的成果,那么你最好先找到你的位置.
你对技术有兴趣,希望自己成为一个技术专家.那么专注于技术,其它的东西都可以先抛在一边.因为专,所以精.在你取得一定的成果的时候你的价值就会体现得更高. 如果你希望成为一个优秀的管理者,全身心投入到其中,不断学习和提高.
从物理上讲,你的时间和精力始终是有限的,你的产出自然也是有限的.但是因为你产出的东西是有深度的,就具有更高的价值.都是八小时工作,为什么有些人能做得更多?能力和方法上的区别而已.

不要轻易决定去做你不擅长的事情,可能会事倍功半.在社会化分工的大环境下,每个人都有自己的位置,找到属于自己的正确的位置,那么你就已经领先一步.

接下来要做的事情就是努力去达到你的位置.以技术专家为例,可能你想做一个架构师,那么列出架构师必要的技能,(深刻理解OO原则, 理解很多的框架技术,或者掌握足够多的设计方法),看看自己还需要在哪些地方提高,去努力吧.
还要列出架构师扩展技能,选择合适的两三项出来去研究就可以了.首要原则是先专再通. 或者换个角度,评估自己的特长,具有哪些优势,然后选择可以更有效利用和发展这些优势的位置.

这是从完全独立的角度去分析这个问题,如果从另一角度看,可能会得出稍稍不同的结论.

可能你希望在现在的公司里获得认可,并长期服务,或者你就是公司的创始人(之一).这种情况下你必须从公司的角度出发考虑问题,比如说公司目前最迫切需要的人才是什么样的,罗列出几类.找出跟你自身有关联的来,设法通过提高自身才能来解决这些问题.这时候就需要你从更高层面上看待这个问题,暂时放弃个人得失.
有两个朋友在合伙经营一家软件公司,一个负责技术,一个负责市场.但发展到一定的阶段之后,做技术的必须做出改变,为市场推广提供更多支持.这种转变是有风险的,可能会完全放弃原来在技术上的积累,但是为了公司更好的发展,这种牺牲是值得的.

不管怎样,决定了就立刻去做.不要花时间去犹豫,后悔.只有做了你才知道结果,不做你永远不知道.这是非常重要的一点,是值得你一生去遵守的原则.

不要急躁,但也不要固步自封.不要满足于目前的成就,在到达你的位置之后,立刻确立你的新目标.你找到你的位置了吗?

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

点滴乐趣(Dibert)

samuelray — Fri, 29 Feb 2008 13:25:23 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/166110 发表时间: 2008年02月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我以前偶尔看过几幅Dibert的漫画,主要是通过接触到.最近发现原来可以订阅,还有相关的产品,如书籍,T恤,杯子,屏保,电子贺卡等,不过后面的产品都是收费的.但确实很有意思,我已经订阅了,每天一封邮件.网站是http://www.dilbert.com.

生活就是这样,工作和休息谁都不能放弃,相辅相成才让生命更有意义.

P.S.一个小小的漫画人物,可以带来巨大的商机.那么专注你的事业,一样可以拥有广阔的空间.

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

数据库命名规则

samuelray — Wed, 27 Feb 2008 15:34:11 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/165477 发表时间: 2008年02月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

这么多年的开发,始终未离开过数据库应用.从MSSQL到Oracle,现在又要mysql,真是要命.为了不让数据库的设计工作全压在一个人身上,所有队员都可能会做一部分工作,为自己负责的需求建立表结构.于是统一数据库的表名和字段名规则就不可避免.不过在做数据库设计时常常遇到同事对表名,字段名设计规则的质疑.因为到现在为止,我确实没有发现很通用的设计规则,在不同的项目环境下可能会启用不同的规则.

我最常用的规则:
1.表名分两部分组成--前缀_主题.如库存表whs_inventory,whs是前缀,表明这是用于仓库模块的,inventory是主题,表示这个表的业务概念.
2.字段名也分成两部分--前缀_主题.如库存数量inv_amount.inv是库存表的缩写,amount是主题,表示这列用来存储库存的数量.
3.外键的引用.如果库存表中引用了货品的ID,那么那一列就用Crg_id,而不是inv_crgid或inv_cargo_id.

现在问题就出来了,以前是手工建立相关的POJO,所以不是什么大问题.现在要通过Appgen或是Middlegen,生成的类名,字段名和Mapping文件名都不符合要求.如果用Maven生成代码的话,要改动的地方更多,想起来就恐怖!能想到的方法就是先生成Mapping文件,把不符合要求的类名和字段名全部改过来,然后再根据Mapping文件生成POJO.但是效率就低很多了.

候先的规则:
1.表名没有前缀,直接用主题命名.库存就是inventory,不做模块的划分.
2.字段名也甩掉前缀,该是什么就用什么.
3.外键字段用表名和字段名.如cargoId.这一点有个小问题,如果货品ID在多个表中被引用,可能会出现不同的形式,cgrId, cargo_id.这一点常常令人头痛.

当然了,数据库设计规则函盖的内容很多,这里我只谈到表名和字段的命名规则.希望大家能够他享更多更有效的最佳实践.

补充：
现在使用appfuse2.x，通过mvn appfuse:gen-model先生成POJO,修改后再用mvn appfuse:gen生成相应的其它代码。爽！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

有效的会议

samuelray — Fri, 22 Feb 2008 17:39:44 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/164324 发表时间: 2008年02月22日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

两个小时,整整两个小时,十个人在一起谈了三件小事情,而这三件小事情本来只需要花五分钟相互沟通一下就可以了.

你会问,那剩下的时间在干什么?其实也不多:
1.空谈.谈一些将来的事情,可能会发生也可能永远不会发生.我们应该如何如何去解决这些问题.OMG,现在的问题都解决不完,将来的问题更是无从谈起.
2.争论.为现在存在的问题争论,为将来可能存在的问题争论,而且没有结论.
3.跑题.不断地偏离主题,只有一个人谈了一句跑题的话就已经让人无法接受,刚才至少有三次跑题,每次至少十分钟.更糟糕的是让人想不起来刚才是谈到哪里了.

事实上会议是我主持召开的,但也不能强制某个话题停止讨论,只能拼命引导大家朝既定的方向走.失望是有一些的,但生活还是要继续,不是吗?我制定了主题,决定要在半个小时内结束会议,结果却是两小时.

我想我需要汲取的教训是:
开会前准备要充分.开会前要做好很多准备工作,订好会议室,检查所需要的设备是否正常工作,最重要的是拟订会议的主题并分发给参加者,好让大家在开会前就做好准备,不要在会议上才开始思考.还要让大家知道我们只有半个小时时间,不要迟到,不要乱扯.

引导会议.如果会议一旦跑题一次,你很难保证不会有第二次?怎么才能让会议不要第二次跑题呢?答案是:不要让第一次发生..主动引导会议朝正确的目标前进,始终让会议的主题摆在每个人的面前.不要怕花费一点油墨和纸张,一旦发生跑题产生的成本足够你买十次会议的油墨和纸张.不过,一旦出现了跑题,应该立刻停止,回到正题上来.

迅速得出结论,不要拖延.在适当的时候结束讨论,不要为无谓的争论浪费时间和生命.如果得不出结论,就没有必要再谈,如果可以得出结论,那么也没有必要再谈下去.行动迅速,不要拖延,对每个人都有好处.没有结论的会议是没有意义的,同时也伤害大家对会议的观点.本来是想解决问题的,结果浪费时间和精力,从而抗拒任何会议.

有针对性地讨论.每句话都要有其目的,一句费话都不要有.那么这就要求我们对任何问题都要先有个方案才开始讨论,方案不是在会议上想出来的.没有人有时间等着你在会议上发呆.有了具体的方案,讨论就会更有针对性,也更有效,甚至迅速得到必要的结论.

我这是我的心得,我还需要更多更有效的方式.你愿意和我分享吗?
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Subvert your ant

samuelray — Mon, 18 Feb 2008 17:26:16 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/163022 发表时间: 2008年02月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近开始给项目中的配置一些自动化,希望能让更多的事情由机器来做,减少人力的浪费,ant成了首选的工具.ant本身有许多的libs,但一些特别的功能还是需要增加扩展包.随着功能越来越多,向ant的lib目录下添加的jar文件数量不断上升.而build.xml是统一使用一个文件,但扩展的jar却不是统一添加的,可能一些人的机器上有比较全的jar而另一些人却没有.于是每次增加一个jar到ant里面就必须发邮件出来让每个开发,测试人员把附件中的jar加到自己的ant/lib目录下面去.如果有人忘了,多数情况下他的ant就无法看到'Build BUILD SUCCESSFUL',又要花时间解决.这样的问题是在打击负责build.xml的人,在压力下他可能就不敢轻易添加扩展功能.

我无意中想起几年前的一篇文章,已经记不清在哪看到的.作者建议subvert所有的东西,包括运行程序,运行环境,数据库,当时觉得有些夸张,至于吗!现在回想起来,简直太有道理了.现在的工具升级非常快,一不留神已经发布了几版本了.而且我已经把数据库subvert了.于是我决定再走前一步,把ant也加入到SVN中去,大家都到一个固定的地方去获取最新的ant运行环境,解决了前面的问题.

同时,在SVN中稳定ant和源代码的相对目录,不需要每个人去修改自己的路径参数.这是意外的收获.

下一步呢?Subvert发布程序?这个我暂时不会做,因为我随时可以把各个版本的发布程序打包.也许我应该把Tomcat也加入到SVN中来.Eclipse?CruiseControl?甚至是Subversion?你的答案是什么?

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

你为什么而工作?

samuelray — Wed, 13 Feb 2008 14:12:07 +0800

作者: samuelray 链接：http://samuelray.javaeye.com/blog/162063 发表时间: 2008年02月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

春节过完了,又开始新一年的冒险.

前几天看到<财富>上的新闻,罗列了google的13位创始人现在都在做些什么.他们在离开google后基本上都去了新的公司创业,其中一个家伙先是在youtube做首席财务官,与google谈判成功后,又去了Facebook.令我最难忘的一句话是他不想迷失在巨型公司,小公司给了他激情与生命.

啊哈, 激情与生命!我想知道到底有多少人是在为激情与梦想而工作,又有多少人是在为生存而努力?

大家都希望能够实现自己的梦想,不惜付出时间,精力和钱财,无论失败成功.但有一个问题是,如果你还没有解决生存问题的时候,应该先考虑梦想,还是先考虑生存?你决定冒险,孤注一掷,压上一切. 如果成功了,从此你的生活就变了样了,一切都不同了.如果失败了,恐怕你的生活也会变了样了,为了不失去工作而忍气吞声,将自己的原则踩在脚下. 但是我仍然鼓励你去追求自己的梦想,年轻就是你的资本,过期作废.

为自己工作和为别人工作最大的区别就是:每一秒都是珍贵的.如果你失去一秒,你就失去了这一秒所能产生的成果.总是在不经意间,一秒秒的失去.必须在短时间内做无数的决定,并承担每个决定的后果,还要学会不去后悔.为别人工作则不一样,你只需要考虑简单的事情,很快就能做完.不用很快做决定,就算做了也不会承担多大的后果,或者获得什么特别的奖赏.看到了差别吗?为自己工作像头牛,为别人工作像只狗. 我还是建议你为自己工作,做头聪明的牛.

永远不要等到万事具备的时候才去做.现在就去做吧!
新的一年开始了,总会有新的想法,最大的希望就是这一年不要荒废了,为你的梦想而努力吧.
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Samuel 软件(物流), 生活...Less is more

清除沟通障碍

解析运输系统 之四 --报表打印

规划职业生涯

现在就开始

解析运输系统 之三

解析运输系统 之二

解析运输系统 之一

依赖倒置(DIP)

大公司与小公司

Salesforce与Google App深度合作

浅析技术领导

开闭原则(OCP)

使用To-Do List

做专业开发者

点滴乐趣-笑话

单一职责(SRP)

阅读与生活

OO 设计原则

提高你的效率

找到你的位置

点滴乐趣(Dibert)

数据库命名规则

有效的会议

Subvert your ant

你为什么而工作?

解析运输系统之四 --报表打印

解析运输系统之三

解析运输系统之二

解析运输系统之一