作為獨立開發者，有哪些可以分享的經驗？

11-16

獨立開發者或個人開發者，即 independent developer 或 indie developer. 也就是獨立軟體或獨立遊戲的開發商。

謝邀。

我曾經有9年做獨立開發者，開發shareware，主要銷往歐美，客戶中不乏五角大樓，美國海軍學院，微軟，惠普，美國眾多州政府等等。（很可能有人覺得我在吹牛，完全理解：）。我的軟體網站有幾個，有個知道人比較多的，在Web Log Analyzer）。

後來有了孩子後就出來工作了，以CTO身份參加過一次移動互聯網創業。現在因為家人身體原因，離開了北京在珠海工作，搬家過程可參見搬家珠海。

下面分享一下做獨立開發者的經驗，想到哪裡就寫到哪裡，缺乏條理，見諒：

不要總做外包，要有自己的產品
外包無論價格多高都還是苦力錢，要形成自己的產品。
每年給自己制定學習目標和計劃
做獨立開發者後，就失去了和同事們交流學習的機會，而作為Programmer不停的學習新技術是必須的，所以這方面要特別加強。
工作計劃可以和大眾的節奏錯開
做獨立開發者最大的好處就是時間的自由。很多地方，例如美術館，電影，旅遊勝地，在周末人滿為患，周一到周五則幾乎空無一人。所以我常常是周末工作，周一到周五抽一到兩天休息。做獨立開發者的時候，黃金周是絕對不出去玩的，都是在家工作，旅遊淡季的時候出去玩。
盡量購買或外包一些非核心工作
現在網上有很多成熟的各種服務，比如template monster的網站模板，可以讓你簡單填寫內容就能搞出一個很漂亮的網站。這種工作不需要自己做，盡量外包或直接購買。自己做最核心的東西。但這個核心並不等同於核心技術，而是你的核心競爭力。當你的核心能力是整合能力的時候，甚至所謂的核心技術都可以外包。
要養成規律的生活習慣
如果生活沒規律，工作也就缺乏計劃性，那工作的拖延不可避免，拖延多了，人的狀態，心氣都會下降，最後形成惡性循環
養成體育鍛煉的習慣
體育鍛煉一個是有助於保持身體健康外，對你保持心理健康，保持積極的心態很有幫助。我在做獨立開發者期間，養成了長跑的習慣，那9年的北京馬拉松除了有次因為在國外沒能參加外，其他全參加了。
要重視社交生活
對這9年的生活非常滿意，如果要說有什麼不足的話，就是開始沒太重視社交，後來才開始重視。如果有機會重新來過，一定會更積極的參加社交活動。我這個人原先就比較孤僻，自己一個人工作後，就更有點離群索居了，和客戶和朋友都是靠email，IM聯繫。雖然經常去旅遊，甚至一年有半年在路上度過，但大多是自己一個人背包到處轉。過了幾年才意識到問題，感覺自己脫離開社會太遠了，才開始在親友幫助下重新開始積极參加各種社交活動。
關於社交活動有幾個建議：

多參加積極向上的群體的活動
在北京的時候，長期參加了陽光志願者，後海龍舟隊，古逸讀書會的活動。這些組織，尤其是陽光志願者，人們都很有正能量，又都很友善，認識了不少很好的朋友，他們是我這輩子最好的財富。和積極向上的人多交流有助於自己心態的調整。
覺得不擅長溝通可以參加培訓班
我不擅長與人當面溝通，於是就總是有意無意躲避與人溝通，結果越來越糟糕，做獨立開發者後就更愈演愈烈。後來聽從朋友的建議，參加了一個關於如何溝通的培訓班，確實有效果，關鍵是從此樹立了不懼怕當面溝通，重視溝通，積極溝通的態度
建立自己的Network（應該叫關係網，但中文的這個詞有點貶義）
不要以為個人開發者不需要Network，其實應該是更需要，這個道理我今年才明白。

多參加技術聚會
一個對學習新技術有幫助，還有就是能認識一些朋友，有助於拓展自己的交際圈。看樓主是深圳的，我去參加過深圳的Startup Grind認識了不少有趣的人，推薦。

排名第一的哥們說的很好，基本也是這個感觸，謝謝了！ @崔英傑。獨立開發2年以來比較深刻的有幾點：

1 不要試圖做所有的事。作為獨立開發人一般都具有多面手的能力或者有自己搞定所有工作的傾向。但是時間長了就會發現這樣會造成很大的時間浪費，很容易在某個工作面（尤其是會但是不太擅長的方面）的小細節卡住，而最後又發現這一個小點其實對整個工作沒有太大的提升。我後來的方法就是把跨專業的工作（比如你專長是開發，但是也會用ps做點界面）控制在1-2個小時可以完成的範圍，當做是工作之餘的休息。而超過這個層面的工作就全部外包。

2 控制期望。獨立產品本身就是自己理想化的實現，所以很容易糾纏於一些過於理想的東西。就我個人來說是做手機遊戲開發，第一個作品最終沒有開發完成。因為在設計之初添加了太多的東西遠遠超過獨立開發所能承受的工作量。

3 堅持但是設置底線。獨立產品的開發周期一般比較長（動輒以年計算）。隨著時間的增加一些聲音會隨之而來，比如朋友會問：開發到什麼程度了？怎麼周期這麼長？這麼長期的投入是不是值得？久而久之你也會對自己產生疑問，這個時候唯有信念可以支撐你走下去。同樣的，各方面的聲音很可能是客觀而務實的，那麼在這種情況下就需要為自己設置底線，到底什麼是不能越過的？給自己設置一個底線非常重要，可以是時間，比如投入2年時間。也可以是金錢，比如計劃投入50w。超過自己的底線也許就真是該松一下的時候了。舉個例子：拍《賽德克巴萊》的導演魏德聖一直想拍這個片子，但是最初的嘗試在耗盡了130w的集資之後還是忍痛凍結了計劃。後來在拍了《海角七號》後無論是能力還是資金都有了更好的準備才拍出了《賽德克巴萊》。所以堅持很重要，但是了解自己能堅持到什麼程度在某種意義上說更為重要，因為那是你韌性的表現。

4 尋找同伴 相信我，找到同行的人會讓你的計劃更容易被實現，也能讓你的視野更寬闊一些。

有一段時間，我的公司僅剩自己一個人。那個階段也算是獨立開發者了。隨便說點感悟。

要了解自己的能力範圍，開發效率，作息習慣。制定開發計劃時要嚴格以自己過去3個月甚至6個月的平均效率做預估。千萬不要對自己的實力過於樂觀，以自己的巔峰效率去做計劃。只有在未來的3個月表現好了，才有資格制定3個月後的樂觀計劃。
做完一件事，再做下一件。看完一本書，再看下一本。同性質的事情絕對不要同時做。
Just Do It. 這都是戰勝拖延的老生常談了，馬上開始，哪怕是動手5分鐘，都比光用腦子想什麼都不幹強。
將工作內容劃分成研發部分和開發部分。研發部分指的是完成的時間無法確定，突然會被一個 Bug 卡住幾天的類型。而開發部分則是只要投入時間就肯定有成果，自己能像流水線工人一樣把活幹完的。研發部分佔比要小於30%。
自己創造一些方法或者規則。因為是原創，所以你會很投入地去執行它們。
- 我曾經創造過一些規則：
  - 寫代碼前先在腦海里構建。靜坐，冥想，在腦子裡仔細構建每個模塊每個類，模擬程序執行的過程，在腦子裡運行一遍。確認 OK 了才開始動手開發。這種方法很費腦子，相當累，後來我還是藉助思維導圖去做這件事。
  - 每次刷知乎，都必須先留下一個回答，然後再刷別的。（這個是目前正在乾的事）
增強與其它人的聯繫
- 獨立開發者社交的機會不多，不像上班那樣可以被動地加入到集體里。人本來就是社群性動物，必須處於群體中才能發揮並提升自己的價值。
- 要多跟人產生交流反饋，有些人很厭惡現實中的社交，那就退而求之換成線上社交，多上社交網站。須注意的是單方面接收信息是沒用的，要多與人互動交流。
- 一款產品的成功，衡量的標準無非是對他人造成影響的深度或者廣度。想要擴大影響力，先得把聯繫建立起來。在知乎上吸幾w 粉，發一條微博或 Twitter 會被轉發多次，開發的產品影響了多少人，這些現象都可以反過來成就你的成功。
成為獨立開發者之後，如果感覺時間上還是不自由，那肯定是錢還沒賺到位。所以，趕緊賺錢最重要，這是你每天工作的首要標準。
獨立開發者跟上班、創業沒有什麼區別，都是生活方式的一種，有得也會有失，別把自己想得太特殊，平凡的心態最好。
以上。

謝邀
作為獨立開發者來說，被開發過程虐的死去活來是必須的，非自己專業的難題也是家常便飯。
不過我認為能克服的都不是問題，甚至解決問題的方法我覺得都不太重要，因為每個人有自己的行事風格。會成為問題的只有那些不能解決，讓你徹底被擊垮的，羅列一些你感受一下。

1. 餓死。
非常實際的問題，程序員需要麵包。當你預期自己的存款夠用一年，而實際上大半年過去了還沒完成/上一個產品沒賣出錢/開發需要的開支遠大於預算，你是要繼續開發，還是找份工作？

2. 社會地位
很多獨立開發者沒法得到家人/朋友/親戚的認可，和NEET划上了等號。這種情況可能會一直持續到你成功之前。「沒問題，我不在乎別人的眼光！」是的，但是你的家人可能在乎。

3. 社交
成為獨立開發者，你的時間會變得非常寶貴，因為要處理很多的事情。相應的，用於社交的時間會顯著減少，然後你會發現很多朋友日漸疏遠。一年、兩年，周圍的人都離你而去，只剩下孤身奮鬥的你。

4. 焦慮
獨立開發的過程中，焦慮是幾乎每個我認識的人都碰到的。因為自己全盤掌握了所有細節，每個暫時難以解決的問題都會變成一把劍懸在你頭上，讓你食不下咽，夜不能寐。隨之而來的是胃炎帶來的消瘦、失眠帶來的消極，如果你工作太久得了前列腺炎，更糟糕，你連坐下來好好寫代碼的福利都失去了。「沒問題，我會堅持運動！」嗯，也許你會在運動完後想著要是剛剛那一小時沒跑步，用來寫代碼就好了……

5. 人手
雖然是獨立開發者，但是很多時候你還是需要小夥伴來替你處理美術/音樂/策劃/xxx...、
「沒問題，我能外包出去」是啦，現在外包行業那麼發達，不過我舉個栗子——外包美術出去，需要一個美監和對方溝通進度吧？外包音樂出去，需要寫需求文檔吧？什麼？你連策劃案都要外包？o_O...
這時候你會衷心覺得，要是有多一個人幫忙就好啦！一起創業士氣倍兒棒！
可惜現實是，在你成功之前，獨立開發者這個頭銜幾乎不能為你吸引來任何強力幫手→_→...

湊了5條感覺我回答這個問題的時候也是蠻拼的...→_→
我不會勸你去做/不做獨立開發者，你要自己考慮好自己的前途。
一旦決定就果斷去做，你會發現你的選擇永遠是對的

好像很少有人談及華人獨立開發者的海外生存情況，我來談談吧。我說的獨立開發者是被其他公司以自雇合同形式工作，不是靠開發自己產品生存。
獨立開發者在歐美國家非常流行，我是一個全棧工程師，曾在倫敦和紐約從事freelancer開發工作(現全職於startup)
獨立開發者優勢是報稅自由，我經歷的倫敦日薪大約300-450磅，紐約日薪500美金，可能有人更高，但我基本平均。報稅上你需要一個註冊快計師，然後一家自己的公司，我公司開在倫敦，公司資本1英磅。接下來獵頭會與你接觸幫你安排公司，一般合同為3個月起，如果工作順利，項目基本都會繼約，認識的朋友里有直接一家公司合同形式僱傭2年以上的。
你的收入是以分紅形式給自己，好處是美英的公司稅都低於個人所得稅，所以稅收上是優惠的，缺點是有的公司不定時發工資，有的甚至3個月一結賬，如果銀行里錢緊張，是比較難受的。
在做獨立開發者的時候你還會碰到那種全球到處飛的開發者，多見於澳洲，與歐美之間，他們的目的是為了避稅，因為你可以享受各地的免稅區域，具體可以諮詢你的報稅師。
工作方面，前台工作較多，但全棧能力很重要，因為公司很可能無人懂技術，需要你從伺服器到維護各方面的控制
另外你的假期是沒有工資的!你得要自己購買各種商業保險，公司不會給你買。還有什麼，想到再說好了。

-------
來回答些問題
每天工作沒啥區別,但合同工的notice period一般只有1天到1周,也就是你活乾的不好,明天可能就讓你滾蛋,我見過無數來3天就滾蛋的朋友,最牛一次上午來,下午公司就讓他走了,因為他坦誠一個技術不會.但我感覺第一個月認真些干,問你行不行都說行,一般都能撐下去,因為僱傭你的一般不是技術類公司,他們只要看你做出的成果.

工作類型大量為無超技術含量的前台工作,CSS/HTML/JS最多,java/C#/python/ruby各種活都要能幹,手機android,iso都會些最好,行的話最好還能來個design,另外是各種做電商網站/企業網站的居多,或者有的項目吃緊人手不夠,你會被叫去干.有時候買域名,買伺服器的事都要你來決定,反正雜,就是重複重複,學不到什麼東西

每年的話要報個稅,給自己放假是沒有薪水的,放一周假感覺自己少賺了幾千磅,都會感覺不太爽.
倫敦或紐約項目的話太多了,如果linkedin上獵頭多,一個項目快結束在linkedin上喊一聲有活嗎,電話立即被打爆,不用太操心..一般只有你干到太累想放假,沒有你想乾沒活乾的事發生.

謝邀（更新於 2017 年）。

在我接受邀請的時候，我真正獨立製作的應用應該只有 Look — Photo is Reminder Todo on the App Store on iTunes（鏈接的應用現已下架，新版本見下文）。

Look 是在我大學申請前的一個暑假完成的。當時上午去上課準備學校申請，下午回家開始寫代碼，整個星期都沒有休息。我記得大概是早上七點左右起床，中午十二點左右吃完飯回來幹活，一直寫到晚上十一二點。如果看 GitHub 的泡泡圖的話，就能看到每天下午到夜裡的區間都布滿了大大小小的泡泡。

除了要早起很不爽之外，我還是很喜歡當時那樣的生活的。

自己做應用時候，是可以真正自己隨心所欲的。除了可以做各種新奇大膽的實驗，還可以包容自己各種各樣的毛病。因為我不以此為生，所以我不需要強制用戶給我評分，不需要記錄用戶習慣活躍度，不需要添加廣告，不需要推廣…

我也不會賺很多錢，其實，成本都收不回來的。只是因為我真的很喜歡啊。

一個月前，我完全重寫了 Look，現在新的版本在這裡：Look 備忘錄 2 on the App Store

供獨立遊戲開發者參考的2D美工教程（一）

供獨立遊戲開發者參考的2D美工教程（二）

我就mark一個，你們隨意

謝邀嚴格的說作為獨立遊戲開發者，不算嚴格意義上的「獨立開發」（only one）自認為沒有這個實力，個人認為最重要的：愛與堅持！
作為完全個人開發角度來說個人不是很贊同，單兵作戰不是本行業趨勢，精兵團隊才是目標。
這裡只說一下單兵開發的可發揮領域。
（1）原型實驗：這個我一直在玩我自己發明稱為40小時（一周工作日）極限設計的鍛煉
就是只能用40個小時來編碼，快速迭代，做出一個小遊戲：）非常鍛煉對遊戲設計的理解
（2）技術點深入：可以把一個技術點做到極致，我一個朋友就是不斷在優化光線跟蹤演算法（神人）

個人不建議報有太大商業目的的完全獨立遊戲開發，還是有執行力的小夥伴最重要。

我現在是一名快大二的學生，但是我也在做Android App開發，8月15日我把我的應用提交到了360市場，審核通過之後就在應用商店上線了。這款App是我一個人做的，第一次做，沒有什麼經驗，走了很多彎路。不是很權威的敘說，只是想分享一下自己的經歷。

之所以想做這個App最初也是因為自己有這個需求。上學的時候無論是在圖書館自習還是在宿舍寫代碼都會常常犯困，初高中的學霸生活已經使我對咖啡茶這類提神的藥物免疫了，趴在桌子上小睡一會兒反而會很有精神。記得原來看到卡耐基的書中也曾說，小睡一會兒可以讓人有精神，工作得更好。但是上鬧鐘是一個麻煩的事，特別是在及其困的狀態下，而且手機上個鬧鐘還要撥那麼多的鍵。我覺得很麻煩，我就在想我為什麼不能撥動一個開關就開啟鬧鐘讓它10分鐘之後提醒我呢？有時在圖書館上自習，假如用自帶的鬧鐘即使在靜音的情況下也會發出聲音，這在圖書館顯然很不好。那時Android才學一點，但我就有了做這個App的想法。於是在暑假中，我花了差不多15天的時間做了這麼個簡單但卻實用的App(趴會兒【原小睡鬧鐘】：小睡鬧鐘_360手機助手）

最開始的時候軟體做得很複雜，從小睡拓展開的就是稍後多少時間提醒，我又認識到只做這個太簡單了，於是又加了定時的提醒。我知道，我的編程水平並不是很高，想做出好的產品就要在產品方面下功夫，讓用戶體驗好，讓App有一些人文的東西，於是我又加，加了比如三天洗一次澡啊，生日提醒什麼的。功能做得越多，我越迷茫，技術上的難度也越大。我有時又在想，我到底要做什麼的。我當時要做的那個東西，是一個定時提醒，一個ToDo提醒，一個變相的日曆，還是什麼？弄來弄去，不知道自己要做什麼了，整個App就是一個四不像。

之前我在知乎上看到過 @賈物體做的Look，我覺得圖片提醒這個idea很不錯，於是又在自己的App加上這個功能。可是越做越大的同時，也覺得這個App一點亮點都沒有，就是各種各樣亂七八糟的東西拼在一起。I hate it!我自己都不喜歡的東西，用戶會喜歡嗎？我沒法把一個自己都不喜歡的東西分享推薦給我的朋友。於是我想去看看Look到底做得怎麼樣，於是在網上查了資料，也在App Store下了這個App(我開發android，但是平時用iPhone)啟發我的是，在Look的知乎專欄里有人評論這個圖片的Todo能不能代替原來的Any.do teambition等。作者說不會，但是Look可以做一個補充。我也在反思，我完全沒必要做一個與時間有關的功能全部集成在一個App裡面，作為個人開發者那樣是不適合的。所以我覺得，作為個人開發者，應該 抓住一個小的需求，把它做到最好！我最初為什麼想做這個App?為了趴桌上睡覺方便一些，那我做其他亂七八糟的幹嘛。於是我只做了一個功能，那就是小睡，做到最簡單，撥動一個開關就可以開啟小睡。如果用戶想用ToDo應用可以下Any.Do，幾天洗一次澡完全可以通過日曆設置重複提醒。就這樣，走了很多彎路之後，我回歸正途，把亂七八糟的功能全部砍掉，只留下一個功能「趴會兒之後提醒」
作為個人開發我覺得很重要的就是 藉助開源 GitHub CSDN上面都有很多開源的代碼，這些代碼是大家用來學習交流的，而很多時候自己開發的App的一些功能完全可以從開源項目移植過來。這時，你就不是一個人在開發，是全世界最優秀的工程師和你一起開發。這也大大減少了工作的強度和難度。
勞逸結合
我曾經一天除了吃飯就是寫代碼，結果寫了一整天，一點進展都沒有，問題反而越來越多，就像毛線團越來越亂。晚上倒頭就睡，第二天早上一起又繼續寫，打算再寫個一整天。但是同前一天，完全沒有進展，反而越來越煩躁，最後索性不寫了！我去看了一部電影，陳木勝導演的《掃毒》，還看得挺感動的。看完之後歇息了一會兒又開始寫代碼，！！！原來錯綜複雜的問題突然找到了簡單的解法！所以以後每天我都會安排好時間，勞逸結合好。

我做了一個APP，我當然想把這個分享給和我有同樣需求的人，想著別人能用上自己做的軟體心裡都會不由地笑起來。於是我去了Android吧，用幾張截圖和一些文字介紹了自己的APP。我希望吧友們能夠用到我的軟體，同時能夠給我提一些意見。其實我對自己原來那個版本的APP挺滿意的，但是，沒想到吧友們提出了那麼多好的建議。我一想，對啊，我原來確實做得不怎麼好，界面也很粗糙。其實我最想不到的，大家可能會對這個APP產生誤解。我的本意是做這樣一個APP，當我工作學習累了，打開開關，趴桌子上睡一會兒，一會兒APP會提醒我。但是有的同學就理解成了早上貪睡時小睡一會兒（其實小睡本來也有這個意思）還有同學理解成了睡午覺的APP，說是不是20分鐘太少了，午睡30至40分鐘比較適合。

假如我不和用戶交流的話，我永遠不知道自己的不足，我也永遠不知道用戶會對產品有不同的理解。
所以我認為，開發者，即使是獨立開發者，做出來的東西是要給人用的。不能自己想當然地認為用戶怎麼怎麼樣，而應該多和用戶交流產品，多聽用戶的反饋意見，和用戶成為朋友，讓用戶和我們一起完善。我想之所以小米有很多發燒友也是因為小米尊重用戶，聽用戶意見，和用戶成為朋友。所以大家也願意提出自己的意見，成就更好的小米。我雖然是一個小的開發者，但我也相信小米的精神。

還有一點，也是吧友提到的。說我的手機上已經有了鬧鐘和計時器了，為什麼還要用這個APP呢？而我的回答是，這個簡單，只需要打開開關。而無論是鬧鐘還是計時器，都要設置好幾下，我自己覺得麻煩，特別是在特別困的狀態下就想直接趴著睡。
其實這個APP也不是什麼了不起，只是讓生活方便簡潔一些吧。

最後，感謝所有吧友和所有幫助過我的人，希望我的這個小APP能為大家生活帶來一點點簡便。

啊。。。是不是該說謝邀。我其實沒有太多經驗。而且我也就是自己做一點小項目，唯一一個賺錢的項目基本被我擱置了。
只有教訓：
絕不要對別人做做不到的承諾，工作給自己預留三倍以上的時間。至少按照我的經驗隨時可能開始頹廢／對新的東西著迷／因為單相思失眠一周。有一個項目擱置是我目前還很後悔的事情。。等我有時間了補上吧。
學適量的技術。。。沒必要搞太多。每個門類會一種就好。但要隨時學習，或者了解新東西。因為大浪淘沙。很難一藝橫行天下。
還有。。是我正在掙扎中的。。在開發方面經濟獨立。純軟體還好點。。。
再有。。其實人脈有時候比技術重要，真心的。當然前提是，你有足夠應付這些機會的能力。

A.教材上的知識
這部分內容來自計算機專業的課程教材。也有可能會涉及一部分來自其他相關專業或者相關課程的內容。
B.編程語言
每一個程序員只有在會使用一門語言的情況下才有可能從事開發工作，所以學習並掌握一門語言是最低要求了。
C.SDK
光有一門語言是不夠的，從事任何實際的軟體開發都需要一個類庫或者開發包才可以完成。比如C語言中的庫函數，C#中的.NetFramework類庫，Windows的API等等就屬於這個範疇。這方面的資源有個平台DevStore可以關注下，收錄了很多的sdk服務配置過程評測，直接搜索就可以了。
D.開發工具
以如今的情況來說，沒有開發工具理論上也是可以開發軟體的，但效率就是一個問題，所以掌握並使用一個開發工具完成開發任務應該也是一個最低要求。
E.領域知識
軟體總有用戶，於是開發這些用戶使用的軟體，那麼程序員就需要了解用戶所在行業的知識，至少需要知道一些基本的必須的知識。還有一部分的內容也劃分為領域知識，比如從事Photoshop這類軟體的開發那麼圖形相關的知識就必須了解一些，從事工控軟體的開發，那麼對控制方面的知識也要有所了解。
以上的分類是在本文中我對知識的理解，一個程序員知道這些知識後從事一個軟體的開發應該是沒有問題了。下面分別來討論一下這些知識的學習問題。
一．教材知識的學習
做為一個已經從業的程序員來說，我不認為計算機專業的所有專業課程（包括專業基礎課，我在讀大學的時候還有這個說法）都是有用的。實際上對於大部分程序員來說，只需要很少的一部分知識就足夠了。這些知識主要由三門課程組成：數據結構，編譯原理，操作系統。對於大部分的程序員來說，其他課程的內容不是沒用，而是在實際工作中用不上。
數據結構這門課程的重要性，可以理解為是程序員的聖經，怎麼如何形容其重要性都是不過過分的。這門課程中需要掌握的內容，我個人觀點如下：
1. 掌握所有線性數據結構的知識，比如表，棧，隊列等（廣義表可以不作要求）
2. 二叉樹的基本操作和基本使用
3. 圖中需要知道遍歷和了解最短路徑演算法，以及相關的一些概念
當然對於某些程序員來說，這是不夠的，因為從事的具體的軟體開發工作會有不同的要求。但是對於大部分從事MIS軟體開發的程序員來說，這些知識夠了。掌握這些知識可以有兩個層面的要求。第一個是完成足夠的習題，從而可以熟練的答題，第二個是能夠在實際工作中使用數據結構描述實際的事物。做到這兩點要求應該說不算太高，注意多加練習就可以了。目前來說這門課程的經典教材也不少，相信只要按部就班的學習完就是合格的了。
編譯原理這門課程主要是學習方法和思想而不是課程中的知識本身。因為畢業出來能從事編譯器開發的人實在是太少太少了。這門課程需要掌握了解的東西不多，我個人的觀點主要是以下幾個：
1. 確定有限自動機和非確定有限自動機的使用
2. 詞法分析程序的實現
3. 語法分析的方法
自動機在實際應用中的體現就相當於是狀態轉換圖，這個工具非常的重要，希望能夠務必掌握。我們在開發EntityModelStudio時，設計界面交互部分的內容就是先設計出狀態轉換圖然後再寫代碼的，否則直接開發的話就會面臨開發失去控制的風險，同時重構和維護也會相當麻煩。所以這個工具極其強大，非常實用。另外提一下，非確定有限自動機，這個工具的能力和確定的有限自動機是等價的。但是由於它的不確定性，更符合人的自然思維習慣，從而在某些設計場合相對會方便很多。這一點是很實用的，也是很吸引人的。
掌握詞法分析程序的實現，可以大幅度拓展開發能力和思考能力。這部分東西理論上描述可能比較麻煩，但是實際使用時還是很容易上手的，所以非常值得學習一下。語法分析程序不需要掌握了，畢竟開發編譯器的機會是微乎其微的。但是相關的方法和思想希望能夠了解，這可以幫助程序員用電腦的思維來思考問題。
操作系統需要掌握的東西只有兩個：
1. 五大管理的基本方法，尤其是涉及內存管理的策略
2. 線程或者進程的同步技術
操作系統是複雜的，但是教材中介紹的這些管理方法相對來說是簡單易懂很多了。這一難一簡之間體現了基本知識的重要性，基本知識在實際開發中的應用的廣泛性。好好的體會，就可以明白用簡單方法解決複雜問題的技巧。線程進程的同步，這個就不用多說了，大家都知道它的作用，如果實在不想掌握的話那我也非常願意相信你的理由一定是充分的，否則你絕對不會那麼做。
最後我想強調的是，無論你如何看待這些知識：可能覺的沒用，可能覺的太難，可能是不感興趣，但是如果你想做程序員的話，那麼請你務必最大可能牢固，最大可能熟練的掌握它。
二．編程語言
對於一個程序員來說，一般需要掌握2,3門語言是基本的，並且學習一門新的編程語言也是基本功級別的能力，所以這部分主要談談快速學習一門新的編程語言的方法。我學過的語言有這些（這裡編譯器和語言的概念等同了並且不按先後次序）：Foxbase，C，C++，彙編，Visual C++，Delphi，FoxPro，VB，C#。就我個人的體會來說，這些語言可以分為三種類別：非面向對象的，面向對象以及支持可視化設計的。
這三種類別的語言有一些共同的內容，而這些內容也是我們在學習一門新的編程語言時首先需要知道的，可以說是關鍵的知識點。這些內容大致如下：
1.常量，變數，數組，不同的數據類型
這部分需要掌握常量，變數，數組的定義，初始化，不同數據類型的使用。數組中元素的讀寫，作為參數如何定義，作為返回值如何定義。有些語言還支持數組大小的重新定義。
2.函數（或者叫子程序）
函數如何定義（比如參數和返回值），如何調用（這裡存在非同步調用和同步調用的問題），全局的還是非全局的。
3.流程式控制制
分支結構：if語句，if else語句，switch語句；循環結構：for語句，while語句，do…while語句，有些語言可能是Loop。
4.最基本的輸入輸出和文件操作
最基本的輸入輸出語句可以幫助你在學習語言的過程中完成簡單程序的練習任務，比如：輸出到控制台，dos操作系統中輸出到屏幕等等。文件操作也要知道，至少以後寫個程序生成日誌文件就會了。
以上內容在學習一門新的編程語言時，希望能首先掌握，這能讓你很快的入門，並儘快使用新語言寫出代碼。另外還可以關注一下其他方面的內容，比如：
1.了解語言的新特性
這個階段只需要了解，不需要掌握，記住有這些新特性，在需要用的時候想起它們就可以了。
2.了解一下幫助文檔中，該語言的所有關鍵字
這部分內容有可能讓你發現一些很有用的東西。
好了，知道這些內容差不多一門新的語言就算入門了。當然還有其他很多東西，但是這些內容可以在具體開發中遇到時再去找例子就可以了。下面談談這些語言的差異。對於面向對象的語言來說，需要知道面向對象三大特徵：封裝，繼承，多態在具體的一門編程語言中是如何表達的或者等價表達的。對於支持可視化設計的語言來說，還需要知道如何設計窗體，以及常用控制項的使用。按照這個方法，從一門已經會的編程語言到學習另一門新的編程語言應該是比較快的。對於還在大學中學習的人來說，我的建議是C++或者Pascal中的一個，VB或者C#中的一個或者其它可視化開發語言中的一個學習一下。如果可能學習一下彙編是最好的。
三．SDK
掌握一個SDK才能使程序員在掌握一門語言的基礎上進行實際的開發，如果僅僅是一門語言那是不夠的。所謂SDK舉例子來說就是Foxbase的命令和函數，C的庫函數，C++的類庫（比如微軟的MFC），Windows的API，.NetFramework，這些都是我所說的SDK。程序員可以根據自己的實際開發需要，有選擇的學習相關的內容。我最初的做法是先google，然後查文檔，一般的問題都可以很快解決的，慢慢的也就逐步掌握了。但是搜索的過程中難免會搜索不到你想要的東西，需要SDK服務的話就去DevStore平台上找，像一些日常遇見的問題可以去百度，每個人對同一個問題有不同得看法和解決方法
另外一個建議是買一本書學習也是可以考慮的，這也是一個不錯的方法，只是買到好的書需要緣分。就我個人來說，絕大部分的情況下是看電子書，直接從網上下載的。
四．開發工具
除非你只用獨立的文本編輯器寫代碼，並且用命令行編譯，否則你一定需要一個開發工具，尤其是一個帶IDE的開發工具。對於你使用的開發工具而言，需要了解的基本內容如下：
1. 項目或者工程的創建，屬性修改，打開關閉等基本操作
2. 具體開發時的環境設置
3. 項目中的文件組織及管理
4. 常用功能的使用，比如：編譯，執行，斷點設置，代碼跟蹤，調試信息輸出，實用的快捷鍵，調試時變數查看，查找/替換等等
5. 從幫助文檔中了解IDE的新功能。因為這些功能有可能對你是非常有幫助的。
6. 幫助文檔的獲取
如果有自己的使用習慣的話，還可以了解一下如何定製IDE環境以滿足自己的開發習慣。首先了解這些內容可以幫助你相對快一點適應一個新的IDE。
五．領域知識
一個從事技術工作的程序員需要了解與技術不相干的領域知識，確實有點無奈。但是在具體的開發中，不了解這些知識就無法更好的理解用戶的需求，也無法更好的完成開發任務以及與同事領導的溝通。所以這個步驟是重要的必要的，有時候有可能還會帶來更嚴重的後果。在有些項目中如果不能很好的了解這些領域知識，項目中的成員有可能會被替換掉，我個人就有過這樣的經歷。所以這裡特別列出來強調一下。
差不多這些知識應該夠用了，下面再提幾個額外的內容，這幾點雖然和開發不是太直接相關，但是確實也很重要。它們是英語，數學，讀源代碼和讀書，有餘力的程序員可以盡量提高這幾方面的水平，這是很有用的學習途徑和方法。對於英語而言主要是讀和寫，這樣就可以閱讀英文資料並用郵件，論壇或者聊天工具和老外溝通。由此獲得的幫助是非常顯著而高效的。這裡要說明一下，微軟論壇上的回復的質量非常之高。
對於數學我的理解主要是三個部分，都是很具體的：
1.中學裡學過的知識
這部分知識很重要，這是我們用簡單方法解決複雜問題的基礎，同時使用的幾率也非常高。如果全部忘記的話，建議多少複習一下，或者用到的時候回顧一下。
2.離散數學
我需要承認在開發中直接使用離散數學知識的場合我一次都沒有遇到，但是如果沒有離散數學的知識，那麼我就無法思考，很多問題就無法解決。
3.組合數學
這門課程屬於研究生級別了，相對難度會大一些。我的觀點是你不需要全部掌握，知道一部分就可以了，比如：鴿巢原理，母函數，以及常用的計數方法和技巧。尤其是技術方法這部分在問題的分析簡化，工作量的評估，演算法設計以及軟體測試方面都有非常實用和具體的應用價值，是很值得掌握的。是否可以使用這部分知識，在實際工作中表現出來的效果至少相差一個等級。
一個好的源代碼具有不可估量的價值，潛心學習一下可以讓你從一個門外漢變成一個開發老手，所以注重培養從讀源代碼學習編程知識的能力。我的體會是，閱讀源代是一個非常有效（有用並且高效率）的方法來提高自己的開發水平或者解決實際問題的能力。我第一次認真學習的源代碼來自當初的程序員大本營。一個例子是實現Visual Studio 6.0中Workspace的界面，另一個是如何實現給主菜單加入圖標。兩個例子大概花了我一個半月的時間並且寫了幾篇心得，記錄下學習的內容。應該說收穫很大。再比如，下一個版本的EntityModelStudio中會加入代碼編輯器，這個支持語法高亮和行號的編輯器就是在讀懂開源代碼後我們自己獨立重新開發的。在閱讀源代碼的時候希望能注意兩點：
1. 最好能配置好環境可以單步跟蹤代碼，這樣理解代碼的速度和效果會好很多。
2. 快速的定位那些自己想看的代碼。這裡建議可以使用IDE提供的查找功能，看文件名，類名等方式來定位。如果實在不行，考慮注釋代碼，來快速定位。
第四個內容是讀書，閱讀是學習的一個最基本和最重要的途徑。在這裡我不想列出任何需要閱讀的書目，這是因為當下流行的所謂經典或者著名的開發書籍我讀得很少，所以也說不出體會。我看過的書都比較老了，比如：
1. BorlandC++4.5使用及開發指南
這是我的C++的教材，C++部分先後看了不下6次
2. 一本1970年發行的軟體工程的書，這是我第一次接觸軟體工程
3. 代碼大全第一版，我覺得第二版沒有第一版好
4. 用於面向對象的設計和分析方法，這是美國哥倫比亞大學的一個教授寫的。是清華大學原版教材中的一本，非常好，是OOD的絕好教材。
目前有印象的就這些，以後想到了再補充吧。其他讀過的書還有很多，都是具體的編碼的書就不再一一列舉了。有些書需要仔細閱讀的，比如講設計，講方法的書，有些書需要很快的瀏覽完，比如講具體編程的書。我的體會是，一本幾百頁的書，你應該花1,2小時就能過一遍，最好是20分鐘到40分鐘就能過完。在實際開發中，用到的時候再看書，查找需要的內容。如果你需要花很長一段時間全部學完一本書的話，那麼你看的第一本書可以這樣，否則我覺得你的學習方法就有問題了。至少一本書中不可能所有的東西都是你馬上要用到的，你沒有必要立刻學習，所以應該學會快速閱讀的技巧。當然這是個人觀點，取捨對錯自行判斷吧。
你不能寄希望於一次就能買到一本理想的書，也不能希望在一本書中學到自己需要的所有內容。遇到一本好書是需要點運氣和緣分的。我的總體感覺是，外國知名出版社的圖書的質量明顯好一些，還有台灣一些出版社的圖書也還不錯。建議大家可以買一些絕對知名和權威的書籍，這樣相對風險會小一些。對於那些書名為XXX大全，XXX寶典，精通XXX，XXX權威這樣的書，我是很不看好的，當然這是自己的看法，僅供參考。
最後說一下不要學習的東西，幾天前在群里聊天，一個人說想解析暗黑的通信協議，然後做外掛。我對這方面很不在行，但是這明顯是一個非常耗費時間，難度也非常大的事情。我在這裡給出的建議是，一個職業的程序員需要知道自己的價值，自己的知識和精力應該花在能夠創造實際價值的地方。不要僅僅出於愛好或者熱情去做一些成本很大的事情，與其炫耀自己的能力，不如踏實的做好本職工作。如果實在想做可以作為業餘愛好，適可而止。

安卓開發學習學習網站

推薦你關注DevStore還有csdn和開源中國，都是程序員經常聚集的網站。

DevStore（開發者服務商店）整合開發者會用到的服務，可以實現在線對比評測，省去自己去網上搜索尋找的過程，還有sdk配置過程，很方便的，嘿嘿，我還在這個網站上寫評測掙過外快呢。

csdn（中文IT社區）中國最大的開發者技術社區，牛人還是很多的

開源中國是目前國內最大的開源技術社區，主要是軟體下載，源碼託管

自學的話平時就多看一些官方文檔，幫助文檔也是一個很好的參考資料，多看看，平時多敲代碼，多看住喲啊哈斯看規範，看完之後去敲代碼主要是在實踐過程中發現錯誤，多做項目自然多遇見問題，遇見問題解決問題，下次自然就知道怎麼解決，在實踐中發現真理。

謝邀。

果然改了一下自己的備註立刻就有人邀請我了。

我目前也不能完全算是獨立遊戲開發者，只是以前上學時曾經和同學合作做出過一個毫無名氣的獨立遊戲而已。現在過去兩年多了，上個月也才剛剛集結小夥伴打算重新開始，而且還是用業餘時間。

上面前輩們總結的都很不錯，我看了之後多少也學到了一點東西，我沒什麼成功的獨立遊戲可以拿來曬，不過作為商業遊戲的從業人士多少能知道這中間的差距，能分享一點開發獨立遊戲需要注意的地方，雖然方式方法可能會比較傾向於商業化遊戲的開發模式，不過我覺得多少還是應該可以看一下的：

①要有明確的開發方向

你可以忽然腦子一熱想到一個很GOOD的IDEA，但是只有IDEA還不行，你必須要為這個IDEA量身定做一套具體實現它的方法和路線。如果你沒有明確規划出你的計劃，那麼實際實行起來將會浪費極多的時間和精力。

如果你不是一個人而是一個小團隊的話，那麼這個東西就更重要了。這個計劃將決定了你的小隊的開發效率。

②不要有拖延症

你有了最初的計劃，你即將開始製作你的遊戲。可我今天遇到一個問題。哦，解決它需要用一個多小時，這將影響我的睡眠。於是你把它拖到第二天？最好不要這樣，如果只是小問題的話最好就在當天解決，哪怕會稍微犧牲一些個人時間。第二天還有第二天的事情，如果你總把事情拖到明天，你會發現你的開發周期永遠都是在彌補昨天沒做完的工作。

③不要堆積小麻煩

無論是獨立遊戲還是商業遊戲，很多遊戲開發者都會犯這樣一個毛病：今天出現一個不起眼的小麻煩，但是不想立刻就解決，因為它太小了，等這種問題累積到一定程度之後再一起解決好了。這樣是不可以的，人的記憶力有限，特別是對小事情記憶力更是沒得分配。像我這種擼管擼到記憶力衰退的人，刷完盤子之後連剛才吃的是什麼都會忘記。不要以為記在本子上就沒問題了，過幾天之後看到自己簡略的縮寫你肯定不會記得那是什麼玩意。而且如果你有詳細記錄的時間，相信你肯定可以利用這段時間解決這個小BUG了。

④不要盲目樂觀

無論是開發周期還是完成發售，都不要盲目樂觀。樂觀的給自己的項目定下兩個月完成的目標，按照平均分配每天只需要做一定量的工作就可以如期完成？不要想這種好事了！你會發現你根本不可能按照原定計劃完成的，因為會意想不到的狀況太多了，比如測試事出現預料外的BUG，調好的動作放進去覺得很不協調，畫好的人物立繪在遊戲里和背景放一起真他喵的丑。好吧如果你不注重遊戲品質也許這些並不是大問題。朋友邀你去玩，家人要你回家看看，女朋友和你鬧分手，你還會有很多私事應接不暇。如果你已經不食人間煙火，為了做獨立遊戲做到無情無義，那可以無視我的意見。

而至於發售之後的情況和玩家反饋，更不要盲目樂觀。不要以為自己用心去做了就一定會被大家喜愛，獨立遊戲再怎麼說也只是表達一個人或者一個小組的想法而已，它不像商業遊戲那樣是為了取悅大眾才出現的。首日發售一份沒賣出去？連瀏覽都沒有幾個？發售日里你的遊戲不在任何顯眼的地方，甚至連翻幾十頁都看不見自己的作品？這些都很正常，你的遊戲發出去之後哪怕能在第一天收到十幾條差評這都是幸運的，至少有人玩過你的遊戲了。所以，開發獨立遊戲，一定要把心態放平，一定要有一切最差狀態的心理準備。

⑤完成比什麼都重要

很多前輩好像都說過這個問題，我也覺得是這樣，而且實際經歷過之後才真領會到這裡面的真諦。完成比什麼都重要，無論是對你個人還是對你的開發小組。完成是對你努力的一個最直觀的反饋，是你一直以來時間精力甚至金錢的投入而形成的最終產物。它就像十月懷胎之後生出一個寶寶是一樣的感覺。沒人能接受十月懷胎臨產時流產的。如果你說你是男性不好理解，那就腦補一下自己單身了二三十年好容易找到個女朋友時卻因為車禍被壓碎了睾丸的情況吧。

我見過太多連一個項目都沒做完就半途而廢的人了，他們通常都會抱怨這個社會不公平，或者抱怨領頭的人沒有能耐，而往往他們自己都沒盡到最大的努力。也有很多獨立遊戲製作者因為無法將遊戲完成而喪失了對遊戲的熱情。

以上都是個人從業兩三年的一點小經驗，個人化成分有點重，不能說就是權威的意見，不過新手可以看看，至少無論是獨立開發還是商業開發，這個套路肯定是沒有錯的。

再次，感謝邀請。

謝謝邀請。

首先扔接活網站：
1. http://odesk.com
2. http://freelancer.com
3. http://elance.com

然後談談入行準備：
1. 足夠的麵包。
2. 個人網站：一個顯示你個人涵養，介紹你過往經驗，展示你個人項目的平台。我挺喜歡weebly的。
3. skype，facebook，paypal賬號，用以溝通與付費。（國外）

為自己添加credit：
1. 個人github項目。
2. 一份具有親和力、顯示個人優秀的溝通與理解能力的自我介紹。

自我管理方面：
1. 時間表：個人的時間表喜歡按「本日類型」定製，比如說今天是A日，我專註學習；明天是B日，我專註做事。另外，如teambition等的項目管理工具可以作為個人任務管理工具使用，很有幫助。
2. 情緒：找一種在大部分情況下可以放鬆的方式。卡項目出現的焦躁需要及時治療。。。
3. 人生：嘗試只接能提升個人價值的項目；擁有自己夢想的項目。

注意事項：
1. 留住好僱主，多結交同行不同特長的朋友（比如美工，設計師，網站編輯），特別是geek們，可以隨時讓你學到很多東西。
2. 三餐定時防疾病、每天運動免體弱、多照陽光好精神、打理房間不邋遢。

老天，頭一次有人邀我，先謝邀。
其實我在IT業的經驗幾乎是一點沒有，和題主相比根本就是一個天上一個地下，我不過就是自己拿rm做過幾款姑且被玩家認可的遊戲而已。
看了一下樓上車軸草的答案，我是完全認同的。以下的東西僅是以我個人碰到的經歷進行補充：
如果第一次嘗試獨立開發，千萬別想著去做一個規模恢宏，氣勢龐大的遊戲——你拿個小的練練手就好。本人第一款rm是一個打算做到時長12小時以上的遊戲，後來我的序章和第一章加起來達到了遊戲時長2小時，足足做了半年之久。之後……之後由於分支過於龐大，導致我現在那個工程連碰都不想碰了（狂汗ing）
一般頭一次開發，你做一個時長一小時的遊戲就好了（這都至少兩三個月出去），主要是給自己樹立信心，並且發現一下自己哪方面有不足。所有方面都好那是不可能的啦，你想做的遊戲如果想出彩，也不一定需要樣樣都好，但在某一方面，你一定要亮眼。
題主似乎沒有說清楚，到底想做什麼方面的遊戲呢。要是可以的話要不要提供更多一些的信息呢？

獨立開發一般都是在遠程的狀態，作為遠程開發者你需要避免的4個大坑，以下摘錄 @喵在野

寫在「程序員客棧 http://www.proginn.com」2.0 web和APP都已完成的現在，給我們團隊前面8個月的工作和觀察經驗做個小結。

從2015年1月份我們程序員客棧遠程協作團隊組成到現在，這8個月我們發布了4個web大版本和不計其數的小修改；iOS和Android分別發布了8個版本，從1.0到2.0，其中1.0用了2個月的時間（包含春節）；2.0上線用了2個月的時間（包含從業務邏輯探討，到最後web, iOS Android端全部上線）。中間小版本的迭代，基本是2-3周一次。

所有這些事情的完成，全部基於遠程協作。

經過這麼一段時間的嘗試，不能說多成功，但起碼有了不少經驗，踩過了不少坑，可以分享出來供大家參考。所有經驗適合於需要通過團隊協作來完成產品的各位。

坑一：沒找到正確的人，時間的浪費以月來計算

這也是最重要的問題。是我們一開始遇到的問題。現在看來，找人的時候，以下幾點都需要考慮到：

l 有經驗是前提條件，對於你要實現的產品，他有過類似開發經驗，80%的開發需求他已經瞭然於心，不僅能夠實現想法，還能夠基於自己的經驗給出更優的建議；另外20%他也知道去向誰求助。

l 很聰明，善於學習，是第二條。總有他沒有做過的部分，但沒關係，他會輕鬆告訴你，我去看下文檔就會了。（目前我的親身體會，我們開發團隊童鞋們簡直就是神筆馬良，能想到，就能做到#_#)

l 同時，他還要有時間有興趣，願意來做你的項目。

以上三點，缺一不可。

這樣的人肯定不便宜。是的，他們的正常薪水比平均水平高50%-100%。

那麼要不花少一點的錢，找個便宜點的新手？

那意味著你將承受更大的成本：需求往複修改的時間翻倍，開發的時間翻倍，測試之後再修改的時間翻倍，他走了之後別人因為讀不懂代碼而導致產品不得不全部推翻重來……我還是建議你不要做這個嘗試了，因為最後你會發現：成本並沒有降低，也許更高，因為他薪水雖然是高手的一半，但他的用時卻是高手的2倍；你還花了更長的時間讓整個團隊付出了更高的時間成本，得不償失。

從去年11月份開始，這樣的人我們花了3個月，才找到，1月底才組成我們自己的開發團隊，然後開發速度颼颼的就上來了。

在做程序員客棧的遠程項目功能時，我們對所有申請簽約的開發者，都像8個月前為自己找開發團隊一樣仔細篩選，然後再加上匹配演算法，確保需求方的項目發布後，我們可以用12個小時，就為你對接到過去我們用了3個月才找到的優秀開發者。

如果去年11月我們就有了程序員客棧的遠程項目這個產品，我們的發展時間，可以再快3個月。

坑二：協作的順序沒安排好，將導致時間以周為單位被浪費

一個產品的簡單順序如下：

原型（一般需求明確的情況下，所有文檔一周左右）-&>設計（根據頁面而定，一般簡單的產品1-2周）-&>後端（根據功能需求而定，一般簡單的產品1-2周）-&>前端開發（2-4周）-&>測試-&>上線。

對於我而言，每個版本，從原型到最後上線，都是在一個完整的時間段裡面。作為創業小團隊的產品負責人，同時還是測試負責人，意味著只有當產品上線了，這個版本的活才幹完，然後才有精力開始計划下一個版本。

但這恰恰是之前效率低下的原因之一！在我們早期某個版本，需求，原型被同時傳達給了設計和所有開發者。導致前端小夥伴足足等了一個多星期，才拿到可以開工的文檔。我們的上線時間也因此延誤了一周多。

實際上，當設計和前端交接完，你就應該請設計師開工準備下個版本的設計了。當然，這意味著你此時已經完成了下個版本的原型，準備好了和設計師探討下個版本他需要做什麼。

詳細來說，一個更高效的流程應該是這樣

產品開發協作流程

l 當你的前端開始開發1.0版本的時候，你已經在準備1.1的需求和原型；

l 當你的前後端在進行聯調的時候，1.1的設計已經開工；

l 當1.0版本最終發布的時候，1.1的後端介面已經完成。

這樣，項目才會無縫運行下去，大家都能高效運轉。

坑三：以為日子到了？事情就發生了

遠程協作，意味著大家沒有面對面工作的機會，不會有這樣的瞬間：他抬起頭來，看到你，想起你這邊的任務Deadline快到了，於是快馬加鞭一氣呵成。

l 設計師會等產品原型確定；

l 後端會等產品邏輯，流程和文檔確定；

l 前端會等靜態設計，產品交互，流程文檔，以及後端介面確定。

是的，每個環節都在等，而作為產品負責人的你，是拉動整個機器的引擎，是鏈條，是潤滑劑。你不能等。

人只受眼前事物的影響，這是必然的心理狀況。因此，作為遠程項目的負責人，你可以學習Scrum的方式：

l 每天和你的遠程團隊開一場虛擬立會。每天主動去提醒他，項目進展如何？要完成項目，還需要什麼支持？什麼到位了，什麼沒有到位？

l 每周有可交付任務，每周進行回顧總結，上周完成情況，本周計劃如何。

我們的周會總結

我看到過有項目，負責人在項目建組的時候和大家打了個招呼，問了項目執行時間，然後就不再過問。前面一周組內都非常安靜，沒有人主動發言，待到預定的第一個Milestone，不出所料，全面延誤。

坑四：以為對方隨時都等著和你互動？別忘了你們有時差

遠程協作的團隊，一般都有時差。

也許你在中國，他在美國，你睡覺時他正好上班；

也許你是全職，他是兼職，你下班了，他才開始上你的班。

即使你們都是全職，可你喜歡白天，他夜晚最有靈感，白天需要補眠。

這些問題都可能碰到，所以做Milestone的時候就要考慮到，所有需要溝通協作的節點，都要提前協商好時間。

我們的經驗小結

l 高質量的人才是高效率完成項目的基礎，選對了人，就是節省了時間和金錢。

l 根據項目流程提前做好人員安排，嚴格遵守原型-設計-後端-前端的順序，是多方協作的基礎。

l 項目負責人要主動推動每個環節前進，而不是等待。

l 提前協商好milestone和共同工作時間，能提升協作效率。

我相信遠程協作是未來的趨勢，也是遠程的堅定實踐者。國外已經有非常值得學習的對象，創造了Basecamp,Rails on Ruby的Basecamp公司（前37signal)是一個典範：他們的員工分布在兩個大洲8個城市，他們同時享受著生活和工作的樂趣，他們不用等到退休以後才去做自己想做的事情。希望有一天，我們也能實現這樣的目標。

1、不要貿然離職。最好在業餘時間，自己做做東西，找找感覺。也許獨立開發者並不是你想像的那樣。
2、最好不要做外包。把自己的創意，做成產品，提供給幾萬、幾十萬、幾百萬的用戶使用。進，可拉投資創業。退，可每月賺幾千塊，補貼家用。

以下列舉的僅是幾個即將踏入獨立開發領域的人應該關注和思考的問題, 至於它們的具體解決方案和實現細節, 我想每個個體都會有不一樣的答案, 樓上諸位也已提供了很多非常好的例子以供參考.

1. 為什麼要做獨立開發?
從個人生活/意識形態/追求和夢想這些方面或許很容易回答這個問題.
但既然做獨立開發, 就要充分發揮獨立開發者的優勢. 產品獨有的特點是什麼? 它一定要是像阿基米德的槓桿那樣, 用很少的力(個人可以在合理的時間內獨自完成)就可以撬起地球(可以獲得行業內和用戶的一致肯定). 雖然很少有人能在將產品推向市場前斷言它是有魔力的, 但它們中的大多數的確在登場之前就已經可被斷言"毫無希望".
很多人為了實現自己的夢想或是為了將自己所學不受限制地付諸實踐, 從而踏上獨立開發者的道路. 但他們交出的作品卻只是完成了自身的一項成就, 對這個社會而言卻全無吸引力. 所以在從事一個獨立項目之前就要反覆確定這一事宜——它獨有的特質為何?在項目中無論遇到任何挫折, 我都不會放棄的又是什麼?

2. 你的出路是什麼?
在IT行業和遊戲行業內, 有無數的創業者和獨立開發者潛藏其中. 但他們中的很多人存在的理由並不只是因為在行業中容易獲得成功, 而是因為入行的門檻實在太低了.
為了和他們有所區分, 獨立開發者在一開始就應該對一些事情有所思考: 項目的大致開發周期是多久? 我的個人投資可以支撐自己做多久? 我想要發展合作夥伴和團隊么? 代價是什麼? 我是否想要一個或多個投資人在某個階段參與其中? 項目做到可以吸引投資的階段大概需要多久? 項目的各個部分可實現性有多大? 可否有一部分功能在上線之後以更新的方式完成? 我對這個項目的"正常"期望回報應該是什麼? 項目的換現方式有任何問題么? 如果項目在商業上徹底失敗, 那麼在這個過程中我又獲得了什麼?
如果對其中一個或多個問題的回答是模稜兩可的, 那麼你對項目的控制力就自然無法確定.

3. 項目管理和自我管理
對於很多在大企業工作的朋友而言, 他們的事業和生活一開始被父母照看, 之後被學校照看, 最終被企業照看, 一直無法斷奶.
所以對於獨立開發者而言, 不僅意味著事業上的獨立, 也意味著生活上的獨立. 你不僅要自己控制事業的方向, 也要重新尋找生活的方向.
你需要在項目的一開始就關注它的技術難點, 和所有非常重要又不確定的因素. 你需要做一個又一個Prototype, 以確定項目開發的各種邊界. 你需要將它們糅合在一起, 然後在不斷的迭代中尋求它內在的和諧完美.
同樣, 你需要開始關注自身在獲得突如其來的自由後面對的各種問題: 你的腰圍可能會瘋長, 你的表達能力或許會驟降, 你的生物鐘可能在向美國靠攏, 你的異性朋友或許會突然增多或減少——有的人為了生活而工作, 有的人為了工作而生活. 但無論如何, 你需要以一個自己滿意的方式活著.
永遠不能後悔.

在家人能接受底薪的時候，考公務員閑職。
然後你就有大把的時間揮霍，並且不用擔心餓死。
最穩妥的方案。毫無風險。哪怕你開發不出任何東西，你和家人至少餓不死。

有過一次失敗的2年SOHO經歷，想聽聽失敗的經驗么？
我後來想起來自己失敗的主要原因大概有這些：

過於樂觀地估計工作量，貌似大多數碼農都會犯這個錯。
項目太大，一個人承受不起。應該先做幾個quick dirty的東西出來，先能糊口再說其他的偉大理想。
缺少壓力，工作效率低下。我曾經用統計當前活動窗口停留時間的軟體觀察過，平均下來我每天寫代碼的時間不超過2小時，其他時間都在刷SNS，看網頁等等。
不會做市場。硬傷，致命傷。
其他方面比如缺妹子之類的就不多說了。

踏入程序員這個行業，你就註定要學習一輩子，新技術層出不窮，技術體系更新快速，這是和其他行業最大的區別之一。所以，如果你想在這個行業混出點樣子，那麼請你隨時做好學習的準備，如果你想成為優秀的程序員，那麼一定要有正確的學習方式，下面推薦幾條開發者的最佳學習方式，希望能幫你事半功倍。

書籍和期刊是必不可少的

無論你是新手菜鳥還是高級程序員，你都離不開書籍，當然我們要有選擇的讀書，盡量選擇一些經典的書籍來看，如果你英文水平比較好，那麼讀一些老外撰寫的書籍是最好不過的了。書籍能讓你在繁雜的互聯網上總結出一些對你有幫助的知識體系，能讓你在某方面變得越來越精通。

期刊則能讓你的技術知識更加廣泛，作為優秀的程序員，你最好每一個領域都要能夠涉獵一些，知識面越廣越好，因為編程這東西都是相通的，也許有一天你用Java的設計思想實現了智能家居。

建立自己常用的類庫

這是積累知識的一種有效手段，有時候可以幫你大大提高工作效率。不要認為你寫過的代碼沒有用處，有些常用的工具方法一定要收藏起來，整理出屬於自己的工具類庫。比如：文件操作類、序列化類、資料庫操作類、字元串處理類等等，時間久了，你會發現他們對你的幫助不是一般的大，這裡不多說，自己去實踐一下就知道了。

推薦一個網站DevStore，可以關注一下，這個平台主要是針對開發者做的第三方服務的集合平台，可以下載源碼和服務包。

花更多的時間分析問題

花更多的時間理解和分析問題，然後再設計方案吧。你會發現剩下的事情很容易了。設計不是說要用建模語言和工具，可以是僅僅看看天空在腦子裡構思。那些在遇到問題就開始敲代碼的人往往會最終偏離需求。

作為程序員，當你在編寫代碼之前，盡量把問題分析透徹一點，這不僅能提高你編碼的效率，更重要的是能提高你的分析問題能力。

學會幫助別人

許多人都有個共同特點，只有當他需要幫助的時候，他才會求助於論壇或者群。優秀程序員不同之處在於他們會經常瀏覽論壇去幫助他人。相比較於靠別人幫助解決問題，他們幫助他人讓自己學到更多。在一個團隊中也是一樣，幫助他人解決問題收穫更多。相信我，了解他人的問題，思考並最終提供解決方案吧，你會比之前學到的更多。

和領導處理好關係

這點是技術之外的技能，也就是人際關係。無論是小組組長，還是部門經理，你都要想方設法和他們搞好關係，儘管他們不可能教你很多知識，但是他們會給你很多學習知識的機會，比如將重要的項目交給你做，或者是一些公司的培訓。

處理人際關係是大部分程序員的弱點，在領導面前少一點吐槽，不要黑你的產品經理。