程序員關注什麼問題

『壹』 程序員開發時要考慮那些安全問題

代碼范圍
1,不安全的pageload,
2,不安全的get/post
3,不安全的read/write 許可權
4,不安全的html element
5,不安全的jscript/ajax
6,不安全的webservice/remoting
7,不安全的passport
8,不安全的IIS主機
9,不安全的data source主機

更多的安全性問題來自於本地用戶對主機的操作.和人為的具有管理許可權的賬戶泄露.

『貳』 作為一名程序員，從事技術管理工作，應該注意什麼事情

從程序員到技術管理，這要用人力資源管理的專業知識來看，就是一個非常典型的從「個人貢獻者」向「團隊管理者」角色轉變的過程，這也是各公司人力資源部門會重點關注的一個群體，幫助這些新晉升為管理者的人員快速進行角色轉換。

我將結合我人力資源從業生涯見到過的諸多案例、以及個人從員工升到管理層時的一些心路歷程，來回答這個問題。

第三步，掌握激勵下屬及增強團隊凝聚力的技巧和方法

依賴下屬完成業績目標的管理者，最重要的就是解決兩個問題，一個問題是讓下屬會幹活、有能力幹活；另外一個問題就是讓下屬有意願幹活，擁有一個能夠好好乾活的環境。

輔導和培養員工能夠解決員工幹活能力的問題，而激勵下屬及增強團隊凝聚力則能夠解決員工幹活意願的問題。主要分享3個主要方法。

• 自己做一個肯負責有擔當的領導人，遇事自己要沖在第一線，帶領大家一起解決問題和難題，有了榮譽、好處和利益，則更多把真正有貢獻的下屬推在前面；
• 鼓勵團隊成員之間互助互利，切忌主動製造內部矛盾和小團體；
• 營造一個以追求成長、進步、上進為榮，敷衍、懶散、得過且過為恥的團隊文化和氛圍。

『叄』 程序員，在開發的過程中應該注意哪些安全方面的問題

可忽視的誤區 企業的軟體開發能力取決於該企業的軟體過程能力。如果一個企業軟體過程能力越成熟，那麼該企業的軟體開發能力就越有保證。大量的實踐經驗表明，在體現企業軟體開發能力的因素中，技術或工具並不是第一位的。其實，許多問題不是出在不懂怎麼做，而是沒有安排做，做的次序不對，或不知道怎樣做得更好。 目前，比照軟體過程管理模型（如圖一），中國的軟體企業中還存在各種影響過程改進的因素和誤區，主要表現在個體和組織兩個方面。 在組織方面，首先，中國軟體企業實施CMM往往缺乏高級管理者的支持。其次，沒有足夠的SEPG資源。從很多情況考慮，SEPG成員要比其他CMM相關組綜合素質高一個層次，CMM相關組的管理素質需要比技術類組高一個層次，才能順利開展工作。第三，沒有合適的先行者或者沒有適當全局觀的項目經理配合。被組織選為先行者的人員經常說自己沒有時間，由於這些人都是從各個項目中抽出來的，一般人很難有足夠的權力讓他們為配合CMM做工作。最後，軟體組織缺乏足夠詳細的項目計劃和監督調整機制。 在個體方面，首先，手工作坊式的個人英雄主義情結成為實施CMM的制約。其次，某些軟體開發人員錯誤地認為過程管理會影響或壓抑專業人員的創造性，其實這是不清楚過程的定義造成的。第三，由於軟體項目的成功更多地依賴於少數人員的傑出技術能力和項目管理能力，成功項目的經驗不能得到最大限度的繼承，軟體生產的可重復性相對比較差。最後，軟體企業人員變更相對頻繁也增加了實施CMM的難度。 「三七」法則 在過程改進總體建議方面，應該從三個方面做准備，分七步走。 首先，在組織方面的准備上，除了要求高層經理出資支持CMM改善軟體過程，委託具有管理職責的人員負責CMM實施之外，須成立軟體工程過程組（SEPG），研究CMM、編寫/修改必要的文檔並推廣文檔；成立軟體質量保證組（SQAG），研究軟體質量保證技術及過程，編寫/修改必要的SQA文檔並推廣已編寫的文檔，測量和分析項目進展情況，反饋項目過程狀態，准備和評審過程、計劃和標准，審計指定的軟體工作產品以檢驗其遵從性，審計軟體工作過程的符合性；成立軟體配置管理組（SCMG），研究軟體配置管理技術及過程，編寫/修改必要的SCM文檔並推廣已編寫的文檔，建立必要的工具支持。 在知識准備方面，要加強培訓工作，建立內部過程評估隊伍和龐大的過程改善隊伍。對各角色人員進行專項培訓，普遍開展軟體工程基礎及CMM的培訓，使每個崗位的人員都具備過程改進的意識，並掌握所必需的過程改進知識和技能。此外，要重視對軟體工程的研究，包括方法、工具和過程，加速培養過程改進的骨幹隊伍。 在能力准備方面，建立有效的軟體項目管理，文檔化且遵循軟體項目管理過程，在建立管理過程中，使用組織的方針來指導項目，建立基本軟體工作產品完成准則和檢查單，並迅速實施，然後根據反饋意見及時修改。堅持適當的監控機制，例如對項目進度進行跟蹤而建立的例會制度，制度化的日報和周報活動。做好實際數據收集、測量與分析工作等。重復成功的以前項目的開發經驗。 改進過程總體可以分為以下七個步驟。 確定目標：確定在一段時間內達到的改進等級。 狀態診斷：把過程改進要達到的狀態與目前的狀態作比較，找出存在的差距。 制定計劃：「凡事有計劃，按計劃辦」不僅是CMM強調的，也是軟體開發過程中應該注意的。 規程制定：過程改進的一個重要的地方就是「事事有規程，時時有記錄」，這樣，即使關鍵人走了，原來的事也能繼續而不致產生過多的停頓。 過程試點：制定了規程後，要對行動計劃按執行過程的情況進行適當調整。其中，尤其要注重評審和驗證，實現定期監控，注意採集度量數據。 反饋修正：總結過程試點的經驗，修訂規程。 過程推廣：擴大應用范圍。 軟體過程改進實施步驟 公司的過程改進活動也是一個項目，並且是很大的項目，涉及的人員、技術和資源都很多，還要平衡現有產品或項目的進度等。同時，它也是一個不斷往復，螺旋上升的一個過程。 第一個步驟為高級經理下定決心，提供足夠的資源來主持並完成前期的准備工作，這個階段核心是評價SEPG組長的資格和資質，還包括評估培訓、購買工具的預算及相應資金能否及時到位。 無論是軟體商業化的過程或CMM實施的過程之中，建立規范化的易於操作的軟體開發行為規范都是首先要做的工作。但是，切記，編制規范的時間一定不能長，以10到12個工作日為宜，文檔不宜過多，以5～6個規程為好（對應5個或6個關鍵過程域），這是第二個關鍵階段。評價標准可以是SEPG組長能夠順利、流暢地講解其制定的規程。在規程編制階段必須有老闆或常務副總直接領導CMM工作。但是一定要記住，制定的過程要遵從「從實踐中來，到實踐中去」，同項目經理、有經驗的開發人員研究、討論，從而使SEPG組長能夠及時反映工作中的問題，並且問題能夠得到及時解決。 第三個步驟是制定並發布公司的評估方針和方案，包括開發體系重組過程中的激勵措施，中層在此階段必須介入，這關系著過程改進的結果。SEPG和CMM實施的周例會，必須有高級經理參加，要有記錄或錄音作為證據，是考核的一個指標。 除此之外，對於還沒有進行基於CMM改進的企業，還要重視設計復查、代碼復查以及測試工作 。很多程序員習慣於「只做不想」這樣一種工作方式，他們更關心每天可以寫多少行代碼，完成幾個模塊，在這種態度下，他們都很不願意復查自己的工作，而習慣於在軟體測試階段把隱藏的錯誤改正過來。CMM實施過程，就是要通過各種復查，溝通信息，及早發現並更改問題。 在實施了初始的過程或技術部署後，培訓成了主要問題。但人員變動時，附加培訓的必要可能沒被認識到，管理技能的培訓尤為重要。而對於那些由於過硬的技術而被提升到管理職位的人員，需要接受一整套新技能的培訓，包括人際關系技能。 項目經理在整個過程改進中（尤其是CMM二級）的工作量大約要佔到整個總量的一半到四分之三，在評估訪談時也佔有了舉足輕重的地位。有些項目經理認為自己心裡有一套計劃，只要按計劃進行就可以按時保質完成項目，但事實並非如此，在項目組之間的協調問題上，高層經理的作用是非常明顯的。 試點或模擬項目可以很小，哪怕只有兩個人，或者聯合SEPG進行指導全部公司的模擬項目，這是縮短試驗的最好途徑。先組織配置管理活動的培訓或學習，配置管理活動和質量保證活動在此期間可以得到很好的練習。 CMM為軟體企業的過程能力提供了一個階梯式的改進框架，它基於過去所有軟體工程過程改進的成果，吸取了以往軟體工程的經驗教訓，提供了一個基於過程改進的框架; 它指明了一個軟體組織在軟體開發方面需要管理哪些主要工作、這些工作之間的關系、以及以怎樣的先後次序，一步一步地做好這些工作而使軟體組織走向成熟。 但是由於CMM中不研究所有軟體過程和質量改進問題，也未提供有關實現子過程域所需要的具體知識和技能，因此要進行個體軟體過程PSP的實踐活動，以填補這一空白，並優化過程改進途徑。

『肆』 IT面試經驗：程序員面試什麼最重要

程序員面試一直是社區樂於討論的熱門話題。我自己從06年實習以來，先後經歷了4家軟體公司，全部是外企，其中有世界500強的通信企業，有從事期權期貨交易的歐洲中等規模的金融公司，也有為大型汽車製造商開發Android智能汽車的新興公司。跨入IT行業以來，我在求職過程中經歷過多次面試，最近兩年也有過多次面試別人的經驗。我感覺現在到了對這個問題發表自己看法的時候，這篇文章是我站在面試官角度對於程序員面試問題的一個階段性反思和經驗總結。
目標
相信和不少朋友一樣，有了幾年工作經驗成為Senior後就開始了面試別人的經歷。我在最初這個階段只是按照自己的想像把」找到基礎好的程序員「，」找到演算法能力優秀的程序員「，」找到有Android開發經驗的程序員「等作為面試的目標。但是，實際的經歷告訴我，尤其是按「基礎好」，「演算法好」這些目標招到的人最終效果並不好。比如，有的面試者基礎知識和演算法掌握情況不錯，進程、線程、內存等概念清晰，基本的Hash，二叉樹，快速排序等數據結構和演算法也比較熟悉，但是進公司後在實際工作中表現得很糟糕。後來，我才發現原來是我的面試目標出了問題，我原先的面試方法更像是大學的演算法或操作系統期末考試，按照這種方法讓許多並不合適的人通過了面試，同時也可能錯過了許多合適的人。
後來，我的反思是，從公司的角度講，面試的根本目的是找到「能夠干好工作」的人，而「高學歷」，「演算法好」，「基礎好」，「有經驗」這些都是表象而不是根本，它們並不能直接和「工作好」劃等號。
方法
目標明確了，但接下來的問題是假設面試者是一個黑盒系統，「工作好」不是直接可觀測變數，你所能直接觀測的變數是基礎、演算法、經驗、學歷、性格、談吐、年齡等等。所以，實際上，你只能從「基礎好」，「演算法好」等可以直接觀測的量去推測「工作好」的概率，這就是一個在「X好「條件下」工作好「的條件概率問題：P(工作好 | X好)。
根據這個模型，面試所應該考察哪些方面就很明顯了，那就是選擇那種最具有區分性的方面來考察。比如，考察面試者的體型特徵沒有太大意義，因為P(工作好|高)，P(工作好|矮)，P(工作好|胖)，P(工作好|瘦)的概率都差不多；所以，體型特徵不具有區分性，這不是面試所應該關注的內容。
面試官應當結合職位的要求明確哪些因素具有比較好的區分性。比如，如果要招一名技術門檻比較高的3D游戲引擎開發工程師，面試者A具有3D游戲引擎開發的經驗，但是在基礎知識和演算法面試方面表現一般；面試者B相反，基礎知識和演算法面試表現很好，但沒有游戲開發經驗，而你只能選擇其一。你選誰呢？其實，這就是兩個條件概率問題P(工作好|經驗好，基礎一般，演算法一般）和P(工作好|沒經驗，基礎好，演算法好）。這個問題就留給面試官來判斷了，就我個人而言，對於技術門檻較高需要技術積累的職位，經驗更加說明問題，因此，我更傾向於面試者A。
下面，我再結合自己的經驗談談對面試中常見方面的看法。
演算法
演算法是Google和MS等大公司面試所重點考察的內容。我個人很喜歡演算法，曾經參加ACM/ICPC拿過北京賽區的13名。但是，就個人經驗來看，我所接觸過的絕大多數開發職位而言，演算法都不適合作為考察面試者優劣的主要因素。對於普通的非演算法性開發職位，考察面試者的演算法就相當於考察他打乒乓球好不好一樣，與目標「工作好」的相關性太低。就我個人的經驗來看，差不多P(工作好|演算法好)=50%，也就是演算法面試沒有太大的區分性。
甚至，還有一種很不好的情況特別多地出現在演算法好的面試者身上，我稱之為「只磨刀，不砍柴」。什麼意思呢？有類人只對什麼A*演算法，非同步編程，JVM類載入機制這種純技術問題感興趣，對實現用戶需求毫無興趣。這類人看起來有一定的技術能力，但是對公司來講貢獻十分有限，甚至不如技術一般但認真負責的人。所以，一旦遇到面試者演算法好，我就特別留意考察會不會是這種「只磨刀，不砍柴」的人。
另外，雖然我個人不了解Google和MS，但我對於其特別重視考察演算法能力的面試策略是持懷疑態度的。即使在這樣的世界級大公司，演算法雖然重要，但可以想像在項目實施過程所遇到的各種各樣問題中，演算法問題絕大多數時候不會是主要瓶頸，沒有到那種需要每個人都是演算法高手的情況。實際上，絕大多數項目真正難點並不是一兩個演算法瓶頸，甚至也不是單點的技術瓶頸，而是系統性的組織、協調、設計、開發問題，有大量的看起來不是那麼有技術含量的臟活累活，也有許多問題是由於信息不足，並不是技術能力強就能克服這些困難。一個團隊最好優勢互補，有人演算法強，有人業務分析能力強，有人擅長後端服務，有人擅長前端界面，有人聰明，有人踏實，這是最好的。如果按照「演算法好」的單一標准選材，必定會把許多優秀的人才拒之門外。
基礎
基礎面試是指考察諸如指針使用、進程線程概念等基礎知識的面試，十分類似於大學期末考試題。我曾經以為基礎面試十分重要，但是現在不這么看了。在工作中基礎的確是重要的，但是在面試過程中，它必須具有區分性才有意義，也就是說P(工作好|基礎好)的概率要高，那麼考察指針使用，進程線程區別這樣的基礎題目才有它的意義。我的實際經驗是，基礎面試並不具有很好的區分性，和演算法一樣， 差不多P(工作好|基礎好) = 50%。同時，基礎面試是最容易准備的，中國人有長期的應試教育經驗，要准備幾個把玩指針題目太容易了。
我曾經遇到過這樣的面試者，他的C語言基礎和編譯、鏈接等原理掌握得非常好，給我留下了深刻的印象，我給的面試結論是：知識面不寬，只會C語言，但基礎很扎實，建議錄用。後來的事情證明了那個結論的前半部分是對的，但是」建議錄用「錯了。他在實際工作中表現得一塌糊塗，不理解需求，不理解整體架構；同時，上班時間不是花在項目上，而是花在閱讀諸如《程序員的自我修養》之類的書籍上。最後，這位同事由於長期「不出活」離開了公司。
基礎不是不重要，而是「基礎好」不足以說明面試者能幹好工作，因為基礎是屬於局部性知識，而實際工作需要綜合性能力，二者有天壤之別。C語言、操作系統能考高分，但是不會寫程序的人在大學我們還見得少嗎？ 軟體開發就像蓋房子，綜合能力是設計和搭骨架，基礎知識是碼磚。張小龍原先Foxmail是Delphi開發的，他它不懂C#，你如果要招聘一個開發.NET Email客戶端的人，你考察他對CLR掌握得好不好有意義嗎？ 讓張小龍來開發一個C#版的Foxmail真的會有困難嗎？ 你招一個精通C#但沒有Email客戶端開發經驗的人來真的比張小龍靠譜嗎？
我說基礎知識不重要，和古人說的「不積窪步無以至千里」是不是矛盾呢？不矛盾！「窪步」與「千里」是一種可累加關系，但再多的「基礎知識」都累加不成「綜合能力」。學習軟體開發要像持續集成一樣，一開始就是一個完整的系統，雖然規模不大，問題很多，但它麻雀雖小五臟俱全，從小系統到大系統，從簡單系統到復雜系統逐步演化。
所以，基礎好本身不足以說明太多的問題，必須進一步考察綜合能力。對於基礎面試表現不好的面試者，如果時間允許也要進一步考察，有的面試者其實是有能力的，只是沒有進行充分的准備。最理想的狀態當然是基礎和綜合能力俱佳，若不能兼顧，應當綜合能力優先。
經驗
這里所說的經驗不是通過工作了多少年來衡量的，而主要是指面試者的經歷，比如，是否完整地實現過一個軟體，或作為主要開發者完成過一個項目。經驗的重要性在於它能說明一個人的綜合能力。從項目的性質、規模和難度，面試官就可以大致判斷出面試者的綜合能力。如果一個面試者一直在大公司負責一個小模塊的開發維護，那麼基本可以判斷他不具備獨立或作為主要開發者承擔一個項目的能力，只適合在另一家大公司做類似的事情。對於門檻較高需要長期技術積累的職位，相關經驗更顯得尤為重要，比如，linux內核開發，JVM開發，游戲引擎開發，資料庫實現，高級UX等。對於這類職位，沒有經驗的面試者即使綜合素質不錯也是需要長時間的學習和積累才能勝任。所以，基本上如果確定了你的職位屬於此類，那麼相關經驗毫無疑問應該成為首選因素，換句話說，P(工作好 | 相關經驗好)的概率是非常高的。
通過項目經驗判斷面試者的優劣比通過基礎和演算法測試更加靠譜，所以，面試過程中面試官應該花比較多的時間聽面試者介紹項目經驗，並進行深入地探討交流，了解面試者的知識面、思維能力、表達能力等。同時，可以結合項目提一些基礎知識和演算法的問題，比如，如果面試者做過C++相關的項目，那就可以問他如何進行內存管理？是否熟悉智能指針？如果面試者的回答不能令人滿意，那麼就基本上可以判斷他的項目做得不是很好。
要注意的是，經驗也是一個多維度的事物。比如，C++股票交易中間件系統，這就涉及(C++，中間件，股票) 3個維度。假如面試者A做過C++股票交易客戶端，面試者B做過C的股票交易中間件。從語言角度看，A最匹配，從項目性質看，B最匹配，你如何選擇？這就是在多個維度中，哪個維度更重要的問題，就這個例子而言，我個人更傾向於B，因為我認為中間件開發經驗是主要矛盾，而從C切換到C++並不是問題。所以，面試官需要判斷哪一種經驗是主要的，而哪一種經驗是次要的。比如，我們招聘Android應用開發，這個職位的Android技術門檻並不高，它的真正難點在於做出好的用戶體驗(UX)。所以，如果一個面試者沒有Android的經驗我們是可以接受的，但是我希望他在UX方面有經驗，至少做過其他平台的移動應用開發。
性格
現在，我來談我認為最重要的因素：性格。這可能是許多初為面試官的朋友所難以想像的，怎麼會是性格最重要呢？說實話，當我意識到這一點時，我自己也很驚訝！說白了，還是 P(工作好|性格好)的概率最高啊。我的實際經驗是，如果一個人的性格好，他能把工作做好的可能性是最高的，性格好遠比基礎好、演算法好要靠譜。
一個人如果技術上有缺陷，經驗上有不足，但性格好，在團隊中是很容易由其他人來補位的，他自己也很容易逐漸補起來；相反，如果一個人的性格不好，所有的技術優勢經驗優勢都發揮不出來，甚至還會起到負作用，而且性格缺點很難改變。我一直談到實際工作所需要的是綜合性的能力，這種綜合能力的發揮中性格是至關重要的。項目中不止會遇到技術問題，要涉及溝通、協調，不同的人不同的部門既有合作又有磨擦，如何處理這些事情都需要一個良好的性格。可以說，在開發團隊里讓你與眾不同的不是你從哪個學校畢業，也不是你過去的經驗，而是你的性格。
當然，性格是一個復雜的東西，它包含了很多的方面，並非所有方面都是程序員面試所需要關注的。我的經驗是可以重點考察這些方面：
1) 態度積極還是消極。有的面試者在談吐中就會自然給你一種積極上進的感覺，或者你可以在他的經歷中發現他積極的因素，這些都不是太難看出來的。相反，有的面試者你能明顯感覺到他的消極情緒。積極性在工作中是十分重要的，積極的人能給團隊帶來朝氣，也更易於合作。基本上，如果確定面試者屬於態度積極的，他通過我這一關的可能性就會大大增加；相反，如果確定屬於態度消極的，即使技術能力不錯我也會十分謹慎。
2) IQ。我的經驗是，總體來看，聰明的人在工作中的表現更為優秀。在面試中要考察一個人是否聰明並不一定要像Google和MS那樣找些專門測試IQ的智力題，其實，你只需要看他討論問題是不是很有邏輯性，思考和說話是不是反應敏捷就可以做出大致的判斷。另外，眼睛是人心靈的窗戶，一個人聰明與否，眼睛是會說話的。不過，聰明也不完全是優點，比如，當公司或項目遇到困難時，往往是聰明人先跑掉了，堅守的往往是IQ一般的人。
3) 語言表達能力。語言表達能力也是程序員十分重要的一項素質，它關繫到項目中的溝通是否順暢。面試官可以看看面試者能否用簡明的語言介紹清楚曾經做過的項目，能否抓住要點，能否考慮到聽者的相關背景。一般來講，語言表達能力強的人綜合能力都不會太差。
4) 是否具有用戶意識。有人說程序員是做研發的，哪來什麼用戶？只有銷售、市場人員才會和用戶打交道。其實，這是完完全全的錯誤認識。你寫一個模塊，甚至一個API，只要有別人用，他就是你的用戶。有的程序員設計一個模塊或是一個軟體總是習慣於從使用者的角度來考慮，盡量地方便使用者，這就是一種良好的用戶意識。具有良好的用戶意識的人更能考慮別人的感受和整體的需要，而不是單純地從自己和局部來思考問題。當面試者談及過去的項目經驗時，面試官可以常常站在用戶的角度對其進行提問，從這個過程中觀察其是否具有良好的用戶意識。
5) 如何應對質疑和壓力。面試官應該對面試者的回答以及以往項目進行合理的質疑，看看他如何應對。曾經有一位面試者談到做游戲登錄伺服器的經歷，我就問：「如果登錄伺服器掛了，怎麼辦呢」？他說原先雖然沒有考慮這個問題，但是可以怎麼怎麼改進。其實，大家都理解項目中有各種不完美，這裡面原因很多，只要面對質疑和壓力能從容應對努力往好的方向思考解決就可以了，不需要掩飾缺陷，更不應該有情緒。我遇到過有的面試者，一旦你對其項目提出質疑，他馬上產生反抗情緒，或不高興，或不承認有問題，這很容易一下子看出來他在工作中容不得質疑和批評，這種人要想合作就很困難。
6) 個性特點。許多面試者喜歡在簡歷上寫「精通C++/Linux「，這些字眼看得人麻木，如果有人寫」喜歡C++/Linux「，我就會有一種眼前一亮的感覺。「精通」是沒有感情色彩的敘述，而「喜歡」包含了面試者的個性，我更願意看到面試者的個性。我相信對某樣東西真正的熱情遠比你當前對它的掌握程度更為重要。其實，N年的經歷告訴我們，同一個班的同學，同一個項目組的同事，雖然每天所學的知識，所接觸的工作都是相同的，但其實每個人的成績和表現差異是十分明顯的。那麼，到底本質的差異是什麼呢？其實，就是每個人的個性。是個性使得有的人業余時間去打球，有的人業余時間去看書，有的人喜歡Linux，有的人喜歡Mac。一個人在團隊中扮演的角色也和他的個性有很大的關系。面試官應該引導面試者展現自己的個性，並判斷其是否有益於團隊。
總結
最後總結起來，我的經驗是： 1) 面試官的目標是找到」工作好「的人，一定要圍繞這個目標來進行面試，如果把面試當成了演算法或操作系統期末考試這就走入了誤區；2) 面試過程是通過學歷、性格、基礎、經驗、演算法等可以測試的因素去綜合判斷面試者「工作好」的概率；3) 在各種因素中，性格 > 經驗 > 基礎 > 演算法。性格是最重要的，如果性格不好，所有技術能力都會大打折扣，而且技術缺陷容易彌補，性格缺陷很難改變；經驗體現了一個人的綜合能力，你可以從面試者過去的經歷中判斷他能從事哪種工作，不能從事哪種工作；基礎和演算法則主要起到輔助參考的作用，基礎好的程序員一般適應性比較強，學新技術更快，但是切忌單純從基礎來判斷一個人的能力。

『伍』 hr面試程序員問什麼問題，程序員在面試的時候的注意事項

01 和優秀開發者溝通
如果你本身沒有編程背景，那就盡量找到一些優秀的開發人員給你指點迷津。
02 問專業的問題

1. 簡要介紹一下你自己以及你最近在做的項目嗎？
作用：這個問題可以讓你更好地了解你的候選人，而談論近期工作能了解他對工作的熱情和奉獻。

2. 其他時間有別的項目要做嗎
作用：鑒於你的項目的時間長短和工作復雜程度，你可能只想找一個能完全投入到這個項目的人。但是很多程序員都會同時兼顧好幾個項目，你要確保彼此雙方的需求是什麼。

3. 你是怎麼看待自己的身份的？開發？產品經理？還是二者都是？
作用：理想的回答一般是『二者都是』， 但是你要認真評估每個候選人可能給你團隊帶來的有利和不利影響。產品經理可以幫助設計新的功能和交互，但是你也需要足夠的開發才能跟上方向從而建構你想要的內容。

4. 你會如何管理一個程序員團隊？
作用：這個問題可以幫你了解候選人的領導能力和風格。

5. 告訴他們公司想要的人是怎樣的。
作用：直截了當地告訴對方你的期望。像工作時間，項目長短，目標等等，這些都是對方很想知道的。就像你評價他是否適合公司一樣，對方也會評價你的公司是否適合他。

03 去合適的地方招聘
你不能指望天上會掉下個好程序員給你，微軟和谷歌的優秀程序員也不會自己蹦到你跟前。你的機會在於，很多這樣的程序員都擁有或追求商業想法。
你可以多去一些網站、活動大賽等地方探索發掘，這比你在社交網站上找到他們的運氣要大得多。

· 編程大賽
編程大賽就是程序員高手們雲集在一起，合作共同完成一個軟體的開發。
猿圈會定期舉辦此類招聘編程大賽，幫助企業挑選優質人才，提高企業品牌僱主形象。

· 開放性源代碼貢獻者
一些網站比如GitHub，提供在線代碼存儲庫, 程序員可以自由對開源項目貢獻自己的代碼。
所以，在招聘之前，你可以先去這種網站上找一找有潛力的候選人。

· 大學
· 軟體開發大會
盡可能多的去參加一些和你的產品相關的軟體開發大會。

· 技術博客
你能根據他們的博客判斷他們的技術技能、解決問題的能力以及寫作和溝通能力。

04 沒通過編程測試，堅決不錄用

你只能記住一條原則，那必須是，沒有讓候選人參加編程測試之前，千萬不能決定錄用與否。

通常情況下，出於項目的緊迫，我們會傾向於選擇看起來靠譜的第一個程序員，但是不拿到他的編程測試結果，不要沖動地下offer。

我也是個不懂代碼的HR，但是我善於利用各種各樣的工具，前段時間發現了一個猿圈測評的工具，我用它測試程序員候選人，通過測試結果判斷是否值得邀約來面試，這個我覺得很贊，你可以試試看

『陸』 程序員應該注意哪些身體健康他們容易患什麼職業病

沒吃過泡麵不算程序員，沒加過班的不是程序員，久而久之各種健康問題就來了，當然小編也知道要要因人而異，不同的職業會引發不同的毛病。據國外的一項調查表明，頭發的變化與相應人群在年齡，性別甚至職業上都有明顯的特徵，程序員的脫發現象，很有可能是因為長時間工作壓力大，長期加班和睡眠障礙，作息混亂等等原因造成的亞健康。

如何很快的淘汰一個人，是讓他太忙，忙到沒有時間休息，沒有時間創造思維，沒有時間學習，才為可怕。所以，請擁有好心態，技術學不完，時間是自己的。有些關於身體上的一些疾病自己要注重，畢竟身體是自己的，別人無法與你一起承受疼痛。

『柒』 程序員面試常見問題有哪些

你有沒有做過什麼項目，這個問題要回答得簡明扼要，直接簡潔地描述你參與過的項目和在裡面扮演的角色。面試官是想看看你是不是真的參與項目了，你對項目的把控度、你在項目里擔當的角色、對項目類型以及你對項目應用的了解。通過你的回答，有經驗的面試官能看的出你對這個行業的認識。

『捌』 你要面試一個程序員，應該問他什麼問題

首先面試程序員分有沒有經驗
面試沒有經驗的程序員就隨便問問點ssm，ssh五大框架問題，多線程什麼的，再問問是否會點前端技術
有經驗就看看他的簡歷，問他簡歷項目上的問題，可以圍繞著簡歷上的項目問，通過他的回答涉及到的技術點之類的，拓展出去問其他的

『玖』 程序員日常生活面臨的問題和挑戰有哪些

一、熬夜
很多程序員將熬夜變成了生活習慣，還口口聲聲解釋「程序員只有在晚上效率才高」，這是非常扯淡的理論。有人將程序員做下圖的類比，雖然比較貼切，但這種方式對你的健康傷害是最大的。建議你嘗試一下晚上10點睡覺，早上6點起來工作的作息方式，也許會事半功倍。
二、久坐
有些程序員在電腦面前一坐就是一天，中間除了吃飯上廁所外，基本不起來動動。這是非常不好的習慣，時間久了，很容易得肩周炎、頸椎病，到時候後悔就晚了。建議每坐一個小時就起來動10分鍾，主要是轉轉手臂和脖子。
三、外賣和泡麵

很多程序員在飲食上也非常不注重健康，上班的時候為了貪圖方便經常叫一些外賣，更厲害的是直接搞一桶方便麵來做午餐。這里建議大家中午出去吃，葷素搭配，再可以弄點水果。
四、缺乏鍛煉

建議在工作日下班後做一些簡單的球類運動，乒乓球、羽毛球。
五、用眼過度
IT公司的員工的體檢報告中大部分程序員都患有「慢性結膜炎」，當然對於這個病並不是長時間對著電腦引起的，但是用眼過度也會加劇「慢性結膜炎」的惡化。
建議大家平時准備防止眼乾的眼葯水，如果確定是結膜炎的話，還要及時去醫院就診。另外電腦的背景可以設成綠色，這樣對眼睛也能起到一定的保護作用。

『拾』 做一個新手程序員應具體哪些知識

程序員是一種技術工作，在IT的發展中有相當重要的地位，從底層硬體通訊協議的建立， 到數據傳輸層的處理，到操作系統的建設，到資料庫平台的建設，一直到應用層上各種數 據營銷平台的搭建，程序員在裡面都扮演著舉足輕重的角色並為IT事業的發展做出了巨大 的貢獻。

中國有很多精於編碼的人，但是中國軟體行業，尤其是網路應用開發方面誤區很大，很難形成有規模的軟體開發力量和產品能力，不但比美國差距甚遠，和印度相比也是頗有不如。這些問題不是在於中國程序員的智商和工作努力狀況，也不是在於國家和民間對開發的投入程度，而是很大程度上，有一些對技術，對程序開發，對項目設計方面的思想誤區，這些誤區，導致了軟體行業的產品化能力不足，缺乏規模化和大型復用系統研發能力，可以說，改變認識誤區，是解決軟體行業小作坊模式和個體英雄模式所帶來的局限性 的重要工作。

中國有很多小朋友，他們18,9歲或21,2歲，通過自學也寫了不少代碼，他們有的代碼寫的很漂亮，一些技術細節相當出眾，也很有鑽研精神，但是他們被一些錯誤的認識和觀點左右，缺乏對系統，對程序的整體理解能力，這些人，一個網上的朋友說得很好，他們實際 上只是一些Coding fans，壓根沒有資格稱為程序員，但是據我所知，不少小網路公司的 CTO就是這樣的coding fans,拿著嚇人的工資，做著嚇人的項目，項目的結局通常也很嚇 人。

程序員基本素質：

作一個真正合格的程序員，或者說就是可以真正合格完成一些代碼工作的程序員，應該具 有的素質。

1：團隊精神和協作能力

把它作為基本素質，並不是不重要，恰恰相反，這是程序員應該具備的最基本的，也是最重要的安身立命之本。把高水平程序員說成獨行俠的都是在囈語，任何個人的力量都是有限的，即便如linus這樣的天才，也需要通過組成強大的團隊來創造奇跡，那些遍布全球的為linux寫核心的高手們，沒有協作精神是不可想像的。獨行俠可以作一些賺錢的小軟體發點小財，但是一旦進入一些大系統的研發團隊，進入商業化和產品化的開發任務，缺 乏這種素質的人就完全不合格了。

2：文檔習慣

說高水平程序員從來不寫文檔的肯定是乳臭未乾的毛孩子，良好的文檔是正規研發流程中 非常重要的環節，作為代碼程序員，30％的工作時間寫技術文檔是很正常的，而作為高級 程序員和系統分析員，這個比例還要高很多。

缺乏文檔，一個軟體系統就缺乏生命力，在未來的查錯，升級以及模塊的復用時就都會遇 到極大的麻煩。

3：規范化，標准化的代碼編寫習慣

作為一些外國知名軟體公司的規矩，代碼的變數命名，代碼內注釋格式，甚至嵌套中行縮 進的長度和函數間的空行數字都有明確規定，良好的編寫習慣，不但有助於代碼的移植和 糾錯，也有助於不同技術人員之間的協作。

有些coding fans叫囂高水平程序員寫的代碼旁人從來看不懂，這種叫囂只能證明他們自 己壓根不配自稱程序員。代碼具有良好的可讀性，是程序員基本的素質需求。

再看看整個linux的搭建，沒有規范化和標准化的代碼習慣，全球的研發協作是絕對不可 想像的。

4：需求理解能力

程序員需要理解一個模塊的需求，很多小朋友寫程序往往只關注一個功能需求，他們把性能指標全部歸結到硬體，操作系統和開發環境上，而忽視了本身代碼的性能考慮，有人曾經放言說寫一個廣告交換程序很簡單，這種人從來不知道在百萬甚至千萬數量級的訪問情況下的性能指標是如何實現的，對於這樣的程序員，你給他深藍那套系統，他也做不出太極鏈的並訪能力。性能需求指標中，穩定性，並訪支撐能力以及安全性都很重要，作為程序員需要評估該模塊在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程序員至少需要2到3年的項目研發和跟蹤經 驗才有可能有心得。

5：復用性，模塊化思維能力

經常可以聽到一些程序員有這樣的抱怨，寫了幾年程序，變成了熟練工，每天都是重復寫 一些沒有任何新意的代碼，這其實是中國軟體人才最大浪費的地方，一些重復性工作變成 了熟練程序員的主要工作，而這些，其實是完全可以避免的。

復用性設計，模塊化思維就是要程序員在完成任何一個功能模塊或函數的時候，要多想一些，不要局限在完成當前任務的簡單思路上，想想看該模塊是否可以脫離這個系統存在，是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重復性的開發工作，如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題，那麼程序員就不會在重復性的工作中耽誤太多時間，就會有更多時間和精力投 入到創新的代碼工作中去。

一些好的程序模塊代碼，即便是70年代寫成的，拿到現在放到一些系統裡面作為功能模塊 都能適合的很好，而現在我看到的是，很多小公司軟體一升級或改進就動輒全部代碼重 寫，大部分重復性工作無謂的浪費了時間和精力。

程序員應具備的素質中

6：測試習慣

作為一些商業化正規化的開發而言，專職的測試工程師是不可少的，但是並不是說有了專職的測試工程師程序員就可以不進行自測；軟體研發作為一項工程而言，一個很重要的特點就是問題發現的越早，解決的代價就越低，程序員在每段代碼，每個子模塊完成後進行認真的測試，就可以盡量將一些潛在的問題最早的發現和解決，這樣對整體系統建設的效 率和可靠性就有了最大的保證。

測試工作實際上需要考慮兩方面，一方面是正常調用的測試，也就是看程序是否能在正常調用下完成基本功能，這是最基本的測試職責，可惜在很多公司這成了唯一的測試任務，實際上還差的遠那；第二方面就是異常調用的測試，比如高壓力負荷下的穩定性測試，用戶潛在的異常輸入情況下的測試，整體系統局部故障情況下該模塊受影響狀況的測試，頻發的異常請求阻塞資源時的模塊穩定測試等等。當然並不是程序員要對自己的每段代碼都需要進行這種完整測試，但是程序員必須清醒認識自己的代碼任務在整體項目中的地位和各種性能需求，有針對性的進行相關測試並盡早發現和解決問題，當然這需要上面提到的 需求理解能力。

7：學習和總結的能力

程序員是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有 領先性，程序員如果想安身立命，就必須不斷跟進新的技術，學習新的技能。

善於學習，對於任何職業而言，都是前進所必需的動力，對於程序員，這種要求就更加高 了。

但是學習也要找對目標，一些小coding fans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程序不懂通訊傳輸協議，做應用程序不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語言，永遠不會有質的提 高。

善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段代碼，都應當有 目的的跟蹤該程序的應用狀況和用戶反饋，隨時總結，找到自己的不足，這樣逐步提高， 一個程序員才可能成長起來。

一個不具備成長性的程序員，即便眼前看是個高手，建議也不要選用，因為他落伍的時候 馬上就到了。

具備以上全部素質的人，應當說是夠格的程序員了，請注意以上的各種素質都不是由IQ決 定的，也不是大學某些課本里可以學習到的，需要的僅僅是程序員對自己工作的認識，是 一種意識上的問題。

那麼作為高級程序員，以至於系統分析員，也就是對於一個程序項目的設計者而言，除了 應該具備上述全部素質之外，還需要具備以下素質：

第一，需求分析能力

對於程序員而言，理解需求就可以完成合格的代碼，但是對於研發項目的組織和管理者， 他們不但要理解客戶需求，更多時候還要自行制定一些需求，為什麼這么說呢？

一般而言，進行研發任務，也許是客戶提出需求，也許是市場和營銷部門提出的需求，這時候對於研發部門，他們看到的不是一個完整的需求，通常而言，該需求僅僅是一些功能上的要求，或者更正規些，可能獲得一個完整的用戶視圖；但是這都不夠，因為客戶由於非技術因素多一些，他們可能很難提出完整和清晰，或者說專業性的性能需求，但是對於項目組織者和規劃者，他必須能夠清醒認識到這些需求的存在並在完成需求分析報告的時候適當的提出，同時要完整和清晰的體現在設計說明書裡面，以便於程序員編碼時不會失 去這些准則。

程序設計者必須正確理解用戶需求所處的環境，並針對性做出需求的分析，舉例而言，同樣一個軟體通過ASP租用方式發布和通過License方式發布，性能需求可能就是有區別的，前者強調的是更好的支撐能力和穩定性，而後者則可能更強調在各種平台下的普適性和安 裝使用的簡捷性。

第二，項目設計方法和流程處理能力

程序設計者必須能夠掌握不少於兩到三種的項目設計方法（比如自頂至下的設計方法，比 如快速原型法等等），並能夠根據項目需求和資源搭配來選擇合適的設計方法進行項目的 整體設計。

設計方法上選擇不當，就會耽誤研發周期，浪費研發資源，甚至影響研發效果。

一個程序設計者還需要把很多功夫用在流程圖的設計和處理上，他需要做數據流圖以確立 數據詞典；他需要加工邏輯流圖以形成整體的系統處理流程。

一個流程有問題的系統，就算代碼多漂亮，每個模塊多精緻，也不會成為一個好的系統。 當然，做好流程分析並選擇好項目設計方法，都需要在需求分析能力上具有足夠的把 握。

第三，復用設計和模塊化分解能力

這個似乎又是老調重談，前面基本素質上不是已經說明了這個問題嗎？

作為一個從事模塊任務的程序員，他需要對他所面對的特定功能模塊的復用性進行考慮，而作為一個系統分析人員，他要面對的問題復雜的多，需要對整體系統按照一種模塊化的分析能力分解為很多可復用的功能模塊和函數，並針對每一模塊形成一個獨立的設計需求。舉個例子，好比是汽車生產，最早每輛汽車都是獨立安裝的，每個部件都是量身定做的，但是後來不一樣了，機器化大生產了，一個汽車廠開始通過流水線來生產汽車，獨立部件開始具有一定的復用性，在後來標准化成為大趨勢，不同型號，品牌甚至不同廠商的汽車部件也可以進行方便的換裝和升級，這時候，汽車生產的效率達到最大化。軟體工程也是同樣的道理，一個成熟的軟體行業，在一些相關項目和系統中，不同的部件是可以隨意換裝的，比如微軟的許多桌面軟體，在很多操作模塊（如打開文件，保存文件等等）都是復用的同一套功能模塊，而這些介面又通過一些類庫提供給了桌面應用程序開發者方便 掛接，這就是復用化的模塊設計明顯的一個佐證。

將一個大型的，錯綜復雜的應用系統分解成一些相對獨立的，具有高度復用性的，並能僅 僅依靠幾個參數完成數據聯系的模塊組合，是作為高級程序員和系統分析員一項最重要的 工作，合適的項目設計方法，清晰的流程圖，是實現這一目標的重要保證。

第四，整體項目評估能力

作為系統設計人員，必須能夠從全局出發，對項目又整體的清醒認識，比如公司的資源配置是否合理和到位，比如工程進度安排是否能最大化體現效率又不至於無法按期完成。評估項目整體和各個模塊的工作量，評估項目所需的資源，評估項目可能遇到的困難，都需要大量的經驗積累，換言之，這是一種不斷總結的累計才能達到的境界。在西方一些軟體系統設計的帶頭人都是很年長的，比如4，50歲，甚至更老，他們在編碼方面已經遠遠不如年輕人那樣活絡，但是就項目評估而言，他們幾十年的經驗積累就是最重要和寶貴的財富。中國缺這么一代程序員，主要還不是缺那種年紀的程序員，而是那種年紀的程序員基本上都是研究單位作出來的，都不是從專業的產品化軟體研發作出來的，他們沒有能積累 那種產品化研發的經驗，這也是沒有辦法的事情。

程序員應具備的素質下

第五，團隊組織管理能力

完成一個項目工程，需要團隊的齊心協力，作為項目設計者或研發的主管人，就應當有能 力最大化發揮團隊的整體力量，技術管理由於其專業性質，不大同於一般的人事管理，因 為這裡面設計了一些技術性的指標和因素。

首先是工作的量化，沒有量化就很難做到合適的績效考核，而程序量化又不是簡單的代碼 行數可以計算的，因此要求技術管理人員需要能真正評估一個模塊的復雜性和工作量。

其次是對團隊協作模式的調整，一般而言，程序開發的協作通常分為小組進行，小組有主 程序員方式的，也有民主方式的，根據程序員之間的能力水平差距，以及根據項目研發的 需求，選擇合適的組隊方式，並能將責權和成員的工作任務緊密結合，這樣才能最大發揮 組隊的效率。

一個代碼水平高的人，未必能成為一個合格的項目研發主管，這方面的能力欠缺往往是容 易被忽視的。

綜上可以看到，作為一個主管研發的負責人，一個項目設計者，所需要具備的素質和能力並不是程序代碼編寫的能力，當然一般情況下，一個程序員通過不斷的總結提高達到了這種素質的時候，他所具有的代碼編寫能力也已經相當不簡單了，但是請注意這裡面的因果關系，一個高水平的項目設計者通常已經是代碼編寫相當優秀的人了，但是並不是一個代碼相當優秀的程序員就可以勝任項目設計的工作，這裡面存在的也不是智商和課本的問題，還是在於一個程序員在積累經驗，逐步提升的時候沒有意識到應當思考哪方面的東西，沒有有意識的就項目的組織和復用設計進行揣摩，沒有經常性的文檔習慣和總結習 慣，不改變這些，我們的合格的項目設計者還是非常欠缺。

另外，為防止有無聊的人和我較真，補充一點，本文針對目標是作商業化的軟體項目和工程，那些科研機構的編程高手，比如演算法高手，比如圖象處理高手，他們的工作是研究課題而非直接完成商業軟體（當然最終間接成為商業產品，比如微軟研究院在作的研究課題），因此他們強調的素質可能是另外的東西，這些人（專家），並不能說是程序員，不 能用程序員的標准去衡量。

最後補充一點東西，一個軟體項目研發的設計流程是怎樣的呢？以通常標準的設計方法為 例，（不過筆者喜歡快速原型法）。

第一個步驟是市場調研，技術和市場要結合才能體現最大價值。

第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手 冊。

用戶視圖是該軟體用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。

數據詞典是指明數據邏輯關系並加以整理的東東，完成了數據詞典，資料庫的設計就完成 了一半多。

用戶操作手冊是指明了操作流程的說明書。

請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟體設計之前完成，完成 這些，就為程序研發提供了約束和准繩，很遺憾太多公司都不是這樣做的，因果顛倒，順 序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。

需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明 書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或 公司市場部門）能夠有真正的溝通和了解。

第三個步驟是概要設計，將系統功能模塊初步劃分，並給出合理的研發流程和資源要求。作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是並不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。

第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。

那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。

第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都出現過。編碼時的相互溝通和應急的解決手段都是相當重要的，對於程序員而言，bug永遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！

第六個步驟是測試

測試有很多種：

按照測試執行方，可以分為內部測試和外部測試

按照測試范圍，可以分為模塊測試和整體聯調

按照測試條件，可以分為正常操作情況測試和異常情況測試

按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試

以上都很好理解，不再解釋。

總之，測試同樣是項目研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外 部測試都是正常的，因為永遠都會又不可預料的問題存在。

完成測試後，完成驗收並完成最後的一些幫助文檔，整體項目才算告一段落，當然日後少 不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，知道這個軟體被徹底淘汰為止。

寫這些步驟算不上賣弄什麼，因為實話講我手邊是一本《軟體工程》，在大學里這是計算機專業的必修課程，但是我知道很多程序員似乎從來都只是熱衷於什麼《30天精通VC》之類的，他們有些和我一樣游擊隊出身，沒有正規學過這個專業，還有一些則早就在混夠學 分後就把這些真正有用的東西還給了老師。

網上現在也很浮躁，一些coding fans亂嚷嚷，混淆視聽，實際上真正的技術專家很少在網上亂發帖子的，如筆者這樣不知天高地厚的，其實實在是算不上什麼高手，只不過看不慣這種對技術，對程序員的誤解和胡說，只好挺身而出，做撥亂反正之言，也希望那些還 沉迷於一些錯誤人士的coding fans們能認真想想，走到正途上，畢竟那些聰明的頭腦還 遠遠沒有發揮應有的價值。