標籤:
1.代碼很重要 (功能和代碼品質的關係。應該是功能滿足的情況下,代碼品質也需提升,如果建議3,4)
我在很多地方工作過,發現成功之中隱藏著這樣一種普遍現象:早期的代碼看上去像是一群程式猿喝醉之後寫的。這聽上去似乎有悖常理,那是因為你得竭盡全力讓企業成長,所以就沒有時間去追求軟體的完美。從另一方面講,失敗的企業,卻會花很多很多時間來修正其程式碼程式庫。
打個比方:如果你是一個壽司師傅。作為你工作的一部分,你收集了一套絕版的刀具。你花時間花精力來完成收藏,它們提升了你作為一名廚師的競爭力。
但無論你每天用多少時間去打磨你的道具,你就不是一個鐵匠。你的工作依然是做壽司。你雖然擁有了世界上最好的刀具,但如果做不好壽司,那麼你的客戶服務就是差評。你的餐館生意永遠不會成功。
軟體也是同樣的道理。當你運營公司的時候,你的業務目的是滿足客戶。代碼只是一個能達到目的的工具,它本身並不是目的。你可以,也應當關心你的代碼,因為這能有助於提升客戶服務。但是,如果錯將工具當作了目標,那麼註定你將一敗塗地。
經驗教訓:你的客戶並不關心什麼測試覆蓋率、技術堆棧,版本控制系統,也不在乎你使用了什麼演算法。你的工作就是解決客戶的問題,越方便越好。
2. 關注實現,而不是點子(時間長了,就無所謂產品整體情況了,做好自己的本職工作就好了;做了非職責之外的事情,會帶來許多無形中的矛盾)。
這聽起來似乎違背了傳統的創業須知:快速發布!執行!迭代!執行,不需要創意!快速失敗!
上面這些都是偉大的忠告。但是,“不需要創意”,並不意味著我們能通過卓越的執行矯正一個糟糕的點子。成功就是發現好的問題,再好好地解決這個問題。所以,點子好卻沒有好好實現或者完美實現了一個壞點子,都是不行的,當然前者還有得救。
很多程式員被困實現的死亡漩渦中,花了大量的時間去建立各種功能或者修複bug,相信再添一個功能就能成功。我告訴你,這是錯覺。你只需要解決了某個重要的問題,否則你這樣不斷為產品添加功能根本是沒有意義的,除非你添加的功能確實能解決需要的。
點子好卻沒有好好實現,總比完美實現了一個壞點子要好。
經驗教訓:如果你添加的功能是用來修複一個失敗的產品,那麼最好先問問自己這能不能真正地解決問題。
3. 代碼是寫給電腦的
我總是想不通為什麼這一錯誤會如此之曆久彌堅。無論程式員是第幾次因為同事的糟糕文檔和溝通習慣而陷入困境,他們因此而得出的結論往往還是——程式員天生不擅長這類事情,也不應該做做這些事情。
大錯特錯啊。
如果你是一個團隊的一部分,那麼提升團隊效率最大的一個障礙就是溝通——這不是誇張,團隊面對的是O(n2)問題。如果代碼是你的主要輸出,那麼你需要改變你對編程的看法:代碼是寫給人看的,然後又剛好能在電腦上運行。
很多時候,我看到程式員花了幾個小時孜孜不倦地寫代碼,但是卻省略了用於更新代碼文檔的十分鐘。這是因為他們覺得:“殺雞焉用宰牛刀,這種事情留給以後的人就行了,我的時間寶貴著呢。”從某種意義上講,他們的想法荒謬至極。
經驗教訓:代碼是寫給人看的。沒文檔就不要寫代碼。
4. 這是代碼編寫的最後一步了。
你是不是認為,一旦你寫完這個功能,投入產品,那就大功告成了?錯了。每一個功能都有一個生命週期。你今天寫的代碼,如果成功,那麼將會在你之後的多代程式員中耀武揚威。可能,就為了照料你今天寫的代碼,而不得不成立一個團隊。
好好想一想。如果你的工作就是為了照料別人寫的代碼,你願不願意?
解決問題的關鍵是要有危機意思:寫完第一個版本,並不意味著代碼的完結。務必做好文檔、注釋、整理等工作。
經驗教訓:己所不欲,勿施於人。
5. 程式員的工作就是寫代碼 (點贊)
大多數的程式員認為利用時間的最佳方式是坐在電腦前,戴上耳機敲代碼。但是,如果你寫的每行代碼都必須維護和支援整個產品的生命週期,那麼演算法就又有所不同了。
當你是因為愛好寫代碼的時候,那麼你可以為所欲為,做任何你喜歡做的事情。但是如果你是在一個團隊中生產產品,那麼你的首要義務變成了維護現有的代碼。其他的重要工作為:協調、溝通、規劃和指導。
經驗教訓:程式員的工作是解決問題。指的並不總是寫代碼。
你不僅是程式員,也是產品經理。
有時候,你可能會想:這事情聽起來像是產品經理的工作,而不是程式員的。但是,如果你拿的是寫代碼的薪水——尤其是在初創企業——那麼把自己當成是產品經理吧。如果你也希望產品能獲得成功,那麼從大局出發是至關重要的。這不僅有利於你的初創企業,對你將來的事業發展也很有好處。
最後,如果各位什麼不同見解,歡迎不吝賜教。
英文來自:Five Things I Knew About Programming Before I Did a Startup
http://www.iteye.com/news/30294
創業前需要知道的5個編程謬論(轉)