"非典型"開發習慣
Written by MK - http://mkhome.blog.163.com/
# 代碼篇
* 代碼不愛注釋
* 沒空行、折行
* 不工整縮進、對齊
* 善用Hard Coding
* 用誰也猜不懂的縮寫命名變量、函數
* 不寫log，或只寫同一級別的log
* 為什么不用斷點調試代碼，讀log很累的
* Eclipse 好棒，換掉vi吧，親~
* 超長的函數、類
* 寧可copy語句也不抽象為函數
* ”聰明“的編寫一個業界已存在的函數、算法
* 多得記不住、眼花繚亂的繼承和接口
* 使用各種非只讀的全局變量
* 函數不顯式的輸入輸出 （既參數表和返回）
* 修改代碼時只為達到目而”不擇手段“，代碼優化都是扯D
* 函數間或模塊間緊耦合，繁雜的嵌套、調用
* 文件隨意命名 （例如 login.html, dengLu.js, Tom.css)
* ”深邃“的目錄結構
* 不使用svn、git等代碼管理工具
* 垃圾文件不清理，無用代碼不刪除
* 單模塊多人開發卻懶得使用branch
* 代碼免單元測試就check in, 提交了讓她們測測再說
* 代碼有潛在的問題，難發現，可我不告訴她
* 功能優先，升級忒復雜，臨了再考慮
* 在網上找到類似的代碼，大量粘貼，不注出處
* 不合法的使用商業或有開源類庫、代碼，且不購買，不通過法律部門審核
* 只用順手的語言、類庫、架構，對新技術視而不見
# 架構、設計篇
* 覺得別人寫的應用是垃圾，自己從頭寫，更”高級“ 的垃圾
* Java多高大上，C多技術范，遺棄掉你的腳步語言小女友吧
* 你選擇prolog做AI，選擇Lisp做原型，why？傻吊了吧？ * 在某系統中為類似目的使用不同框架或方案 （例如在一個html文件中既使用bootstrap 又使用css）
* 只看自己的產品，殊于了解競爭對手的產品
* 對于ugly 的設計和用戶體驗已經習以為常
* 對于他人提出的問題或挑戰，第一時間駁斥
* 不使用技術語言進行技術溝通 （例如 不選擇BPEL、UML，而使用更”通俗“的語言討論問題）
* 為快速解決眼下工作而缺乏長遠的vision （例如是用Java JNI 做視頻界面，而在多個發布之后將代碼翻譯為C，庫巴？）
* 缺少產品的roadmap （藍圖）
# 項目管理、產品管理篇
* 工程師為保證進度不做代碼優化、設計優化
* 不了解需求就匆忙開發
* 為保證按時交付某需求而忽略不好實現的部分（這樣產生的”limitation“后患無窮，甚至會導致redesign）
* UE 不超前，使用無新意
* 把bug的修復交給新手，而認為bug的修復比新功能更容易
* 違背經理提出的bug fix方案，出花樣
* 不保留基本設計文檔，認為快速開發變化大沒時間完善 （建議使用UML圖描繪總體和復雜模塊，附加視頻和音頻解說，既快速又實用)
* 過多的設計文檔、大范圍的討論和長時間的review
* 混淆產品的免費和收費的功能，或左右徘徊
* 但凡有”測“這個字眼的工作就要求測試部門去做
* 產品經理提出了新特性，或者遭拒絕，或者要N長時間實現
* 項目經理狂追項目進度，忽視質量和特性的完整度 （見過release為導向的PM嗎？）
# 人員管理篇
* 高級經理認為一切都是分分鐘的事
* 經理們愛替工程師做決定
* 工程師喜歡按時下班
* 經理們加班沒夠
* 按照工作時間發薪水，按照工作態度發獎金
* 工程師不愿意自己掏錢買技術書
* 經理們只關心項目
* 工程師就是創可貼，哪里破了就用它貼上
* R&D 的VP志向很遠大，可現實很骨感
* 招人，要招帥哥和靚女，包括前臺，秘書，和工程師
* 招人，Teamwork 很重要，聽話才是硬道理
* 招人，要生baby的女性我忽略，年紀大的我pass
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！