上海麦思博培训总结

“什么是真实？”，如果你指的是能触到的、闻到的、看到的、听到的，那么真实只不过是大脑所传达的电子信号而已。

那么软件世界与现实世界的界限又在哪呢？

 

工作：

1 、工作不能一直总凭着感觉做，按照命令做，没有原则、没有方针的做。

需要慢慢学习、积累经验、教训 , 需要思考，形成自己的体系，方法论

需要思想（ OO ）、原则（ SOLID ， KISS ， DRY ）、方法（ UDD ， TDD ）、工具（ UML 、重构、。。）

 

架构：

架构并不应该完全是由需求一步步分析出来的，需求并不是架构的基础。

需求只是架构的检验手段，架构应该由愿景、成本、公司战略、决策等、产业等而来。

 

完全由需求一步步分析推导出来的架构，会框住架构，如果没有想象力，可能导致该架构可能只满足该需求。
架构重要的不应该是复用性，灵活性，应该是独特性，能创造价值。

架构应该有愿景而来，加上想象力和知识。

架构不能假设某些事物是正确的，而是用一些事实和假想来推翻一些假设

 

架构比喻：

火锅店的桌子挖一个洞，就是桌子的架构，客人来了就可以放锅子，上菜。

桌子板是什么样，并不是因为桌子腿是什么样的

 

敏捷团队：

CMMI 有它的生存环境和好处，

SCRUM 也有它的适用环境：短频快，软件复杂程度很高（可参考：复杂程度评估模型）

“简单”的软件，可能就不一定需要 SCRUM

 

用 SCRUM 要清楚：你为什么用 SCRUM ，解决什么问题？

SCRUM 的团队、人的必须的条件：自律，开放，激情，承诺

 

使用全套的 SCRUM 的对团队和个人要求很高，有一环节或则某一个人，就会导致并不能达到想要的效果。

全套装备并一定能让你学会游泳，造物必先造人

 

设计：

TDD 不是 Test Driven Development ，而是 Test Driven Design ，测试驱动设计，而且关键不是 T ，是 DD 。
TDD 和 UML ，的目的是一样，都是为了表达用户场景，固定用户意图，【为什么，谁，多少，时间，位置，怎样】【固定了，你下一步走的才有自信】

只是表现形式不一样，一个是用代码，一个是画图。

当是一个新人，设计能力有限时，写代码比较容易，用 TDD 效果比较好。
TDD 用多了后，会积累一些设计方面的经验、原则和方法，这时候可以先设计一部分，再 TDD 一部分。
如果你的设计能力很高，有很好的设计方法体系的时候，这时候可以先做好设计。

 

重构有两种方式：从上到下，即适用开发原则： SOLID ， KISS ， DRY ；

从下到上：发现代码异味

 

TDD 与重构绑在一起的，才能发挥强大的威力

 

测试：

软件测试不能完全保障软件的质量

软件测试只能说明从某些方面说明软件质量的好坏

天天称体重，并不能让你减肥，只能说明你有没有瘦，有没有胖