1.开发时本人做法
(1)仔细研究产品原型，尤其是自己负责的部分；
(2)针对自己负责的部分，每个功能画一个业务流程图；
(3)在画好业务流程图后，研读项目结构，每一层主要做什么，每层之间的关联是什么
(4)在做好上述三步以后，我充满热情的开始写代码，写代码前我会先看前辈怎么写，尽量保持代码风格一致，然后把自己的思维逻辑写成注释，然后按照注释一边思考，一边写；
(5)由于经验不足，自身技术不成熟以及排期比较紧的问题，为了与研发团队风格整体保持一致，在写代码的过程中，遇到了一些自己从未见过的方法，在这个时候，为了不拖团队进度，我选择了大致查一下这些方法怎么使用，并未详细研究便直接使用；
(6)在开发的过程中，我习惯先全部写完，然后再逐一进行测试；
(7)遇到实在解决不会的问题我会及时去问前辈；
(8)不管产品，前端以及研发前辈们以及研发告诉我什么，我总会因为自己经验不足不够自信而完全听大家的。
2.开发后经验教训
(1)开发以后，从第四步我就开始犯错了，不是做的不对，而是在看前辈的代码时，完全失去了自己的判断，风格保持一致，不代表代码写法要完全一致，想要成长，还是要有自己的成分在，前辈的经验可以借鉴，但是照搬照抄不可取；
(2)在接下来的第五步，我也犯了错，那就是对自己不熟悉的方法在没有仔细研读就直接使用，不拖进度的想法是好的，但是盲目使用可能虽然能让自己的开发速度加快，但是在后期测试得时候可能会造成很多麻烦，所以还是要弄清楚到底怎么用，不要盲目；
(3)第六步中我也未能幸免犯错，这种方式也不算错，但是个人在参与项目开发后，觉得这种方式还是比较适合大佬，对于开发小白，还是选择写一个某块测一个模块比较保险，要保证自己写的代码都是有质量的可以用的，只要一个模块通了，后面也就通了，如果选择全部写完再测试，运气不好的话，自己写的可能全是问题代码，并且把所有的问题都堆在了一起，是时间紧的情况下，解决起来会非常棘手。所以个人建议，如果还是研发小白，最好写一块测一块，等到经验丰富，晋级成大佬，再选择全部写完再测的方式；
(4)第七步中，错误倒是没犯，但是由于自己不够细心的问题，很多问题明明是细心就可以解决的，但是自己却总是忽略细节问题，这一点再犯，一定要狠狠的给自己大脑一拳，长长教训；
(5)如果是自己写好的代码没有达到预期的效果，自己又找不出原因，个人建议请教前辈的时候，最好直接告诉前辈自己怎么做的，想要达到什么样的效果，现在是什么效果，而不是直接去让前辈看你的代码，看别人的代码需要时间，前辈一般也有很多事情要忙，直接让他们看代码可能会浪费他们的时间，如果前辈直接从你的业务逻辑中找出你的问题，就可以避免浪费前辈太久的时间；
(6)虽然经验不足，也不能完全否定自己，如果有质疑直接进行沟通，而不是带着质疑完全听从大家的话；
(7)不能过分不相信自己，也不能过分相信自己。前者是针对经验教训第六条，后者是指写完代码未达到预期效果，请检查自己的业务逻辑是个否正确，不要过分相信自己的思维逻辑一定没错；
(8)遇到问题不要害怕，不要着急，要勇敢地去解决，遇到问题很正常，一定要找到问题在哪里，一着急就只会盲目的猜问题在哪里，这样只会事倍功半，可能连半都达不到，所以遇到问题请一定要稳住，冷静分析，找出问题并解决。
3.心路历程
从开始的充满热情，到结束时的对自己的否定以及失望，只是短短一个周的时间。还好自己脸皮够厚，很快调整了心态，重拾信心和战斗力。第一次开发虽然离自己预期结果很远，很失败，但是不能因此放弃自己，自暴自弃，而是要好好总结自己的本次开发问题所在，不断学习，不断积攒经验，只有不断努力，才会让自己毫不费力！
现在的我，又是一个战斗力爆棚的我，虽然技术很差，但是只要不断努力，相信不会再留下没有技术的眼泪，也不会再让这个过程中帮助和鼓励自己的人失望。
希望研发小白们都能早日经验丰富，不再流没有技术的眼泪。
最后强调一点，一定要勇敢的去问问题，不要觉得问题简单就不去问。用我们组小哥的话鼓励大家问问题：每个人都是这样走过来的，不要管问完以后别人怎么说你，要记住，你和前辈的高度是不一样的，别人就算会说你也是正常的，不会就是不会，只要问过以后会了，这就是收获和成长。多问问题，会成长的更快。当然一般大家都是很好的，是很乐意为大家解决问题的，比如我们组的大佬们人都很好。
在这里再次祝愿大家，都能和我一样，工作刚起步，就能遇到这些很好的前辈。
原文地址：https://blog.51cto.com/13678728/2430440