关于技术和产品的一些体会

今天药忘吃喽~ 2022-06-08 10:00 267阅读 0赞

从毕业伊始，到现在工作有一年多了，经历了很多项目，游走于技术、业务、产品之间。大部分工作是在开发业务功能，但并不妨碍自己从中学到很多东西。做着做着，慢慢觉得设计一个好的项目骨架，使用适合的设计模式、数据结构、算法能让你的系统变得易于扩展，可维护性增强，事半功倍。大学时候学的设计模式以及数据结构用处还是非常大的，是时候好好温习一下了。

### 技术 ###

反正就是写代码呗，但希望自己是那个写代码写得好的。

#### 1. 注意响应时间与执行效率 ####

互联网应用后端大多数都是业务接口开发，如果这个接口的响应时间奇慢，用户可不能忍受。所以，在开发功能的时候，好好想想高效的解法，设计好的数据结构去表示业务模型，能缓存的则缓存，降低接口访问时间，提高用户体验。

#### 2. 分页处理批量数据 ####

业务系统的开发中，经常会遇到要去处理数据库里的大量数据。常规做法是一股脑从数据库中将批量数据取出来，然后循环处理，这是很有风险的，大量数据加载到内存中没准就内存泄漏了，曾就遇到过这种情况（线上服务器直接宕机了）。那处理大量数据最好就是分页去处理（limit 0, 100），每次取出一小部分数据来小心翼翼的处理。

#### 3. 复用代码 ####

打开你的工具库，开箱即用，一次编写，多个地方使用。抽出公用代码块，做成供大伙使用的一个个小方法，杜绝重复代码，杜绝冗长的方法代码块。

#### 4. 可扩展 ####

永远不要只是实现功能就行了，寻找适合你业务的设计模式，在需求变动的时候，只需少量改动代码就能满足需求。

#### 5. 每一行代码都是要有意义的 ####

每一行代码、每一个字母都要是有意义的，删除那些永远执行不到的代码，保证代码整洁。

#### 6. SQL优化 ####

写了一条sql以后，想想是否用上了索引，是否还可以优化变得更高效。

#### 7. 服务化 ####

后端服务基本上都是SOA服务，在你的业务领域里对服务进行细粒度的拆分、归类，比如一开始就根据不同的业务板块拆分成多个服务。  
![项目初期服务拆分][SouthEast]

如果一开始还在试错阶段，所有的业务操作都写在一个服务里，那也要根据业务情况对服务进行拆分，将这些服务放到不同的package下，服务之间进行解耦式设计，在业务爆发式增长后，要把这个服务里某些服务拆分出来也很容易。所以在前期一定要规划好项目结构，独立的服务不要耦合在一起，为以后拆分服务做好准备。  
![业务增长-服务拆分][-]

#### 8. 技术成长 ####

多看书，多总结，谦虚谨慎，形成自己的知识、技术体系！ 要从重复性的劳动中解放出来。

#### 9. 沟通 ####

做技术的人给人的刻板印象是木讷、不善于沟通，虽然天天和机器打交道，遇到问题要及时说出来，虚心请教，将细节沟通清楚，大胆说出自己的想法，不是一人孤军奋战，要共同去完成项目交付。

#### 10. 反思 ####

当你在写重复代码的时候，当你的团队在天天熬夜加班，总是在做修补bug的事，写了一天代码感觉只是在搬砖……那就要好好反思一下自己了，是不是可以改进这个流程，这个事情是不是应该搞一个自动化工具去做，是不是应该学习新的东西去设计系统……

> 记住：机器是用来改变人力的，而不是人力去做机器的事情！

### 产品 ###

开发过程中和产品经理交流最多了，作为开发，透彻理解产品需求是再怎么强调也不为过的。理解不透彻，直接影响你的技术设计，就像一锅汤里的老鼠屎一样，令人讨厌无比。

认真阅读需求文档，明晰每一个产品细节，和产品经理积极沟通。如果存在不合理的地方，那就给产品经理提建议寻求更好的方案。开发工程师基于已有的技术基础，梳理清楚业务需求，美好的场景是：工程师带着技术，产品经理怀揣着点子，然后一起去拨开云雾见天日，相爱相杀，共同去缕清业务逻辑，打造更好的产品。

可有可无的需求点：我遇到的情况就是加上这个需求点之后，我需要写一个很恶心的SQL语句，也没有其它很好的解决方案。这个烦人的SQL语句很可能会拖垮系统，哈哈，那就砍掉这个需求点吧（产品经理同意了）。作为一个成熟的开发者，要及时在你的技术范畴里去规避这种可有可无的需求点，并会带来技术缺陷的功能。存在技术缺陷的地方，保持关注，过早处理掉，不要等到问题出现了，才意识到这个问题。

[SouthEast]: /images/20220608/af60afc2bfc8454cbdc6acd1b9abc94a.png
[-]: /images/20220608/cf00196da9fc4284ac1f2558100e033f.png