我的工程师的能力评估和发展

Part 1

虽然是作业，但是我也准备好好地评估一下自己的能力，看看自己到底有多菜鸡，好给自己一个响亮的耳光来督促后面的自我学习！所以我就好好地给自己评估下（参照第二次作业的内容）：

可见，我真的还只是一个写程序的而不是写软件的，那些很基本的流程里面我缺了很多，基本上是想到什么就写什么。 用GitHub也不是为了团队合作，只是为了版本控制和方便多台电脑之间切换工作环境。结合上面的一些自我认知，以及《构建之法》的PSP体系介绍，我有如下的一些关于工作需要的能力的认知：

另外在构建之法的第三章中有说到考级之路，我在大二大三分别将计算机等级考试全部考完，另外也已经注册了中国计算机学会的学生会员，准备参加近期的CCF能力认证，我的导师给我的任务是280分，有点虚，但是听前辈说不是很困难。我尽力而为。前阵子也想去参加中级软件设计师的资格认证，但是因为那个时候还要考研，所以就停下了脚步。后来保研了已经错过了报名时间。我准备看看大四下能否参加，好取得更多的能力认证！

Part 2

瀑布模型（Waterfall）

优点：

• 1. 强调开发的阶段性，各阶段具有顺序性和依赖性 ，各个Part分模块，格子封装，暴露接口，然后耦合在一起组成一个整体
• 2. 强调早期调研和需求分析，推迟编码实现的观点，在《构建之法》第二章的PSP对比大学生和软件工程师的时候。可以发现，实际的操作中更注重于前期准备和后期的完善，对于编码，不仅仅是由于丰富的资源库，也是因为有了几年的工作经验可以迅速的编码。所以现实中使用模型比较多。不论是模型带动工程师，还是工程师推动模型发展，两者之间的联系都是固定的!
• 3. 提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以 在该摸板下有一个共同的指导。相同的模板下，方便后来的工程师阅读前辈写下来的模块。另外也方便任务的交接，同时还可以更方便的借用网络上开源的库，这些都是模型化设计模型的优点。

缺点：

1. 文档驱动，用户无法及时了解产品的情况。因为很多程序员甚至不知道自己写的代码的全部部分，API接口的使用使得更多的源代码对于程序员不可见了！所以经过程序员的手，到达用户手中之后就更别说了。很多时候出了问题基本就没法找到具体的“事发”地址。对于后期的维护十分麻烦。这是牺牲了底层构建，实现迅速开发的代价。

2. 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定 性。 因为毕竟是模型开发，很多时候为了追求速度会采用一些现成的代码。这样必然存在兼容性问题。而且具体的功能需要对应的模块实现。比较依赖于初期的调研，不然后期修改很麻烦。

3. 流程单一，必须要完成前一阶段的任务，才能进行下一阶段，开发过程中的 成功经验无法用于本产品。 瀑布模型这儿特点很僵硬，无法实现并行开发。

4. 测试在后期引入，对于系统存在的重大缺陷，如果在可执行程序评审之前没有 被发现，将可能造成重大损失。 求取速度所必须付出的代价！！

总结来说，基于模型的设计真的是一种对劳动力的巨大解放，让我们可以站在巨人的肩膀上安心的搬运轮子来建造自己的宝马，比如说，代码自动生成，文档自动化图形化设计这些，都能够给工程师，设计人员带来巨大的便利。但是，这种情况下如果没有Bug那还好说，但是一旦有了Bug并且没被发现，那就一定是深层次的Bug，这样的一个设计，在推广开来后所要付出的代价与前期开发代价之和，要远远的大于一步步开发自身的设计的方法，但是从头开始添砖加这种事情也只有大公司背得起，互联网公司如果不能迅速的开发出想要的功能，拿不到风投，那就可能夭折，所以说，基于模型的设计利弊皆有，但是目前从实际情况来看，还是利大于弊的。