• 在软件开发阶段的日常管理，要尽量减少非开发的时间，不要动不动就开“全体会议”，因为团队成员们的自我时间管理也很重要。像我们团队，一开始听说每天都要开例会，我觉得这样是不实际的，因为开例会时，自己总得要被逼着说进度。如果天天开例会的话，自己动手研发的时间就被限制了，没有太大的跳跃进度，天天开例会的意义也就不大。有些优秀的团队（例如Google公司的一些团队）规定一周要有一天是不能开会的。但同时我们也不鼓励“封闭开发”，大家应该要有更多的自由交流的时间，这样团队成员们就会更乐意在无拘无束的环境中提问和分享。

• 对于每日构建，一旦工作忙起来，我们确实没有时间去管构建的问题。我们团队有时集体开会的时间是在晚上，一般我们讨论得火热就会忘记时间，直到外界突然干扰（教学楼关灯锁门）才想起到应该散会了，而回到宿舍后又由于网络的原因（断网）没法及时更新我们团队讨论的进度，从而可能会导致第二天后因为还有其它事情要处理而忘了，最终就没有把讨论的内容更新出来。所以，就像书里“阿超”说：“在理论上，理论和实践是一回事，而在实践上，理论和实践是两回事”。

• 我们做程序时要懂得并熟悉构建，因为构建是核心，就像小工做建筑时要懂得并熟悉搭脚手架，球员在比赛时要懂得并熟悉运球。

• 工作时要懂得平衡进度和质量。我一直有一个困扰：像我们团队这次做 男神女神配 社区交友网，我负责主页的设计及内容模块，有个队友负责网站的注册和登录模块，有个队友负责搜索模块，有个队友负责活动查看模块。但是一个项目是一个整体的，每一个人所负责的每一个模块都必须关联起来才能成为一个整体，例如我的主页完成了50%后，为了查看整体效果，发给队友与他的模块连接起来，如果对方在我的程序上修改了部分，然后同时我也继续编写我剩下的内容，双方都在我那个原本完成了50%的进度模块上做了修改，那接下来的工作，到底用谁的？实际上两边的修改都要用上，然而我不可能等对方修改后再继续做下一步工作，而对方也不可能等我完全100%做完我负责的模块后才查看修改或连接，因为这样会导致工作效率大大的下降。这个我觉得这个仿佛有点像我们学习 操作系统 时的那个 售票系统 ，几个窗口同时都要给顾客售票，总得有一个机制管理剩余的票数，因为不可能能同时几个窗口成功售出同一张票。

第十二章（用户体验）

• 计算机软件的用户界面（UI）和用户体验（UX）是一个有着丰富内容的学术领域。我个人觉得用户界面设计的工作并不是打打补丁、让界面好看而已，而是一个充满创意和非常潇洒的工作。

• 用户在使用软件时，其实第一印象是很重要的，这很大机会会影响到用户是否会把该软件进行二次使用，但这也并不意味我们设计软件只设计一个外表光鲜的东西，毕竟一个外表漂亮而没什么实际用处的空壳是没有多大的用处的。

• 我们要做一个好的设计，就要做到：

         ♠谁是你的目标用户？

       ♠他们会在什么时间使用你的产品？

       ♠目标用户会在哪里和你的产品交互？

       ♠你的产品是什么？而用户的期待是什么？

       ♠用户为什么要使用你的产品？他们的动机是什么？

       ♠在众多竞争产品中，用户为什么会选择你的产品？

       ♠用户是如何与你的产品发生交互的？他们怎么用？在使用过程中有出现什么问题吗？

• 我们要多从用户的角度出发，同时我们也要多了解自己写的软件，而我们的心里、技术能力和一般用户有很大差别。

• 用户体验设计时要尽量降低用户的认知阻力。Vim我有用过，起始真么不知道怎么用，敲键盘时，电脑就一直“叮叮叮”地响，后来才发现要在键盘输入“i”后才可以进入插入模式。我觉得这对于刚接触这个软件的用户来说，阻力挺大的。