虽然是作业,但是我也准备好好地评估一下自己的能力,看看自己到底有多菜鸡,好给自己一个响亮的耳光来督促后面的自我学习!所以我就好好地给自己评估下(参照第二次作业的内容):
PSP2.1 Content | Chinese/中文 | 我的技能需求 | 耗时 |
---|---|---|---|
Plan-Estimate | 计划-任务时间 | 幕布-思维导图 | 2 |
Devolopment-Analysis | 开发-分析需求 | 博客园作业指导 Github_Readme.md | 2 |
Devolopment-Spec | 开发- 设计文档 | 简书 | 2.5 |
Devolopment-Review | 开发-设计复审 | ||
Devolopment-Standard | 开发-代码规范 | Qemu调试 | 1.5 |
Devolopment-Design | 开发-具体设计 | 阅读老师示例代码 | 0.5 |
Devolopment-Coding | 开发-具体编码 | Mac_sublime C编码 | 5 |
Devolopment-Code Review | 开发-代码复审 | gcc代码(语法)调试结合Github实时更新 | 1 |
Devolopment-Test | 开发-测试 | Ubuntu下Qemu测试 | 3 |
Record Time Spent | 记录用时 | ||
Test Report | 测试报告 | 简书,博客园博客作业总结 | 1.5 |
Size Measurement | 计算工作量 | PSP评估 | 0.5 |
Postmortem | 事后总结 | 简书 | 1 |
Process Improvement Plan | 提出过程改进计划 |
可见,我真的还只是一个写程序的而不是写软件的,那些很基本的流程里面我缺了很多,基本上是想到什么就写什么。 用GitHub也不是为了团队合作,只是为了版本控制和方便多台电脑之间切换工作环境。结合上面的一些自我认知,以及《构建之法》的PSP体系介绍,我有如下的一些关于工作需要的能力的认知:
技能 | 需求 | 学习路径 |
---|---|---|
精修的编程语言 | C/C++、Python、Java、Javascript、PHP、Ruby、Shell、C#等任选 | C/C++、Python |
标准库的学习 | 很多轮子已经做好了,我们学会用就好了,公司需要对常用标准库和一些新型的框架要多认识 | C/C++11标准库,Python Flask等框架 |
调试 | 能够用常用的IDE进行单步测试,代码Debug等调试任务 | Xcode单步测试、《C++ Primer》 |
Debug | 能找出错误进行修正 | 暂未定计划 |
访问外国网站 | 很多代码的错误最开始都是在国外出现解决办法,所以要能沟通世界 | V** |
画UML图 | 能够把需求变成图形,促进更好的沟通 | 幕布-思维导图、流程图-Visio |
基础能力 | 推荐学习路径 |
---|---|
软件工程的认识 | 《构建之法》《编程之美》 |
算法数据结构 | 牛客网、Letcode、算法导论 |
效率 | 知识管理、效率软件--印象笔记+幕布 |
编程能力 | 一万小时定律 |
搬轮子能力 | Github、码云、Stack Overflow |
造轮子能力 | 由于情景是初入职,暂不考虑 |
硬件认识、计算机组成 | 这些是不可避免的,要想做高端的程序员,你连你最好的合作伙伴都认识不彻底,怎么可能? |
另外在构建之法的第三章中有说到考级之路,我在大二大三分别将计算机等级考试全部考完,另外也已经注册了中国计算机学会的学生会员,准备参加近期的CCF能力认证,我的导师给我的任务是280分,有点虚,但是听前辈说不是很困难。我尽力而为。前阵子也想去参加中级软件设计师的资格认证,但是因为那个时候还要考研,所以就停下了脚步。后来保研了已经错过了报名时间。我准备看看大四下能否参加,好取得更多的能力认证!
瀑布模型(Waterfall)
1. 文档驱动,用户无法及时了解产品的情况。因为很多程序员甚至不知道自己写的代码的全部部分,API接口的使用使得更多的源代码对于程序员不可见了!所以经过程序员的手,到达用户手中之后就更别说了。很多时候出了问题基本就没法找到具体的“事发”地址。对于后期的维护十分麻烦。这是牺牲了底层构建,实现迅速开发的代价。
2. 依赖早期调研和需求分析,很难适应在许多项目开始阶段必然存在的不确定 性。 因为毕竟是模型开发,很多时候为了追求速度会采用一些现成的代码。这样必然存在兼容性问题。而且具体的功能需要对应的模块实现。比较依赖于初期的调研,不然后期修改很麻烦。
3. 流程单一,必须要完成前一阶段的任务,才能进行下一阶段,开发过程中的 成功经验无法用于本产品。 瀑布模型这儿特点很僵硬,无法实现并行开发。
4. 测试在后期引入,对于系统存在的重大缺陷,如果在可执行程序评审之前没有 被发现,将可能造成重大损失。 求取速度所必须付出的代价!!
总结来说,基于模型的设计真的是一种对劳动力的巨大解放,让我们可以站在巨人的肩膀上安心的搬运轮子来建造自己的宝马,比如说,代码自动生成,文档自动化图形化设计这些,都能够给工程师,设计人员带来巨大的便利。但是,这种情况下如果没有Bug那还好说,但是一旦有了Bug并且没被发现,那就一定是深层次的Bug,这样的一个设计,在推广开来后所要付出的代价与前期开发代价之和,要远远的大于一步步开发自身的设计的方法,但是从头开始添砖加这种事情也只有大公司背得起,互联网公司如果不能迅速的开发出想要的功能,拿不到风投,那就可能夭折,所以说,基于模型的设计利弊皆有,但是目前从实际情况来看,还是利大于弊的。