1

時隔一年後，相同的坑進去兩次，悲慘！

究其原因，還是一樣的。各種分支程式碼的維護，導致一套架構在各個專案上千瘡百孔，架構已從A迭代到W了，但還是拿著A在重構，不出問題才怪，說到底，還是管理的問題。

討論架構設計有問題時，有個程式猿說了個很奇怪的言論，“老闆難道不知道架構這麼多問題嗎？如果搞一套完美的架構，那測試等其他附屬的部門是不是要下崗了？架構差一點，就業機會是不是就多了一點？”

什麼？‘資本家’這麼善良了？為了創造就業崗位，自己犧牲每個月幾百萬的流水？

這理由很難站住腳！也不過是能力差的說辭。如果啊，真的這麼牛X的架構，砍掉其他附屬部門完全可以，一套程式碼坐收漁翁之利，但那只是夢！現實是，一個架構引出N多分枝，然後分枝再分枝，修修補補，多到枝繁葉茂，卻結不出果實。

“祝願你們的程式碼少一些bug，多一些摯愛的使用者。”

2

如何做測試，從而保證可以開發出可靠的、值得信賴的產品，一直是值得不斷思考的問題。

有段時間奉行“少則清晰”，於是在測試用例及流程上進行刪減，關注使用者痛點，解決痛點，好處是確實能從大方向上把握，讓一個產品趨於能用的狀態，不足的地方就是，細節無法都關注到。導致有的BUG就在那等著你，然後默默的噁心下你。

所以，基礎的東西還是不能丟，因為你沒有一個支撐你丟的架構，也不應該丟，因為那是根本。學再多高大上的玩意，基礎丟了，確實會出大錯。

在《Google軟體測試之道》中有這麼一句話：質量不是被測試出來的。

但其具有兩層涵義：

質量不等於測試，當你把開發過程和測試放到一起，就像在攪拌機裡混合攪拌那樣，直到不能區分彼此的時候，你就得到了質量。

如果某個產品出了問題，第一個跳出來的肯定是導致這個問題發生的開發人員，而不是遺漏這個bug的測試人員。

一個產品團隊不能任意降低測試人員招聘的技術要求，從而僱傭更多的測試人員，然後再讓他們做一些簡單和瑣碎的髒活累活。這些功能相關的髒活累活本應是開發人員的工作，不能簡單地扔給倒黴的測試人員。其實反過來，一個團隊也不能招聘一個和團隊技術要求不符的人員，如果一個水平一般的開發，在不瞭解業務的情況下，就開始快馬加鞭的寫bug，那受累的是整個團隊，而不是某一個人。

3

國家應該好好的治理下中介行業，這個利用資訊差，可以隨意賺取服務費的行業，真正實際的社會產出是什麼？存在是有多少能真正幫助到該幫助的人？更多的是電話、資訊騷擾，有個APP，你註冊完以後瀏覽，不出3分鐘就能收到電話，問您是否找房看房買房，精準服務，可能開發這個產品的專案經理覺得，你不看房買房，瀏覽它幹嘛？既然瀏覽了就應該有需求，有需求就有必要賺點服務費，這樣的設計確實精準，但是很討人嫌。這妥妥讓人意識到，這玩意不能開啟，否則像被人監視了一樣（雖然實際也是），大資料也意識到，打開了，那一定是有了賺錢機會，來，張經理負責電話跟進一下。

4

很多人在遇到別人做不好，或者做錯事時，總會忍不住想要去指導或者評價一下。這個行為其實是在告訴對方，不太允許你。

如果可以的話，無論對方做什麼事情（前提是沒有踩到你的底線，或者涉及到對方的生命危險，人生規劃等等），你儘量允許對方去做，允許讓他犯錯。不要去給對方任何的建議。即使你知道他的行為馬上就會犯錯，你也不要給他任何提醒。只管讓他去做。

這個是為了給對方建立一個被允許的環境，在這個環境中，對方可以無壓力地進行自我檢驗和修復。