文章列表
【谨以此记录最近阅读的博文】
2010年度CSDN十大博客文章
我，一个写代码的
概要：这是一篇2009年写下的博文，但我们却愿意将它评选为“2010 年度CSDN十大博客文章”之首。因为这篇“慢热型”的博文，整个2010年内，在CSDN社区内被广泛转帖，并得到网友们的交口称赞。那这是一篇什么样的文字呢？本文作者岑文初根据自身经历，总结出六条秘籍：爱这行；踏踏实实打好基本功；注重日常积累，厚积薄发；技术上做到既广且钻；培养分析问题能力，善于追根溯源；全面培养能力，不做纯粹“技术人员”；阿里巴巴六脉神剑文化。文章措辞丰富幽默，相信一定可以给开发者带来启示。
链接：http://blo ...
我奋斗了18年才和你坐在一起喝咖啡
我的白领朋友们，如果我是一个初中没毕业就来沪打工的民工，你会和我坐在“星巴克”一起喝咖啡吗？不会，肯定不会。比较我们的成长历程，你会发现，为了一些在你看来唾手可得的东 ...
程序员的灯下黑：坚持和良好心态近乎道（转）
- 博客分类：
- 软件设计师之路
程序员的灯下黑：坚持和良好心态近乎道（转）过去有一位年轻和尚，一心求道，希望有日成佛。但是，多年苦修参禅，似乎没有进步。有一天，他打听到深山中有一破旧古寺，住持某老和尚修炼圆通，是得道高僧。于是，年轻 ...
第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法： 一是重复存储职工号和姓名。这样，关键字只能是电话号码。 二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性 三是职工号为关键字，但强制每条记录只能有一个电话号码。 以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。 第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。 例 ...
- 2009-03-20 18:06
- 浏览 766
- 评论(0)
虽然许多文章曾经讨论过J2EE最佳实践。那么，为什么我还要再写一篇文章呢？本文究竟与以前的文章有何不同或者说比其他文章好在哪呢？ 首先，本文的目标读者是正在从事技术工作的架构师。为了避免浪费大家的才智，我会避免讲述一些陈腐的最佳实践，例如"日常构建（build daily）"、"测试一切（test everything）"和"经常集成（ integrate often）。 任何具有称职架构师的项目都有分工明确的、定义良好的团队结构。他们还为进行编码检查、构建代码（每日或在需要时）、进行测试（单元、集成和系统的）、部署和配置/释放管理而具备已记 ...
- 2009-02-08 11:05
- 浏览 655
- 评论(0)
软件工程中的经济行为1. 在传统财务概念下，软件公司或者商业公司IT部门的员工，是公司的成本中心。对于一个定额合同项目，员工工资成为项目中唯一的可变成本。2. 因此，尽可能的缩短工期，减少人员投入就成为缩减成本 ...
- 2009-02-08 11:00
- 浏览 890
- 评论(0)
作为项目的技术主管，构架师的技术需要非常的广泛，这比技术深度更加重要（当然构架师在特定的领域需要一定的技术深度）。
软件构架师是技术主管
首先，软件构架师是技术主管，这意味着除了他要有技术上的技能外，还要有很好的领导才能。构架师的领导能力在团队中和项目质量控制中起着十分重要的作用。
在团队中，构架师是项目的技术总管，他需要有丰富的知识背景，以便作出技术上的决定。相对于构架师来说，项目经理是来管理项目的资源，时间进度和花费的。使用电影制作来做类比的话，项目经理就是制片人（他要确定工作被完成了），而构架师是导演（他需要确定工作被正确的完成）。由于他们在项目中所处的位置，构架师和项目经 ...
- 2009-02-08 10:59
- 浏览 964
- 评论(0)
什么是软件架构师？ 架构师（Architecture）是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢？这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。 所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我 ...
- 2009-02-08 10:57
- 浏览 1204
- 评论(0)
敏捷质疑: TDD
Q: 为什么通过单元测试发现的 Bug 很少 ?
A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的. 如果采用 TDD, 测试用例完成之时, 产品代码尚未编写, Bug更无从谈起.
Q: 那是否写单元测试就能提高代码质量了 ?
A: 关于这一点, 似乎有人不这么看, <<TDD Opinion: Quality Is a Function of Thought and Reflection, Not Bug Prevention>>. 不错, 代码质量并不必然关联到单元测试, 诸如净室软件开发之类的方法依然可以在没有单元测试的情况 ...
- 2008-12-15 16:40
- 浏览 861
- 评论(0)
敏捷质疑: 持续集成
Q: 我的产品是电信级的设备, 几百人分成几十个项目组在开发, 各个项目组进度不统一, 如何集成?
A: 你要做的其实跟技术无关, 更多的是管理工作, 就是制定你的产品级别的集成策略.
这涉及到需求分析和发布计划(依赖管理, 价值和风险识别), 开发方法(自顶向下还是自底向上, 横向分层还是垂直特性), 集成粒度划分(完整特性的集成还是API的集成), 集成间隔计划, 版本控制策略, 还有尤为重要的集成测试/验证策略, 甚至你的决心.
任何集成策略在执行过程中都会遇到困难, 如迟迟得不到能够成功集成的版本. 这时你要找出原因, 并有权力或相应措施要求整个几百人的团队停下来, ...
- 2008-12-15 16:39
- 浏览 827
- 评论(0)
敏捷质疑: 结对编程, 代码集体所有权
Q: 结对编程、责任共享，完全是胡说，代码找不到作者，开发人员哪里会有责任心!
A: 这个疑问基于一个假设: 开发人员的责任心来自于问责制度, 开发人员只有在恐惧的驱使下才会细心去编 ...
- 2008-12-15 16:37
- 浏览 885
- 评论(0)
ThoughtWorks University 取经第二记
接续上一篇文章关于ThoughtWorks 公司文化和敏捷开发思想的传承，这篇文章主要描述的是我在ThoughtWorks University所接受的敏捷开发技术培训的内容和方式，在一些介绍中会穿插一些对我的真实工作所起 ...
- 2008-12-15 14:24
- 浏览 1694
- 评论(0)