優效學院，名師執教，學習更優效，
it----
四六零五七零八二四
----
缺少必要的注釋
大段的if-else
缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在
hack
或複雜邏輯的**，缺少注釋會讓後來者不明所以。為了你好，也為了後來者好，請務必加上**。說不准以後還是由你來維護這段**。
不變和變化的部分拆分
程式設計師中流傳著一句話，此處不要寫死，將來必改。有經驗的程式設計師會將一些業務層的邏輯抽象出來，寫成配置檔案，好處就是若後續需求有改變，只需改配置檔案即可，肯定不會引入
bug。
忽視測試部分
程式設計師中又流傳著一句話，沒有測試的**等於沒寫。雖不敢全部贊同，卻也有幾分道理。從測試用例驅動開發，持續整合，每次編譯自動跑測試用例，能夠保證系統的穩定同時也減輕測試成本。自己改的的部分做好自測，理解需求，做乙個有責任心的工程師。
直接運算元據
你應該通過方法去運算元據，而不是直接運算元據
,這樣能夠保證你總能運算元據正確。例如乙個類中定義的屬性發生變化了，**中所有涉及到直接操作該屬性的**都需要修改。如果通過方法操作該屬性，則僅需修改操作方法，對於外部呼叫者，類屬性變化被遮蔽了，遵循了解耦的原則，**穩定性大大提高。
缺乏文件或文件質量低下
前期文件很重要，不論是框架的
api使用手冊，還是需求或設計文件，以及各種既定流程的規範，不同種類的模板及核對表，等等這些文件，對於專案來說都是非常重要的資源。而往往有些專案，這類文件就是交由非軟體行業的人員來編寫，或者前期根本不打算在文件上浪費時間。
無盡的需求變更，永遠追不上的進度
這是最常見也是最可怕的，因為無論怎樣，我們都無法完成它。客戶可能認為改個程式，就像改個
excel
一樣簡單省事，甚至會使用可動用的一切權利和資源來推行變更。好吧，我承認這樣的客戶我遇到過很多。當我向客戶解釋過變更的代價並提供備選方案後，也就只能等待客戶的選擇了，這多少有些運數的成分，但也是無奈之舉。
僅僅靠加班應對進度落後
進度落後並不可怕，可怕的是僅靠加班來追趕進度。這是問題的關鍵，長時間的趕工仍然無法趕上進度，這只意味著專案有某種更深層次的問題，已經不是單開趕工可以解決的了。留意那些長時間加班的專案，他們往往在管理上存在很大問題，發現這些問題，在你成為
pm時，不要犯類似錯誤。
460570824
，讓我們共同進步！
新手程式設計師常犯的十個錯誤
先介紹下背景，博主由運營轉行前端，入職乙個月，完成了乙個相對較大的模組。由於基礎相對薄弱，犯下了不少錯誤，故想記錄下來警醒自己和分享各位。前端技術棧是es6 backbone react antdui,後端使用的ruby on rails。mvc說起來非常簡單易懂，即model view contr...
通往災難之路 程式設計師創業常犯的錯誤
一直以來新產品從概念萌芽到發布上市都沿用著以下模式 圖1 傳統新產品匯入模式 表面看來，傳統新產品匯入模式脈絡很清晰，很有邏輯的說明了怎樣把新產品一步一步交付到客戶手中的，但是這一模式往往忽略了乙個非常重要的前提 沒有幾家初創企業清楚自己的客戶是誰？儘管這樣，許多初創企業仍然堅持利用這種傳統的新產品...
你與其他程式設計師可能常犯的 6 個錯誤
我擔任 cto 已經有一段時間了，我覺得這是乙個非常好的鍛鍊機會，因為我不僅可以編寫 還要帶領團隊，管理專案，設計架構，組織工作，審查 調查不同的問題，研究各種解決方案，了解許多技術以及聯絡客戶等等。通過這麼廣泛的任務，我學到了很多不同的技能，並有很多想法想跟大家分享一下。也許你的觀點是不同的，也許...