我擔任 cto 已經有一段時間了，我覺得這是一個非常好的鍛煉機會，因為我不僅可以編寫代碼，還要帶領團隊，管理項目，設計架構，組織工作，審查代碼，調查不同的問題，研究各種解決方案，了解許多技術以及聯系客戶等等。
通過這麼廣泛的任務，我學到了很多不同的技能，并有很多想法想跟大家分享一下。也許你的觀點是不同的，也許你學到了一些其他的東西想在這裡跟我們分享一下。我期待着聽到您的意見和見解。
本文主要針對 ctos 和程式員，因為不是每個人都遇到過這些我觀察到的、學到的和解決過的問題。
問題1. “我對xx技術/工具不熟悉”
這是當我要介紹一門新的技術或者語言的時候聽到的最常見的一句話。這也是當我要求某位同學用他之前沒用到過的工具驗證他的想法的時候常常遇到的問題。
這讓我感到非常驚奇，因為我是在問一個非常聰明的人，一個開發人員。我們是不是能夠很容易地學習新的東西，一些新的理念，模式和架構？我們不應該不斷的學習新的事務，了解最新的消息嗎？
或者，這隻是一種假象？也許我們對很久之前學到的東西感到很滿足并且不想更換？也許是我們沒有時間學習新的東西？也許我們不能有不同的想法？
一段時間之後，那個被我安排了任務的人完成了任務。他們做到了，最初的猶豫終于被克服了，他們的舒适區擴大了。那麼，一開始缺乏動力的原因是什麼呢？
我認為這是一種對新鮮事物的恐懼，對失敗的恐懼。我們在我們所做的感到舒服，因為我們了解它，我們認為我們擅長它。事實是我們可以擅長其他一切東西，隻要我們像學習之前的技能那樣去學習、去實踐。
問題2. “在一開始就考慮的太多”
這是我在開始新的項目時遇到的最常見的問題。程式員更加願意加入到已經在開發的項目中，因為不需要做什麼決定。而新的項目卻不一樣，我們需要考慮并确定需求以及功能。
我看到的最大的失敗就是實作，比如，一開始的身份認證。這不是我們應用中最重要的功能嗎？我們不應該考慮安全嗎？不，根本不是。
我們應該盡可能的縮小範圍。我們應該提供一個mvp展示概念驗證。我們應該提供基本的商業規則，以及應用程式的核心功能，而不是考慮性能、分頁、安全認證以及擴充等等。這是非常簡單的，至少在一開始的時候是這樣的。
如何實作呢？我覺得跟客戶的溝通是至關重要的。這是他們的錢，他們的投資，他們是給我們付錢的人。我們不想浪費他們的資金，他也不想浪費。我們應該
一起讨論重點是什麼，我們應該向他們的潛在客戶或者投資者提供什麼。我們不應該專注于其他人不會考慮的地方，如登入/注冊功能，更改電子郵件或删除帳戶。
問題3. “沒有選擇正确的工具”
我多次與不同的公司談到他們開發堆棧。有時候他們做的很花哨，并發和分布式事物使用ruby…。當我問他們為什麼選擇這個相對低效的語言時，他們的
回答是所有的程式員對ruby最了解。當然，這顯然是最快并且最廉價的方式。他們并沒有考慮到長期運作的可維護性。他們隻關注價格和便捷性。這給他們帶來
很大的技術債務，并且很可能需要做很多hacking來實作既定目标。
另一個常見的現象是，很多程式員在熟悉業務規則之前就選擇技術棧。經常可以在充滿激情的程式員中見到這種現象。他們是如此熱衷于開始開發和使用所有的最新的架構。他們不考慮系統将要做什麼，需要解決什麼問題，他們就已經選好了資料庫和語言。
在這種情況下該怎麼辦？我的建議是讓程式員了解很多不同的語言。在熟悉問題和用例後，我們可以讨論這個工具的利弊。了解市場上有正在發生什麼，有什麼架構或者語言，它們解決了什麼問題是非常好的。堅持使用一種大家都知道的工具，可能在開發過程中帶來很大的痛處。
問題4. “重複造輪子”
這個問題主要是對其他人參與的不熟悉。當我review别人代碼的時候經常看到這種情況。我經常問：“你看到那個class/module
/function 了嗎？它跟你已經實作的完全一樣。”這主要是程式員不經常浏覽代碼，他們不知道一些代碼可以重複使用，而不用在任何地方都重複提取。
如果我們遵循一些共同的模式，指導方針和架構的時候尤其如此。極有可能其他程式員已經在其他地方解決了這個問題，提取、抽象出了我們現在需要一個功能。
為了避免這種情況，我們應該用一種更加明智的方法更多的做 code reviews。我們不應該檢查别人的括号是不是對齊了或者是不是缺少了逗号，這些應該留給自動化工具來做。我們需要 review 業務邏輯和行為。一段時間之後，我們會想，“ kamil 已經實作了它，我可以用他的子產品”。
問題5. “學習文法，而不是程式設計”
我遇到過這樣兩種程式員。實際上我可以說還有一種是前兩種結合起來的第三種程式員，但在這裡并不重要。
第一種是非常優秀的 coder。他們了解所使用語言的各個方面，他們知道所有标準庫以及很多第三方的工具。他們知道8種方法來寫一個循環、如何使用模式比對和所有的文法。但問題是，他們不知道架構和模式。他們的代碼是必要的，但他們不能提取出功能、處理封裝并分解到不同的層或者子產品。他們隻會編碼。
第二種是非常棒的 craftsmen
(工匠)。他們是真正的架構師，他們會子產品化他們的應用程式、使用單獨的庫來提取元件、按照模式設計有效的流程。隻是他們不會編碼。他們把太多的時間花費
在低效的算法、不建議使用的函數、過時的庫。也許他們的架構體系是可靠的，工作流是強大的，但他們的代碼可能很難看，很難讀。
問題出在哪呢？第一種情況可能是程式員隻讀與他使用語言有關的程式設計書籍。就相當于隻學習文法而不學習别的。他們認為他們會文法，是以他們會程式設計。而實際上我們隻會寫代碼。第二種情況是程式員忘記了他們使用的語言或者工具的新版本，他們不看更新日志，不看新聞和簡訊。
解決方法是什麼呐？就是在項目中兩種人同時存在，每個人都會互相學習，這是每個人都會感到滿意和受益最多的一種方式。
問題6. “忽略模式”
當一個人加入到一個有堅實基礎的項目是，他很可能會遵循一些規則和指引。通常，開發人員在每一個地方都會有一個慣例，使其在每個地方都是可讀和可了解的。
不幸的是，當一個新人加入編碼的時候，他可能不知道内部正在開發項目的相似性。他可能會使用一種不同的、不符合目前要求的方法。
我們是如此熱衷于提供一個新的功能，以至于我們不想浪費時間來觀察現有的趨勢和模式。我們完全忽略了既定的規則，并因為我們自己的習慣打破一緻性。
這是不好的嗎？并不經常是這樣。有時候，特别是有經驗的程式員加入團隊的時候，這可能是好的。他們可以教其他人如何架構應用，并給他們分享知識。這
如何解決呢？我覺得引進一個新的項目是必要的。我們不應該要求盡快的有新的功能，而是要有人能夠深入到既定的規則。我們應該任命一個一開始就能指導别人的人為主管，讓他掌握所有的概念。
總結
程式設計的世界中有很多的問題，我們每個人都有不同的技能，不同的能力和動力來源。即使是我們不這麼想的方式也會不同。我們應該互相溝通，共同解決問題，并做出權衡。
學習是關鍵。自主開發不應該停止。我們不得不這樣做，除非我們不想成為優秀的程式員。不斷地學習和了解新的東西是我們應該做的工作。
讀書是第一方式，結對程式設計是第二種方式，訂閱電子報可能是第三條道路，以及關注一些部落格可能是另一個方式。
可能性是無限的，我們隻需要選擇适合我們的就是最好的。
來源：51cto