程序員的創造力

㈠ 軟體工程十分需要創造性么

如果你打算自己創業有自己的品牌，產品當然少不了創造性。一般的程序員只是熟能生巧而已。

㈡ 程序員的必備技能有哪些

數組、字元串與哈希表
任何受過專業訓練的程序員，對「數據結構」這門課程中涉及到的各種數據結構都不會陌生，但是在實際的編程工作中，大部分的數據結構都不會用到，而且也永遠都不會用到。雖然如此，深入地理解基本數據結構的概念和實現細節，仍然是每個程序員的任務。這不僅僅是因為，掌握這些知識將有利於更加正確和靈活地應用它們，而且也是因為，對於語言背後的實現細節的求知慾是一個優秀程序員的素質。
正則表達式
在程序員日常工作中，數據處理占據了相當的比重。而所有的數據之中文本又占據了相當的比重。文本能夠被人理解、具有良好的透明性，利於系統開發、測試和維護等就必需要有一定規律遵循一種規則，當你掌握一門正則表達式語言，就能夠培養你編程的直覺本能，達到較高水平，也能夠在實踐中提供更高的開發和執行效率。
調試
軟體調試是軟體工程的一個重要部分，其過程出現在軟體工程的各個階段，從最初的可行性分析、原型驗證、到開發和測試階段、再到發布後的維護與支持，都有軟體調試過程參與。學習和靈活運用軟體調試技術，不僅可以提高程序員工作效率，而且有利於對代碼的感知力和控制力，加深對軟體和系統的理解。此外，調試技術是解決各種軟體難題的一種有效武器，它直擊要害、銳不可擋，相對其它間接方法具有明顯的優勢。軟體有大美，調試見真功!
兩門語言
任何一位職業化的軟體技術人員都會將編程語言當成自己的利器。它們代表了開發人員對計算機本身的理解與對軟體開發工作的執著。同時，建立在編程語言之上的基礎也標志著程序員的職業化道路發展到了一個新的階段，而單一語言又有一定的局限性，軟體開發的本質就是處理信息以及數據。一種專門用來處理數據的腳本語言常常是走向更加職業化的必備武器之一。所以精通兩種語言，對於任何一個開發人員來說，並非必須，但是對於一個專業化程度較高的開發人員來說，又常常是必要的。
一個開發環境
隨著技術的進步，IDE已經越來越強大，遠遠超出我們心目中的最初形象，越來越多的內容被涵蓋到IDE中，從需求分析、業務建摸大批軟體發布，IDE已經逐漸覆蓋了軟體開發的整個生命周期。
SQL語言
說起SQL，絕大多數程序員對其作用都瞭然於胸--用來訪問資料庫嘛。確實，數據是信息系統的核心，沒有數據的計算機應用沒有任何意義。信息系統中，大量數據本質上就以實體--關系的模式存在，而RDBMS支持SQL這么簡單但表達能力豐富的訪問介面，同時還提供了內建的事務ACID特性保證和故障恢復能力--因此，RDBMS理所當然地成為了大部分信息系統的標准數據存儲介質。於是，無論使用何種語言開發信息系統，從C、C++，Delphi到Java,從Perl、Python到Ruby，使用SQL訪問RDBMS都是我們必須修煉的武功秘籍。
編寫軟體的思想
說起程序員的武器自然少不了技術書籍，它們就像是拳譜、劍經、雖然不能馬上轉化為巨大的傷害輸出，但假以時日勤以研讀，有朝一日成為傍身絕學也是說不定。不過雖然各類技術書籍汗牛充棟，除去入門時淺顯易用的參考和復雜深奧的學術專著，能夠讓所有程序員常看常新的心法秘籍還是不多。

㈢ 編程需要創造力想像力嗎

做獨立開發者的話很需要，一般程序員只需要把上面交代的任務完成就行了

㈣ 程序員如何才能有獨立開發項目能力

難！我本身是軟體工程師，我從業都十多年了，就拿網站來說吧，比如你獨立開發一套PHP或者是Java的網站，通常，美工+WEB前端+後端開發+需求分析，設計的能力，相當於，你一個人，頂一個團隊的工作量，連項目經理都兼任，維護客戶都兼任！因為你得分析需求啊。
如果Java更難了，相當於美工（1人）+WEB前端（1人）+後端開發（3-7個），如果是APP的，還得加安卓+IOS工程師+項目經理。
如果是C++，巨難，雖然我也可以獨立開發。問題是，太耗費精力了。特別是嵌入式，其實C語言都有幾種，Java也有幾種，其他人，半桶水，不專業的。
最終，你要給客戶看到的效果！如果你美工 不行，後端不得，只要有一個嚴重的短板，你就不勝任真實的項目獨立開發的能力，自娛自樂可以。
寫驅動，談何容易，全世界，不超過1000人會寫底層的驅動。
第二個，我看到你說，做嵌入式的是學c++還是java ,我java比c++好一些，說明，你基礎不行，雖然是科班出生，科班難出人才，除非自學成才的天才例外！如果天才，你這個年紀的，或者大一點的，都能獨立開發了。特別是美工，需要天賦的！編程也是。需要悟性的，才有創造力，如果死讀書的書獃子，沒什麼創造力的。少數例外。

㈤ 程序員需要一個創意的頭腦嗎

可以別人創意你編程

㈥ 程序員有哪些常見的惡習

• 聰明但是給人的感覺是不謙遜。

• 交流與合作能力比較強，但是又往往嚮往個人主義。回

• 懶惰（體力勞動），大部答分程序員可能都是這樣，也許是因為程序員已經習慣了腦力勞動！

• 創造力非常強，但是好像又缺乏紀律性！

• 學習能力非常強，但是又往往太過於依賴個人經驗。

• 程序員肚子局部胖的比較快。

• 愛電腦勝過自己愛人。

• 作為思考者的程序員，不喜歡熱鬧得商場，比較喜歡同一兩個朋友呆在一起玩電腦的感覺！

• 抽煙。在我接觸過的同事中，相對於其它部門而言，技術部的程序員抽煙的比例比較高！

• 十二點之前基本不休息。

㈦ 選擇程序員的十大理由

上得了廳堂，下得了廚房，寫得了代碼，查得出異常，殺得了木馬，翻地了圍牆，開得起好車，買的起好房，抓得緊女郎。不做還作甚？

㈧ 在大家眼中，程序員是一個怎樣的職業

程序員首先是雇員、然後是工程師；比起創造力，工程能力對這個職位更為重要

為什麼有人在技術造神

大家應該已經感受到，技術圈這兩年已經和娛樂圈創業圈差不多的氛圍了，這其實是有原因的。

最主要的原因是，創業公司和創業媒體越來越多，他們需要大量的程序員投身到創業這個高風險的行業中，而造神，正是讓程序員們自動跳進火坑的絕佳辦法。不是說程序員不能創業，我是說，創業媒體們故意模糊了創造和創業的界限，把程序員們的創造沖動偷換概念，鼓吹了太多不適合的人去創業。

另一個原因是，招聘成本高漲，CTO 們為了能提升影響力，不得不頻頻出席各種大會刷臉。文筆好的再做做自媒體和技術社群，既能強化個人品牌提高身價，又能在融資的時候提升成功率。

總之，這個行業出現了各種技術大神。

這些大神在普通人類和初級程序員眼裡是無所不能的，是他們嚮往的目標；在中級程序員和高級程序員眼裡，這些大神就是他自己，只不過他還沒紅起來而已…

於是攀比心理也開始泛濫，全國第三的架構師比比皆是，整個圈子漸漸就浮躁起來。

然而絕大部分程序員，依然是雇員

媒體們在包裝時，最喜歡按獨立開發者的路線來整。「從小就對技術有天分」、「大學時曾在某編程大賽一鳴驚人」、「寫了個 APP 玩結果一個月有了千萬用戶」、「從公司離職自立門戶三年上市」。

OK，這的確是程序員的一條職業路線圖。但是媒體們不願意告訴你的是，一：只有極少數程序員是通過這個路線成功的；二：這條線其實需要太多非程序員職位的技能，比如產品設計能力和銷售能力。

程序員的價值決定

絕大部分互聯網公司的程序員職位，沒有技術門檻

然而不幸的是，絕大部分互聯網公司都不是技術驅動的公司。真的就是鳥哥說的那樣，絕大部分技術崗位，其實技術門檻都不高（門檻在工程上，後文細講）。技術不過是這些公司的護航艦，而不是破冰船。

先別打我，冷靜下來想想，到底有多少你會的那些技術，是你的同行們不會的呢？不多，對吧？

幾年前億級別的搜索還是問題，現在已經到處是通用解決方案了；幾年前千萬到億級別的網站和 APP 解決方案還在大公司手裡，現在各個架構大會都講爛啦，而且其實都差不多；就連 DeepLearning，帶 API 介面的框架也開始涌現，只需要把圖片用 REST 傳進去就能取到結果了。

很多事情，已經沒有難度，只需要持續投入。是的，對絕大部分程序員來講，他們不需要成為科學家，而需要成為工程師，成為從科學家手裡接過火種，去燎原大地的人。

怎樣才是一個好工程師

工程的本質不是創造，而是去風險化。

工程是關於如何低成本、高效率、按時按量完成既定任務的。所以判斷一個工程師是否優秀，並不是他多有創意多有名氣，而是看他有多穩，看他能多 GettingThingsDone，中文就是「靠譜」。

有時候一個好的解決方案，未必採用了最新的技術和框架，而是看上去朴實無華，功力都包涵在背後的細節里。就像頂尖高手打的斯洛克檯球，每一桿都平淡無奇，只是因為上一桿的回球太到位。

有同學問，那我工程做的太好，豈不是沒有機會遇到一些高難度挑戰了么？放心，一般公司都僱傭了產品經理來幫你製造高危事件。

同樣的，一個好的工程師，會選擇最適合需求和團隊的方案，考慮開發效率和系統效率的均衡，從而已達到最優效果；而不是整天和別人去爭論什麼語言最好、哪些框架過時了。

工程的另一個要求是進度控制和質量控制。

在項目立項之後動工之前，對要做的事項作出詳盡的規劃，對未來一到兩周的工作給出細致的排期，這是進度控制的基礎。

代碼的及時入庫與合並，自動化測試和每日構建，CodeReview 和文檔編寫，這些看似無關緊要的習慣則決定了項目質量。

不幸的是，很多程序員把這些工程上至關重要的東西當成垃圾，視為對他們「創造力」的壓抑。

他們總是以創造力為借口去尋求自身的自在，比如上班不帶胸牌不打卡，中午休息時間在公司看視頻打游戲，最好可以遠程上班，項目到期之前再來檢查進度，公司不要用統一框架，只有傻逼才寫文檔。

對職業的理解偏差和工程能力上的荒蕪，培養了大批能寫代碼但死活寫不好代碼的「碼農」，反而讓那些有著彪悍工程能力和良好習慣的程序員變得奇貨可居。

最後，來說說程序員那無處安放的創造力

有了錘子想找釘子是很正常的原始沖動，但我們必須認識到，創造力對於程序員這個職業來講，是錦上添花的東西。如果你沒有強大的工程能力，那麼創造力也不過是無本之木。所以扎扎實實的把工程基礎打好，這是最根本的。

在此基礎上，我比較推薦程序員採用內外兩條線來培養自己。在公司內的項目上採取相對保守的策略，盡力把穩定性做到最好，培養出自己卓越的工程能力；然後在公司外的開源項目和自己的獨立項目上，採用一些新的技術、實踐一些新的想法、充分發揮自己的創造力，夢想還是要有的，對吧。

這樣做最明顯的好處是，你可以了解到新技術和激進方案的優缺點，從而在進行方案選型時，有更多的依據；還有一個職業發展上的好處：如果不是主負責人，公司的項目往往不能代表你的能力；但獨立項目卻可以作為一個非常好的能力證明出現在你的簡歷里邊。

你可以是一個身懷絕技的手藝人，在自己家裡你嘗試各種手法各種風格的個人作品；但當你參與頤和園這種級別的工程時，好好的把自己負責的石頭雕成總設計師要求的樣子就好 —— 畢竟這個時代一個人已經很難負責整個項目了。這就是我所理解的程序員的工匠精神。

㈨ 如何成為有思想、創新的程序員

寫這篇文章也源於我和新員工的一些談話心得，一些基礎比較薄弱的技術人員，看起來有點像沒有思想和靈魂的程序員。你可能也會覺得國內有很多小企業出來的人或者剛畢業的人，會的最多也是CRUD和拖拉控制項。我也接觸過一些技術人員，他們告訴我他們再也不想搞技術了，因為技術是在太無聊了，特別年紀稍大一點的，想的最多的就是轉行。曾經我非常驚訝於這樣的狀況，事實上，寫程序是一件很有創造力的事情，但為何很多人都會覺得無聊呢。 隨著年紀的增長，這些問題的答案慢慢變得清晰一些。在這里，我不敢說，我說的都是正確的，我只是在一直不停的探索。在探索之後，我對我的新員工說了以下的話：「進入我們公司，雖然我們也是很不起眼的剛創業的小公司，但是，你在這里需要做一些改變了。我知道你們以前的工作性質可能是上司給你交代任務，告訴你怎麼做，然後你管也不管就照章辦事，拉拉控制項，以完成項目功能為首要任務。在我們這里，你需要成為一個有思想的程序員。有思想的程序員需要懂得如何使用聰明的腦袋瓜。事實上，很多人都不知道我們的腦袋瓜到底能做多少事情，不過，一旦你嘗試了，你就會體會到『不是做不到，而是想不到』。需要記住這些話，從思想上改變，從今天開始。首先，我們是做軟體產品的公司，質量是產品生存的首要標准，產品質量的最低要求就是易用性；其次，我們要保證產品的質量，代碼的質量首先要過關，標准編碼方式、異常處理方式、代碼的生命周期管理、編碼的完整性都需要兼顧；第三，避免寫一些垃圾代碼和重復的代碼，這需要動用你聰明的腦袋，我曾經寫了10幾個的CRUD產品，從而自主創新了控制項關系映射、對象-對象映射、通用窗體框架，乃至我們現在的OSGi.NET產品和雲計算SaaS商店平台，都是從這些重復的勞作中不斷思索發明的。我看到設計模式的書時，可以驕傲的向同學們吹牛，我也設計過幾個『模式』；第四，學會發現問題，探索問題，積極詢問，避免把問題遺留下來或者拖機取巧。浪費一個發現問題和解決問題的機會，相當於浪費提高自己的機會。最後，你要有信心成為一流有思想和靈魂的技術人員，別哪一天你離開尤埃時，丟我們的臉，：）。」 我不敢說，我現在多有思想，但是，我隱隱約約感覺到一些這樣的有意思的東西。我崇拜「道法自然」，它告訴我違反規律就會受到懲罰，因此，我會時刻反省我是否有做錯的事情，包括在平時編碼、設計和架構的時候，以及平時生活上的為人處事。接下來，我介紹一下，我如何來發明我曾經的產品，希望能夠給人一些啟發。 1 我是如何發明了控制項關系映射組件 控制項關系映射的發明源自於我在參與一款MIS系統的設計，該系統是一個鋼管管理系統，每一個鋼管的信息有很多很多的屬性，我記得鋼管廠給我們的數據說明書裡面，一個管子的信息有驚人的380多列。因此，我們在查詢、修改、添加記錄的時候，總是會有類似以下成片成片的代碼。1 var add***Sql = "insert into Test(a1,a2,....aN) values(@a1,@a2,....@aN)";2 ...... 3 var para1 = new SqlParameter("@a1", SqlDbType.String, a1.Text.Trim(); 6 var paraN = new SqlParameter("@aN", SqlDbType.String, a1.Text.Trim(); (忽略中間的N-3行代碼，以及查詢、修改和刪除的代碼)我記得，我們一起做的另一個小伙拿了一個CRUD一千多個欄位的表來向我們顯耀說：「我他媽的把這功能實現了！」。我不知道大家是否反感這樣的代碼，反正我是厭倦了。當我想到這是一件很痛苦的事情的時候，我考慮了如何來解決它。經過一些思考，我驚訝的發現，所有的CRUD以及界面的流程都可以抽象為「輸入-處理-輸出-輸入-處理-輸出......」的過程，處理的過程實際上是獲取輸入，然後組裝成SQL語句，最後在響應到界面。這個過程是以SQL語句為中心，SQL語句的參數來源於界面的控制項或者界面類的其它成員，SQL語句執行的結果可能是跑到另一個頁面、執行DataGrid綁定、執行下拉列表綁定、給控制項賦值。因此，我想到一個方法，可以設計一個SQL映射的配置，即利用這個配置，直接將界面控制項映射到資料庫，並且也可以執行反向映射。以下是映射SQL的配置。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 以下是調用映射SQL語句實現CRUD中的一個操作。 1 namespace HumanDispSolution2 {3 public class login : CrmPage4 {5 private void btnLogin_Click(object sender, System.EventArgs e)6 {7 DataSet ds = this.ExecuteMapping("Login") as DataSet; 8 if(ds.Tables[0].Rows.Count > 0) //登入 9 { 10 System.Web.Security.FormsAuthentication.RedirectFromLoginPage(UID.Text,false);11 }12 else13 this.lAlert.Text = "alert('登錄失敗，請重新輸入帳戶信息！');";14 }15 }16 } 另外，我還編寫了一個工具來自動生成這樣的配置文件，從此以後，關於資料庫的CRUD，我爽了！！ 2 我是如何發明了通用窗體框架 控制項關系映射的發明也是源於上面提到的鋼管系統。當超過2個人一起參與一個復雜項目時，可能他們都需要操作主界面，在主界面加上各自模塊需要的菜單、需要的界面元素，此外兩個人設計的東西也完全不一致。這就造成一些問題了，因為如何實現兩個人的集成就有一些麻煩，而且經常出現意外。於是我就發明了一個通用窗體框架，這個框架提供了以下功能：（1）集成用戶許可權；（2）集成數據訪問；（3）插件式支持，每一個人都可以並行開發，集成時僅需要將配置文件集成一起就形成一個組裝起來的軟體了。 每一個開發人員只需要編寫類似以下的配置文件就可以集成了： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 3 我是如何設計了對象-對象關系映射 ORM對於一些小型應用感覺有點龐大，但是對於大型應用，我想是一個比較總要的組件了。在我們使用ORM組件時，也經常會寫以下代碼。1 var user = new User(); 2 user.Name = NameTextBox.Text.Trim(); 5 OrmFactory.Save(user); 6 ----------------------------------------------7 var user = OrmFactory.QueryScalar(...); 8 NameTextBox.Text = user.Name; 9 ...... 如果一個MIS系統充斥了大量這樣的代碼，估計你也會膩味，從而喪失對編程的興趣了。記得我剛才說什麼來了，「有問題，意味著升華」，「做一個有思想的程序員」。因此，接下來的問題就是，我們如何來解決類似這樣重復的勞動。我在2006年時想到的辦法就是實現一個對象-對象的映射。首先，設計如下實體類： 1 public class UserEntity2 {3 ……4 [Member]5 public int Age; 6 [Control] 7 public string Name8 {9 get { return this._Name; } 10 set { this._Name = value; }11 }12 [Control("CardNo.Text")] 13 public string CardNo14 {15 get { return this._CardNo; } 16 set { this._CardNo = value; }17 }18 ……19 }20 21 public class EmployeeEntity22 {23 ……24 [Reference(typeof(UserEntity))] 25 public UserEntity User26 {27 get { return this._User; } 28 set { this._User = value; }29 }30 [Control] 31 public float PostSalary32 {33 get { return this._PostSalary; } 34 set { this._PostSalary = value; }35 }36 ……37 } 其次，調用ObjectEngine實現OO映射。A 實現表單類與實體類映射1 private void Map_Click(object sender, System.EventArgs e)2 {3 this.o = CZB.ObjectMapper.ObjectEngine.Map(this,typeof(EmployeeEntity)) as EmployeeEntity; 4 } B 實現實體類與表單類的映射1 private void InverseMap_Click(object sender, System.EventArgs e)2 {3 this.o.User.Name = "c.z.b in"; 4 this.o.User.Age = 19; 5 this.o.CompoInsurance = 0; 6 CZB.ObjectMapper.ObjectEngine.InverseMap(this,o); 7 } 4 我是如何設計OSGi.NET和SaaS商店產品 至於OSGi.NET和SaaS商店是我在不斷思索通用窗體框架以及對現有科技的趨勢的把握下，由幾個很有創造力的編程人員，在建立了完善的產品保障體系下，構建起來的。這兩個產品我會在後面介紹如何設計的。他們的設計我用了很長的時間。 我不是什麼老鳥，希望我們在如此多的技術的世界中能夠多多交流，共同進步。解決這些問題，不僅增加了編程的樂趣，更是增加了自己的見識，從而避免自己成為一個沒有思想的程序員！我也知道，我們可以找到很多理由來反駁文中提到的做法和觀點，但是，提高自己才是最重要的，不要去著急的否定一些什麼，並給自己找借口。

㈩ 中國程序員VS美國程序員，差距在哪裡

程序員本身沒有差距，而且中國的程序員工資更低，工作時間更長。但是組織差別是構成中美程序員行業的最主要差別，也就是體質差別。在中國努力工作的人並不能產生更強的結果，美國是是個程序員都一般努力，但是最終成果卻很好。但是中國的程序員是大家都很努力，但是力氣用不到一起去，內耗導致很多重復勞動，最終結果一般。權利壟斷和惡性競爭是中國所有行業的最大問題。
30歲之後程序員轉行的問題在於，美國沒有那麼多程序員可用，很多勞動離開了某個人，其他人無法頂替（技能差別，年輕人不是那麼多，也沒有那麼努力）。而在中國不是這樣的，年輕人工作更努力，工資更低，用你干幾年，然後換年輕人，從技能上來說並沒有什麼根本差別，而且由於競爭存在，新鮮血液的工作效率更高，可以有效的降低工資成本。但是這會帶來一個問題，30歲之後的程序員處於尷尬地位。於是行業內的惡性競爭就形成，權利壟斷者（管理層）成為香餑餑。而且更換底層勞動力，有利於上層權利壟斷。
但是問題就來了，被淘汰掉的勞動力並非無用勞動力，多年的技能積累付諸東流，形成較大的勞動力浪費。這些被淘汰的勞動力並不會就此退出，而是循環進入下一層惡性競爭，從而形成更大的重復勞動。
從宏觀上講，就是經濟結構失衡。無效的生產，導致產品過剩，而真正有效的需求得不到滿足。中國下一步會減少程序員供給，從人員培養上來減少程序員的產生，才是有效改善程序員待遇的最佳手段。