11月，课程繁多、作业繁琐、项目紧张、情感危机，身不由己，时间不够用、精力不够用、心情不够用，学习工作效率很低。万幸，艰难的岁月过去一半了，项目到今日完成第一版，小伙伴们带着我们的寄望飞去海口了；情感危机也幸得珑姐姐和俊文哥哥的开导，心情豁然开朗。剩下的是，课程考试和课程设计。回望过去的11月，有什么新收获？哈哈。
度过艰难的11月份，也许就能在简历上加上新的标签：累积一年多项目开发经验，参与大型项目开发，能够独立开发完整网站，团队意识良好，热爱技术，重视总结等等。
总结几点感悟：
1，同一问题多种解决方案
偶然的机会，国国和师弟讨论起我，说起我的惯常做事风格：“应付”项目要紧，出现突发问题，先放下技术钻研态度，找出解决办法（也许只是一些不入流的伎俩），日后时间充足时候再思考。问题是“被解决”，但确从此找不出额外的时间专研问题。
做事不认真。久而久之，居然养成这样的做事习惯，真心惭愧。
我意识到：同一问题能找到多种解决方案的技术水平很重要。例如，需要呈现类似于手机通话记录的数据，包含短信通知列表、电话通知列表、系统通知列表，通知的基本数据项包含通信人员信息、通信时间、状态等等。怎样才能用便捷简约的方式将数据呈现在用户用户面前，应该使用怎么样的布局，怎么设计不同数据项的层次等等，在没等到美工设计出样式的时候，解决这个问题，有好多方案。 又如，针对ext4对树实现的设计：树加载，自动刷新多次。每点击一级，需要额外加载一次，但是具体的项目需求：单纯加载该权限下人员列表，不需要额外加载。ext4提供便捷，针对常规项目实现功能，却灵活性不足。你会选择怎么样的解决方法呢？如果你选择了回到ext4源码，修改reload，你是否同时考虑到项目是多人开发，修改核心脚本，可能造成其他人代码无法运行。面对新问题，你是否又为新的问题找到新的解决方法？
同一问题多种解决方案，需要多思考，综合考虑、全局把握，想出多种解决方案，然后选择最优的方案，解决现实的问题。
2，全局思考
项目有点大，前期没有好好规划，日后问题会越来越多；项目时间有点紧，分工与计划没有考虑周到，时间只会越来越紧。
怪我咯。没有很好的技术储备，做项目的时候耽搁大家时间。 这时候，已经不能稚嫩地继续“见步行步”。
项目最终决定用ext4开发，ext4的自定义类有利于多人，个人开发的组件放置在各自的文件包里，减少相互影响干扰的可能性，高内聚低耦合，编写好自定义类和脚本文件命名规范，分工，然后一起开发。可是问题来了，分工出现了重叠，两个人做的组件类似，另外两个人同时向后台同学询问数据键。
回想起以前的项目和课程设计，在提高某算法的时间复杂度时候，是否考虑到其实降低了空间利用度，用空间换时间是否值得。在你勇敢使用“便捷”的方式解决问题时候，这样的做法是否会影响整个项目，用更快的开发效率换更弱的性能是否值得。
全局考虑，要求你有前瞻的思考能力，项目开展之前考虑到日后会遇到的一些问题，学会取舍。
3，提高时间利用率
杠杠的远成师弟，每天记录当天学习时间，每周总结当周学习状况，分享到微信朋友圈。
掌握某门技术不难，熟悉掌握确不简单。事件紧迫致使我很多想做的事情都来不及做。github已经好久没写，租了空间、网页却久久不能发布，一直想找个时间温习一下基础，可是书本已经好久没翻，坚持每个月写至少一篇博客，却每次都要等到月末熬夜写出来。
提高时间利用率，需要你在有限时间内规划你自己的需要做的事情，有取必有舍，把握二八原则，着手解决最重要的事情。没有挤出时间来进修，我感觉一直在退步。
4，代码整洁，样式风格简洁自然。
这一点相信也是你们一直的追求，不再累述。
5，及时总结
事至今日，一直很后悔一件事情。如果当初，从做项目第一天开始就找一个小本本记录项目开发的过程多好。即便这个过程中没有遇到技术难点，没有想到解决方案，只是能够记录下当初的思考路线或者需求的变更，从第一版到最终版，相信也是有点小非凡的创举。可惜我已经错过很多有用的记录了，这里希望师弟师妹们能尽早意识到这一点。
6，文本稚嫩，逻辑思维太弱。
写了那么多篇博客，文笔还是那么稚嫩，逻辑依旧没有深度可言，多看综合类的书，接触程序员领域以外的文章，或者。。。这一点打死懒惰的自己。
关于这个项目，还是有几点值得回味，值得自豪的：
1，提议使用ext4，为项目搭建基础开发平台。
2，制定规范，开发部分基础公用组件。
3，与美工沟通，成为前端和美工的通信桥梁。
4，为项目前端部分制定计划，分配任务。
5，定时总结项目进度，并向老师汇报。
最后献上章杰师弟的诗：
无奈的我们
我们可以日撸千行 无奈程序启动难
我们可以日撸千行 无奈异常捕捉难
我们可以日撸千行 无奈程序bug满堂
我们可以日撸千行 无奈前后交互难
难难难