午夜杂谈
按正常的作息时间,现在已经睡着了,但今天加了点班,回到家又吃吃饭喝点啤酒,就不太困了。 既然无事,就写些闲话杂谈吧,反正也好久没更新过了。
刚才看博客园一篇文章《记一次面试经历》,里面谈到zookeeper分布式协调,很高深的样子,就百度科普了一下,原来是和大名鼎鼎的Hadoop有联系的。
此处也附带几个链接,为以后查看做个标记。
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
就在上一年,这些分布式之类的概念都离我很远,只存在我的念想中。因为之前是做企业或学校内部管理系统的,对分布式的需求几乎没有,或者那时候我还没有意识到什么是分布式。但自从进了互联网公司之后,会越来越多的接触这些概念。公司在成长,数据在变大,个人也要跟着成长,要不然跟不上时代的脚步就被遗弃了。现在一些数据量大,耗时的动作,为防止网页超时,需要发送指令给后台处理,还要涉及不同系统之间的信息共享,又要防止因各种错误中断,不影响任务的继续执行。这些都是现在或以后需要考虑的事。
以前觉得自己的技术还行,除了设计无感,前后端都可以,接触了更多的同事之后,发现自己的js水平还很初级。去年刚来公司时,连chrome的js调试工具也不会用,以前完全即使alert或者IE的debugger调试的。chrome的这个F12 console调试更加方便。之前我也封装过各种弹窗,表格插件,提醒等,但和新同事的比起来,规范性和维护性都有些差距,认识到不足,才能提升。
以前做查询的时候,还是一个一个的拼接字符串,是多么的浪费时光。后来发现asp.net MVC自身的Model绑定,然后利用一些ORM或泛型或反射来处理好查询条件,节约了不少精力。这是对去年的自我检讨,今年已经再渐渐改正了,逐渐采用3.0,4.5以后的操作方式,lamuda表达式,List的查询,C#的表达式树等,来提高工作效率。新版本的特性也要更多的了解。
以前听说高内聚,低耦合,只知道模糊的概念,并不知道有什么好处,也没有具体的案例来分析。现在总算有一个大体的认识了(或许也很基础)。如果新建了一个项目,要引用老项目里面的一个小接口,却需要把老项目很多地方都引用进来,一层套一层,这就是比较坑的地方。老项目有些地方耦合太深,解耦任务经过不断的尝试和修改,已经有了很大的提升。说起这里,我想起过去一个项目的二次开发,那里面一个方法里面一层套一层,最后能套几十层,再加上里面一层层的接口实现,横跨大半个仙姑,最后都不能确定某个方法是谁调的了,维护性非常差。经历了这些坑,就能理解高内聚,低耦合的重要性了。高内聚就是要模块内的各个元素尽量紧密结合,低耦合就是要各个模块之间尽量减少依赖。
工作(生活)就是不断填坑(需求)的过程,有的人懂的多,已经预先填好了,走的路就顺畅些,有的人走一步填一步,没有规划,走过的路就坑坑洼洼的,一下雨就完全瘫痪。弥补这种情况的好方式,就是多学习,多思考,多看牛人的解决办法。
计算机界有个出名的摩尔定律:当价格不变时,集成电路上可容纳的元器件的数目,约每隔18-24个月便会增加一倍,性能也将提升一倍。摩尔定律虽然不是万能的,但生活也应该像摩尔定律一样,在相同的工作时间,产出的效率和工资,约每隔18-24个月便会增加一倍。如果还没有做到,一定是还不够努力,努力学习新知识吧,在合适的情况下,多投投简历,试试自己的水平。比如金三银十阶段,即使不打算换工作,也可以试试水,毕竟如果一年半换一次工作的话,贸然提高一倍工资会心虚,但如果换成三个阶段,每半年广撒网一次,探探水,看看外界都是需要什么水平的,实时调整自己的方向,每次试投提价30%,一年半后就真的翻倍了。摩尔定律作为一种指导思想还是不错的。随着年龄的增大,步入中年期,就有瓶颈了,毕竟IT是个吃青春饭的活。
最近盛传36岁IT男加班猝死,园子里也多有文章辩论,所以大晚上的还是好好休息吧!。