• 高级软件工程实践总结


    一、对比开篇博客你对课程目标和期待,再对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?

    1. 在开篇博客中写到想通过高软这门课程发现以往所学的遗漏点,虽然本科阶段也有软工课程,但只是仅仅把它当成一门纯理论课程,没有深入了解相关内容,所以在大学的课程设计中也没考虑过代码复用、设计模式、系统测试等问题。之前在编写软件系统时,需求一旦发生变化,自己就要重新翻阅大量代码,然后再七拼八凑地整出很多类,很多奇怪的变量,结构越来越复杂,功能却没有增加多少,到最后就真的什么也改不动了。经过这学期的学习和实践,自己也在不断改进代码编写习惯,特别是在学完类设计原则和设计模式后,发现之前使用糟糕代码解决的问题现在完全可以用这些模式来解决,代码会变得更加优雅,复用和对需求变动的适应性都会显著提高。在系统设计阶段,自己不再想之前一样想的尽是如何实现复杂多变的业务,而是如何用面向对象和设计模式去实现该系统,以及如何去面对即将到来的各种业务变化,对软件系统的设计有了新的认识。

    2. 之前对项目管理的一些做法,总有“理想很丰满,现实太骨感”的感觉,应用到实践中其要面临的问题往往会更多。在本次课程实践中也有这种感觉,特别是在项目初期,限于时间和能力,提高不了项目开发的效率。不过在经过一段时间的团队磨合后,我们的项目也逐渐走向正轨。通过日常的会议、commit记录以及冲刺过程中每天的博客,都能较清晰地记录下当前阶段所处的问题,以及下一步的改进方案,同时也在这过程中提高自己在团队中的沟通合作能力。经过课程实践,认识到文档在开发过程中的重要性,通过文档可以更好地记录问题和做好下一步规划,需要一直保持写文档的习惯。

    3. 由于项目开发进度前期偏慢,导致后期在测试上花费的时间不是很多,自己在对测试的了解上仍然存在不足,比如对一些自动化测试工具的使用等,还没有去较深入地了解。

    二、写下属于自己的人月神话。

    1. 学习Git。之前的开发都是自己关起门来写代码,各种随意的编写代码习惯,完全不用考虑代码阅读者的感受。而且对于下一个软件的开发又是重新建工程,又重复造起“轮子”,上一个工程遗留下可重复利用的模块也没能很好地用到当前软件的开发中。开始学习Git后,开始注意到代码阅读质量的问题,以及如何将一些常用的模块进行封装以用于不同场景的开发。Git软件在团队中反映了分工和组装两大块的内容,分工即对应于Git分支,而组装就对应于分支合并。团队需要有明确的分工才能提高开发效率,而真正完成软件项目还需要对各个分工产生的结果进行组装,这过程经常伴随着冲突的出现,这时候就需要在团队中进行讨论,以真正解决该问题。学习Git,就必须先了解其包含的团队分享和协作精神。

    2. 代码复审很重要。调试对于程序员来说就如同大战一样紧张,害怕BUG这个敌人的出现。编写,运行,输入,查看结果,没有问题就会如释重负,一旦报错,就知道接下来这段时间就要和这个“狡猾”的敌人不断地进行游击战了。调试工具是手上的利剑,输出中间结果是防御敌人的强盾。有时候到最后才发现这个敌人只是自己当初不小心打错变量名字产生时,便会有一种“放虎归山”的感觉,如果在编写代码时,能注意到这些小错误,或者进行代码复审,就不会在测试阶段承受调试之痛。

    3. 尝试不一样的任务,丰富自己的编程体验。写后台的人专注于事务处理,就是对各类表的增删查改,不能马上看到系统运行结果,略失成就感;写前台的人专注于界面交互,使用各种框架传数据和显示数据,略难感受到后台业务的奇妙。变换一下,去接触一些不是自己常在做的领域,可以发现不一样的世界,让自己的编程体验不再只是单调重复的工作,同时也会用新思维去重新思考自己擅长的领域,如写后台的人能重新思考怎样的接口设计才能更符合前端的需求。

    三、对下一届实践的建议,你有什么想建议和告知的呢?

    1. 在团队项目开发中,如果要使用新框架,并且队员中需要用较多时间去学习时,要在项目计划早期就应评估好学习成本会不会影响到项目的整体进度。如果会严重影响项目开发的进度,那就应该使用大家都经常使用和较熟悉的框架,因为重头开始学习,不仅是学习时间较长,随之而来的调试问题也需要花费很多时间。如果还是要坚持采用新框架,就需要从一开题后,就要不断地安排相应的学习内容,并在团队会议中对各队友的学习进度进行验收,让队员能及时反馈学习中遇到的难题以及汇报接下来的改进计划。

    四、分析一下自己所处的团队。

    1. 由于对新框架不熟悉的原因,我们的团队在项目早期管理得比较混乱,对于分工没有给出具体的方案,任务完成点也不是很明确,导致前期开发进度较慢,这在Alpha阶段表现得很明显。经过一段时间的修整,以及对新框架进一步的熟悉,我们不断加快项目开发进度,终于在Beta阶段前完成了系统的主要功能。同时,我们也意识到上一阶段存在的分工不明确的问题,所以在Beta阶段开始前的会议,我们对项目开发中存在的问题进行了讨论,并给出下一阶段较明确的工作计划,能够以指标的方式来衡量项目的进度。Beta阶段的项目测试就有了明显的分工,而且每个队员也都参与到BUG的修复过程,进一步通过日常会议以及Commit来验收各个完成点,保证项目能够如期完成。

    2. 互帮互助。在项目开发过程中遇到的问题,都可以随时在讨论组中提出,项目开发经验较丰富的同学也会积极地给出答复,如果还是不能解决,都会在小组会议中以面对面的方式处理问题。

    五、实践总结和提升。

    1. 改变代码编写习惯,改变系统设计思考方式。运用面向对象和设计模式的观点去思考系统的设计,提高复用性和对需求变动的适应性;提高类设计的合理性,使其更符合类设计原则的要求,如开闭原则等;同时改进代码的阅读质量,以读者的视角去编写代码,而不是仅仅是为了实现系统的功能。

    2. 学习了一系列新软件和新框架的使用,如Git、VUE框架等。通过项目实战来学习新知识,限于时间,遇到什么需求就先学那部分内容,其中会遗漏一些关键点,所以在调试阶段有时候很能发现出错的原因,但经过团队中其他成员的帮助,能较快地定位到出错代码并解决问题,这也让我进一步加深对新框架使用的熟练程度。

    3. 不断适应团队协作的编程方式,融入到自己的项目团队中。闭门造车是之前一直习惯的开发方式,一个人从头做到尾,想怎么设计就怎么设计,不考虑系统的复用性和生命周期。但经过本次实践,进一步习惯了以分工和组装的方式来完成一个项目,重新思考代码的复用性和可阅读性。同时,也认识到文档对于团队项目开发的重要性,需要保持编写代码的同时也写好相关项目文档的习惯。

  • 相关阅读:
    HPU 1007: 严格递增连续子段(贪心)
    Codeforces Round #224 (Div. 2) A. Ksenia and Pan Scales
    Codeforces Round #224 (Div. 2) A. Ksenia and Pan Scales
    51Nod 1058: N的阶乘的长度(斯特林公式)
    51Nod 1090: 3个数和为0
    CSU 1112: 机器人的指令
    有关刷题时的多组输入问题
    HDU 1060:Leftmost Digit
    《算法导论》— Chapter 6 堆排序
    《算法导论》— Chapter 9 中位数和顺序统计学
  • 原文地址:https://www.cnblogs.com/htd6/p/8151501.html
Copyright © 2020-2023  润新知