口水記

今天還是下雨了，不過是在下午時分，上班的時候還是挺明朗的。

昨天的那個需求，還是有人接下來了，好吧，接下來我認了，需求他們偷偷的評掉了，找我改代碼，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