BlogJava-狂人思维·成都-随笔分类-工作间

工作三年后再次受到面试里的某些因素打击

狂人思维·成都 — Mon, 18 Jun 2007 11:59:00 GMT

摘要: 阅读全文

狂人思维·成都 2007-06-18 19:59 发表评论

引人深思的一张图:软件形成过程

狂人思维·成都 — Thu, 09 Nov 2006 07:40:00 GMT

如题,做为IT从业者的您,看了这张图后感触几何?

狂人思维·成都 2006-11-09 15:40 发表评论

[转]成功跳槽靠的是什么？

狂人思维·成都 — Mon, 24 Jul 2006 05:07:00 GMT

你也在准备跳槽吗？你知道跳槽之前应该做什么吗？当你开始认真思考这些问题的时候，说明你开始关注自己的职业发展了
跳槽是一门学问，也是一种策略。“人往高处走”，这固然没有错。但是，说来轻巧的一句话，它却包含了为什么“走”、什么是“高”、怎么“走”、什么时候“走”，以及“走”了以后怎么办等一系列问题。
　　那么当面临跳槽时，如何才能顺利地完成跳槽，从而取得职业的成功呢？
　　首先，要确定你跳槽的动机是什么和自己是不是需要跳槽。大致来说，一个人跳槽的动机一般有如下两种：一是被动的跳槽，即个人对自己目前的工作不满意，不得不跳槽，这里又具体包括对人际关系（包括上、下级关系）、工作内容、工作岗位、工作待遇、工作环境或工作条件、发展机会的不满意等方面。比如，如果你与上司关系不融洽，觉得得不到发展，你自己也感觉无法适应目前的环境，那么恐怕就要考虑换个环境试试了；第二，是主动的跳槽，即面对着更好的工作条件，如待遇、工作环境、发展机会，自己经不住“诱惑”而促使自己跳槽；或者寻求更高的挑战与报酬，比如你发现自己的能力应付目前的工作绰绰有余，并且发现了自己真正感兴趣的工作的时候，你就不妨考虑换个工作试试。
　　无论如何，当你具备了跳槽动机的时候，就是你跳槽行动的开始。但是，为了跳得更“高”，你在跳槽前不妨先问自己下面的问题：
　　1、是什么让你不满意现在的工作了？
　　2、你想跳槽经过慎重考虑了吗？还是一时的情绪？尝试做自我调整了吗？
　　3、跳槽会使你失去什么，又得到什么呢？
　　4、适应新的工作或环境、建立新的人际关系需要你付出更多的精力，你有信心吗？
　　5、你的背景和能力能适应新的工作吗？
　　6、你是为了生活而工作，还是为了工作而生活？
　　7、你有没有职业目标？新的工作是不是为你提供了一个清晰的职业方向？
　　8、征求过专家的意见吗？有没有咨询过职业顾问？
　　如果对上面的问题回答是“是”，那么你可以接着考虑下面的问题：
　　1、你要跳过去的公司的职位是什么？如果比你现在的职位还低你能接受吗？
　　2、新的工作要求你从头做起，你有这个心理准备吗？
　　3、你在目前的公司里工作有多久？—一般来说，在一个公司的工作至少应该满1年，否则它不会为你提供非常有价值的职业发展依据；
　　4、你应何时跳槽？——最好的状态是在目前工作进展顺利时跳槽，那么你的职业含金量会大大提升。
　　5、你实事求是地估价自己的能力了吗？你的优点或特长是什么？你有哪些不足？——这里要求你既不要好高骛远，也不要自甘弱小。
　　一旦决定跳槽，你就要大胆地付诸实施了。这时你需要选择恰当的跳槽时机，以下是职业咨询顾问提醒你跳槽时应当注意的事项和建议你的比较妥当的做法：
　　1、知己知彼：查阅与目前公司签订的劳动合同，明确自己是否受到违约金或竞业壁止等条款影响、离职手续办理难易程度等，做到心中有数；
　　2、尽可能收集新公司的信息以及可能要求自己提供的项目，做到有备无患；
　　3、设计简历：准备一份职业化的简历，你可以寻求职业顾问的帮助；
　　4、有时候根据自己的工作经历和能力，使用猎头公司应聘也不失为一种有效的策略；
　　5、递交辞呈：向原公司递交辞职信，做好离职过渡期的安排。记住千万在拿到“O ffe r Le tte r”以后再递交辞职信；
　　6、与人为善：虽然你应聘成功了，虽然你可能“痛恨”原来的公司，但是也不要在背后恶言冷语，你哪天还会“用”到原来的公司，这谁也说不准。
　　你也在准备跳槽吗？你知道跳槽之前应该做什么吗？当你开始认真思考这些问题的时候，说明你开始关注自己的职业发展了。但是，你必须明白：跳槽并不意味着你就能够取得职业的成功，这个时候，寻求职业顾问的帮助可能是个理性的做法，因为职业顾问会告诉你什么是正确的跳槽、什么是你应该选择的职业方向。一句话：职业顾问会帮助你取得职业生涯的成功！

狂人思维·成都 2006-07-24 13:07 发表评论

当10,000,000 = 零

狂人思维·成都 — Fri, 26 May 2006 08:42:00 GMT

摘要: 有趣的对比性能测试结果--我对比测试基于开源组件写出的框架与花费10,000,000元买的产品阅读全文

狂人思维·成都 2006-05-26 16:42 发表评论

最近很忙,很郁闷,也很有收获

狂人思维·成都 — Mon, 27 Mar 2006 11:02:00 GMT

进入项目就一直忙忙碌碌,朦胧中已经有近一年没写Blog了,放下手中的笔，体息一下，觉得是乎应该对自己最近的工作总结一下，拿起键盘，却又不知道具体要说些什么，似乎有很多要写的，很散，思维还有点乱......，还是就由着思绪来吧～～

我所在的项目由于一期使用的是一个公司的开发平台，因为其平台自身的功能限制无法扩展、难以维护且系统可控制度极低，因此，客户方决定在二期重新设计架构并在新的架构上完全重新开发，而我正是在为新的架构做技术预研，其中形形色色的问题乱如麻。

首先是JSF，我们采用的是MyFaces的实现，服务器WAS5.1,JDK1.4.1.2，在发布JSF应用时的第一个问题就是JSF容器无法正常初始化。这个问题很容易定位，就是由于Servlet 2.3规范对Lisener和Servlet的初始化顺序要求不严格，从而使不同厂商有着不同的实现导致的。但因为有朋友也在使用JSF，且服务器版本也一致，他们没有问题，偏偏我整死也跑不通，所以，开始觉得自己的判断可能不对，但郁闷的是用google搜索半天没搜到解决方案，最后没折了，只好自己去打开JAR包看看源代码，结果发现里面有个MyFacesServlet，打开一看内容，简直想一头撞死，原来该类解决了2.3规范问题，从而他可以替换Linsener类的初始化职责。他在被加载时首先会检查StartupServletContextListener有没有正常初始化，如果未初始化则调用StartupServletContextListener进行初始化。看来有时候还真是不能偷半点懒，要相信自己的判断。

其次是JSTL，我最初用的是apache的参考实现1.1版本，结果整死都无法使用，总是报taglib无法解析，到网上查了半天，没有一个人说具体的解决方案，没办法，从来没用过JSTL啊，新手总是会碰上一脸灰的，后来打开看Tablib的版本，天啦，人家要求的是JSP 2.0，而我的还是基于2.3规范的1.2，当然无法解析了，然后从新从网上DOWN个jstl 1.0下来，一跑就通！！唉，真是没办法，在网络上，有些问题一搜就到，而有些看似简单的问题却能把人折腾个半死，结果发现你还是要自己定下心来去查，千万不要全指望别人。又受教了。

再次SpringWebflow，到目前为此，webflow还处于1.0早期版本，现在还不能确定1.0正式版何时推出，做为我们来说，也算是一次大胆偿试，说实话，当前的webflow版本功能还不能足以应用到项目中来，但我相信他的正式版应该会很快推出，所以就抢先偿试了，偿试中的问题就不说了，就说说它现在的缺陷吧，
1.支持流程级变量创建，却无法给变量赋值，郁闷，这么重要的功能居然还没提供
2.调用POJO方法时，必需要有参数，且参数必需是在flowScope上下文里，连静态常量参数都不支持，又狂郁闷了一把。在流程里，这是再常用不过的功能了，居然没提供，希望正式版快快出来，并补上这些缺陷。要不然，他是不可能进入实际项目应用的。偶现在真是想修改他的代码，把这些功能通通加进去。。，但最终还是得先抑制住冲动---再等等看吧。。。
3.与JSF集成的JSP里的非受管Bean的普通JSP参数无法在flowScope里获得，这一点不能肯定，有可能是转发方式的问题，希望能修改该问题。
4.流程里的表达式灵活性太差，尽管是采用OGNL做的解析，但还是只能写一些极其简单的逻辑表达式，稍微复杂一点的----别想。这一点，也有可能是我还没用好的缘故，需进一步证实

最后就是自定义Data Table UI组件了，我们要同时支持列表分页，定制式的组合查询，动态排序等；这几功能点乍一听觉得应该不难，可一做起来，也并非易事，我现在没有基于JSF的UI实现，而是通过JSP TAG +XML+XSLT+AJAX的方式来实现的，其中最复杂的就是组件的参数绑定和状态绑定的问题，服务端是无状态模型，所有状态及参数都保存在客户端，解决如何能让自己的组件里的状态参数不与其它组件或页面上的其它参数发生冲突是个非常重要一环，另外就是SQL的解析，结果模型的抽象，转换器的抽象，对UI前端的命令解析及执行，参数模型的封装，对不同的数据来源用不周的解析器等等，都是要考虑的问题，这一块要说起来就太多了，等先把这个组件完全测通了后，再拿现来专门讨论讨论。

感想，开发一个好的框架是一个非常考水平的事情，他不是我们平时所想像中的那样简单地将一些现成的开源框架拼凑起来就了事的，他涉及到了项目群的协模式，系统架构，各层所选用的技术框架特性，业务集成等方方面面，即使使用Spring这种几乎现成的框架来做为系统的主干骨架，做为框架设计者，你要做的事还很多，你要从系统总体角度去考虑系统的逻辑模式，与外部系统的协作模式，系统的可扩展性和低侵入性；你要让开发人员尽可能的少做重复劳动；你还要保证你所选的技术方案能在开发过程中无障碍；你要做好解决开发过程中的所有技术难题的准备；除了这些，更关键的是你还要能做好业务模型的抽象和设计，你要能及时或预先发现潜在风险和问题并解决它。。。。等等，太多太多。。。，而我，现在要行的路还长得很.....

狂人思维·成都 2006-03-27 19:02 发表评论

架构、框架、基础件之反思

狂人思维·成都 — Fri, 20 May 2005 08:44:00 GMT

看过微雨心晴（X-Brave）的对架构、框架、基础件三者关系的论述后，我陷入了一阵不安和恐慌之中。
发现我原来对软件框架的理解还是那样的浅溥，并由此想起，应该不只我一个是这样，我想大多数的开发人员在从普通的程序员向架构设计转型时都会遇到的这样的问题，在阐述的这个问题之前有必要将这三都的关系描述一下(这里就直接引用微雨心晴（X-Brave）的描述)：
从层次结构来看，软件架构是从整体上来看软件设计开发的，框架通常是从较高的层次来实现或者被选择来实现软件的架构，基础件/类是更小的软件元素，只是更加的强调通用。三者之间存在微妙的关系，以至于确实容易引起人们的混淆。实际上，试图完全的割裂它们即使不是错误的做法，也常常不是良好的设计：三者之间存在紧密的依赖关系.

我很赞同这种说法，现在我来描述我以前设计系统框架时的问题所在：
最初在第一次担任框架设计时，总是从功能类出发。
即：先考虑系统有哪些复杂而又频繁使用的类，对这此类进行分包，归类，并命名为UTILS。

然后再是对系统分层，分包，几乎没有多少中间接口，相临层之间总是紧耦合的调用，造成了层与层的改动牵连边过大。

写出来的框架就像工具包一样，由一大堆看起来没有联系的类堆积而成。

后来，经历过一次大项目后，开始关注一些建模理论以及开源框架，对先前的框架设计思想产生极大的冲击，开始关注系统的整体搭配，接口解耦，代码重用，自动化控制程度有所提高。
但感觉问题还是依然很严峻，主要表现在：对系统的把握层次仍然偏低(从代码角度出发)，缺乏对系统整体的抽象能力和建模能力。对零散的业务规则难以抽象出很好的业务模型并以与系统架构结合起来。

总的来说我经历了两个阶段：1。以公用基础件为核心的积木式开发 2。以局部框架结构(实现)为起点，分层整合的泛射式开发(最明显的问题就是层层之间不成一体，项目越大越到后期就越松散变得越来越难以控制)

目前，开始将目光从系统业务层面出发，以架构为主，逐步向框架结构设计过渡的方向发展，但这时常令我感到力不从心，毕境理论归理论，现实中还需要丰富的实践经验去累积。

狂人思维·成都 2005-05-20 16:44 发表评论