口水记

今天还是下雨了，不过是在下午时分，上班的时候还是挺明朗的。

昨天的那个需求，还是有人接下来了，好吧，接下来我认了，需求他们偷偷的评掉了，找我改代码，en？黑人问号？为啥我也要改。行吧，看了下对应开发的技术方案，嗯？

大致是这样的，半个月前上线一个项目，其中涉及两个需求的一个数据，就叫sb数据展示吧。

当初的需求评审我也参加了，技术方案我出的，产品的意思是，这两个sb数据的展示是不同的，也就是说，这两份数据，那就叫sb1数据和sb2数据吧。那没毛病呀，这两个数据就是两份数据啊。不同系统，那自然是在不同库咯。

不过我没开发，当时也忙，出了方案就去做另外的项目了。

上线才大半月，产品改需求了？"嘿，有人想要这个sb1和sb2数据同步，也就是sb1=sb2。技术来来来，我们开个需求评审"。当然，这个我不知道。我知道的时候已经是评审完了，也就是前面的情况。然后有一开发找我让我系统改一改，sb数据修改时通知他...en???

ta的方案大体如下，我画了下图。

其中a、b系统分别存储了sb1和sb2的数据。

这需求提的也莫名其妙，接的也莫名其妙，技术方案也莫名其妙。

我也是莫名其妙，这需求做是不可能做的，要不产品拿出数据原因和我怼。

当然，ta直接就接了需求，我就这个技术方案提了点意见。

"你直接用b系统的sb2数据不就行了，sb1数据直接废弃"。最后ta被我说服了，其实我的意见是不做这需求，哎，开发小伙伴，咋就不知道怼怼产品。也可以学学网上的，桌面一个二维码，要提需求先扫码

另外就是分表方案大坑，大坑呀。。。。。。

没办法，前人已走，这坑我先填了。

至于以后的锅，我在想，我得升级一下，先秃头，这样我可能会不沾锅

小结

技术方案还是要考虑全面一点，能简单的绝不复杂化，能一个系统解决的事情，绝不放到两个系统串一串。

还有一点，不要在业务项目代码中炫技，很重要。规规矩矩写代码，好好写注释，是不会错的。

好几年前，我也是炫技圈的一个，能用流操作，绝不分行写。能异步，我就不同步。可以用到设计模式，我就是要用，管你项目是不是需要，我用模式我牛逼。诶，java出新特性了，我在项目中试试效果。这哪个写的代码啊，写这么多行，不行，我优化下，你看，一行就好了。

管你看不看得懂，看不懂我才牛逼。什么，我自己也会看不懂？不存在的；两周后...这哪个sb写的代码，嗯？看看git提交记录：小猿？ 嗯？原来是我啊，哦哦哦，代码是这个意思，我懂了，这代码牛逼呀、

代码上的炫技在个人项目上、在框架*上写写，我觉得挺好的，但是真不适合团队合作。如果团队有这种人，及早从团队中给他拧出来，否则哪天，他跑路了，你会嘿嘿嘿的。

不正经语录

• 桌面摆个二维码，要提需求先扫码
• 团队业务项目中炫技之人，不外乎两种，一为自私自利之人，二为萌新小韭菜

声明

本文故事纯属遐想，如有雷同，我是原创。

欢迎转载。
转载请务必注明以下信息。
原作者：谙忆
原文地址：https://copyfuture.com/blogs-details/20200515193726720r3nhsoucod0q9mk