小猿日記 - 程式猿的日常日記（2）

口水記

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

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