目录
一、彼岸花开，花开彼岸
古
- 看了下当时写的博客，发现当时自己写这个好像不怎么用心，很多可以再仔细思考的内容，并且那时并没有真正的对软件工程有深刻的了解，不外乎认为是写个软件而已，就是敲代码，希望有个任务强迫着自己学多学点知识，再加上组队后，担任队长的角色，有点担心自己做不好。
今
- 现在吧，我会希望自己能够先端正态度，每个任务都用心完成，学会时间合理规划，不要每次都是deadline才冲刺；努力让团队意识巩固，树立良好的团队氛围，加强团队内的沟通；别为了完成任务而应付，草草了事，务实使用到的知识，其中有很多值得自己一直学习的；文档和代码一样重要，不要忽视任何一样；代码能力要加强，要系统的学会语言，不然会留下很多短板。
新软件、新工具
- markdown编辑的VScode、逻辑框图的XMind、原型设计的墨刀与AxureRP（来来回回使用了好多个，就简单推荐两个）、UML的Rational Rose Enterprise Edition、流程图的viso
新语言、新平台
- Java的MyEclipse、Android的Android Stdio、代码分享控制的GitHub、便捷数据库的SQLite
代码统计
- 由于分工安排，编写的代码量真的偏少些
新方法
- 文档格式转换，视频格式转换，代码测试工作
其他
- 怎么有效地组织团队讨论，团队分工，团队交流，怎么进行技术交流，怎么快速使用代码，怎么代码命名等等
二、立足实处，执笔挥洒
`站的直` + 站的直，顾名思义，站似一棵松，行的端坐的正，身正不怕影子斜。每个任务，不能懈怠，不能带有敷衍的情绪，因为松懈了，就会有不如意的地方，就会给了自己一个无法反驳的原因，为什么得到的评分这么低，为什么做出来的效果这么差，为什么这么简单的点会难道自己，会有很多个为什么让自己无能为力，大家应该都不太喜欢哪种有劲却使不上的感觉吧。走的稳
- 行走一步一个脚印，没学会走，别想着跑，别摔得爬不起来。就像把学一个语言，没去理解基础代码知识，只想着网上搜样例，认为看着改改就能成，可是吧，到头来你会发现，你根本不会改代码，你压根看不懂它写的什么，然后干着急，到头来还是得从头开始学习，白白浪费时间，又破坏了情绪。
看的远
- 视野远，不能光想着眼前简单解决，最终发现，当时随意的解决方法是错的，如今自己还得从头开始改正，需要为曾经的随意付出代价。我们组，一开始时对Git的使用不是太在意，使用率不是太高，有很多的使用技巧没有系统化的巩固过，所以就选择了coding.net进行使用。然而到了后期，发现coding.net的使用上，会有点难以符合使用的要求，很多需要的反馈没法给我们，只好不甘愿地转向了GitHub的使用，然后因为一开始就不太熟悉git的使用，那时就花费了两天时间，废寝忘食地恶补，一点点地尝试git的使用。等成功时才发现自己那时的想法是多么的幼稚。
三、回观来者，谨遵初心
`建议` 1. 软工要花费很多时间，怎么样的付出就有怎么样的回报，怕幸苦的赶紧退出。-
软工主要教你的是整个软件成型的过程，不是教你写几行代码，授之以渔，并不是授之以鱼。
-
文档和代码一样重要，不能轻视任何一样，多写注释、文档，利大于弊，你想想假设你去看别人的文章，你是希望别人像你一样只关心代码，还是兼具备注，理解难度降低许多。口头上信息，容易忘，还不准确，文字简单明了，还不易忘。
-
希望能够先端正态度，每个任务都用心完成，别为了完成任务而应付，草草了事，因为每次都有评分，最后成绩是每次分数的汇总，如果等你哪天突然心血来潮想要那个好分数，可是你之前的完成情况不允许，你会不会后悔。所以，有句话可以送给你，“优秀是种习惯”。
-
学会时间合理规划，真的因为课程原因，自从Alpha版本冲刺开始，每周的时间都很忙，忙着编码，文档，再加上课程学习，作业甚至于后面的考试复习，经常需要熬夜。特别有一点需要强调，不要每次都是deadline才冲刺，因为那样给自己的可控区间太少，并且稍有不慎，心态很容易崩，并且一定会熬夜。
-
确定自己的目标，不要犹豫，放心大胆的往前走。
-
作为“PM”，我也不知道自己合不合格，姑且这么叫吧。从我的角度，软工是个团队项目，需要有很多的交流，需要团队协作，需要团队意识巩固，良好的团队氛围，所以有的时候说话要三思。说话很容易，什么都不用想，“为什么是我，我不会，反正我不会，我很忙”动动嘴皮子，甩锅也容易，“这是他的事，没我什么事啊，干嘛找我”。这种情况，问两边，第三遍不用听完，转身就走，因为接下来的话也是没意义的。然后，我要强调背锅的重要性，这点我深有体会，一开始还觉得背锅很羞耻，这都没做好，到最后，习惯了，我的锅我认，我认的理直气壮，我问心无愧，但是，不是我的锅，呵呵，谁爱背谁背去。背锅是到坎，没人喜欢承认自己错了，没人想在别人面前出丑，说多了都是矫情。然后呢，别太相信“自觉”这个词，因为吧，没人会自己给自己找别人的事（干嘛要我，谁爱干谁干），别太相信你手机上发的信息，特别是团队信息（啊，说了啥，哦，没我的事，哦，忘了）。所以，一开始我吃了亏，我认为这是团队项目，大家会自觉的想要把任务完成好，自觉地去承认任务，所以我没有紧跟着组员，所以导致一开始的一些软件设计，项目流程上会有点问题，将错就错吧。到Beta版，我学乖了，把deadline提前，你也不希望熬夜吧，那我当面分配出来的任务，你按时完成，我要了解你的进度，你甩锅，哦（转头，分配给另一个人）。我也承认我有时也有点脾气，没分配好，因为我没有足够的底气去反驳。我想要用合适的人，去写合适的内容，但是吧，计划赶不上变化，要变通。一不小心话就多了，总而言之，言而总之，多动脑子，多思考，一切都简单。
四、携手并肩，同铸辉煌
`四大阶段` 1. 萌芽：这是我们一开始确认选题，通过讨论，交流选定作品，在通过采访一些用户，访问一些学长学姐获取他们所了解的信息，进行一定的需求分析，确保项目的可进行性。突然发现在这个内容中，我又要加上我背锅的内容，在讨论的时候，因为组员的水平不一，导致讨论都是某几人主导，其他人旁听，我想过改变但是奈何旁听生没想法。 1. 磨合：这个阶段，我们进行讨论，磨合所需功能，可否提高，是否还有更好的，一系列思维碰撞，确定原型，确定代码规范，进行体系结构设计，确定数据库等等细致的构造。哈，我又来了，在Alpha阶段，我做的的确不好，基本采取放养的策略，都是成年人没必要有人催着，所以发生了连锁反应，而我的解决措施也是没措施。 1. 规范：通过作业的督促，在我们Alpha的冲刺下，完成了版本1.0，已经有了一个样板房，就剩下装修。所以，在Beta冲刺下，我们进一步完善功能Bug，进一步充实功能，增添了云端服务，社交服务，已经粉刷好，把家具全都放进去了，整个家都已经快要能住人。我，这次不背锅，我很认真的分配了任务，了解组员进度，项目发展，虽说还是会有些小问题没处理好，但是，我问心无愧，我什么事都希望完成到最好，我也不想大家熬夜，奈何别人拖延，给我的只有60%，拜托这是团队项目，不是个人的，这么任性，别怪我“掀棋盘”。- 创造：最后但也是项目不可或缺的，校验，debug，一点点的找出bug，完善，修正，发现家中某个家具位置错了，或者墙面颜色不正确，一点点地把新家修缮好。看着我们完美的家，会发现一切付出是值得的。我也不确定这算不算的上创造，至少让人挺满意的。
五、多言半语，浅显易懂
+ 在读了《Open Source Software Development Should Strive for EVEN GREATER CODE MAINTAINABILITY 》这篇论文后（当然，以我的水平，只能靠翻译），觉得里面的内容开源，代码，规范，我觉得最有感想的是，规范吧，因为可能自身的水平还不足以让我对开源的构思会有很大的一种见解。 + 如果说没参加软工，或许我的代码在我没忘记时只有我自己能看的懂，如果我忘了，估计我自己都看不懂，因为没注释，没命名规范。命名规范是看了很多demo使用驼峰，而注释，是有一次需要别人帮忙，只是需要他写的一个爬虫程序，然而别人大佬，不屑与给你讲解要怎么使用，代码又一点注释都没有，完全不知道。所以真实的教训，很深刻。但是现在自己也发现一点，有时自己明白要写注释，可是由于当时自己正在构思，脑子一直在思索代码，如果这时抽空思考注释，很容易就没idea了，然后代码写着写着注释就越来越少，除非后面再回返特意填注释。 + 有关代码的规范，大泥球自己还是会注意的，除非自己一开始的结构错误，不得不复制粘贴一大段冗余段，这是让人很蛋疼的。六、学以致用，用以促学
`问题一` + 由于考试月，加上水平有限，在与组员讨论后，这方面的措施都觉得不太切合实际，所以实施出来的可能性较低。问题二
- 我们博客园的团队随笔汇总记录了我们软工所有的过程，见证了我们的成长。
问题三
- 我们团队的GitHub的Beta库中，保留着我们的最终版代码，虽说master上的commit记录没了，但是分支上还是能有所体现的。