构建执法阅读笔记六

通过阅读构建之法,这一次了解了代码的规范性,在这之前的编写程序的时候,由于对英语的标准命题知道的不是太多,在命名德时候多数用汉语拼音进行命名,自我感觉提方便,但是阅读构建执法的代码片发现这是不好的习惯.其次平常编写程序会表明姓名和日期,进行大框架的解释,便于日后进行来了解编写的内容.同时注意缩进,行宽,括号的使用,分行的表示作用.但是了解后,含有许多需要改进的地方:例如程序设计.模块之间的关系.设计模式,当错误出现时如何进行处理.了解结对编程,两个人员相互肩并肩.平等地.互补地进行开发工作.就像

对于“程序=数据结构+算法”之前已经反复去讲解和思考了很多遍了,似乎是有一些理解,二叉树是数据结构,周游的实现细节是算法,这加起来就是程序吗?所有的程序都是这样子的吗?在JAVA和一些语言中并不会出现指针,那二叉树又有什么用呢?我们还要去学习它了解它吗?或者换一种说法,现在网络如此发达,诸如程序之类在网上随处都能搜到,我需要的时候可以直接拿来用,为什么还要去学习那么复杂的数据结构呢?我们真正需要会的程序代码是什么?究竟需要达到怎样一个水准? 在读了一部分<构建执法>后,邹欣老师的思想启发我对什

第九章 项目经理 项目经理的作用 协调团队成员的工作内容,把握产品定位和方向,解决用户痛点,调节团队中的矛盾,总控团队的进度,使一个团队加强交流.在一个团队中,项目经理是必不可少的一个重要角色.一个合格的项目经理需要良好的沟通能力,通过和团队成员的沟通交流,使一个团队能够有效地运转.同时,项目经理还需要及时的了解用户需求,精确地把握软件的定位与方向.而且还需要有长远的眼光和独特的见解,是产品的功能更加完善 第十章 典型用户和场景 在做一个产品之前,我们应该明确产品所需要服务的用户,为不同的用户建

接着往下读两人合作.在IT行业,我们所说的敲代码,即编程是我们的基础能力,是衡量我们是否专业的标准,但是编程能力高并不代表着我们的职业素质就高,所谓的职业素质就是我们的代码个苏是否规范,是否有严格的缩进,在模块中是否有{}的划分,结构是否严谨工整,代码的思路是否清晰等等.我们刚接触这个行业,学习编码时间也不长,因此我们应该从现在开始从每一个程序中做起,严格规范代码,以一个专业的素质标准来衡量要求自己,从一开始就养成良好的习惯,提高自己的职业素质,显得更加专业.在我们写完代码后对代码的复审也是必不

本次阅读笔记写一下<软件构造十步走>最后一篇<组织篇>. 本篇共分为四章,分别是建立需求分析体系,需求分析部门的组织结构,需求分析部门的管理工作,需求分析部门的业务工作. 首先是<建立需求分析体系>. 长期以来"轻业务.重技术"的理念根深蒂固,而解决措施是建立一个专业从事软件需求分析的独立部门来承担这项工作.此部门是介于业务部门和技术部门之间的,专门负责对组织自身业务.客户业务.客户对象和竞争对手的研究,然后将其转换成提供给技术部门的软件需求规格说明

今天看完构建之法,开始写最后一篇感想,在开始写对构建之法这本书的感想之前,我想先写一下对今天软件工程概论课上老师讲的话的一些感受.今天上课一上来老师就说我们离“人”还差很远,在听完之后发现还真是这么回事.那么,人是什么,人分为做事的人和不做事的人,而仅仅当一个做事的人就可以了吗?当然不行,做事的人又可以细分成做真事的人,做假事的人和假装做事的人,你想当哪种人呢? 言归正传,今天看了构建之法中有关软件发布这一部分,联想到自己团队也要发布bata版本,感觉还是应该仔细看一下的.在软件生命周期的最后阶

架构之美--企业级应用架构(四) 给我看你的流程图而隐藏你的表,我仍然莫名其妙.如果给我看你的表,那么我将不再需要你的流程图,因为它们太明显了.                                                                                                                                                                                  

1.我认为在团队合作的过程中,编写程序之前,应该要首先规范命名,通过第四.五章我知道了,作为一个软件工程师不仅要有出色编程能力还要有对代码注释的意识,因为在团队工作中,你如果不注释你写的代码,那么当你有事,别人接手你的代码时,就会遇到很大的问题,他需要一点一点读懂你的代码,这会对团队的进程造成影响.我们还要在编写程序前先要对代码的命名和缩进等问题进行同一的规定,这样会使得团队的进程得到很快的发展. 2.在团队合作中,刚开始也许我们并不知道应该怎样进行合作,通常我们都是自己编程,没有和其他人合作的

今天主要查看的是:需求工程组织篇呼吁建立需求分析体系 "千夫所指人人相轻"这种不重视软件需求的观念体现在一个个软件项目只是表象,其症结在于长期以来"轻业务.重技术"的理念已根深蒂固.需求分析部门的组织结构 "什么样的工作职能,将决定建立什么样的组织结构".需求分析部门的管理工作 需求分析部门的管理思路是"抓两端.促中间.一条业务线.专业化分工".需求分析部门的业务工作 需求分析部门的业务工作主要由需求业务和需求开发业务两部分组