就像程式都有500個錯誤了，還改啥改啊，別改了，一樣的道理，怎麼能這麼頑固？必須1個錯誤都不能有，才是正確的硬道理。
改變開發人員的思維很難、固執的多、自以為是的多、老頑固的多、聽不進勸告的多，我們今天封建了嗎？
最近給幾個開發人員檢查程式，進行技術溝通交流：
1：建議做軟體先有設計，後有施工的思路，雖然軟體都已經做好了，但是設計圖紙還是有必要補充的，表結構等，應該整理出來，修改哪個模組就應該把哪個模組的表結構都整理好，方便今後的維護工作，人員之間的交流。
乙個管理軟體，若乙個像樣的資料庫設計文件都沒有？這不是成了軟體作坊了？以後還怎麼上層次、怎麼提高呢？
曾經有個比較有水平的朋友跟我講：「別人做的軟體是否設計合理、功能是否正確，有經驗的人看看資料庫設計文件就能感覺到很多」。
再說了將來我們的軟體行業也會走設計、施工分離的發展路線，做軟體前總需要有設計圖紙的吧？就是軟體做好了，也應該把設計圖紙補充好吧？
大家駁倒：工作量大、意義不大、現在有更緊急需要處理的事情，好幾個人都這麼認為，我不好意思暴力做決定必須要把資料庫設計文件補充好。
2：現在都是2023年了，都vs2010 ado.net entity 技術都出來了，老程式還是 拼接sql的， " + this.txtname.value + "，物件導向都有10年了，總需要把老的程式改進為物件導向的吧？別都面向過程的，將來維護起來不上檔次。
大家駁倒：程式現在用得好好的，這麼修改了，客戶用起來也沒啥變化，而且可能會帶來工作量，還可能會引起程式的不穩定，哇靠暈倒啊這不是明顯拒絕提高嗎？別人想給你提高一下努力往前拉動，你倒是想盡一切方法阻止進步啊？兄弟真夠倔強啊，我服了。
3：程式裡有一大堆沒必要的方法、命名紊亂的方法、功能重疊的方法、寫錯位置的方法，這些很多沒必要寫或者根本不需要寫那麼多**，呼叫一下基礎類裡的先有方法就可以了，修改到**，仔細修正一下不就可以了，按專業術語來講就是需要不斷重構完善的？
大家駁倒：程式現在很穩定，這麼修改了，會引起程式的執行不穩定，我們冒不了這個風險，我服了、那乾脆啥也別動了。
4：程式裡層劃分太多了，寫**寫太多了，有接近7-8個層，什麼設計模式、開閉原則、反射把時髦的技術都用上了，導致寫乙個方法，需要到處去修改，重新命名一方法也要修改很多環節，搞那麼多層幹啥？有必要嗎？何必跟自己過不去呢？等以後有需要時，再把這些層加上去也可以了，我說只需要3層就足夠了，見效快、修改程式簡單、維護起來也方便，搞那麼多技術玩自己幹啥呀？
領域模型層 + 商業邏輯層 + 頁面層， 就這麼3個層就足夠了，搞那麼多飛機幹啥？
大家駁倒：若用mysql資料庫，每個客戶端還要引用mysql的dll，將來的維護量大？，我服了mysql才272k，更何況公司的產品從來沒用過mysql，我們有必要天天擔心太陽會掉下來，有必要嗎？
5：建議大家用**生成器，不要總是手寫，太累又不規範，太小農了，生產量不夠，現在都啥年代了，機械化批量生產了？
大家駁倒：乙個表才幾個字段，手寫一下也很快，沒必要用**生成器，哇靠牛b啊，居然手寫比**生成器還強？那麼多人寫的如何規範化？**是否還要檢查質量？若100個字段，那不是要寫死人啊？人來人走的，為什麼不接納一下**生成器？大家都比我年輕至少5歲以上，為什麼還這麼老頑固？是我太老頑固了嗎？
就這樣5個比較好的提議，都當是放屁了，都被大家駁倒槍斃了，想難道這5個建議就這麼差勁了？大家為什麼就聽不進去呢？是誰固執呢？程式設計師朋友們固執呢？還是我沒能把道理講清楚？還是說話的語氣不對？組織的方式不對？為什麼就沒能讓大家接納呢？
有時候想想，我們中國人為什麼總是那麼封建？就是因為我們大家封建，思想不開放，才導致我們大家封建，現在都啥年代了，這前5項估計都是做管理軟體最最基本的技能了，大家才25歲左右，就這麼頑固，那到30歲了，不是更頑固了？可能是我太人才啦，太另類了，哈哈
我們就不提老美的創新，接收新思想，還都這麼艱難啊？不用總用自己的理解能力、自己的思維對待新鮮思想，新鮮做法，若你有那麼高的智商，早就考入清華北大了，不會在這裡天天寫管理類軟體了，多聽聽別人的，多聽聽比你經驗更豐富的，能力更強的人的建議，你走過的路人家大多都做過來了，你還沒做過的路，人家也都可能走過了，多聽聽別人的說法，多吸納一下別人的優點，改進一下自己的缺點，別總自以為事，別人也不是豬，別總搶著說自己的，不成熟的思想說出來就是丟人，先聽別人的，然後再結合自己的，若有必要再提出更好的思路，你就是不提出思想，別人也會把你當成是豬。
若不是為了維護公司的安定團結、同事之間的和睦相處，真有做決鬥的念頭都會產生，怎麼這麼固執啊？是我跟不上同事們的思路了？還是同事們跟不上我的步伐了？一下班全跑了，什麼時間來不及？忙不過來，全當是放屁了，產品開發部只剩下3個人寫繼續寫**什麼的，其中我乙個在整理文章。
也有人說，你怎麼老是這些重複的理念？觀點已經重複很多次了？
我回答：乙個人能把乙個理念堅持到低，能徹底做好，就足夠了，畢竟我們是十多億人，若每個人能把一件事情乙個理念做好了，我們很快可以超越美國了，哈哈。
程式設計師的思維方式
讀書不覺已春深，一寸光陰一寸金。不覺間實習已近四周，我想起這首詩，並非標榜自己學習，工作有多投入，而是感慨時間靜悄悄得溜過，只有當你回首時，才能覺察到它的存在且已過去。這幾周的工作主要都是修改公司專案的bug，通過修改bug，我思考了下網際網路人工作對自身思維的影響，這裡只粗 談產品經理，測試人員和...
男程式設計師思維VS女程式設計師思維
今天下午參加了乙個技術分享，產生了一些想法。本文沒有什麼理論性，也沒有什麼科學性，單純主觀感受。如果您讀後有所收穫，那就再好不過啦。先說事情的流程 知識點就不涉及了，主要講講大boss問的問題帶給我的思考。問題 1 2 請參考上圖 1 問題 為什麼不能直接通訊，而是經過 解決 這就能牽扯出 這一部分...
也談程式設計師
對於從事程式開發的人員來說，今後的前景問題了，應該算的上自身最關心的乙個問題了。最近也開始比較有空了，看了些文章，本來是想學點jbpm的，可是始終沒認真看完。道是對自己的前程開始有些擔心。大學畢業的時候，就聽說乙個問題，做程式開發員人，一般都超不過30的。30後再做開發，估計就比較難了。一想在想這是...