构建之法三、四、五章总结

趁着五一小短假期间阅读了这三章，让我感觉想要成为一名软件工程师的路还要很长，在我面前就出现了一条分叉路:即是成为一名个人能力优异但不顾及团队成员理解与否的程序员还是个人能力一般但会结合团队人员的理解能力去编程的程序员，如果两者都能取长补短呢？或许太过于理想化了，每个人对于程序都有自己独特的程序风格，即便是使用同一种规格下的编程风格，但是每个人执行起来总会添加有自己的东西，像是变量名的取向，函数的调用，还有类似的等等。如果是我的话，可能会选后者，毕竟以后加入了团队以后，首要的宗旨是服从团队的安排，不要抱着个人英雄主义的想法，因为这会让团队内部存在瑕疵，或许一开始还没什么，但久而久之存在的问题就会越来越多，等到最后补不过来的时候，团队就等于完结了。为什么现在的创业团队这么容易解散？因为看不到业绩，看不到继续下去的希望，就会有想退出的想法，一旦有人开始退出了，剩余的也就不想继续了，以至于一个团队就这样名存实亡了。生活中的团队是如此，软件工程中的团队也是如此吧？

时间： 2024-10-10 06:51:06

构建之法三、四、五章总结的相关文章

读《构建之法》第五章

第五章说的是团队和流程, 什么是团队? 团队有一致的集体目标,团队要一起完成这目标,一个团队的成员不一定要同时工作,例如接力赛跑. 团队成员有各自的分工,互相依赖合作,共同完成任务. 软件团队有许多模式,例如:: 主治医生模式 明星模式 社区模式 业余剧团模式 秘密团队 特工团队 交响乐队模式 爵士乐模式 功能团队模式 官僚模式 开发流程: 写了再改模式 瀑布模型 瀑布模型的各种变形 Rational Unified Process统一流程(RUP) 老板驱动的流程 渐进交付的流程

构建之法（第五章 团队和流程）

第五章主要讲了典型的软件团队模式和开发流程.以及我们也将讨论团队模式和开发效率之间的一些关系.   1.非团队和团队    团队的主要特点: 1)     团队有一致的集体目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作. 2)     团队成员有各自的分工,互相依赖合作,共同完成任务. 2.软件团队的模式 1.主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作. 2.明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的

《构建之法》第五章

第五章 团队和流程 5.1 非团队和团队 团队共有特点: (1)团队有一致的集体目标,团队要一起完成这目标. (2)团队成员有各自的分工,互相依赖合作,共同完成任务. 5.2 软件团队的模式 1.蜂窝模式 2.主治医师模式 3.明星模式 4.社区模式 5.业余剧团模式 6.秘密团队 7.特工团队 8.交响乐团模式 9.爵士乐模式 10.功能团队模式 11.官僚模式 5.3 开发流程 1.改了再改模式 2.瀑布模式(从瀑布模型开始的各种模型都有一个共同点:重计划.重事先设计.重文档表达) 变形:生

《构建之法》第五章读书笔记

第5章 团队和流程 一.非团队和团队 团队的共同特点: 1.团队有一致的集体目标,团队要一起完成这目标.一个团队的成员不一定要同时工作,例如接力跑. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 二.软件团队的模式 软件团队的模式最初是混沌的一窝蜂的形式:一群人开始写代码,希望能写出好软件.随着团队的成熟和环境的变化,团队模式会演变成下面几种模式之一. 1.主治医师模式:这样的软件团队中有首席程序员,他负责处理主要模块的设计和编码,其他成员从各种角度支持他的工作(后备程序员.系统管理员

《构建之法》第五章读后感

   团队 团队的特点: 1.团队有一致的集体目标,团队要一起完成这个目标.一个团队的成员不一定要同时工作. 2.团队成员有各自的分工,互相依赖合作,共同完成任务. 软件团队的模式: 1.主治医师模式 首席程序员"主刀"(负责处理主要模块的设计和编码),其他成员"为主刀医师服务"(从各种角度支持他的工作). 2.明星模式 主治医生模式运用到极致,可以蜕化为明星模式. 3.社区模式 社区很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬. 4.业余

构建之法第四章学习心得

今天我学习了构建之法第四章,主要讲述了两人合作的理论和知识点.合作,无论在任何领域,都是不可缺失的,往往能产生不可替代的效果.同样在软件设计中也是如此,经过我的学习,我了解到软件设计中两人合作主要包括包括代码规范.极限编程.结对编两人合作的不同阶段以及影响他人的技巧. 其中最让我印象深刻的是代码规范.包括:代码风格规范和代码设计规范,代码风格规范主要是文字上的规定,看似表面文章,实际上非常重要:代码设计规范牵涉到程序设计.模块之间的关系.设计模式.等方方面面的通行原则: 同时,我了解了代码风格规

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

Gradle 1.12用户指南翻译——第三十五章. Sonar 插件

本文由CSDN博客万一博主翻译,其他章节的翻译请参见: http://blog.csdn.net/column/details/gradle-translation.html 翻译项目请关注Github上的地址: https://github.com/msdx/gradledoc/tree/1.12. 直接浏览双语版的文档请访问: http://gradledoc.qiniudn.com/1.12/userguide/userguide.html. 另外,Android 手机用户可通过我写的一个

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

构建之法1,5,17章读后感触

看了构建之法1,5,17章的内容,我对团队有了新认识.在一个团队中,不同成员来自五湖四海,为了一个目标,走到了一起.所以,需要的是全身心的投入.但人资历,成绩,口碑有差别,这就有了好/中/差,三等待遇,所以付出的努力不同,得到的待遇自然而然也就不同. 在我们这次软工中,我们需要一个真团队,高效的团队,来互相提升帮助我们完成这些任务.在这过程中,我们需要负担起身上的责任和要对伙伴负责.这样才能让团队走向成功