随笔分类 - 读书有感
摘要：书中主要提到了关于服务团队，与传统的管理理念体现的控制背道而驰，但作为软件团队的管理者不应该对此表示诧异。艺术家能按严格的管理产出作品嘛？答案是能生产一堆不被人认可的带有瑕疵的标准作品。同样作为脑力工作者的软件开发人员，按严格管理就能生产出合格的作品嘛？建议是：把合适的人员组成一个团队，给团队一个任
阅读全文
摘要：书中提到团队是一群紧密结合在一起的人，其整体大于部分的总和。也就是说这样一个团队的产量，要比同样一批个体成员产量更大。一个团队的所有成员都应该具有相同的目的，正因为如此，这个团队才能够更好地更有效率的工作。一个团队形成必然会降低流动率，团队成员基本不会在工作完成之前而放弃。在团队中人们在工作中能获得
阅读全文
摘要：管理人力资源这部分介绍了一种完全不同的考虑、管理人的方法。一种特别适应人力资源的非模块化特点的方法。对于当前研究过的占绝对多数的失败项目来说，解释失败的原因不仅仅是技术问题。并且，书中指出培养一种不允许出错的气氛只会让人们产生防备心理，相反应该允许人们犯一些错误。软件工程项目中的错误几乎无可避免，一
阅读全文
摘要：《人月神话》，那什么是人月？是在估计和进度安排中使用的工作量单位。Brooks认为，用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之 间不需要相互的交流。 保持设计的概念
阅读全文
摘要：书中写到“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢?我也说不清楚。
阅读全文
摘要：当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。 作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的
阅读全文
摘要：和我以前阅读的其他软件工程书籍一个很大的区别在于，作为教材，《构建之法》的启动过程非常的平滑。有一些读物是按照经典的瀑布模型，从需求分析，概要设计开始——是的，我教过这样的教材。而本书则是从一个微型项目最有可能的起步过程开始：组建团队、准备工具。从经验来讲，版本管理工具和单元测试工具，也确实是非常适
阅读全文
摘要：邹欣老师在这本构建之法中形象生动的描述了软件工程人员在工作中的点点滴滴。 他提出软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。确实如此。 在两人合作这一章节里，第一点就强调了代码规范，让我知道了工作中代码如何写的规范的重要性。然后讲述两人在一起合作，自然会出现不同意见
阅读全文
摘要：通读完构建之法之后，我有一个很大的感触。就是一个优秀的软件工程师不仅仅要代码写得好，而且要善于交流沟通，具备团队协作精神。我以前一直强调个人努力，认为一个人只要勤奋努力，学习好编程代码写得好就是一名优秀的软件工程师，一个人就能开发出非常优秀的软件产品。其实不然，一个好的软件必定是一个团队分工合作，共
阅读全文
