《构建之法》初步阅读

<构建之法>阅读有疑 在用将近五节课的时间将邹欣老师的书<构建之法——现代软件工程>第二版大致看完.虽然全书是以轻松的口吻与”移山公司”员工的一些趣味谈话来传输一些理念和思想的,但是读完并理解依旧不是一件很容易的事情,并且在这过程中我对书中的一些看法抱有怀疑的态度,现将问题所在列在下面. P68页:我不是很认同邹老师的“精通”魔方的判定方法.就好像在软件工程开发中,一个人解决了一个bug.解决了bug却不算是“精通”,还得能恢复bug,再现bug才算是懂得各中原理吗?我觉得作为一个

1.程序=数据结构+算法 2.构建管理,源代码管理,软件设计,软件测试,项目管理是软件工程的核心部分. 3.软件=程序+软件工程 4.软件企业=软件+商业模式 5.软件开发的不同阶段:玩具阶段,业余爱好阶段,探索阶段,成熟的产业阶段 6.软件工程是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程 7.软件工程包括:软件需求分析,软件设计,软件构建,软件测试和软件维护等领域 8.软件的特殊性:复杂性,不可见性,易变性,服从性,非连续性 9. 软件工程的目标--创造"足够好&quo

我通过老师发的链接读了“<构建之法>阅读梳理篇”,我从中懂了很多,我懂了软件与程序的区别,明白了作为一个程序员是要掌握的基本能力,更明白了一个软件或项目是由一个团队完成的,个人的能力再强也强不过一个团体.在这篇文章中我明白了很多,同时我也对我日后可能要做的工作有了更全面的了解,也令我看清了程序员这个工作的前景和工作方式,更令我看清了自己的缺点和不足.我要以这篇文章里的要求去要求自己,向真正的程序员努力. http://www.cnblogs.com/lwr-/p/5199030.html?fr

这一学期,开始了健民老师的软件工程概论课,早就听闻健民老师的软件工程概论课很牛,听了两节课下来,果然如此. 老师引用了<构建之法>书中的理念,认为软件不是靠着理论堆积而成,而是一个个实发的项目组成的,在课上,老师引用了书中的例子来形容学生和老师的关系. 1.餐馆服务员/食客 2.老板/雇员 3.保姆/幼儿:像保姆一样操办一切 4.哥们/哥们:一起混吧 5.路人甲/路人乙 6.狱警/犯人:想法点名/想法逃课 7.健身教练/健身学员:鼓励成长 当然,大家都更加喜欢7,希望能够获得更多的编程技能和知

<构建之法>第一章阅读笔记 大马哈鱼洄游模型 软件工程按照经典的瀑布模型 1. 需求分析 2. 设计阶段 3. 实现阶段 4. 稳定阶段 5. 发布阶段 6. 维护阶段 事实上在现实世界中,软件工程师的职业发展与瀑布流程刚好相反 毕业进入公司(或者实习生),开始学习并维护一些已有的软件(维护阶段),主要由自己的师傅(Mentor)带领 能够在项目中改一些 Bug,然后发现发布小规模的更新版本(稳定/发布阶段),联系重构,开始和其他同事打交道 有机会负责重写一个较小的模块,没有多少文档,自己要写

阅读第一章所得: 就像上半学期学到的那样:程序=数据结构+算法,通过阅读<构建之法>的第一章后,更加清晰的认识到:软件=程序+软件工程.也清楚的意识到我现在的水平也只是略懂皮毛,书中也提到了软件开发的4个阶段,分别是玩具阶段.业余爱好阶段.探索阶段.成熟的产业阶段.我现在就是处于玩具阶段向业余爱好阶段的过渡阶段,即写程序练习,并用新的语言如JAVA尝试C语言的程序,这么说来......大一至今是处于玩具阶段的状态.如果大学时期好好学习,按部就班,即精通老师教授的语言,那么等到毕业时,就像书中说

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

问题1:敏捷开发在现阶段急于使用或试行,会不会得到相反的结果? 对于并没有体验或者初步体验过软件过程的学生来说,直接运行在高强度的开发模式和工程模式下会不会出现化学中的“钝化”现象,即跟不上或者勉强跟进时产生对这样的模式产生抵触心理.就算没有直接的数据证明即使出现了“钝化”问题也能让所有人受益,最好也能解释或根据一些教学或工作经验,证明或推理其可行性. 问题2:邹欣老师担任的是微软亚洲研究院技术创新组研发主管,所有整套书的知识和体系结构都有微软.NET开发流程的痕迹在里面,虽然软件流程并不限制与

最初接触软件工程时仅仅以为软件工程就是写代码,只要编写的代码能够符合题目要求.运行成功就算是成功.<构建之法>用生活中的一个实例启发我什么是程序,什么是软件,什么是软件工程.程序指的是源程序,就是一行行的代码.能满足各种功能的是应用软件.写代码并不等于软件开发.软件的开发也是复杂的,需要经过:构建管理.源代码管理.软件设计.软件测试.项目管理等相关活动.概括为:软件=程序+软件工程.在阅读中我明白软件开发中应用工程化原则的重要性. 在读第二章阅读时我更是一头雾水,到底什么是单元测试,具体应该如

快速阅读完<构建之法>后的几个疑问: 1.成长与代码量是什么关系?代码量与工程师的水平呈现什么关系? 2.课本上对结对编程很赞赏,而实际工作中,两个人结对编程是不是浪费了一个人的工作量,有多少比例公司或者部门领导允许两个员工结对编程? 3.书中讲的敏捷流程变化大,效率高,但我感觉这只适用于小团队,人少才好管理,如果很多人的团队,能否在用敏捷流程? 4.如何避免产品开发后期有重大修改? 5.如何进行风险管理?能否用更多的例子来讲解它.