程序員如何開發新業務

1. 一個java程序員剛進公司，如何適應企業開發

上司叫你幹嘛就幹嘛，別偷懶。事情做完了去找事情做，別乾等著。
不需要去考慮現在做的事情 有沒有意思之類的。剛進工作的人，不是考慮這些的時候。
過了幾年就知道 什麼才是重要的了

2. 如何讓程序員不斷開發或完善網站的功能

剛剛看到你的提問，我們算是同病相憐的人，我們公司也在運營一個門戶站——山東創業網，www.sdchuangye.com。個人認為，一個成功的站長不在於功能的強大，而在於你的盈利模式和運營思維，當然完善的功能是實現這些的基礎和媒介！對於開發新功能，關鍵在於你們團隊要先決策出新的模式，是否可實現，是否能夠帶來效益，同時要盡可能的讓技術參與其中，咨詢他們是否具有可實現性，讓他們主動的去改進程序。對於薪金方面，公開，公平，公正就OK！

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

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

4. 做C和C++開發的程序員怎麼能快速提高自己的業務能力

多做項目，多思考，看別人的業務代碼，這是唯一的辦法

5. 怎麼樣開發一個軟體

一般而言開發一款軟體，大致需要這三個大模塊：需求分析、代碼編寫、軟體測試。

• 首先，分析用戶需求，進行客戶調研。

這個過程是開發一款軟體的關鍵性步驟，需要准確把握用戶的需求。若需求不夠明確。那麼後期的工作都將白費。因此在這階段，需要多與用戶溝通，認真分析用戶的需求，將各個功能合理劃分，最終才能開發出一款符合用戶需求的軟體。

開發一款軟體，在開發過程中大致劃分為以上這些步驟。每個階段都是在上一個階段的基礎上完成的，這些步驟是不可逆的。第一階段的需求分析是開發軟體的重中之重，相當於地基，所以相對耗時較長。

6. 程序員可以如何選擇發展方向

絕大多數程序員最終的職業目標可能都是CTO，做到CEO的人估計會比較少，也有一少部分人自己去創業去當老闆，也有部分人說我轉行去做業務 了，對於當老闆的人畢竟是少數，對於轉行的人來說，都不在這行做了，自然沒什麼好說的了。一般來說，程序員的發展基本上都會經歷這么幾條路徑。程序員-系 統分析員-架構師-技術經理-CTO，程序員-項目組長-項目經理-項目總監-CTO，程序員-產品設計師-產品經理-CTO.
當然這只是一個大致的路徑，不是所有程序員都必需要這么經歷的，有些人可能跳過其中的一些步驟，也可能有些人會把中間的很多職位都做了。而最終做到 CTO的程序員，也是非常少的一部分，原因很簡單，這個世界上不許要那麼多的CTO和CXO.
也就是說，許多的程序員最終可能是做技術經理、項目經理或者項目總監之類的，那麼到底我們職業生涯要選擇哪一種呢？我覺得這個問題沒有一個統一的答 案，因為每個人的性格不一樣，際遇也不一樣，就像你從小希望當貪官，可是命運卻偏偏讓你做了一個程序員。所以應該根據你的興趣、性格與際遇選擇一條道路， 比如說你正好有機會帶一個項目，而你又不是很討厭項目經理這個位置，那麼你就可以選擇向項目經理方向發展。
實際上很多時候，國內並沒有明確的技術經理、項目經理、產品經理之分，在許多的公司里，他們經常是由一個人承擔。在外包公司里，通常會有項目經理和 系統分析員（也可能是技術經理）。在一些非IT公司里，可能會有部門經理，而做自己產品的公司可能會分得比較詳細一些。我大致說一下這三個職位的區別，讓 正在徘徊的程序員有一個大致的了解。
項目經理是項目的直接負責人，這個角色相當於一個中間介面，不管是團隊成員還是需求方（客戶），或者是上級領導，有事都直接找他，所以這個職位著重 於管理與溝通。一般來說，項目經理的工作重點在同客戶溝通需求、項目進度的把控、團隊的溝通方面，有些公司也會需要項目經理承擔團隊建設的工作，不過貌似 很多國內公司都忽略了團隊建設這個工作了。對於項目經理來說，重點會要求溝通能力、協調能力、危機把控能力、執行力、團隊管理能力，著重於溝通、管理與計 劃。當然也有些公司還要求項目經歷要參與招標談判，這就要求項目經理有一定的商務談判能力。
技術經理有時候也可能叫系統分析員，一些小公司可能會整個公司或者部門有一個技術經理。技術經理承擔的角色主要是系統分析、架構搭建、系統構建、代 碼走查等工作，如果說項目經理是總統，那麼技術經理就是總理。當然不是所有公司都是這樣的，有些公司項目經理是不管技術團隊的，只做需求、進度和同客戶溝 通，那麼這個時候的項目經理就好像工廠里的跟單人員了，這種情況在外包公司比較多。對於技術經理來說，著重於技術方面，你需要知道某種功能用哪些技術合 適，需要知道某項功能需要多長的開發時間等。同時，技術經理也應該承擔提高團隊整體技術水平的工作。
產品經理這個職位一般在有自己產品（不管是軟體還是網站產品）的公司比較常見，產品經理主要會負責產品的設計、產品的改良等工作。需要注意的是，產 品設計與設計師是兩個不一樣的工作，產品設計主要會從用戶體驗、業務需要等層面去設計產品，而設計師更多是從用戶的視覺上去做。產品經理應該是最懂業務的 人，比如說你在設計一個微博的產品，就要求你對微博這個東西非常熟悉，從用戶習慣、用戶體驗、公司的發展戰略上去設計這個產品，還要對比同類產品會有什麼 優勢等等。
不管是項目經理還是技術經理與產品經理，都要求要熟悉業務，業務是需求的來源，沒有不談業務的技術，所以不管你從哪個方向發展，都要求對業務熟悉。 產品經理要求對業務最熟悉，項目經理次之，技術經理排最後。對於程序員來說，剛開始工作的前幾年可以埋頭扎到技術裡面，一般這個時間在2-3年的時間，然 後就應該多關注業務了。這個業務不一定是指某個具體的業務，因為具體的業務的范圍太少，而且也需要機遇。
我見過許多的程序員，他們是做Web開發的，但對互聯網很不熟悉，對於互聯網流行的趨勢基本上不聞不問。不知道現在大家都在使用微博，也不知道SNS，也 可能從不使用網銀。我覺得這樣很不好，程序員應該多多去關注互聯網的發展，多多去玩一些新的網站。

7. 程序員如何才能成為獨立開發者

當你有了知識體系之後，遇到和你知識體系對應的場景相關的問題，就可以快速找到相關的知識，系統的分析問題，最終解決問題。

你看，是否擁有知識體系，導致了熟練開發者和普通開發者的一個非常重要的區別：熟練開發者能夠獨立負責一個模塊或子系統的設計和開發工作，擁有分析問題、解決問題的能力和任務分解的能力，可以分配任務給普通開發者。

進階修煉方向

好啦，從技術水平的角度講，普通開發者和熟練開發者的區別就在於：普通開發者的知識不成體系，而熟練開發者構建了與某個應用場景相關的知識體系。

這樣看來，普通開發者要想進階，方向就非常明確了：構建自己的知識體系。

那麼，怎麼構建知識體系呢？先參考我的另一篇文章：構建知識圖譜，讓自己更值錢。如果後續有機會，我會重構一篇新的文章，再聊聊構建知識體系這個話題。

8. 軟體開發，如何開發速度最快

當我們考慮速度的時候，代碼的價格和質量會扮演很重要的角色。同時，在很多軟體開發項目中，為了更快完成開發任務，會去走很多的捷徑。
變得更快更成功
現在，我想要給你一些關於如何成為開發速度更快，並且更成功的程序員的靈感。
讓我們開始吧！
多數的時間並沒花在編碼上
當我們深入的去分析程序員的時間分配，會發現，其實程序員們並未將大部分時間花在編碼上，事實上，花在其它事情上的時間有可能更多。
以下我列舉了很多會花費時間的事情：
1 重構和修改bug；
2 寫一些實驗性的代碼用於驗證你的想法；
3 google你所面對的問題；
4 編寫測試測試並且測試它們
多寫代碼會使你變得更迅速
編程是有很多的套路。熟悉套路的過程被稱為練習。
多練習會使得你：
1 更快速的找到思路；
2 更快速的閱讀
3 更快速的把你所遇到的問題串聯起來；
4 更快速的尋找到解決方案；
多練習，會讓你稱為開發速度更快的程序員。
集中精力（譯者註： 多進行深度思考）
編程過程里，會有很多的時間花費在思考上。作為真正程序員的我們，會更傾向於深度思考（作者用的詞是over-think，意思是寧可想得過度），同時還會花費很多時間去擔心和思考問題和解決方案。

這是一個非常重要的事情。開始編程後，電子郵件，Slack群聊，Skype，Facebook，Twitter都需要放在第二位。
無論你是否相信，一旦這些軟體彈出提醒信息的時候，你就會非常難以集中精力在更重要的事情上了。
其實只需要2.8秒，你的精力就分散了。
因此，你必須在編程時，排除掉那些有可能幹擾到你的事情，讓自己的精力更加的集中
使用正確的工具
如果你像我的話，你可能會非常享受使用新的測試工具和軟體。有很多工具，在編程的過程中，都會在某一個方面起到特別好的作用。
只不過，雖然這些工具會讓你覺得很酷，可必須意識到，它也有可能會使你精力分散，降低效率。
為自己定製好一套高效的工具鏈並不是一件容易的事情。從產生想法，到做出原型，再到能上線運行的系統。在我之前的blog里，我曾經展示過一套高效的web開發工具，你可以嘗試使用它們去實現你的想法。
慢下來
我知道你可能會想：慢下來是怎麼使我成為更快的程序員的？這不是矛盾嗎？
不，接下來我會慢慢解釋給你聽。
讓我們花上一秒鍾時間去想想我們正在嘗試得到達成怎樣的目標
1 作為一個程序員，你會希望能發現發揮出自己的能力；
2 你像要對項目的整體框架有一個清晰的認識，知道自己會怎麼一步一步實現它們以及每一步都要去做什麼；
3 你希望有一種直覺，當發現項目走入錯誤方向時，你可以及時的發現它們
有了這種想法，你可能就會明白我的意思了。慢下來會幫助你理清思路，始終保持在正確的方向上前行。
下面是一些小技巧，可以使你變得從容不迫：
1 充足的睡眠；
2 時不時換個工作地點試試。創意有可能會隨著工作地點變換，而迸發出來。沒准你走出辦公室，隨意的在外邊散散步或是去咖啡廳坐一坐，就會使你產生很多的新想法；
3 多傾聽。當事情特別煩雜的時候， 傾聽其實並不會有助於你冷靜下來，但是同樣有可能會激發起你的靈感來。
尾聲
還有很多的東西有助於你加快開發速度，但是我沒有列舉在這里。你只需要明白，除了編程以外，程序員還會花費很多時間在許多其它的事情上。
總而言之，在stackoverflow，Quora等等上還有許多關於如何加快你的編碼速度的討論。
最後，我想引用 Jeff Atwood的一些話作為結束：
1 停止空談理論；
2 多寫代碼；
3 總結過去的錯誤；

9. 程序員提升開發技術需要注意哪些

一、不提升非技術技能
我們認為非技術技能是項目成功的主要因素。這些非技術技能也可以稱之為「軟技能」，總體上來說，它已經被公司證明為能夠駕馭企業和客戶之間的長期商業關系，因此也能決定公司的成長發展路徑。一些關鍵的軟技能指標包括：

a.紀律——這是最重要的特徵之一，缺乏紀律，最終會讓這個開發團隊在開發能力上「缺乏自信」。解決這一問題的矯正方法就是每天制定詳細的to-do清單：兌現你的承諾、完成你開始做的事情、避免多重任務，因為這些往往會讓你的生活產生混亂。
b.顧客的聲音——不把客戶置於決策的核心地位只會跟你們業務的原始目的相沖突。如果客戶不高興，即使你擁有世界上一流的專業知識和資源也不會起什麼作用。保持符合客戶期望的解決方案、及時交付才能體現出項目的真正價值。
c.溝通——尤其是當客戶和供應商並不在同一地點的時候，明確而及時的溝通是填補服務空白的極好措施。主要集中在這三個方面你就能克服問題——進行主題討論、清晰表達、乾脆簡潔。
d.了解需求——在整個開發生命周期過程中，決定成功和失敗的之間的一個至關重要的區別將會給人留下深刻的印象。通過最初的頭腦風暴法了解問題狀態，以及後續的交貨程序，這其中都要和客戶完美配合。只有這樣，客戶才會贊賞你的工作，給你好評。
二、對編碼不理智
古人雲：善泅者溺，善騎者墮。但估計絕大多數 的程序員都認為自己的編程技術絕對的牛。而同樣真實的是，每一個代碼，讓不同的程序員去實現的話都會不可避免地發現它所存在的缺陷。所以說，只有通過在一 個項目上的合作，程序員之間必然有的摩擦才能證明誰是最好的。健康的競爭是好事，但它不應該成為一個本來可以成功的項目的負擔。

另一個創意阻礙是無法將預定義的模板使用在對你有利的開發項目里。幾乎所有的編程語言有一個很好的在線 /內置的代碼片段存儲庫，可以修補代碼，防止重新編程。然而，如果因為不理解需求或缺乏接觸各種可用庫/模板的話，這就意味著程序員最終會無意間將一開始 就創建的代碼付之東流。這不僅增加了開發時間，也提高了總體成本。另外一點就是，發布了的代碼已經經過了質量檢測，所以只有將它用作模板才能發揮它更大的 價值。
三、不一定什麼都要被理解
如果你是剛調到這個團隊來的編程人員，對於手頭的工作並不是很熟悉，那該怎麼辦?肯定是先看一些前任留下來的工作計劃，要是他寫的詳細倒也沒什麼，如果寫的不詳細，估計會讓你更加的撓頭。
因此，推己及人，在需要交代的工作上，最好是把任務寫的盡可能的詳細。這么做也是非常現實的原因：能夠把編程問題解決掉，最好是保證使用解釋性的語言和英語發音來表示變數。一些基本的指針可以讓你的程序更容易被理解，包括：
a.把所有參數、引用、方法和變數名稱盡可能接近英語表達。保持文件名簡短但有助於理解的功能。
b.使用++包裝文字是一個好辦法，能讓代碼和注釋更加清晰。
c.將編寫的程序保持在一個連續的流程上，尤其是在使用OOP基礎上的語言：C#、C 和 C++。
d.對於不同的代碼塊使用不同的描述名稱。
四、不使用經過驗證的工具和技術
程序員的好壞從他使用的編程工具和調試工具上就能看出。在異常情況的跟蹤上，下面就是程序員經常會出現的常見錯誤。
對一些可能會對其它代碼有影響的常見案例進行捕捉，處理這些比較常見的異常情況(而不是特殊的異常)意味著無意中除除掉了會抑制整個程序的殘留部分，因此並不會影響他人的代碼。
也許程序員可能帶有惡意的意圖來捕捉所有的異常情況，但即使是捕捉到了也不實施採取措施，這就是常說的「虛假安全閥」，這種異常處理手段是對整個軟體的穩定和安全的一種妥協方式。
五、較差的控製版本
在任何涉及多個團隊的項目里，當談到版本控制的時候不去介紹使用最佳實踐都是一個十足的罪過。版本控制的目的是確保由一個人執行的編輯或修訂不去影響另一個人的工作。
版本控制不僅有助於將由兩個或兩個以上的程序員的編輯工作合並到一起，還有助於跟蹤程序的更改歷史。所以說，任何開發團隊都應該做一些好的改進措施以確保強大的版本控制，這其中就包括：
為每個解決方案創建一個「邏輯單元」
給解決方案制定描述性的名稱
確保你所使用的都是最先進的文件
頻繁的向團隊分享你所做的各種改變
六、擁有最新信息的個人代表不了團隊
這是相對有趣的一點，所有的商業產品都想要以自身的敏捷技術和產品文化來給客戶留下深刻的印象，但是現 實中很少有廠商會花時間去磨練他們員工在介紹產品特點上的技能。許多公司只是簡單地提供了一些基本的培訓，並且抱希望與員工在真實的日常項目里學到更多的 技能。所以部門經理和項目的直接領導可以通過以下兩個辦法來提高員工的業績：
一旦有新員工加入，就立刻強制安排他參加專業培訓，讓他知道他的角色是用來干什麼的，盡早產生創造力。例如一個測試人與加入之後，就應該向他介紹編程的理念，之後將培訓重點放到測試實踐上，而不是繼續闡述編程的重要性。
現階段的技術的進化程度比以往任何時候都要快，，所以要記住，定期培訓是必不可少的，這是在給團隊創造價值。例如一個Web 設計師需要知道響應式設計，提供給設計師大量的用戶日常使用的移動設備的不斷擴張的樣品，希望他們能獲得靈感。
七、不恰當的測試
測試作為整個系統開發生命周期(Systems Development Life Cycle，簡稱SDLC)的重要一個要素，通常不需要開發團隊給出太驚人的結果。但是如果在測試環節沒有付出恰當的、相應的努力的話，這是說不過去的。 下面的一些方法或許對你的測試團隊有用，至少在你們交付產品的時候能夠給用戶一個好的交代。
單元測試
實物模型
綜合測試
八、注意安全漏洞
有的時候在軟體開發過程中，就會遇見如下這樣的安全漏洞：

A、不同組件之間意想不到的交互作用：a、輸入不正確的驗證信息;b、SQL資料隱碼攻擊;c、跨網站指令碼;d、命令植入攻擊;e、跨站請求偽造(CSRF);
B、難以實施的資源管理，包括：a、不尊重可用內存緩沖區;b、對外控制;c、使用有潛在危險的功能;
九、和客戶交流
最初的合同簽訂後，開發公司通常會忘記每天與客戶進行產品上的信息交互，以至於在交貨的時候還需要進行升級。兩大關鍵的交流點可以讓你和客戶保持更好的、更長的關系：
在客戶開問之前，開發方應該和客戶進行交流溝通。
和客戶保持周期性的交流。
十、避免標准實踐面臨的迫在眉睫的最後期限
通 常情況下項目都會遇到進度延誤的現象。然而，這不是說你有理由去偷工減料或者是在開發或測試階段耍花招，未經測試的模塊絕對是一個隱患，會讓你的開發團隊 名譽受損的。一個更好的方法來管理延遲是提前告知客戶並且積極執行延遲計劃。只要延期的理由是有效的，客戶應該會理解，也會給你額外的時間來解決這個問 題。