Loading

福大软工 · 最终作业 - 软件工程实践总结（个人）

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

  • 对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

本次的软工实践，自己最大的收获就是积累了大量的编码经验，在编码能力上有了较大的进步，同时作为项目PM且事事关心都喜欢插把手的我，在这回的课程结束后，有了蛮多之前不经过亲身经历无法有实感的体悟：第一次深刻的了解了一个产品开发过程的来之不易，从规划到美工到原型设计，再到具体的开发、测试、整合，最后是产品的推出以及维护，前前后后无数的构思->推翻->重构，无数个大大小小的项目会议讨论，无数个熬过的夜晚(我已经熟悉了周六凌晨的福大，当然这里有点夸大的成分，但表达的就是那么个意思)，每个具体的过程都需要专门的人员的负责，确实不易。经历过这么个种种的我，基本上达到了我之前对于课程中所能获得的收获的期待，当然我还存在着大把的能力提升空间，例如对于一个项目前期的开发规划能力欠缺、上台演说时的个人发挥能力太差、对于组内人员的任务制定与督促能力太过乏力云云。但是，确实就是这么一次软件工程的实践课程，让我第一次对于开发有了一个粗浅的认识，虽然粗浅，但却是一次实用的经历。

  • 总结这门课程的实践总结和给你带来的提升，包括以下内容：

    1. 统计一下，你在这门软件工程实践中，完成了多少行的代码；

      大体的统计一下，在个人项目及结对编程期间，大致编写的代码量达到1200+行，在团队的编码过程里，大致编写的代码量有个4000+行(前后端总的有效编码量涉及java后台的数据处理，微信小程序js、wxml、wxcss等等)。所以总结一下至少有一个5200+的代码量积累吧(只会更多不会更少)

    2. 软工实践的各次作业分别花了多少时间？（做一个列表）

      大概列一个这样简单的统计表吧，真的也不是特别在意去记录，但花费的时间绝对不比别人少，而且自己也挺喜欢在编码过程中虽然心里苦嘴里说着不要不要但事实上还是很卖力去做的感觉，哈哈。

      阶段 耗时(min)
      个人项目one 1830
      组队作业one 290
      组队作业two 3030
      团队第二次作业 360
      项目UML设计 165
      团队第三次作业 750
      Alpha 冲刺(1/10) 310
      Alpha 冲刺(2/10) 410
      Alpha 冲刺(3/10) 450
      Alpha 冲刺(4/10) 420
      现场编程-抽奖系统 520
      Alpha 冲刺(5/10) 460
      Alpha 冲刺(6/10) 400
      Alpha 冲刺(7/10) 510
      Alpha 冲刺(8/10) 360
      Alpha 冲刺(9/10) 600
      Alpha 冲刺(10/10) 410
      Alpha 事后诸葛亮 190
      BETA 版冲刺前准备 60
      软件测试(团队) 130
      Beta冲刺 (1/7) 130
      Beta冲刺 (2/7) 110
      Beta冲刺 (3/7) 170
      Beta冲刺 (4/7) 290
      Beta冲刺 (5/7) 380
      Beta冲刺 (6/7) 380
      Beta冲刺 (7/7) 490
      Beta答辩总结 300

    3. 哪一次作业让你印象最深刻？为什么？

      Beta阶段的编程是最让我印象深刻的，因为前期的alpha阶段可以看到我们的进度相当的缓慢，而在beta阶段我们花费了大量的时间，熬了大把的夜，团队内结对赶班，最后终于在Beta结束前有了一个令人满意的成果推出，在这个过程里的艰辛，是我以及所有付出的努力与汗水的组员们共同珍贵且难忘的回忆。

    4. 累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

      累计花费的时间保守估计至少达到240个小时(如果加上博客编写、课后整理材料、组内工作布置整理、代码整合修改等等，至少可以达到300个小时吧)，以软工实践课程时长11周来作为标准，平均每周保守估计花费21个小时(加上其余工作花费至少27.3小时)。开篇博客里计划每周5小时的计划量着实把我笑到了，是的，当初真的也太年轻了吧，还是个dd不知前路坎坷呀。

    5. 学习和使用的新软件；

      • Idea(一款个人认为功能更多样化的java IDE)
      • Balsamiq Mockups(结对编程阶段时使用的原型设计软件)
      • Axure RP 8.0(团队编程阶段时使用的原型设计软件)
      • ScreenToGif(视频压缩为gif动图)

    6. 学习和使用的新工具；

      • Leangoo(燃尽图)
      • 有道云笔记(markdown博文的撰写)
      • Processon(uml等的设计)
      • JProfiler(代码性能测试工具)
      • Tomcat(测试使用的服务器)

    7. 学习和掌握的新语言、新平台；

      • 新语言：wxml、wxss、js(小程序前端语言)、Java(后端数据处理)
      • 新平台：微信开发者工具
      • 新框架：springboot框架

    8. 学习和掌握的新方法；

      • 硬要说的话，第一次很好完整的使用了一次框架，简化了开发过程中的许多繁琐的地方，使得开发的进度更加快捷。

    9. 其他方面的提升。

      • 对于有价值资料的嗅觉更灵敏了
      • 微信小程序的简易开发已经算是能够掌握
      • 团队协作分工的能力加强
      • 责任意识得到提升(毕竟需要负责一个组内的进度推进呀)

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

用几个关键短语来概括吧：前期准备、疯狂投入、顶住压力、及时沟通、组内建设

  1. 前期准备：
    • 当你没有明确目标无从下手时，请千万记住，搜索查找资料是你最好的伙伴，baidu or google，愿意去学去读相关文档去学相关实例代码，就没有解决不出的问题
    • 组内需要达到同步的准备工作，带上电脑开个全员小会，这是考虑到存在能力不够不知所措的组员情况下，务必帮助他们及时跟上进度，达到整体步调的一致性。
  2. 疯狂投入：
    • 代码是肝出来的，这句话非常适合我们小组，尤其是beta阶段，应该是大家有目共睹的，从0到1的编程全记录啊。
    • 熬夜其实就是在修修补补使得你的成果在展示以前能够更好的呈现给大家你认为满意的效果，所以周六凌晨的福大你需要熟悉一下
  3. 顶住压力：
    • 无论组内的进度如何，都需要对后续卯足了信心，前提是你的组内所有成员都依旧愿意付出，过程中部分的队员选择退出，或者看到其他组就地瓦解，都不要影响到你们自己，付出就会有回报，但是回报的多少取决于你们付出的多少。
  4. 及时沟通：
    • 团队编程就是这样，没有及时的沟通，你都不知道自己的组员已经完成度达到了多少？是否还未开工？类似这些都需要在及时的沟通中去了解进度。
    • 要做好一位愿意倾听意见的人，组内觉得项目有什么不妥的地方，直说不误，且愿意讨论去得到一个合理的解决方案，这些都需要全员的参与与一致的同意。
  5. 组内建设：
    • 很遗憾我没有能够做的非常好好，结合自己的情况以及其他组给我的震撼经验，所以也在这里再码一下我认为的组内建设该怎样。
    • 必要的进度deadline，要应用好类似组内记录的工具，开一个组内的进度记录，全员将每日的进度记录在上，起到的作用不仅是督促，还有激励。
    • 活用github，别再全推给组长一人去做这些活啦，自己要去学习怎么使用github、签入项目等云云，这样最终回看也会有颇多的感触。
    • 建立类似组内的技术文档，方便全员解决问题，查找方案，简化开发过程里遇到问题明明有已经解决的方案却无辜第三方不知情的情况。
    • 开心一点，组内需要一种活跃的气氛，给足了组员们压力去赶工的同时，别忘了在每次总结的时候给他们必要的肯定，然后大家又一起再次投入下个回合的拼搏当中去。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：

  1. 你有什么想建议、告知和期许想要告诉他们呢？

    一定不要太低估自己，尽自己的所能，花费足够的时间去努力，不管结果怎样，一定会比你试图划水所收获的多，对了，在造车之前，务必准备好资料以供学习参考，仅有的有限时间里我们需要造的是车而非轮子。

  2. 特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？
    假设依旧是一个90+人数的大班

    我觉得有必要，这样才有可能去逼迫性的使得某些人不得不去改变，去尝试新东西，这无疑是相当有趣且具有挑战性的，另一方面组内的重建势必也会带动组内的新鲜感与活跃度，对项目的推进也有帮助，避免烂摊子一蹶不振。

  3. 身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？

    我觉得一个组的人数控制在5人左右相对合适，相对的紧凑且任务分配也会比较明确，没有必要对文档编写呀制作ppt呀这类没有什么锻炼性的工作分配人员，软工实践到底是一门实践编程的课程，参与其中却没有涉及代码层面的工作我觉得多少有一点点缺乏锻炼了。

  4. 个人/结对/团队作业应该控制在怎样的规模？

    个人/结对的安排我觉得都比较合理，团队作业里我觉得既然有了一个团队的项目确立，就应该全身心的投入其中，中途就不需要再出什么类似现场编程这样的小插曲了，个人觉得蛮影响自己的，毕竟精力的分配不能两全。

  5. 这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

    硬要说最感谢的人的话，我还是想跟那个这学期里的过去的我说点话：谢谢你愿意投入其中，谢谢你花费大把的努力所带给我的宝贵经验，同时还需要指出一些缺漏，游戏还是少玩一些吧，能力不够不可怕，可怕的是你就这样沉沦下去，毕竟这个世界需要更多的英雄。

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

  1. 萌芽：确立一个项目的立题，大家各自谈谈自己的idea，依据可行性与创新点去评估选取最好的议题，当时的我们都还不清楚各自的编程能力，所以这就是一场在白纸上画饼的过程。在设定项目的想法上做增删改查，其实就是在对应着这个阶段。
  2. 磨合：团队内的编程能力依据每个人的情况都是不同的，因此或多或少前期的工作就会显得很不平均，有些人干的昏天黑地，而有些人却无事可做(约等于划水)。抱怨小摩擦肯定是有的，但是都是为了项目最终的成果，因此在这个过程之中就有必要进行一个开发前的全员准备，用到的框架、所使用到的工具等等都需要明确下来(这里也涉及到规范的内容，所以后续就不再赘述)，并且每个人到位的指导，做好在开发之前每个人都可以参与其中(来自Alpha阶段成果惨淡的惨痛经历)，这样就没有理由不做好自己负责的工作，类似不太懂其实约等于划水的行为就会在磨合期里逐渐消除。一个好团队的同心协力，其实很大程度上就是在磨合期里建立起来的。
  3. 规范：这个阶段组内大致的人员都非常的熟络、交流就非常的多。有什么问题直说，异议点可以及时的去讨论解决。同时编程过程中就会有规范性的要求提出，类似命名的规范规则、必要的注释、文档的编写等等，这些都很好的起到了互相帮助的目的，可供查阅，可供阅读，具有引导的作用。这一阶段也是对目前开发进度的明确，基本的开发结果有了一个直观可描述的形象出现。
  4. 创造：这个阶段应该对应于测试版本推出以后吧，很遗憾我们组还没有达到。

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

  1. 研发出符合用户需求的软件
    贴出目前所记录在案的用户使用量情况，如下图所示

  1. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
    从编写到测试再到发布，我们历经了好几个迭代的过程，中间通过沟通交流也是修修补补，最终展示的也是后续在既有功能版本上的删减版(个人版开发权限为了配合微信小程序发布的审核问题，导致几乎近半数的功能砍掉才得以上线)
  2. 并且通过数据展现软件是可以维护和继续发展的。
    在github上可以搜索到我们项目WeEdit的源码，完全开源共享，欢迎下载并提出建议或者issue，谢谢
  3. 对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。
类别 具体技能和面试问题 现在的回答
语言 最拿手的计算机语言之一,代码量多少?(偏web前端,PC/Mobile App) java 4500行左右
语言 最拿手的计算机语言之二,代码量多少?(偏后端,数据处理,网站后台,机器学习,等) python 3000行左右
软件实现 (阅读代码的能力,实现,单元测试)你有没有在别人代码的基础上改进，你是怎么读懂别人的代码的,你采取了什么办法来保证你的新功能不会影响原来的功能?你在开中碰到最复杂的bug是什么,你是如何解决的?这个bug出现的原因是什么,你在将来应该怎么去避免bug再出现? 有过在别人的基础上做修改的经历；读懂代码通常第一选择是阅读相关技术博客，了解实现原理与过程，手动编写demo测试，第二就是阅读相关文档，了解运用方式；编写的过程里可以对通过命名方式的不同或是继承方式区别于原有的功能实现；最复杂的bug应该就是由于程序内部的异步使得表单提交的顺序是乱序的，解决的话通过缓存将表单作统一的提交
软件测试 (测试方法、测试工具、测试实践、代码覆盖率)你如何测试你自己写的代码?你如何测试别人的代码?你掌握了多少种测试工具和方法?你写过测试工具?你如何对一个网站进行压力测试和效能测试?你如何测试一个软件的人机界面(UX/UI)? 代码性能的测试上使用了JProfiler，可以有一个直观的数据呈现；自己也手动编写过@Test；对于网站的压力与效能测试可以通过第三方平台进行跑跑测试
效能分析 效能分析,效能改进，你写过的最复杂的代码是什么?你是如何测量和改进它的效能的,用了什么工具,如何分析的? 暂时还没有过类似的改进工作，所以没办法谈感受
需求分析 (需求分析,典型用户,场景,创新)你做过多少个有实际用户的项目,用户最多有多少?你的项目有什么创新的地方? 目前就只有软工课程写过在市的运行项目，用户量顶峰也只有个90+吧(还多亏柯老板课上进行的一项测试)
行业洞察力 你最感兴趣的领域是什么?这个领域过去10年经历了哪些创新?你分析过这个领域前10名产品?请分析一下他们的优劣,你要进入这个领域,应该如何创新? 浅谈感觉互联网金融还是有很大的空间的，自己也是通过和学长接触粗浅的有个了解，当然自己的能力还不足够去在里头有什么贡献，暂时处于场外观摩
项目管理 你参与过项目管理么?请描述一下两个当下流行的开发方法在你的项目中的具体应用情况;请问你如何决定项目中各种任务的优先次序,有什么理论来支持你的做法如果你突然发现项目不能按时完成,你作为项目领导,有什么办法? 使用项目的管理工具能够很好的帮助到开发，例如github的项目建立到fork到共同编写潜入，整体的项目管理直观且有效，动作的记录也可查可回退；项目的不能及时完成我觉得除了加班加点完成，应该没有什么好的方法了吧，做好秃头的准备
软件设计 你做过架构设计,模块化设计,接口设计么?请说明一下你为何是这样设计,你比较过什么不同的设计方式,你的设计取得了什么结果? 设计这些是用于方便调用，因为项目本身是一个多人协作的事情，在会出现大多数调用的地方设计成接口，将共享的代码块编写成模块化，就不必重复造轮子，这正是这些必要性的设计存在的意义。
质量意识 (代码复审/代码规范/代码质量)你是怎么做代码复审的,你加入我们团队后,能帮我们提高代码质量么,请具体说怎么提高? 复审这一块往往需要测试人员的加入，如果加入新的团队，阅读原有注释，进行测试性使用，过程中通过数据查看整体在代码跑的过程中的变化等等，都可以很好的捕捉到原先的疏漏的地方，从而及时的去修修补补，代码的质量可以通过良好的注释习惯与编码风格的整体统一去规范提高。
工具/社区 Software Tools (performance tool, version control, work item, TFS)你在各种开发平台(web,linux,PC,mobile,machine learning)都使用过什么样的工具,自己写过什么工具来改进工作效率?给社区贡过什么工具和代码?Github有分享代码么?你写的技术博客坚持了多久,读者最多的是哪一篇? IDE换了又换，Java的还是推荐用Idea，功能直接且丰富；花时间去了解一款IDE后，有时候反而可以节省开发过程所使用的时间，因为你可能会忽略其自身强大但你却忽略的功能存在；github上有我目前有成型的项目代码，当然自身硬实力还太嫩，不过就算是自己的小小记录吧；博客写了有一年多吧，作为记录性的查阅以及自我复习的途径方式
团队协作 work with others(协同工作,提供反馈,说服别人)请描述你在项目中何说服同伴采用你提出的更好的解决方案,或者你如何听取了别人的意见,改进了自己的方案?你如何说服懒情的同伴加紧工作,实现团队的目标? 面对面讨论是比较好的方式去解决意见的冲突，当面直接讨论，直言不讳虽然比较刺耳但却是最有效最直接的解决方式。小组内再进行编组结对编程有时候可以起到督促激励的作用。
理论素养 你上过什么数学,计算机或其他理论课,请举出具体的例子,说明你学到的理论知识如何帮助你解决实际问题。 高等数学、线性代数、矩阵分析、算法与结构、面向对象与程序设计等等，具体学到的就是一种思维方式的培养，思考问题会有一个入口去推进，进行自我知识库的查表操作
自我管理 全年级你专业排名多少?你从刚入学(大学一年级)到现在的排名有变化么?如何解释你的排名的变化? 目前排名40/55，整体有小提升，但是大一上与大二下是我成绩最差的两个阶段，尤其是大二下我已经是倒数了，如何解释呢？可能游戏时间有点过度，然后就是不懂得怎么复习，学习很乱，时间效率都很糟糕

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

参考论文文献：

[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

七、个性发挥，包括图文、照片和创意等!
我们是第三小组，我们的组名叫彳艮彳亍，我们的项目叫WeEdit，我们的口号是：我行你也行！！！
第三组WeEdit宣传视频链接
第三组WeEdit宣传海报链接
小程序搜索WeEdit或者通过扫描以下的二维码，迅速的来体验一下我们的产品吧，虽然功能有点太过简单，但毕竟是整个小组的共同付出，因此我觉得我们所有的组员都是最棒的。

也欢迎大家能够指出缺点，查缺补漏的路还有很长很长，谢谢大家。

posted @ 2019-01-09 00:05  诀别、泪  阅读(302)  评论(2)  编辑  收藏  举报