不寫業務的程序員

① 入行不久的程序員，軟體開發/編程中，對於業務邏輯究竟怎麼看待

。。。。業務邏輯就算業務邏輯。。這個還用解釋？普遍就算MVC咯，盡量減少耦合性。寫代碼注意規范格式，因為會減少溝通成本。

② 我剛剛成為一名.net程序員，但一進公司總讓學業務，有點困惑

你好；你是程序員現在公司叫你學業務，那是正確的呀，你想你在該公司應聘程序員對業務一竅不通那是做不好你的本職工作的呀，弄不好還要出現一些問題，因為你不懂業務呀，所以要想在該單位做好工作一定要學好該單位的業務，工作中一看就能知道是否有問題大體上出現在那裡等。好吧。

③ 為什麼程序員不自己寫程序賣，非要在公司拿死工資

我們知道，程序員是一種非常辛苦的職業，在坊間有不少開程序員玩笑的話語，都是關於調侃程序員的工資以及程序員的發量。盡管針對程序員的調侃和笑話都很多，但是我們知道程序員也仍然是一種技術含量非常高的職業，同時並不是所有人都可以擔任這份職業的。而很多朋友就會好奇為什麼，既然程序員的工資這么高，那證明他們寫出來的程序也非常的有價值，為什麼他們不直接將自己寫出來的這些程序拿去賣給大公司，或者是直接賣到市場？說不定還能夠賺到更多的收入，遠遠比他們每天上班坐班，並且還要反復修改來的強。

其實並不是沒有程序員，嘗試過自己來製作軟體再進行出售，但是這個過程非常漫長，同時對他個人的工作量要求也很高，因此很多人都承擔不了經濟和精神上的雙重壓力而選擇了放棄。同時在公司里上班，不僅可以有比較安穩的五險一金和各種福利，而且還可以自己的團隊內的其他同事相互協調合作，不僅可以減輕自己的工作量，將自己的心思全部花在最核心的，值得自己鑽研的部分，而且不用擔心資金斷鏈的問題。

④ 當作為一個初級程序員，自己的業務能力不夠的時候怎麼辦有些功能業務實現不了怎麼辦

你只能繼續深造加強學習，因為你剛參加工作經驗比較少，學的東西和實際結合不進去慢慢的來別著急，多和有經驗的交流，就會改變你現有的壯況。

⑤ 一個Java程序員有必要精通SQL么

程序員精通SQL是最基本的要求
因為做的程序是需要跟數據進行交互的，沒有數據交互的程序，應用層面太狹隘了。
國外的崗位區分的很明確，專門寫代碼的，專門做資料庫的，即便如此，也有區分，專門處理前台的、後台，專門做框架的架構師，還有專門的測試工程師。
但是國內不同，基本上程序員要掌握除了架構以外的全部技能。可以說國內的一流程序員就是萬能的，什麼都會。
這個也導致了國內IT行業從業人員入門的門檻高，培訓不規范。新人不知道該從何入手。
現在國內的IT行業人才缺口很大。這個問題，本身跟行業規范也有一定原因。
作為剛剛進入行業的程序員，第一考慮的是自身能力一定要跟上公司的技能需求，然後在此基礎上不斷學習，有方向有機會的學習新的技能。這樣才能拿到高薪。

⑥ 程序員有前途還是業務員有前途

老實說，這很難說，業務員很辛苦，跑來跑去，到處受人拒絕，
程序員更辛苦，整天對著一堆代碼，有技術含量也好沒技術含量也好，最大樂趣也許就是自己實現了些有難度的代碼，過一會就沒了。
同時也想說，無論是哪樣，你能做到行業的第一名，你就有前途了。
但我想說的是，成功其實是知識+人脈，做業務員雖然也辛苦，但可以到處跑見到不同的人和事，其實也是件有趣的事，而且對擴大你的人脈很有幫助。
當然做你最感興趣的，最熱愛的才是最好的。

⑦ 天天寫業務代碼的程序員，怎麼成為技術大牛，開始寫技術代碼

一個產品業務的開發過程中必然存在很多需要解決的問題，比如 崩潰，死鎖，性能低下，延遲高，伺服器不穩定，數據丟失，某些功能不知道怎麼實現。

產品業務如果要成功，這些問題必須要解決，至少解決其中絕大部分。

誰解決這些問題誰就是大牛，你想去寫業務邏輯公司也捨不得。
遇到這種問題直接退縮或者推給別人，就寫一輩子業務邏輯吧。

問題就是機會，你主動去解決問題，你沒搞定別人也沒搞定啊，萬一搞定了就是你牛逼，多劃算的買賣啊。

以我多年解決問題的經驗來看，其實大多問題並不難，只需要認真去google下跟蹤調試進源代碼深處就能解決，這種問題其實就是誰敢上誰就行。很多人不去解決，就是因為懶和慫。問題解決多了，就會越來越有感覺，別人也就更傾向把疑難雜症交給你。所以一個組里只有一兩個人能成長起來，因為只要有一個人成長了其它人就失去了機會，並不是這一兩個人比其他人優秀很多，只是他們是第一個敢於主動迎難而上的人。

要不怎麼說，性格決定命運呢。

⑧ 程序員如何避免寫過多的業務邏輯代碼

就我個人而言，我認為編寫業務邏輯代碼仍然易於閱讀和理解代碼可讀性。如果有問題的代碼，它可以快速定位和修復。我們不寫底層框架，我們想追求各種設計和可擴展性。雖然面向對象的內聚性和封裝性、子方法和類等太多，但它會使人周圍眩暈，我建議盡可能採用內聯方法，同樣的業務都是以某種方式進行的，如果這個邏輯太長，可以一些測試方法考慮提取（盡量不要太多）。對於類，不要移動到類來封裝一個類，以避免類擴展。

UT斯達康可以給我們信心。此外，UT還可以幫助您編寫清晰的代碼。只是簡單的根據業務場景直白的編寫代碼也是不可行的。必要的設計可以帶來更加清晰的代碼結構。