今天浅读了<构建之法>的前四章,稍微有一些个人的见解与感受 第一点即是开篇提及到的算法与数据结构这门学科开设的必要,大二上学期学习了这门课程,就我个人目前接触到的层面来看,几乎可以说用不太到课上学习的一些算法相关的知识.但是这也并不意味这算法.数据结构这门课不重要,如同一句其他行业的玩笑话所说,没有人会按书上说的情况生病,那就代表着医学不需要教科书教学吗,必然是不对的.用一个拿到多家大厂offer的学长的话来说,刷题是我们和其他竞争者拉开差距的一个重要途径,尤其是对于我们这样一所学校的学生来说…

第九章:项目经理 是讲项目经理的作用功能和重要性,书里面主要讲的是微软的PM(Programe Manager)和其他团队PM(Project Manager)的区别,还介绍了PM的能力要求以及人物,不同的PM有不同能力,一个项目有多个PM我觉得还是挺科学的毕竟每个人能力是有限,找到优秀的战斗力很重要,适当运用人才.我们的团队作业也有一个PM,作为一个PM得到大家支持很重要也要带动大家一起参与.一个无法得到团队成员支持的项目经理,大概也无法得到领导的支持. 第十章:典型用户和场景 这一章主要讲诉…

对于书中所提到的结对编程我还是有些许感受的,在大二上学期我就有和同学合作,共同完成编码.有时候可能是我来做非常非常简易的前端页面部分,然后给同学一个基础框架,让同学往框架里面填充,时而遇到问题我再来沟通解决:也有时候是我来完成与数据库的交互部分,让同学完善service层.总之就是把一个问题分解,共同完成目标,相较于个人,这种方式完成速度更快,发现问题后解决的效率也更高.其次就是老生常谈的需求分析,我自己而言做不好这方面,不太会提取主干,更多的还是根据别人的经验,需要在架构分析设计上下一定的功夫…

在阅读<构建之法>之前,我所认为的软件就是通过c,c++等语言编程,制作出的一个能满足人们操作需求的一些代码,认为一个好的软件工程师,就是能够在很短的时间之内,最快的根据需求写出几段代码程序的人,认为一个完美的软件就是能够满足人们的要求永远都不出bug. 而邹欣老师在<构建之法>绪论中提到,软件=程序+软件工程,程序是软件的基础,而软件工程师吧系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程.简而言之,就是将软件开发.运营和维护的流程进行系统统一化,从而提高软件开发…

最开始听见杨老师说邹欣老师这个名字总觉得很熟悉,后来看见博客上老师的头像恍然大悟,原来机缘巧合已经在微博上关注邹老师许久,一直觉得邹老师是个很有意思的人,兴趣一定十分广泛,看了老师的书确实能感觉到邹老师是个很独特的作者. 这本书与以往的软件工程书籍相比确实不同.<构建之法>首先让我明白了软件工程到底是什么,也让我第一次觉得要对自己做出来的东西负责,让我的想法突然从一个学生变成了一个知道对自己东西负责的人(此处不敢说自己是工程师).作者前面的篇幅一直在强调团队合作,我虽然一直觉得合作很重要,但是…

IT行业的创新: 1.创新的迷思: 灵光一闪现,伟大的创新就紧随其后:大家都喜欢创新:好的想法会赢:创新者都是一马当先:要成为领域的专家,才能创新:技术的创新是关键:成功的团队更能创新 2.创新的时机: 赢者通吃.螳臂当车.只先一步. 我们要遵从技术成熟度曲线:技术触发期.期望膨胀期.迷茫期.低调发展期.主流发展期 3.创新的招数: SWOT分析框架.动量和加速度.技术产品的发展周期.效能过剩和竞争的各个阶段.影响产品竞争的各种因素(产品行业的因素.公司和市场因素.团队执行因素.产品的价值因素)…

 <构建之法>第四&十七章读书笔记 一．         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,…

本周主要对<构建之法>中的一部分进行阅读. 一.软件与软件工程究竟是什么? 本书的概论部分就指出“软件 = 程序 + 软件工程”.而我们这门课的名字就叫“现代软件工程”.其实在上课之前,我对这门课存在一定的误解,我更多地把这门课归入“程序”部分.在我原来的理解中,像电设二一样,自己学新知识(当然很多在电设一已经学过),然好以团队的形式独立去完成一个项目,只不过电设属于硬件(也包含一部分软件),而软工则纯粹是软件了. 而上课之后却和我预想的不一样.首先每周读书笔记这个就让我非常不解,有些推荐书籍…

这段时间我阅读了<构建之法>的大部分章节,包括个人技能.软件测试.用户体验和需求分析等相关内容.之前的个人作业和结对作业结束后,我们的工作重心终于转向了团队项目,作为团队中前端组的组长,我和组员们每周碰面.共同商讨团队项目细节并一起实现.因此,书中与团队项目开发有关的第五章.第六章的“团队和流程”“敏捷开发”两部分内容最令我印象深刻.受益匪浅,本次读书笔记主要记录阅读这两章的心得体会. 1.团队模式和开发流程: 团队项目的开发与团队工作模式(分工模式)和整体开发流程息息相关.我们的团队在决定开…

注:本文档已提交Github,地址是这个 欢迎大家通过PR的方式或者在本博客下留言的方式随时补充意见和建议,我们会持续更新 书中7.2.4的表7-1 MSF团队模型和关键质量目标里面提到的"出口条件"是什么意思?比如开发的出口条件是:我们是否按照功能说明完成了各项功能. 书上8.8.3提到了一个软件团队一开始预计每次天做30小时工作量,做到一半时每天做15小时工作量.我自己在之前的软件编写和大作业上也常常有这样的烦恼.做到后面就要做大量的测试工作,很劳累.和针对测试出的错误修正并确保正…