SVE回顾
写完后的自评：书写太过凌乱，基本无法阅读。
前几日,SVE通过了TR5,虽说是一个小得不能再小的项目,即使到最后也存在一些未能解决的问题,但在用户的通融下还是在超期一段时间后写下了一个暂时的句点.
结束是新的开始,一个项目的开发结束并不是该任务的完结,后续还会间或地有这样那样的事,更重要的是,要考虑的并不是过去已经完成的,而是未来还很长,还有那些要一一去实现的.
六月底加入CAD(Computer Aided Design),酱油了几天跳到了七月,捧着”苦学”了多年的C++重新开始了复习C++的过程,何其Shame.早起为打卡,上班瞅下班的日子过了几天,熟悉了一下环境转着弄了一段时间的QT,算是熟悉了Win下的开发流程.然后是Linux下的Skill一两个礼拜的磨工到了八月.当时想着时光好快,一二三…一个个的纪念日就这样遥远又忽近,瞬即就消失.
终于开始了SVE了旅程.说起是旅程,也像模像样地想要搜索好攻略.听了JW的几讲,似懂非懂地和跟着他跑来跑去了解LY的需求,不过当时只把这个阶段完全当作身外事,左手持笔右手拿机,偷偷摸摸地刷个微博逛个空间.那什么业务细节,需求统统浓缩到了几个名词里面,等到三、四次，面谈结束了才知道个大致的流程，但里面的细枝末节则一无所知。好似要往北京去，就把那指南针往手上一握，拧着眉头思索，然后坚定地遥望远方说：走。
说走就走啊，其实就是无头苍蝇。想要先把涉及的关键技术给理清，结果连哪个是关键都不知道。对其中名词又不知道意义，大半个月的时间就在意义不大地摸索中。等到来“检查”时候才发现，这还在MTS十米范围内嘛！于是又是苦口地几副药，良药入口，稍微有了几个具体化的点，慢慢地啃，进展缓慢。
终于到了九月啦，十月就在眼前，月初就得交付那，还在哪里设想还不走就走不到了呀。什么思考得完善，考虑得周全，问题是没有基本的对需求对关键知识的掌握根本是无法思考得完善的。这点在后面的开发中就明显体现出来了。
前面阶段的C++部分不怎么涉及专业领域，轻车熟路走得尚敏捷。但是碰到不懂和与业务有些许相关后就发现黑色区域太多，把握不到点子了。折腾了一阵后发现有一部分功能没实现，有一部分需求不对，有一个关系不是这样，啊，把那原本就不堪的设计涂鸦地更加难看。
遇强则弱的性格再次占据上风，于是又懈怠了一会，平添了几天的焦虑。磕磕绊绊做出个半成品，不敢拿给用户看，捂着捂着被动开了光，一看，这不行那不对，这点不周全，那点太片面。
想起来，精益求精并不是一句空泛的台词，能做到，第一次就做到才能体会到其中的辛苦。否则，中途就可能需要大改特改。
很多时候做的东西用户是否满意，是否符合需求，自己捣鼓是不知道的，不给用户检验就无法知道最终是否可行。因此越早地将用户拖入到开发过程中就越早能发现问题。尤其是在自身对问题把握不够的情况下，更需要用户来纠正其中错位的观点。但问题是，对于一些地方，用户也不见得就已经注意到，柳暗花明处也许是要走进才知道个中有路。
其次，一个东西是需要良好设计的。如果不能合理规划其格式那么至少要让其统一符合大众规范。而不要以为那是小事，因为这些小事累积起来也要花上多余的琐碎时间。既然是简单的调整在第一次就设计合理其实是最为划算的事。
用户只会聚焦在自己所要的信息上，那些只有开发员才懂的东西就让它隐藏到深处吧或者能开就开要关就关不要东一个西一个太过突兀。
实现功能还是合理架构呢？一个项目越到后面代码量就越大。如果前期不进行重构那么后期要处理的只会越多，到时候刀斧难加，也不想加，你想这每一刀都要又深又阔，该要怎么有时间。况且，后面就不会变了么？没效率的话，不仅功能没实现，更别说架构更好了。因此，重构是有一定斟酌的，能合理重构代表你要把握整个项目的过程以及中间的诸多细节，当然不可能面面俱到，但至少是要七七八八，即使修修补补也不至于大动斧刀。
回想起来，磨刀不误砍柴工，前面如果真能把需求一一和用户明确，明确到最终的效果，而不是模拟两可的大致，那么起码在最终做出的效果上会符合用户要求。其次，明确需求，对整个业务有真实的了解才可以做到胸有成竹。否则再谈什么架构都是虚的，很容易就会发现这缺那少要修补。因此，较好的还是能一开始就走通流程（但这样，有可能也是不可行的，因为在使用过程中才会发现需要的更多，因为用户的需求会得到发掘。）
怎样才是正确的呢？现在还不懂，也不明了，但是掌握更多并不是迟迟不动手的原因，如果是在那里无所事事地思索方案的话，一个不成熟的方法是没什么意义的。还是早起走吧。