构建之法——第1、5、17章

                                   探讨对理想团队模式构建的设想以及对软件流程的理解

第一章   概论

程序=数据结构+算法  这句名言大家都知道。可是，作者连问三个问题，让我意识到，做一个软件工程师，绝非写非常棒的程序这么简单，程序只是软件的冰山一角，软件背后还有工作量更为庞大的一系列工程，要做好这一系列背后的工程，才有一个好的软件产生。作者后面也对这三个标志性问题做了回答，程序是基本功，软件工程决定软件质量，商业模式决定软件企业的成败，从业者和企业的职业道德规范影响了软件用户的体验。

程序员阿超的略带幽默的例子，非常生动形象的解释了，“程序“是什么，而“软件”又是什么。我来稍微总结一下。

 

简单的程序        用户        应用软件       加入平台         软件服务

一个程序员       ——>    一个程序员       ——>              一个程序员

一袋烟的功夫      加需求     熬个夜         再多点要求     太复杂，无能为力……

 

这个例子，展现了软件工程对于做好一个软件有多么重要，当然软件工程绝对不是一个人的事，肯定要有一个完整的团队，乃至到了软件服务阶段，需要一个软件企业。通过这个例子，也展现了很多软件工程的基本概念，源程序、数据、构建、源代码管理、配置管理、质量保障、需求分析、软件测试、程序理解、软件维护、服务运营、软件生命周期、软件项目管理、用户体验等等。做好软件工程，那么就要考虑商业模式和职业道德规范，一个良好的软件企业也就应运而生。

 

       软件工程，顾名思义，就是把软件项目做成一个工程，形成一个工程化的产业。先形成一个流程，再用软件工具实践操作，解决问题，让软件更加人性化。

       我构建，故我在。随着对软件工程的深入理解，将来必须要形成一个大局观。

 

 

第五章 团队和流程

       “非团队”，简单来说就是一个和尚有水喝，两个和尚抬水喝，三个和尚没水喝。

       “团队”，简单来说就是各有所长，分工合作，最重要的是交流。不同的团队模式各有利弊，比较常见，也比较成熟的是功能团队模式和老板驱动模式，前者成员自由交流频繁，后者目标明确。

      

对于软件开发流程来说，最重要的并不是编码，而是需求分析。软件项目，大多都是由用户发起，最终回到用户。好的开始等于成功的一半，需求分析做的好坏，直接决定项目的成败。

 

 

第十七章 人，绩效和职业道德

       团队，说到底还是有一个个人组成的，人的能力和素质，才是最根本的。不论做什么岗位，都要像“猪”一样踏踏实实把任务做好，当好这个做事的P1.。

团队也遵循着正态分布原理，一部分最好的人，一部分最后的人，大部分是一般的主流，区别对待还是让员工们比较容易接受的，队友评估应该是最开明公正的吧。

       如果要我在白菜萝卜里选，肯定选白菜，自己做好，再去帮助同事，踏踏实实做人做事，积极沟通交流，应该对我们这些大多数人是最好的选择。