（十二）

团队开发模式. 这学期我们主打的就是团队开发模式.对于团队而言,我算是有了一点儿基本的理解.书中什么各种团队模式,明星模式,秘密团队,特工团队.但是我发现在我身边的都是一个人担当起整个团队.文中说这是主治医生模式的退化版.就是“一个学生干活,其他学生跟着打酱油”.这也算是团队的一种把.对于团队的沟通也是很重要的.我们一起开发设计,有时候我们的沟通确实很不到位.导致工作进度一直跟不上计划.很多时候也就是30分种解决的问题,但是就是一直拖着. 开发流程被采纳的是瀑布模式.之前看大道至简的时候也提到了

书,人人都可以去读,但是有的人就读不懂.读不通.读不进,甚至越读越糊涂.这里说明读书是有得法与不得法的区别的,但要相信方法总是可寻的.读书不得法,就如上面所说的那样,反之,也有不少人把书读懂而且读通了.读书的方法,也不止一种,现在选列了古人读书十二法,以供借鉴与参考: [法一]."思·问·习"读书法.这是孔子主张的读书方法. [例]1．重视思考.在学习过程中,要动脑筋.他说:"学而不思则罔,思而不学则殆."(<论语·为政>) [例]2．不懂就问.读书在于

大二下学期已经过去两周了,个人感觉,课程方面压力与动力并存,相信一步一步走下去终将得到自己的一份收获. 这几天阅读了<构建之法>的第一,二,十六章,我个人的阅读速度应该属于比较慢的那种,遇到什么不确定的,不理解的概念总要停下来好久,各种百度,否则继续阅读的时候总有种急躁的感觉,老想着前面的停顿,到头来一头雾水,还是跑去理解前面的概念.作业中关于精读的part1,2,3一开始我觉得可能不适合我这种节奏慢又钻牛角尖的,但贵在尝试,以前我的阅读习惯是只读一两遍,虽然第一遍把不理解的概念都慢慢弄明白了

<构建之法>第一.二.十六章疑问 我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章  概论 软件=程序+软件工程 扩展:软件企业=软件+商业模式 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营.和维护上的过程.软件的特殊性有a.复杂性 b.不可见性 c.易变性 d.服从性 e.非连续性.软件工程与计算机科学的区别:计算机科学中与实践相关的部分,都和数据以及其他学科发生关系:

这周看了邹欣老师<构建之法>的1,2,16章,获益匪浅.这本书写得妙趣横生,用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念,让我对软件工程有了初步的了解:原来开发软件并不是我们想的那样简单:上手直接敲代码就可以了,而是会有一套详细的流程规范.下面是我看书时的一些心得笔记,和一些无法自己解答的疑惑,烦请各位老师批评指教. 第一章: 笔记: 软件=程序+软件工程,是否可以通俗地理解为,程序只是死的机器的东西,为什么做(需求分析),做什么(软件设计),做完后这东西是否可行(软件测

第十一章的内容是软件设计与实现. 在第一节中,讲的是关于分析和设计方法,向我们介绍在"需求分析"."设计与实现"阶段."测试""发布"阶段该搞清楚的问题. 在第二节中,讲的是关于图形建模和分析方法.在表达实体和实体之间的关系时,可以用到思维导图(Mind Map).实体关系图(ERD).UCD ;在表达数据的流动时,可以用到DFD工具:在表达控制流的时候可以用到FSM工具:前面提到的这些图形建模方法各有特点,UML却可以有一个

第十一章 问题:为了避免误解,我们是不是可以把我们理解的告诉用户,并且最好是图像的形势或是其他方式展示给用户? 第十二章(P230) 问题:为了让用户满意,是否可以在用户的原来基础上创新,体现出一些人文关怀,请问这是一些好的想法吗?还是这是程序员的顾忌?

第十一章 问题:为了避免误解,我们是不是可以把我们理解的告诉用户,并且最好是图像的形势或是其他方式展示给用户? 第十二章 问题:为了让用户满意,是否可以在用户的原来基础上创新,体现出一些人文关怀,请问这是一些好的想法吗?还是这是程序员的顾忌? 第十三章 问题:(220)文中提到用户需要帮助,但是用户没有那么蠢.是一个人非常典型的例子,但是这个例子问题太过突出.有时候就算我们记住了用户的选择,考虑了用户的感受,但是还是难免把握住那住个度,那么我们如何准确的把握住那个度.

关心自己更关爱你 “本是同根生相煎何太急”,大家都是程序员,规范自己的代码结构不光方便自己还方便看代码的人. 还记得大二的操作系统上机,我的代码因为是在vim里编写的,实在是懒得缩进,大括号也没有对齐,结果在编译时候出错,当时找错误真是找瞎了眼.虽然结果最终是正确了,但是助教检查的时候还是善意地指出了我代码结构的规范性问题. 所以看到邹欣老师在<构建之法>第四章指出的代码规范性问题,给我的共鸣还是很明显的.我认为,程序员在成长的过程中,不仅是知识的不断堆砌,更重要的是不断规范自己的过程.书中指

先占个位置,下次翻译 :p When designing your application to support a wide range of screen sizes, you can reuse your fragments in different layout configurations to optimize the user experience based on the available screen space. For example, on a handset devi