构建之法——第一、五、17章

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

第一章   概论

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

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

 

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

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

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

 

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

 

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

       我构建，故我在。随着对软件工程的深刻理解，未来必需要造成一个大局观。

 

 

第五章 团队和流程

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

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

      

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

 

 

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

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

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

       若是要我在白菜萝卜里选，确定选白菜，本身作好，再去帮助同事，踏踏实实作人作事，积极沟通交流，应该对咱们这些大多数人是最好的选择。