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

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

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

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
2、软工实践的各次作业分别花了多少时间？（做一个列表）
3、哪一次作业让你印象最深刻？为什么？
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
5、学习和使用的新软件；
6、学习和使用的新工具；
7、学习和掌握的新语言、新平台；
8、学习和掌握的新方法；
9、其他方面的提升。

首先贴出软工实践的第一次作业链接：

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）
• 各次作业耗时列表：

• 学习和使用的新软件：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、我的团队、我自己。
感谢善良的薛美玉老师的支持和反馈。

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

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

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

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

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

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

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

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

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

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

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

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

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

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

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

五、怎样证明你学会了软件工程？

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