软件工程python就业方向-软件工程实践总结

软工ByeBye~

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

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

开篇博客的课程目标和期待（包含当时内心想法但是没写出来的）：

开篇博客链接

痛并快乐着。

能够在结束后懂得如何做好一个完整的产品；

学到尽量多的开发知识。

可以提高团队协作、交流能力。

增强自己的文档撰写能力。

已达到期待和目标

痛并快乐着 = 过程真的是很痛苦，但是团队作业时整体经常性被挂观光车还是十分快乐的。

懂得如何做好一个完整的产品 = 团队作业完成了我们的产品记忆罐头，目前可以提供用户正常的使用，作为pm我也更好的懂得了要如何做好一个完整的产品。

学到更多开发知识 = 在完成团队产品过程中由于种种原因我也参与了开发，完成的是记忆罐头主页的备忘录条目展示和备忘录删除界面的前端部分，用无数个熬夜甚至是通宵学习了很多的开发知识。

增强团队协作、交流能力 = 身为pm在这次软工实践中这方面的能力的提高与否，我相信在多次的作业和团队总分中便已经很好的体现。

未达到期待和目标

增强自己的文档撰写能力 = 因为团队中的分工比较明确，美工和文档都有专业人士负责，所以原本打算借助这次机会提高一下自己的文档撰写能力，貌似没有什么见长。

意想不到的收获

最意想不到的收获便是做了pm并且收获了这么一大波的优秀的队友们！！！拥有一个这么优秀的团队。

再者便是一直是作为本组的PPT制作者和演讲者，很好的锻炼了自己的答辩能力，演讲能力提高了不少。

总结这门课程的实践总结和给你带来的提升。

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

根据自己不完全正确的统计，参照自己的学习进度条，大概完成了3113行代码。（当然肯定存在一些偏差，但是应该是会比这个更多不会更少吧）

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

作业

花费时间（分钟）

博客链接

自我介绍

10

第一次作业-开篇展望（包括完成评论部分）

720（估计）

个人项目

1550

结对项目1

1560

团队风采展

240

结对作业2

1890

团队选题报告

1200（估计）

团队课堂UML设计

845

团队需求分析报告

1355

团队现场编程

1410

团队项目测评（福大助手）

180

最终版本展示

360

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

要说最让我印象深刻的其实是团队现场编程的那次，因为那次是我软工实践里的第一次通宵：），由于种种原因我们没有及时完成现场编程的作业，于是我和卉卉小朋友两个人在快12点重头开始码，也正是因为经历了这一次的通宵让我认识到通宵貌似并不难，于是埋下了后面通宵许多次我还不以为意的隐患：），通宵都通过了，熬夜就更不在话下了，于是整个人就比较身心俱疲。但是！！！最重要的是，我们那次的通宵并不是没有意义哈哈哈哈哈哈吼吼吼吼吼吼吼吼，我们圆满的拿下了第一名！！！然后在这里还要好好的感谢一下陪我的卉卉朋友（要是能@就好了）！！！

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

累计花了...22400分钟=373.333小时=15天(要我怎么说：）)

贴出开篇博客回答（当时回答比较佛不明确但内心打算了的）：工作日每天2-3小时，一周10-15个小时吧，四个月不停歇240个小时也没我花的多啊！！！：）

在此由衷的感谢老师和助教，是你们，教会了我什么叫做真香。

学习和使用的新软件；

现场编程重新学习了Eclipce For JavaEE的使用

开发使用了Android Studio工具

UML设计使用了StarUML工具和ProcessOn

结对作业使用了Python

当然还有我们的产品：记忆罐头！

学习和使用的新工具；

现场编程重新学习了Eclipce For JavaEE的使用

开发使用了Android Studio工具

UML设计使用了StarUML工具和ProcessOn

结对作业使用了Python

个人项目中Visual Studio中的性能分析、代码覆盖率也学习使用了部分新工具的功能

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

更加熟悉的使用java语言开发

对Python的基础使用有一定的掌握

在web平台上完成我们的现场编程项目，对web端有更深的认识

Android平台开发有一个新的认识

学习和掌握的新方法；

在个人项目中知道了单元测试的意义和方法

在个人项目中学习了代码覆盖率的概念

在个人项目中对代码进行性能分析对开发中优化代码有一个比较新的认识

结对项目中学习了一定的Python爬虫知识

现场编程中知道了web前端使用模板的魅力

在团队开发中学习了Android开发知识

在团队开发中掌握了Android中如何debug

在团队开发中掌握了如何更好的答辩演讲

其他方面的提升。

首先在个人的答辩、演讲、展示方面的能力在软工实践中算是得到了一个很好的锻炼，十分感谢这样难得的机会

在团队中充当pm角色，收获了很多管理一个团队的管理能力和推进一个项目的领导能力

自己可以更好的处理众多事情繁冗复杂的场景环境了，毕竟经过软工实践的打磨...

旁观团队的美工人员和文档撰写人员，多多少少这两方面还是有一些了解和长进的

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

最深刻的便是团队项目实践吧，作为pm很庆幸拥有了一个最棒的团队、最棒的队友们。

经验总结： 在任务安排的时候一定要遵循三个原则：具体、规范、deadline

三个原则含义：

任务具体到个人

任务完成的目标要给提前规范明确好

任务完成的截止时间要定好并且严格遵守

实例：

一次惨败的教训是现场编程吧，其他的我都貌似遵守的比较好。那一次作业前一天晚上已经有准备，通知好大家是开发JavaWeb项目，使用Eclipce For JavaEE并且要安装好需要的其他工具配置好环境。并且要提前学习一下基础使用，但是由于没有严格审查，我也没有明确告诉队友sevlet的坑尽量避开等等。导致出现了后面全队所有环境都配置好了的只有两台电脑，队友敲了一下午却因为陷入了sevlet的坑点没有很大的进展，最终没能按时完成作业，我和卉卉通宵做完...

分析：

分析自然就是要是我定好了每个人做哪部分、必须配置好环境、提前学习基础开发、提醒他们避开sevlet坑点......那么，我们就可以完成的更快，效率更高，也不用通宵

更多的经验吐槽可以参见我之前的博客：Beta版本吐槽博客链接

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

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

建议：

第一个就是一定要选这么课啊！！！会让你跨入程序员的门...

第二个是一定不要在团队中划水，认真完成自己部分的任务，这样团队才能持续发展并且保证自己学有所获

第三个是好好保护自己的头发：）

最后便是期待看到你们真香的开篇博客

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

我觉得没有必要的，因为在中途其实我们有尝试过交换pm的一次现场uml设计，个人感觉这样根本不能达到模拟职场中跳槽等等这种效果，并且有些团队确实开发很不一样啊，重新换过去8，90%是将会担任划水的角色，无论从重新学习时间的角度或者是融入新的团队配合方面，个人感觉交换的话打不到效果，还不如不交换。

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

个人感觉一个组在9个人左右是比较合适的，pm+美工+文档+三个前端+三个后端

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

个人和结对作业按照之前的规模算比较正常，但是团队作业中要是可以不要再夹杂一些其他的比较好，这样显得比较繁杂，对学生的精力活力会消磨的比较严重，专注于团队项目的开发就挺好了。其他的还要占用过多时间感觉有点不妥，比如现场编程那次。（个人看法）

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

最感谢的是青元同学，其实所有队友都很想感谢hhh，但是理性思考还是青元同学最想感谢，身为前端小组长十分尽职，并且几乎也全身心的投入到项目中，在我焦头烂额的时候帮我分担了很多。

对青元同学说的话：

你雨露均沾的能力真厉害呀，天天能看到你和不同的女孩子自习耶（偷笑）

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

《构建之法》团队发展阶段

萌芽阶段：就像小苗破图而出，柔弱但充满希望。团队成员刚刚接触到团队的宗旨，同时很有可能刚刚互相认识。团队的目标没有真正达成一致，而成员则非常依赖于团队领导的指导。

磨合阶段：就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突。团队无论大小都要客服困难，交付结果，大家不得不认真的面对问题，开展讨论了。这些冲突不一定都是技术问题也许是关于角色、职责、相互关系。甚至是各自性格、文化的冲突。不少人都想成为某个领域的“拥有者”（在软件项目中，谁负责哪个方面，每个方面要怎么做，等等）。同时也有一些人会以不同的方式进行挑战。

规范阶段：从磨合阶段毕业进入到规范阶段的团队成员们就角色、职责定义和流程都取得了比较一致的意见。这一时期团队具有以下特点。

团队的工作流程和工作的方式得到大家的认可。成员之间互相更加了解，欣赏各自能力和经验，工作中相互支持。

领导主要扮演促成者和鼓励者的角色，有能力的成员也分担了一定的领导职责，并自然的获得大家的尊重。

随着项目的开展，一些成文的或不成文的规则逐步建立起来了。

作为一个整体，团队要做什么、不做什么，都更加明确。团队的信心更足，和其他团队打交道更有底气。

创造阶段：经历以上三阶段后团队可以创造一些有意义的东西，并不是所哟偶团队都能到达这一阶段。拥有以下特点：

团队知道为何而战，并将注意力几种到如何创造、实现目标上。

高度自治，不再需要领导的时时教诲与介入。不同意见仍会出现，但成员都以一种积极的心态和方式解决。互相支持，互相依赖，并保持各自的灵活性。

萌芽阶段： 这个阶段显然是经历过的，在最初始定下项目选题的时候我们便是在萌芽阶段，大家对于我们的产品的目标完成的主要功能主要是通过我描述和讨论好多次之后才陆续确定下来的。应该算是在alpha冲刺开发前团队一直处于这一阶段向下一阶段迈进。

磨合阶段： 这个阶段的对个人和团队中的疑惑感觉我们团队倒比较少出现，因为团队一直以来的答辩得分和成绩都在前列，所以主要是出现成员之间的角色、职责、相互关系、各自性格、文化冲突。团队其实在Alpha完成后Beta阶段也出现了这种苗头，因为配合不够到位、存在一些误会等等一些原因，但是最终还是算比较正常的解决和度过了这种现情况。（我感觉团队不管在任何阶段都在不断的磨合配合的更好，所以不代表我们在后面阶段就不再需要磨合）

团队成绩展示

团队现场编程

UML现场设计

团队展示

项目评测

需求分析报告

项目选题报告

规范阶段：

团队已经有一些成文规则（开会做会议纪要、每隔2-3天进行反馈...）和不成文规则（开会地点：34#3 or 青卜 or 35#3）

在Beta版本和最终版本阶段我便是主要扮演一个促成者和鼓励者的角色，把任务分配下去看结果的流程，apk经过13次迭代，其中有一些是我要求迭代修复bug，还有一些是队员主动更新迭代，修复bug并发布打包新的apk

团队的信息更足，和其他团队打交道更有底气这是一定的！从团队每次作业团队总分、答辩分数、文档分数都高居榜首便能知晓。

团队还没有达到创造阶段，但是我们的记忆罐头就是我们创造出来的有意义的东西！！！

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

研发出符合用户需求的软件

我们的产品在开发前做过一次市场调研问卷调查（样本容量：线上93+线下110=203份），并完成了我们的记忆罐头商业企划书。其中包括用户对我们产品功能的反馈饼状图，我们产品功能十分符合用户需求。

需求展示

在完成产品后我们邀请了86位用户进行内测试用我们的记忆罐头,并且收集了用户反馈问卷。

体验指数展示

期待指数展示

通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

我们团队在软件工程实践课程的机会之下，通过团队合作完成了产品记忆罐头！分别在Alpha版本阶段完成产品的初始版本，Beta版本完善产品进行一定的bug修复，最终版本已经迭代13次完成产品的1.1.3版本，产品下载链接。

并且通过数据展现软件是可以维护和继续发展的。

现软件的可维护性和是否可继续发展通过上面的用户反馈问卷截图便能看出。

体验指数展示

期待指数展示

用户需求期待指数超过4分的比例在70%以上，证明我们的产品是可维护和可持续发展的。并且产品具有十分可观的盈利方式和前景，对不同手机（三星、华为、Oppo）应用市场的在线付费壁纸做了一个简单的调研：

三星付费壁纸

华为付费壁纸

Oppo付费壁纸

盈利点

可以看出，我们的核心创新点锁屏壁纸展示如果能够达到美观、友好的前提下，还能展示出用户的备忘内容，那么便完全可以借助于付费壁纸已经广为人知的免推广的天然优势！！！在每种壁纸单价较为廉价的模式下，提高用户购买欲，相信可以很快的抢占付费壁纸的一块市场，这样也为后续的开发提供了条件和盈利希望。当然，这一切都需要在能够解决生成美观壁纸展示备忘的这一难点的前提下。也正所谓难点即卖点！

记忆罐头

产品宣传视频&&宣传海报

记忆罐头宣传海报

对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。

第零部分---基本数据结构和算法问题

这部分链接中的博客文章中没有详细的介绍。所以不能详细的进行回答总结。但是根据个人对自己的实力的总结来说，在基本数据结构和算法问题上面比较薄弱，之前算法课程和一些专业课程的上机代码实践都不是很强，所以这方面还需要好好提高。

第一部分---硬的问题

面试问题

现在的回答

毕业时回答

最拿手的计算机语言之一，代码量多少？

语言: C语言；代码量: 10000+

暂无

最拿手的计算机语言之二，代码量多少？

语言: C++；代码量: 3000+

暂无

有没有在别人代码的基础上改进代码？

有的，软工实践就有这种机会。1. 结对项目 中和队友配合完成作业；2. 团队项目 中配合时需要在队友基础上改进。

暂无

你是怎么读懂别人的代码的？

主要通过注释函数接口的注释来实现调用配合，需要内部修改时根据模块划分，看懂要修改部分的算法/功能注释。

暂无

采取了什么办法来保证你的新功能不会影响原来的功能？

一般不会修改别人的代码内部组织结构，主要通过调用，增加模块来实现改进。

暂无

开发中碰到最复杂的bug是什么？如何解决？

Bug: 安卓开发中自定义适配器里的复选框内容缓存复用问题。解决方案： 未解决；采取每次使用都重新读取，不复用方式暂行。

暂无

这个bug出现的原因是什么，在将来应该怎么去避免bug再出现？

原因: 对安卓前端开发不够熟练。避免再出现: 如果经历过这个bug，那么在再次使用类似的控件写类似的代码便会更注意考虑这个问题。

暂无

如何测试自己写的代码？

通过单元测试。

暂无

如何测试别人的代码？

通过单元测试。

暂无

掌握了多少种测试工具和方法？

只在软工才知道单元测试这种东西，都只有一种吧。

暂无

写过测试工具吗？

没有

暂无

如何对一个网站进行压力测试和效能测试？

不会。好像队友有会的，有机会可以一波。

暂无

如何测试一个软件的人机界面？

暂时还不会。

暂无

写过的最复杂的代码是什么？如何测量和改进它的效能的，用了什么工具，如何分析的？

结对作业热词提醒和爬虫（两人作业）。通过Visual Studio自带的性能分析器和代码覆盖率测试的插件进行效能测试。对覆盖率低的部分进行代码。

暂无

你做过多少个有实际用户的项目，用户最多有多少？你的项目有什么创新的地方？

有实际用户的项目没有做过，记忆罐头有内测用户，创新点之前的所有作业博客都很明了。

暂无

行业洞察力

暂时无法回答

暂无

参与过项目管理么？如何决定项目中各种任务的优先次序，有何理论支持？突然发现项目不能按时完成，作为项目领导有何办法？

参与过。按照基础和附加，核心和辅助来决定优先次序。如果突然发现项目不能及时完成，首先是自己预估没有留有足够的缓冲时间，只有一个办法就是将损失降到最小，尽量提交一部分功能的项目。

暂无

你做过架构设计，模块化设计，接口设计吗？有何办法？

没有做过，只有在软工课上才第一次接触这接口设计这方面的知识，而在团队开发中我也是是属于前端。

你是怎么做代码复审的？你加入我们的团队之后，能帮我们提高代码质量么？

没有正式的做过代码复审。无法回答

暂无

你在各种开发平台都使用过什么样的工具？Github上有分享代码吗？

使用过Visual Studio，Android Studio开发安卓，Eclipse For JavaEE 开发JavaWeb，有通过Github进行团队协作并上传代码，技术博客现在也还在坚持，最高阅读量为5000+ 的博客。博客链接；

暂无

请描述你在项目中如何说服同伴采用你提出的更好的解决方案，如何说服懒惰的同伴加紧工作，实现团队的目标？

如果是更好的解决方案，在个人说服不行的时候，我会采取团队投票的方式来进行决策，这时候是最公平合理的，如果大家都不赞成的时候，一般就要考虑方案时候真的是更好，当然存在少数例外。对于懒惰队友，只有通过严格的纪律和惩罚机制 才是最好的鞭策手段。

暂无

你上过什么数学？计算机或其他理论课？

上过高等数学，含有深奥的微积分知识，还有线性代数和矩阵分析，抽象的现实世界和计算机世界一个工具桥梁，还有离散数学，数理逻辑的推理推断，概率论。专业方面有操作系统、计算机组成原理、算法与数据结构、数字与逻辑等等

暂无

全年级你专业排名多少？

这里还是不方便透露吧hhh，太丢人了.jpg

暂无

第二部分---软的部分，在成长路上学到了什么？

学到了很多hhh，这里不知道要怎么回答哎。

第三部分---团队管理源代码的水平

团队对于管理源代码的水平还比较弱。

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

参考论文文献：

[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

个性发挥，包括图文、照片和创意等

Welcome to 404 Note Found. You can see nothing here.