本周选读邹欣老师的<构建之法>第16章——IT行业的创新. 邹欣老师将本章话题分成五个部分来阐述:创新的迷思.创新的时机.创新的招数.魔方的创新.创新和作坊,博主认为时机和招数这两个部分在编辑上不是很和合理,时机部分的内容不够切题,招数部分却出现了讲时机的内容,以下会具体说明. 创新的迷思尝试为“外行人”拨开迷雾,打破普遍存在的错误印象.未曾涉身IT工业界之前,我们常常认为对一个优秀产品.乃至一个新的商业生态的诞生,最关键的是灵感,是一个颠覆性的好想法,但现实世界不存在这种一蹴而就的好事.邹欣…

Maven是我们在做Java开发过程中用经常用到的一个辅助工具.本篇博客是我学习Maven的一个记录博客,学习过程主要参考<Maven实战>这本书.同时也参考了Maven的官方文档. 1. Maven简介 1.1 什么是Maven Maven是一个开源的Java项目构建.依赖管理和项目信息管理工具. 1.2 何为构建 所谓构建是指项目编译.运行单元测试.生成项目文档.打包和项目部署等一系列操作. 1.3 Maven的优点 Maven是一个优秀的构建工具:帮我们规范了项目的构建过程,我们不在需要…

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

第十三章(软件测试) 要知道为什么有软件测试,首先需要知道软件开发,软件开发者一般都很难检查出自己的错误,所以才需要另外一个人测试,所以软件测试就诞生了. 书本介绍了很多测试方法,各有各的优缺点,至于目的,就是测试者尽最大的努力找出软件中的错误和缺陷. 当测试时发现好多Bug该高兴还是该忧愁? 并不是说测试出Bug后该软件就是不好的软件,因为测试就是为了证明程序有错,而不是证明程序无错误. 一个成功的测试是发现了至今未发现的错误的测试. 第十四章(质量保障) 从第一章我们可以总结出:软件质量 =…

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

<构建之法>第五章用体育运动等团队例子引出软件开发团队的形式,用更加生活化.形象化的例子让读者更能理解软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.瀑布模式:当软件行业还在年幼的时期,它从别的成熟行业借用了不少经验和模型.在那些“硬”的行业中,产品…

软工读书笔记  week 9                 ——<构建之法> 最近的三周我们正式开始我们的项目.然后我也把<构建之法>中的相关章节再拿出来读了一番.以下是一些感悟. 首先就是第十章“典型用户和场景”.书中提到,我们作为设计或者开发者,往往会以自己使用产品的习惯和熟悉程度来出发设计,但我们永远不能代表用户.搞一个“典型用户”会让我们考虑问题从用户的角度出发.由于我们正式开始项目后的第一周就是继续对用户做需求分析,这一章对我们有很大帮助. 我们也要考虑我们的典型用户.…

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

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

从chapter4至chapter6,围绕着构建过程的合作讨论构建之法,而合作与个人工作的区别却以一个微妙的问题为开端:阅读别人的代码有多难? 两人合作:(驾驶员与领航员) 合作要注意代码风格规范与设计规范,如语句分行便于单步执行.使用“匈牙利命名法”等等.这里有趣的一点是,书中认为goto为函数提供单一出口,有助于程序逻辑的清晰体现,但是一些从事教学的教授认为goto语句影响代码的可读性,尽量减少使用,二者均有一定道理.之所以如此注重代码规范,非常重要的一个因素就是错误处理往往需要项目80%的…