警惕技术人员的极端性
生活随笔
收集整理的這篇文章主要介紹了
警惕技术人员的极端性
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
警惕技術人員的極端性
以前一直在研究技術，沒日沒夜的學習，后來發現：把技術玩的轉，那不算什么大的本事，把人玩的轉，才是本事。看到多，接觸的多，思考的多了，感觸也自然多了。 很多的技術朋友，在沒有搞技術之前，思維是很正常的，一旦踏入技術圈子之后，就好像失去了自我。這里說這些，沒有啥意思，只是希望審視自己，看有沒有這樣的情況，因為自己也是花了很長的時間才慢慢的明白這個道理。
每次只要一談技術，一談什么問題，一提到什么解決方案，很多人喜歡反問一句“有沒有最好的方法”，“有沒有最快的方案”，“有沒有最….”。似乎很多的人都喜歡“最”這個字眼，或許至于人類本身追求完美的天性有關，或者是被教育制度的戕害（因為凡事都有標答，或者所謂的最佳答案），或者已經習慣了說出“最”字。 很多的事情，往往沒有所謂的“最”的。此時的最好，可能隨著時間的變化，或者環境的改變就慢慢的開始退化，成為“次好”，“一般”，甚至“差”。
11270_200706140145041.jpg(34.12 K)
9/13/2012 7:38:44 PM
發現這樣一個問題：每次想問一些包含“最”問題的時候，說明我們考慮事情就不夠充分，比較的片面。是的，從單方面，單個因素來看，某個東西確實是最好的，但是把其他的因素一考慮進來，事件就開始變得復雜，很多的人就開始變得躁狂，因為他們心中的“最”已經沒有了。其實這才是事情的真相：每個事情，都是有多個因素同時在影響，只是我們要現決定先考慮那個，或者如何權衡她們。
記得之前在一個項目中，時間比較早了，那時候，Linq語言和Linq2SQL剛剛出來。公司的技術愛好者一看：不得了了，有神器出來了，再也不用寫一大堆的ADO.NET代碼。現在只要一拖，全部搞定。完美了。 確實，漂亮的可視化界面，簡單的拖拽，鏈式的代碼編寫方式，確實把技術人員解救出來了，一時間，全國上面Linq一片。但是，不久問題就出來了。后來發現Linq2SQL在更新數據的時候，有點小bug，因為總是報出“對象已經存在了”這樣的錯誤，一時間，N多人傻了眼，于是千辛萬苦在官方網站找到了解決的方法。
后來更多的人傻眼了：平時總是用所謂的三層結構開發的項目，現在有了Linq2SQL，他們不知道如何三層了：以前業務層，數據訪問層，等等，搞的很清楚，現在倒好，Linq2SQL一拖，很多的實體類就生成好了，以前總是用ADO.NET一個個數據庫字段賦值到業務類的字段中，現在這過程省了，很多人就直接用Linq2SQL生成的類作為業務類，很多人開始有點難受了：貌似只有兩層了。
更糟的還在后面：每次只要數據庫中的表和字段一改動，那么就要再去把表拖一次，而且一改動，其他的人必須要重新獲取代碼管理器中的代碼，如果一個人出問題，其他的人都停在那里等著了。很多意想不到的問題一個個的出來把大家折騰的暈頭轉向，開發效率非常的低。其實這就是技術人員常常犯的一個問題：思考問題的片面性。
確實，好的東西出來，我們第一眼看到的就是它的好處，但是任何事物都是一個平衡體，帶來同等的好處，那么必然隱藏同等壞處。就好像買車，可能我們已經厭煩了每天上班擠公交，平時認為花費太多的時間在路上，于是希望有輛車就好了，于是就開始想到各種各樣買車的好處。但是把車買了之后，發現，油價是個問題，過路費是個問題，車位和停車費是個問題，車子的保養是個問題，還有這這那那名目眾多的費用等。這個道理，在日常生活中，大家都懂，但是一到技術上面，就完全變了樣，各種極端，偏執狂就出來。 201208240929248685.jpg(25.16 K)
9/13/2012 7:38:44 PM
很多人喜歡在項目中嘗試新的技術，我這里也不反對，但是，在使用的同時，有沒有考慮它的其他方面，如萬一出錯，是否有齊全的文檔或者即使的官方說明。新東西的研究和學習的時間成本如何，在開發過程中對項目帶來的好處是什么，帶來的好處是否可以平衡它帶來的不足；不同的人對這些東西的掌握是不是都在預期之中，還是說，只有少部分人掌握，其余的跟著混；這個東西在整個團隊層面上面的影響如何…..
大家可能要說：你談的這些有點偏管理了。
那么，這里就要問了：為什么硬是把技術和管理劃分的那么明顯，非得搞出一個三八線處理？！
平時我們在無形中也是在進行個人的管理，個人的規劃。管理，是讓事情盡可能的朝著目標方面走而已，把一些事情規劃的清楚有條理。好好管理自己
，也是讓自己朝著所謂的理想靠近，不至于讓自己糊里糊涂的生活。
所以，不要認為搞技術的就不要懂管理，不要談到“管理”就色變。其實不談所謂的管理不管理，其實就是要大家看問題全面，思考問題要周全一些。我們平時再買個東西的時候
都要貨比三家，左思右想，先觀望，然后下手，為什么一到技術上面，就不比較呢？！
很多的朋友們總是問，如何成為架構師，如何成為牛人。方法千千萬，但是有一點可以確認的就是：思維肯定是要開闊的。特別在做設計或者架構的時候，考慮的問題不僅僅只是技術層面，項目的利益人，投資人，時間，錢，溝通成本，軟硬件條件，甚至公司的發展和業務走向都是需要考慮的。所以，可能我們平時說“我會做架構”，其實很多的時候，僅僅只是拘泥于技術上面而已，甚至說只是拘泥于片面的技術，如：有朋友以為懂得一些模式，懂得分層，就是會做架構了。其實這里架構很遠很遠。以前我也不懂，后來發現：學的越多，發現自己懂的越少。
所以，用平常的觀點去分析和看待技術，切忌極端。一旦物極必反，自己就陷入泥沼。例如，常常看到社區中有很多的激烈的罵戰，如java好，還是.NET好；再如，是sql server好，還是oracle好。這些討論，其實意義不大，除了把自己搞的郁悶，搞的不爽之外，還有啥。
20090327203708103.gif(15.24 K)
9/13/2012 7:38:44 PM
就算罵贏了，又怎么樣？！人家還是在用java，還有有人用.NET。
其實，說一個東西不好，可以給出千千萬萬的理由，同樣，說一個東西好，也可以給出千千萬萬的理由。 [wallcoo_com]_TREES_0EA49086.jpg(189.52 K)
9/13/2012 7:38:44 PM
一棵樹的成長必定是吸收各種光譜，才能健康成長，同理，一個人只有全面的思考問題，才能把問題看得透徹！ ? ?著作權歸作者所有：來自51CTO博客作者yanyangtian的原創作品，謝絕轉載，否則將追究法律責任 職業規劃 AgileSharp 技術人生 程序人生
以前一直在研究技術，沒日沒夜的學習，后來發現：把技術玩的轉，那不算什么大的本事，把人玩的轉，才是本事。看到多，接觸的多，思考的多了，感觸也自然多了。 很多的技術朋友，在沒有搞技術之前，思維是很正常的，一旦踏入技術圈子之后，就好像失去了自我。這里說這些，沒有啥意思，只是希望審視自己，看有沒有這樣的情況，因為自己也是花了很長的時間才慢慢的明白這個道理。
每次只要一談技術，一談什么問題，一提到什么解決方案，很多人喜歡反問一句“有沒有最好的方法”，“有沒有最快的方案”，“有沒有最….”。似乎很多的人都喜歡“最”這個字眼，或許至于人類本身追求完美的天性有關，或者是被教育制度的戕害（因為凡事都有標答，或者所謂的最佳答案），或者已經習慣了說出“最”字。 很多的事情，往往沒有所謂的“最”的。此時的最好，可能隨著時間的變化，或者環境的改變就慢慢的開始退化，成為“次好”，“一般”，甚至“差”。
11270_200706140145041.jpg(34.12 K)
9/13/2012 7:38:44 PM
發現這樣一個問題：每次想問一些包含“最”問題的時候，說明我們考慮事情就不夠充分，比較的片面。是的，從單方面，單個因素來看，某個東西確實是最好的，但是把其他的因素一考慮進來，事件就開始變得復雜，很多的人就開始變得躁狂，因為他們心中的“最”已經沒有了。其實這才是事情的真相：每個事情，都是有多個因素同時在影響，只是我們要現決定先考慮那個，或者如何權衡她們。
記得之前在一個項目中，時間比較早了，那時候，Linq語言和Linq2SQL剛剛出來。公司的技術愛好者一看：不得了了，有神器出來了，再也不用寫一大堆的ADO.NET代碼。現在只要一拖，全部搞定。完美了。 確實，漂亮的可視化界面，簡單的拖拽，鏈式的代碼編寫方式，確實把技術人員解救出來了，一時間，全國上面Linq一片。但是，不久問題就出來了。后來發現Linq2SQL在更新數據的時候，有點小bug，因為總是報出“對象已經存在了”這樣的錯誤，一時間，N多人傻了眼，于是千辛萬苦在官方網站找到了解決的方法。
后來更多的人傻眼了：平時總是用所謂的三層結構開發的項目，現在有了Linq2SQL，他們不知道如何三層了：以前業務層，數據訪問層，等等，搞的很清楚，現在倒好，Linq2SQL一拖，很多的實體類就生成好了，以前總是用ADO.NET一個個數據庫字段賦值到業務類的字段中，現在這過程省了，很多人就直接用Linq2SQL生成的類作為業務類，很多人開始有點難受了：貌似只有兩層了。
更糟的還在后面：每次只要數據庫中的表和字段一改動，那么就要再去把表拖一次，而且一改動，其他的人必須要重新獲取代碼管理器中的代碼，如果一個人出問題，其他的人都停在那里等著了。很多意想不到的問題一個個的出來把大家折騰的暈頭轉向，開發效率非常的低。其實這就是技術人員常常犯的一個問題：思考問題的片面性。
確實，好的東西出來，我們第一眼看到的就是它的好處，但是任何事物都是一個平衡體，帶來同等的好處，那么必然隱藏同等壞處。就好像買車，可能我們已經厭煩了每天上班擠公交，平時認為花費太多的時間在路上，于是希望有輛車就好了，于是就開始想到各種各樣買車的好處。但是把車買了之后，發現，油價是個問題，過路費是個問題，車位和停車費是個問題，車子的保養是個問題，還有這這那那名目眾多的費用等。這個道理，在日常生活中，大家都懂，但是一到技術上面，就完全變了樣，各種極端，偏執狂就出來。 201208240929248685.jpg(25.16 K)
9/13/2012 7:38:44 PM
很多人喜歡在項目中嘗試新的技術，我這里也不反對，但是，在使用的同時，有沒有考慮它的其他方面，如萬一出錯，是否有齊全的文檔或者即使的官方說明。新東西的研究和學習的時間成本如何，在開發過程中對項目帶來的好處是什么，帶來的好處是否可以平衡它帶來的不足；不同的人對這些東西的掌握是不是都在預期之中，還是說，只有少部分人掌握，其余的跟著混；這個東西在整個團隊層面上面的影響如何…..
大家可能要說：你談的這些有點偏管理了。
那么，這里就要問了：為什么硬是把技術和管理劃分的那么明顯，非得搞出一個三八線處理？！
平時我們在無形中也是在進行個人的管理，個人的規劃。管理，是讓事情盡可能的朝著目標方面走而已，把一些事情規劃的清楚有條理。好好管理自己
，也是讓自己朝著所謂的理想靠近，不至于讓自己糊里糊涂的生活。
所以，不要認為搞技術的就不要懂管理，不要談到“管理”就色變。其實不談所謂的管理不管理，其實就是要大家看問題全面，思考問題要周全一些。我們平時再買個東西的時候
都要貨比三家，左思右想，先觀望，然后下手，為什么一到技術上面，就不比較呢？！
很多的朋友們總是問，如何成為架構師，如何成為牛人。方法千千萬，但是有一點可以確認的就是：思維肯定是要開闊的。特別在做設計或者架構的時候，考慮的問題不僅僅只是技術層面，項目的利益人，投資人，時間，錢，溝通成本，軟硬件條件，甚至公司的發展和業務走向都是需要考慮的。所以，可能我們平時說“我會做架構”，其實很多的時候，僅僅只是拘泥于技術上面而已，甚至說只是拘泥于片面的技術，如：有朋友以為懂得一些模式，懂得分層，就是會做架構了。其實這里架構很遠很遠。以前我也不懂，后來發現：學的越多，發現自己懂的越少。
所以，用平常的觀點去分析和看待技術，切忌極端。一旦物極必反，自己就陷入泥沼。例如，常常看到社區中有很多的激烈的罵戰，如java好，還是.NET好；再如，是sql server好，還是oracle好。這些討論，其實意義不大，除了把自己搞的郁悶，搞的不爽之外，還有啥。
20090327203708103.gif(15.24 K)
9/13/2012 7:38:44 PM
就算罵贏了，又怎么樣？！人家還是在用java，還有有人用.NET。
其實，說一個東西不好，可以給出千千萬萬的理由，同樣，說一個東西好，也可以給出千千萬萬的理由。 [wallcoo_com]_TREES_0EA49086.jpg(189.52 K)
9/13/2012 7:38:44 PM
一棵樹的成長必定是吸收各種光譜，才能健康成長，同理，一個人只有全面的思考問題，才能把問題看得透徹！ ? ?著作權歸作者所有：來自51CTO博客作者yanyangtian的原創作品，謝絕轉載，否則將追究法律責任 職業規劃 AgileSharp 技術人生 程序人生
20
微博 QQ 微信收藏
上一篇：如何快速的提高自己：一切取決于你... 下一篇：談談SQL Server高可用的... yanyangtian99篇文章，106W+人氣，13粉絲
關注Ctrl+Enter?發布
發布
取消
16條評論
按時間倒序 按時間正序推薦專欄
最近更新 網工2.0晉級攻略 ——零基礎入門Python/Ansible網絡工程師2.0進階指南
共30章?|?姜汁啤酒
￥51.00 1155人訂閱
訂???閱 CTO成長的道與術IT人的互聯網名企晉升之道
共28章?|?CTO訓練營
￥51.00 184人訂閱
訂???閱猜你喜歡
我的友情鏈接 這個時代會殘酷懲罰不肯改變的人 Raid磁盤陣列數系列問題答疑 全是干貨：MBR分區結構以及GPT分區結構 北京某公司IBM X3650M3存儲崩潰的解決過程 6個平凡人的經歷，參悟工程師的成功秘密 百億互金平臺救火故事 六年程序生涯掃一掃,領取大禮包
20
0
16 分享 關注 yanyangtian總結
以上是生活随笔為你收集整理的警惕技术人员的极端性的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： APPSERV下安装pear db和au
- 下一篇： 摘抄 web 经 关于 自适应网页设计（