从毕业伊始,到现在工作有一年多了,经历了很多项目,游走于技术、业务、产品之间。大部分工作是在开发业务功能,但并不妨碍自己从中学到很多东西。做着做着,慢慢觉得设计一个好的项目骨架,使用适合的设计模式、数据结构、算法能让你的系统变得易于扩展,可维护性增强,事半功倍。大学时候学的设计模式以及数据结构用处还是非常大的,是时候好好温习一下了。
技术
反正就是写代码呗,但希望自己是那个写代码写得好的。
1. 注意响应时间与执行效率
互联网应用后端大多数都是业务接口开发,如果这个接口的响应时间奇慢,用户可不能忍受。所以,在开发功能的时候,好好想想高效的解法,设计好的数据结构去表示业务模型,能缓存的则缓存,降低接口访问时间,提高用户体验。
2. 分页处理批量数据
业务系统的开发中,经常会遇到要去处理数据库里的大量数据。常规做法是一股脑从数据库中将批量数据取出来,然后循环处理,这是很有风险的,大量数据加载到内存中没准就内存泄漏了,曾就遇到过这种情况(线上服务器直接宕机了)。那处理大量数据最好就是分页去处理(limit 0, 100),每次取出一小部分数据来小心翼翼的处理。
3. 复用代码
打开你的工具库,开箱即用,一次编写,多个地方使用。抽出公用代码块,做成供大伙使用的一个个小方法,杜绝重复代码,杜绝冗长的方法代码块。
4. 可扩展
永远不要只是实现功能就行了,寻找适合你业务的设计模式,在需求变动的时候,只需少量改动代码就能满足需求。
5. 每一行代码都是要有意义的
每一行代码、每一个字母都要是有意义的,删除那些永远执行不到的代码,保证代码整洁。
6. SQL优化
写了一条sql以后,想想是否用上了索引,是否还可以优化变得更高效。
7. 服务化
后端服务基本上都是SOA服务,在你的业务领域里对服务进行细粒度的拆分、归类,比如一开始就根据不同的业务板块拆分成多个服务。
如果一开始还在试错阶段,所有的业务操作都写在一个服务里,那也要根据业务情况对服务进行拆分,将这些服务放到不同的package下,服务之间进行解耦式设计,在业务爆发式增长后,要把这个服务里某些服务拆分出来也很容易。所以在前期一定要规划好项目结构,独立的服务不要耦合在一起,为以后拆分服务做好准备。
8. 技术成长
多看书,多总结,谦虚谨慎,形成自己的知识、技术体系! 要从重复性的劳动中解放出来。
9. 沟通
做技术的人给人的刻板印象是木讷、不善于沟通,虽然天天和机器打交道,遇到问题要及时说出来,虚心请教,将细节沟通清楚,大胆说出自己的想法,不是一人孤军奋战,要共同去完成项目交付。
10. 反思
当你在写重复代码的时候,当你的团队在天天熬夜加班,总是在做修补bug的事,写了一天代码感觉只是在搬砖……那就要好好反思一下自己了,是不是可以改进这个流程,这个事情是不是应该搞一个自动化工具去做,是不是应该学习新的东西去设计系统……
记住:机器是用来改变人力的,而不是人力去做机器的事情!
产品
开发过程中和产品经理交流最多了,作为开发,透彻理解产品需求是再怎么强调也不为过的。理解不透彻,直接影响你的技术设计,就像一锅汤里的老鼠屎一样,令人讨厌无比。
认真阅读需求文档,明晰每一个产品细节,和产品经理积极沟通。如果存在不合理的地方,那就给产品经理提建议寻求更好的方案。开发工程师基于已有的技术基础,梳理清楚业务需求,美好的场景是:工程师带着技术,产品经理怀揣着点子,然后一起去拨开云雾见天日,相爱相杀,共同去缕清业务逻辑,打造更好的产品。
可有可无的需求点:我遇到的情况就是加上这个需求点之后,我需要写一个很恶心的SQL语句,也没有其它很好的解决方案。这个烦人的SQL语句很可能会拖垮系统,哈哈,那就砍掉这个需求点吧(产品经理同意了)。作为一个成熟的开发者,要及时在你的技术范畴里去规避这种可有可无的需求点,并会带来技术缺陷的功能。存在技术缺陷的地方,保持关注,过早处理掉,不要等到问题出现了,才意识到这个问题。