大家好，又见面了，我是全栈君，祝每个程序员都可以多学几门语言。
关键点：
不管什么时候，文档一定要同步，一定要重视，其一是由于有统一标准，其二为后期，或者下个版本号的升级，重构，添加�功能省了一半以上的时间，与没文档的相比較（至于团队等方面比較泛的东西，你懂滴）
需求：
需求人员（事实上业务人员写需求分析可能会更好，由于他对业务灰常了解）需站在用户的角度去想问题，定位清晰的目标人群，切忌模糊不清的需求，看着办或者边做边改动的思想，后期的改动后会让你付出慘重的代价。
通经常使用户也不理解，描写叙述不清该功能应该怎么实现才好，这时候，作为业务人员必须清晰了解，其目的是什么，从目的出发，从而提出合理性的建议，为开发者省时间，减小用户的改动率。越牛B的公司越注重需求，好像我们公司的当中一个项目，就是由于需求不清晰，结果程序人员改到三更，也不能让用户惬意，用户的想法太多了，一会儿说东，一会儿说西，需求需用户签字，就是确定某一个版本号功能，使用户不能三心二意。
用户不当的需求也要懂得拒绝，就像要一个人唱歌，同一时候又要他沉默，不可能的是吧，类似这时候的需求要拒绝，反正你应该懂的。
架构设计：
架构设计，这个相当的重要，要明白开发语言，数据库，还有server承载的压力，从大的方面出发，大功能实现了，再慢慢细化。
架构方面一定要想得长远一点，整个轮廓比需求还要清晰，事实上关键点在于算法，用恰当的算法会为你的项目的性能方面加入�不少的亮色，切忌用转几个弯才干到达的算法。
接口文档，这时候须要定好，还有总体的思想框架也须要定义好，须要注意的是，假设在设计过程中，遇到了错误，或者有不当，第一想的是直接修正它，而不是找替代品，取代它，尽管短期效果非常好，但长期来看，直接改动，前期会痛苦，后期就轻轻松松，由于有可能后期的改动会与那个错误或不当有关系，假设当时没有直接改动，那这时你就纠结的了。我们公司的还有一个项目就遇到这个问题，測试的时候出现了一个功能不合理，他用补的形式，如今就杯具了。
编码
统一标准，统一的格式，规范化的提示语等等
数据库语句尽量精简，比如，一句SQL语句能行的，就不要多条
还有，參数原则，不要写死，要不然后期修改非常大，甚至会牵一发而动全身，这就不太好；多用重构的思想。
測试
越早介入測试越好，測试计划——測试用例——运行測试——測试结果——反馈——回归測试
鉴于一二版本号的系统非常不稳定的，所以这时候对系统的主要功能进行測试即可了
第三版本号之后，就进入详细的功能測试，性能測试，越细节越好，假设是站点方面的測试，一般使用的測试工具是Loadrunner.
美工
一般都是用PS的啦，好的图片要不买，要不自己设计，对了，美工做得好的话，会让站点添加�不少的色彩，但切记太炫，返归自然，是一种不变的规律。前期的成本投入不多的时候，能够考虑看轻，但也须要让人看得舒服。
Anyway，如今好的产品都是好用+运维的，所以在设计方面好之外，还要加上运维的。还有产品好不好，是用户说了算滴，千万不要想当然，假设满足大部分用户的需求，这产品就差点儿相同了。性能，稳定性都OK的情况下，大胆让用户试一下，后期逐渐改进。
附带资料：
灰度法则：需求度，速度，灵活度，冗余度，开放协作度，创新度，进化度
在研究过程中，腾讯形成了一个“10/100/1000法则”：产品经理每一个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。这种方法看起来有些笨，但非常管用。（用户反馈，产品方面的）
清晰、简单、自然、好用的设计和产品，这是人对美最自然的感受和追求。
速度：高速实现单点突破，角度，锐度尤其是速度，是产品在生态中存在发展的根本。（小步快跑，高速迭代）
灵活度：敏捷企业，高速迭代产品的关键是主动变化，主动变化比应变能力更重要。
冗余度：容忍失败，同意适度浪费，鼓舞内部竞争内部试错，不尝试失败就没有成功
开放协作度：最大程度地扩展协作，互联网非常多恶性竞争都能够转向协作型创新
鉴于我没登录进去查看信息，所以仅仅能模糊地说下我自己的看法，纯属个人意见，关于市场方面的话，我相信，你比我更清楚，应该有一份需求在你手上的，你能够研究一下，再查看市场动态，工作是每一个人的必须，提供的这样一个平台，自然有市场，但市场大还是小呢？你是想霸占哪个领域呢？你的特色又在哪里呢？（由于同行毕竟不少）等等，一系列的东西，定位好了，就赶紧行动，行动才是硬道理，在实践在不断地改进，相信会越来越好的，记得反思与总结，最后祝你好运！
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/118935.html原文链接：https://javaforall.net
