`
ohmygodlzl
  • 浏览: 21393 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论
文章列表
偶然翻到电脑里早前写的一篇帖子,转过来 引子 本周二,xxx系统一天内三次故障,报警短信频传。星期三一早,下去协助ABC一起分析zzz系统的事故,此时的PMD老大已经连续在公司待了24个小时,接着又跟我们一起做了一天的事 ...

我的知识地图

一直想干件事儿,就是把自己了解的软件开发领域的知识画成一张知识地图,找了好多资料,没有发现这事儿该如何做的指导方法,于是就一直搁浅了。 前些天部门技术经理开会,讨论到开发人员成长路上的瓶颈和迷茫,颇有感触,又勾起了我画一张技术知识地图的想法。太完美的想法难于落地,所以我画图的时候本着不是全面深入的原则,而是直觉、第一反应,目的就是梳理一下貌似堆在一起的零散知识,归归类,归类方法和内容都是我自己的,所以观者在看的时候也别太较真儿。 图见附件
写给公司开发团队兄弟们的帖子,转到这里分享下。 当初初次尝试Scrum,便即取得成效之后,感觉很兴奋,到处跟人讲Scrum的好处,“用了以后,腰不酸了,腿不疼了,上楼也有劲儿了”,恨不得呼吁门口卖包子的阿姨也来尝试 ...
    中午吃完饭,天气正好,遂沿着世纪大道一个人散步。正走着,一个熟悉的脸庞跃入眼帘----这个人是我大学的同学,一起逛操场深夜谈心的朋友,在学校读研后去日本深造三年,后来又去美国读博士后,前天刚回国省亲----已经八年不见,前天还相隔万里,就这么突然地在茫茫人海中,两个人偶遇街头,一番慨叹,不胜唏嘘。     虽然分别了这么久这么远,毕竟是学校里的朋友,心理上没有距离,很短的半小时不到的时间里,聊了各自的经历,以及时间给彼此留下和带走的东西----工作以后真是少有这样可以直触心底的畅谈,话语不多,传达的东西却可以充盈心扉,很快对彼此的状态都有了了解,仿佛一下子回到了校园,从来没有分别过。   ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。 对这个原则,我的体会不深,主要是因为没有在实际项目中看到违背它的后果,不过作为Bob叔叔OOD基础原则的最后一个,还是要在这里介绍一下。这个原则的说明如下: 子类型必须能够替换掉他们的基类型。     听起来是一个很简单的描述,基于继承的设计中似乎子类型总是可以替换它的基类型。但要注意,基类是一个抽象,用子类对基类进行替换要保证使用这个抽象的类的行为不被破坏。还是用手机充值完成通知商户那个例子来说明:     假设,在定义接口MerchantCallback的时候,notif ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。     在我们目前的开发模式下--使用Spring面向接口编程,这个原则给我们的更多是思维方式上的指导。所以在这里只是简单介绍一下这个原则,不举我们系统中的例子说明了。     先解释一下"依赖"这个词的含义,在软件世界里,引用、继承、实现(realization)、方法参数和本地变量引用都是一个对象对另一个对象的依赖,DIP原则告诉我们: 1、高层模块不应该依赖于底层模块,二者都应该依赖于抽象 2、抽象不应该依赖于细节,细节应该依赖于抽象     这个原则中所 ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。      现实中的每个人都要承担各式各样的职责,这些职责通常是由他面对的"客户"所决定的,比如一个部门经理, ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。     按照面向对象的观点,软件中的实体应该是对现实世界中实体(或者概念)的模拟,这种模拟包括名称、属性(状态)和职责。打个比方,在软件世界中定义"狗"这个对象,我们需要从现实世界寻找启发,定义如下:     狗的属性和动作都是对现实世界中的模拟,这样你玩星际的时候招募了一条小狗,你知道其实是创建了一个狗的对象,它有类似现实世界的这些属性和动作。这种模拟就是David老师经常提到的"低表示差异"。     但是返观我们写的程序,XXXDTO ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。     在继续探讨OOD的设计原则之前,我想先就OOD本身和相关的一些概念做些澄清,概念清楚以后再来看OOD的设计原则和我们 ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。     在探讨单一职责原则(SRP)时,我用黑体强调了一句话:如果你接到一个需求后发现需要修改一个已经存在的类,那就 ...
这个系列是早前发布在部门wiki上的,引导组里的兄弟入门OOD,希望同样对刚刚走到OOD门前的同学有用。     一直想跟同志们探讨一下面向对象设计(OOD)的原则问题,但因为自己理解有限,怕说不好误人子弟,一直就没开始。现在想做个尝试,从浅处说起,便于理解,也希望能对我们日常的开发起到帮助。     我们做软件开发,要做的事情无非就是:拿到一份需求,通过一系列步骤把它转化为可运行的系统。这些步骤简单的说就是需求分析――>面向对象分析(包括领域建模)――>架构设计――>详细设计――>编码――>测试――>发布这样的过程,其中架构设计和详细设计中都要用到OO ...
偶然从google上搜到了多年前自己的帖子,这篇帖子后来自己觉得太过于沉重,就从所有的记录中删除了,现在读起来还是觉得太冷色调,不过作为一段经历,还是保留下来罢。 走出上海交大教学2号楼的瞬间,心里闪过一丝欣慰 ...
    回顾自己对软件开发的认识历程,大抵可以分这么几个阶段: 第一阶段,做程序员,刚刚上路,对软件开发的理解就是你有一堆材料,我有一把锤子,你要椅子我就做椅子,要桌子做桌子,那个时候最擅长的是听到一个需求马上在脑子里反应出该用什么技术去实现,几个类,几个页面。 第二阶段,开始接触分层思想,接触设计模式,知道原来做软件有技巧在里面,你要考虑复用,考虑扩展,同样是做桌椅,你要考虑内在的几何结构,承重要求等。 第三阶段,东西看得多了,了解到模式也分多个层次,了解到从word文档中的文字需求到最后的软件成品,有一套方法可以遵循,有一些原则需要遵守;再到后来,就是架构风格,以及软件之上的业务领域的分析方 ...
    某天,正在驾校学车,突然收到Boss的短信“请将敏捷开发方法总结一下,我们全公司推广”,当时有个师弟刚开始练倒车,正被师傅揪着耳朵教训,想想自己走过来的路,偶一阵得意。     偶现在的公司做的是金融服务,软件开发团队分为四个事业部,大约一百多号人,偶在三个季度左右的时间里担任其中一个事业部的开发团队负责人。现在回忆起最初的那段日子依然心有余悸,相信好多在软件行当里混的兄弟们都经历过某些类似场景: 创业型公司,来自产品和业务部门的需求积压着一大堆,而且一个比一个紧急; 包括QA和SCM在内也就十个人左右的团队像一台小挖掘机,一点点消耗着需求大山; 包括负责人在内的所有人都参与开发,解决关 ...

表 达

   记得上大学那会儿,大二大三的样子,经常随身带一只笔几张便签纸去图书馆或者自修教室,不是为了做笔记,而是为了随时记下掠过心头的情绪、感觉和想法。那个时候网络还没流行,没有多少给你表达的渠道,然而年轻的心脏时刻鼓动着血管,表达的欲望无比强烈,于是就不停地写,不拘泥文法,想到什么就写什么。     毕业工作以后,越来越忙,越来越没有时间,也越来越“成熟”,见得事情多了,做的事情也多了,眼看可供表达的渠道----论坛、博客、微博客越来越多,反倒觉得没有什么想说的了。     写的东西少了,心里就有个声音在催促,“该留下点什么才是”,所谓人过留名,雁过留声,不是为了写给别人看,记下点心情,留下点感悟 ...
Global site tag (gtag.js) - Google Analytics