2017软件工程实践总结做业

2017最后最长的一段话，写给软工。

第一次例会合照：（当时的PM头发还算茂密……）

1、请回望暑假时的第一次做业，你对于软件工程课程的想象

1）对比开篇博客你对课程目标和期待，“但愿经过实践锻炼，加强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为何？
2）总结这门课程的实践总结和给你带来的提高，包括如下内容：
一、统计一下，你在这门软件工程实践中，完成了多少行的代码；
二、软工实践的各次做业分别花了多少时间？（作一个列表）
三、哪一次做业让你印象最深入？为何？
四、累计花了多少个小时在软工实践上？平均每周花多少个小时？
五、学习和使用的新软件；
六、学习和使用的新工具；
七、学习和掌握的新语言、新平台；
八、学习和掌握的新方法；
九、其余方面的提高。

首先贴出软工实践的第一次做业连接：

http://www.cnblogs.com/How-Come/p/7454844.html

20170830—20171229

此次软工实践历时整整 4 个月，其中的悲喜杂陈，也只有用心去经历的人才能真正领悟。

官方地报一下数据：

• 代码行数：3500 行左右（html+js+css 基于vue.js框架开发）
• 平均每周所花时间：天天平均 4h 来算的话，大概一周 30-40 h（与课程量成反比，周末加倍）
  累计所花时间：根据上面的周时间来算的话，大约为 510-680 h（周数 4*4+1）
• 各次做业耗时列表：

做业名	做业内容	用时/h
第一次做业	阅读、思考、指望	2-4
第二次做业	生成数独、PSP、效能分析	20-22
第一次结对做业	部门app NABCD分析、原型模型开发	10-12
第二次结对做业	数据建模、匹配程序	20
α阶段	软工项目开发第一阶段	250
β阶段	软工项目开发第二阶段	300
γ阶段	软工项目开发完善、推广阶段	50

• 学习和使用的新软件：Visual Studio Code
• 学习和使用的新工具：Vue.js 开发框架、服务器
• 学习和掌握的新语言、新平台：github（更深层次使用）
• 学习和掌握的新方法：前端与后端交接（以前没有接API等与后端沟通的开发经验）
• 其余方面的提高：忍气吞声的能力增强了……以为本身更菜了……动做更迅速了……学习能力增强一点点……

官方地总结和吐槽：
回头看了一下软工实践的第一次做业，内容是思考当初选择计算机专业的初衷以及对过去大学两年的总结和对本课程的指望。
看到博客发表的日期，第一反应是，哇！过去了这么久吗！第二反应是，哇！我怎么仍是那么菜。固然，比那时候不菜了一点……
要谈软工实践给我带来的感想，我想会从如下几点展开：

时间过的很快，生活单调但充实，睡眠不足是平常，偶尔烦的想打人。

• 从 “我觉得” 到 “实际上是这样”
  从alpha阶段开始，伴随着繁多的课程，咱们又多了一项任务，开发一款属于本身的项目。
  从选题到架构，咱们都是充满兴趣和信心的，毕竟读了计算机专业三年，终于有机会作一款属于本身的产品了，然而随着开发进程的发展，我仍是以为too naive了。
  现实会告诉你，作产品，光有想法和激情是远远不够的，你还要考虑到时间、能力、其余组员的进度、未知的bug、来自后端的要求、来自PM的督促，现实的环境决定了咱们不可能像专职程序员同样专一于开发，一边要上课，要写做业，要金工实习，还要吃饭洗澡睡觉，我甚至以为打电话都是在浪费时间了。

• 像个程序猿了
  因而我也有了两三天没洗澡、一连几个月一两点睡、偶尔三四点的习惯，看着镜子中邋遢的我，我笑了，我终于像个程序员了。

• 与PM作不成朋友了
  固然，最气的仍是PM的深夜di di di——“xxx，今日份代码敲完没有，赶忙传github，close掉issue！” “xxx，个人意思不是这个意思，你快改！” “xxx，下来拍照！”
  上面的状况每一个组员都会遇到，然而不幸的是我和PM宿舍在同一层，因而就有，在某个深睡的下午，“xxx，还在睡觉，起床debug啦！”……我？？？？
  附上聊天截图：
  先来张平常的：
  
  （从中仍是能看出PM的用心良苦啊……）

再来张更猛的：

国际惯例之话语一转：反过来想一想，此次实践的收获仍是很大的。

• 首先，代码量上去了。
  第一次负责一个完整的项目web开发，对架构、交互、js原理、代码逻辑关系、框架使用的认识有着质的提高。量变产生质变。

• debug能力上去了（或者说被强迫debug的次数增长了）。
  以往的代码经历，几乎都是没有维护的，仅仅是为了完成任务，事后不会再去看。而在开发项目的过程当中显然不多是这样的，随着版本的迭代和功能的完善，须要进行代码甚至框架的修正，在这个过程当中，会改变不少“我觉得”的想法，我也渐渐认识到，开发是面向对象的编程，不少代码并非表面看着AC就能够了，要根据实际的使用状况来判断是否有bug、是否人性化。

• 项目开发算成功了（起码功能都实现了）
  咱们的项目课题一开始就是为了解决几率论的薛老师使用微信批改图片做业的不方便问题而提出的。
  而咱们推广的第一个小目标就是让薛老师可以使用咱们的项目，并争取得到她的承认。
  后来咱们也确实有一次做业经过咱们的项目来提交和批改了。由于项目开发结束时已经接近结课，因此也很遗憾没能使咱们的产品被屡次使用。
  结果附上截图（正经.jpg）：

• 对团队精神的理解更深了。
  若是说以前组队任务给个人感受是有另外一我的帮忙分担的话，那么团队任务让我以为本身是一辆车的某个部件，PM则相似于中控。
  一辆车之因此能跑起来，发动机、底盘、车身、电气设备……每一个部件都不可或缺，而在造车的过程当中，每一个部门不能只管着造本身的部件，要不时地根据协做部门的进度和要求来更改本身的稿纸和制做进程、制做方式，以达到各组件完美契合运做的目的。
  既然是一个命运相关的总体，在开发过程当中天然也会遇到我的开发所没有遇到过的问题。最大的区别就是时间再也不单纯地属于本身，而是属于团队。按照以往个人习惯，大多数状况我都是赶在deadline前一阵子才会完成（得改！），然而在这阶段中，已然不可能存在这样的状况，本身的进度没有及时完成，每每会致使其余组员的任务没法开展，由于本身也遇到过自身进度被队友所拖延的状况，因此也表示对这种态度深恶痛绝（对！）。推己及人，便会要求本身用最高的效率和最诚恳的态度面对本身的任务，由于实际开发时间和面临的难题每每大于本身的想象，不能说明天晚上的deadline，我以为明天中午开始作还来得及，最后每每地求着PM说“哥，我错了”（这是平常……）。你觉得终究是你觉得，没有实际去操做去踩坑，每每不知道坑有多深，时间有多紧。现实始终是那个最爱打你脸的人。拒绝拖延，拒绝优柔寡断。

• 对专业的兴趣和了解更深了。
  如同第一次做业所讲的，当初选择计算机专业的目的就是想作本身喜欢的事情，起初是偏向于游戏开发及设计类。后来进了大学发现教学形式与想象中大不相同，再后来接触了前端后，以为相对而言较符合“设计类”的风格，兴趣即是创建在那个时候。若是要对当时的指望交个差，那么我以为“但愿经过实践锻炼，加强计算机专业的能力和就业竞争力”这个目标，每一个人都是达成的，差异只是在于与本身定的level的差距。就我我的而言，对于软工实践这门课程，整体是满意的。

  期待就是让本身感觉到史无前例的对于计算机新的认知和激情，而后可以从中学到真正有价值的东西、加强本身的专业能力和知识，并认识一群患难与共的好伙伴，也为往后的考研方向有一个大致的定位和强心剂。

• 这是当时写给本身和课程的指望，如今看来，貌似都实现了，然而对自我能力仍是不够满意的，固然，这是下个阶段须要去努力的事情，至少在这个阶段，心安理得了。
  写到这里，突然想起前阶段 @周筠老师 在微信群里分享的一段话，引用至下面：
  #不要一开始就试图找到你的激情所在#

  凯文·凯利给了那些有抱负的大学生一个建议：不要一开始就试图找到你的激情所在，也不必一开始就非要作你感兴趣的事情，而是熟练掌握那些别人以为有价值的技能或知识。你没必要喜欢上它，你只须要作到最好就行。一旦你在这个领域成为大师，就会发现有不少机会能够去作你喜欢的事情。若是你持续完善你的技能，总有一天你会发现你的激情所在。反过来倒不必定能行。

• 这段话对迷茫期的我来讲简直是醍醐灌顶，不一样于其余的鸡汤文，他让我认识到，如今的迷茫、不之所措，是有意义的，是为了之后的爆发作积攒，让我感到放松，感到有但愿，让我积极乐观地去探索未知和将来，使我相信我能找到个人兴趣、个人梦想。固然，不是说一直处在迷茫期就好，仍是要赶忙明确本身的方向的。
  说到这里，不由让我深深感悟到，软工实践这门课，不只仅只是在开发技术、软件工程、环境模拟这些“物质”层面上给予咱们“招式”。在课堂上、微信群中、与老师的平常对话中，彼此分享的心得和心路历程，才是更加弥足珍贵的“心法”。“招式”再繁杂，也要有足够深厚的“心法”来辅佐，而这些“心法”，在往后的学习、工做、生活上，将使咱们受益无穷。我想，或许这才是这门课的真谛和初心吧。

最后，感谢栋哥，感谢邹欣老师、周筠老师以及各位助教、个人PM、个人团队、我本身。
感谢善良的薛美玉老师的支持和反馈。

代码敲多了，说话编程化了，文笔变差了，以上。

2、写下属于本身的人月神话——我的或结对或团队项目实践中的经验总结+实例/例证结合的分析

• 拒绝拖延，立刻行动
  软工以来，我以为天天的时间都变短了。一开始我以为是由于太过充实，然而我开始反思，本身是真的把时间都利用上了吗。
  其实否则，我发现我这人有个毛病，一旦时间相对充裕了，我就会心理安逸，开始消磨时光，而等到时间来不及时，才悔不当初。
  渐渐地我发现了问题的严重性，其一，顾此失彼，我没有利用好相对空闲的时间去作其余事情，致使其余任务的完成也相应地被拖延；其二，本身严重低估了项目开发的未知性和debug的耗时，致使遇到难题时解决困难，又缺少对应的应对时间，最后还得“借”时间来处理。如此一来，就影响了项目开发的进度。
  所以，不管在作什么事情时，能尽快解决掉就不要拖延，你永远不知道明天和意外哪一个先来。

• 不会就问不可行，不会就google才是硬道理
  因为技艺不精，在刚开始编程的过程当中，遇到偏 “底层化” 的问题时，我就会反感和逃避。
  就好比一开始的环境搭建，按照网上的教程一步步执行下去却遇到了神奇的问题，这时候我就懵逼了，明明同样的步骤，为何会这样？因而我开始了“百度”（点开三四个页面的那种），尝试几回（试了两三个的那种），发现问题没解决，因而我烦躁了，以为本身解决不了，开始抱怨问题的神奇。
  然而我忽略了问题的关键所在，问题是无限的，难度和类型也是层出不穷的，不可能遇到什么问题都是以你如今的知识和能力就可以一下看出要点并立马解决。之因此须要增长代码量，就是为了提升本身的学习能力，不只是学习新技术，最重要是学习解决问题的能力。
  而当初的我并不懂这个道理，百度了几回后就去问大佬，一次两次后，大佬开始不耐烦了，而我开始责怪大佬的态度很差了。。如今想一想，换成本身，也会反感吧。
  不过好在为时不晚。
  （好比alpha阶段配置开发环境安装项目依赖时遇到模块丢失问题，苦苦查阅了一个多小时的资料才得以解决，附带连接：http://www.cnblogs.com/How-Come/p/7737928.html）

• 按时汇报真实进度
  这点跟第一点有相关之处，在合做项目中，尤为是团队项目中，每一个人的任务都是按时分配的，只有正确的进度反馈和进度实现才能保证整个项目良好而有序地运营下去。
  当由于自身拖延或者遇到问题卡住的时候，不要“为了面子”向PM汇报虚假进度，这样只会累了本身，害了团队。
  不会就是不会。有问题就说出来。（与第二点不矛盾）

• 有效沟通很重要
  由于我是这次项目web端的负责人，一同开发web端的还有一名队员。在一次任务分配中，由于没有会议式编程，又github的代码同步会出现冲突现象，致使对对方的代码进度和完成状况不甚了解，致使双方对事先分配的任务的理解起了冲突，最后一方的日工做量表示报废。
  对于一个合格的负责人或者组员来讲，分配清楚任务和理解任务是最基本的要求，当出现疑问时，请进行最直接的沟通。

• 合理安排工做和生活
  熬夜是软工阶段的常态，但显然每一个人都想极力避免这种现象。
  利弊与否，我以为今天在微信群看到的这句话就很犀利。

  “熬夜不必定是好事，由于可能效率并不高，有时候选择本身有效率的时候作事情，也是一种能力吧。记住，凌晨四点的福大，不是熬到的，而是给本身的计划，让本身精力充沛，从4点开始的。熬夜到凌晨，睡到中午的生活，以后浑浑噩噩必定是一件值得称道的事情吗？我以为未必吧。”

3、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？

• 我仍是以为每一个人在生命的不一样阶段作出的蠢事，都是有他的意义所在。过度地给予所谓的“指点”，反而会下降自我感悟的体验和价值。既然要给出建议，我想说：
  ① 好好玩吧哈哈哈哈，管他的呢
  ② 若是你按照上一条去作，你之后会打我
  ③ 忽略前两条
  ④
  追随本心，作本身想要作的。
  不要惧怕，多去尝试，早日找到本身的定位。
  多听学长的话，固然，是优秀学长的话，学姐？没有学姐。
  多听栋哥的话。

• 特别地，特别地
  我以为中途换队员仍是有必要的。
  可是这个时间点问题……仍是换一下。
  至于为何，微信群几百条信息大战已经很明确地说明了问题的所在——意义不大，表面工程。
  我理解老师们的想法，想让咱们体验一下“现实模拟”中的这么一个换员环节。然而就我团队而言，并无看到新成员的突出贡献（固然不是在吐槽新成员）。时间太短，又要吸纳融汇新团队的内容，学习新知识新技术，是有点蛇吞象的意思。因此我的建议老师将这个环节放在alpha中间阶段。

4、分析一下本身所处的团队。软件工程实践是大学里少有的认真的团队协做经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）

包括萌芽阶段、磨合阶段、规范阶段、创造阶段。
创造阶段的特色包括：

• 团队知道为什么而战，并将注意力集中到如何创造、实现目标上。
• 高度自治，再也不须要领导的时时教诲和介入。
• 角色和职责可以根据项目的要求天然地转换，没有人为此担忧或发牢骚。

个人团队经历过以上各个阶段，并体现了达到“创造”阶段的特色。

5、怎样证实你学会了软件工程？

1）研发出符合用户需求的软件
​ 必须公开发布，有实际的用户，必定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 作没有用户使用的软件
2）经过一系列工具，流程，团队合做，可以在预计的时间内发布 “足够好” 的软件
​ 有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 经过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）而且经过数据展示软件是能够维护和继续发展的。
​ 而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料

satisfy and achieve

六*（选作）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合本身的实际作一个阅读笔记（例如，本身写的代码质量如何，是否是一个大泥球，如何衡量本身代码的质量）？从如下参考论文中选择一篇或若干篇：

参考论文文献： [1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60. [2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605 [3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87