程序員被老闆發現從網上抄代碼,後果是怎麼樣?

李暉


本人5年自由職業程序員一枚,我來回答一下這個問題。

老闆希望員工以最快的速度完成任務

從老闆的角度出發,完成項目的速度越快,發出的工資越少,盈利越多。程序員遇到問題時就會到網上查找,剛好碰到可以解決的代碼,直接複製過來,或者稍作修改就完成了,大大加快了開發效率。只不過國內的環境是問題的正確答案碎片化,很多百度裡面排名最高的答案並不是最好的答案,所以很多人都用谷歌去搜索,或者去Stack Overflow上面尋找答案。

如果老闆發現員工從網上抄代碼會怎麼樣

新手程序員經常會碰到技術難題,然後習慣的去搜索答案,如果答案能夠直接解決問題就節約了大量的時間。此時如果老闆看到了只會說一句:Good job!再次遇到問題時,第一反應就是,網上有沒有現成的代碼可以使用,如果有馬上就拿來用。


自由職業者阿King


老闆會怎麼樣

if(老闆對程序開發有了解){ //有了解,一點點的瞭解即可

認同,見怪不怪;

}else if(老闆很開明){ //一無所知,但是開明

信任,尊重程序員的做法;

}else{ //不僅一無所知,還要胡亂猜想

可能需要一個合理的解釋;

}

程序員為什麼會從網上抄代碼

我們程序員不把這個叫做抄,一般稱之為“代碼複用”。

當程序員需要使用到一個新的框架、類或者方法的時候,一定會做到有跡可循、有理可依,也就是不要亂用。

例如我們一個Spring Boot的項目,現在想用到Rabbit MQ,但是之前沒有用過,怎麼辦?程序員一般會通過這麼幾種方式:

  • 打開Spring Boot的官方文檔,看看如何和Rabbit MQ做集成。

  • 問一下同事,“你們項目有用到Spring Boot集成Rabbit MQ麼?”如果有,代碼拿過來參考。

  • 使用搜索引擎搜一下相關資料,看一下網上的代碼,或下載個demo。

這些方法,在外人看來,都算是抄代碼吧...

一些建議

  • 方案一,我覺得最好,因為官方文檔一定是最全面的,但是對於大部分程序員,這個方案是最慢的;

  • 方案二,如果能找到的話,這個是最理想的。因為網上的資料不一定適用,還需要篩選。(比如軟件環境、版本的差異)


  • 方案三,這個一定是最常用的,我瞭解程序員小哥哥喜歡萬事不求人,能在網上解決的事情,就不問別人。

我建議,先試試方案1和3,自己解決不了的話,再去請教其他的同事。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解,希望能得到你的關注。


會點代碼的大叔


大家好,我從事嵌入式軟件開發十多年,歡迎關注和交流。我不是老闆,只是一個傳統軟件集團公司的總工程師,帶過很多人,開發過無數量產過百萬級別的電子產品。對於軟件開發中的從網上抄代碼,略表己見,怡笑大方。



首先表明,我們不提倡不鼓勵從網上抄代碼。但從整個軟件行業來看,抄代碼似乎很流行,尤其是今時今日,互聯網如此發達與便利,開源代碼如此豐富完善。

網抄,首先要注意,代碼的Licence是什麼,能否商用,能否修改,用後是開源還是閉源,有沒有專利,等等都必須瞭解得清楚明白,這是原則上的問題,也是法律上的問題。



網抄,其次要注意,有沒有能力搞明白代碼的意義,使用方法,效率優劣,維護,完善和擴展的可能性,千萬不能一無所知,糊塗使用,胡亂修改,否則後患無窮。

網抄,最後要注意,從網抄這事情上,除了解決需求之外,員工能否受益。比如,有沒有學到一些知識,有沒有學到一些代碼思想甚至是編碼習慣,有沒有拓寬認知面和認知深度。




我們鼓勵學習和借鑑網絡資源,鼓勵向開源社區貢獻個人權屬代碼,鼓勵用真金白銀去購買優質代碼或第三方商用庫。

謝謝大家。


嵌入式宏思微想


程序員被老闆發現從網上抄代碼,後果是怎麼樣?這樣的事情被老闆發現了,至少從現在來看一點兒事情也沒有,如果能夠抄得讓項目進度大大提前還不出問題不出Bug,不引起糾紛老闆還大大的高興。給他節約了大把大把的錢,他不高興還咋的。

當然從網上抄代碼並不是說整個項目給拿過來,特別是有知識產權的那種,這樣一旦被原版權人發現會引起糾紛。大部分程序員抄代碼都是一小段一小段代碼實現某種小功能、或者對某些方法、類等等用法的抄,以便於在自己的項目中去實現自己所需要的功能,融合到自己的項目中去,而不是盲目的去抄原封不動的搬運過來,程序員一般很少會做那樣的事情的。


程序員很少有不上網去了解查詢相關的知識的。而現在很多老闆本來就是從搞軟件項目出身的,或程序員出身的,早就知道這些招數甚至自己也用過,根本不值得大驚小怪,基本上都會鼓勵程序員如果有什麼不懂就去百度就去找網上相關的解決方法。

儘快尋找解決方法,才可以儘可能的減少一個問題就被卡死在那裡花費掉太多的時間,大部分老闆不是讓你去當鑽研代碼的開拓者,而是去當能實現項目功能的技術能手,你用什麼方式方法去得到那些技術,大部分老闆不會關心的。

所以抄不抄代碼基本沒人管你,最重要的是抄來的代碼是不是能解決項目的問題、加快項目的進度、節約項目的成本,只要能解決問題為項目帶來效益,總監或者老闆還會誇獎你是高手,是能人。


更多分享及互動,歡迎點擊右上角關注【東風高揚】。


東風高揚


程序員主要是實現功能需求,至於怎麼實現的,是不是從網上抄襲得又有多少關係,現實中又有多少程序員不是從網上直接複製代碼然後應用在自己模塊中,把優秀的代碼看明白然後靈活應用寫在實際代碼編寫過程中特別常見,現在的開源社區不就是典型嘛,拿到源碼然後搞明白,進行各種定製,很多公司都會正大光明的這麼去做,在當今的技術領域特別正常。

如果真是老闆發現了代碼和網絡上接近,但是功能用起來沒有啥問題,如果因此找到程序員說事,那這老闆才是有問題,正常來講代碼的審核主要還是在於直接的技術主管,老闆都操心到代碼是不是從網上找的了,方向估計該處問題了,老闆正常來講關心的是結果有沒有達成,如果進一步拓展自己的業務圈子,把產值最大化。

很多程序員的代碼很少有直接全部自己去原創,畢竟軟件行業發展這麼多年已經積累了相當多優秀的模塊代碼,實在沒有必要重複造輪子,進步都是站在別人肩膀上,這也符合實際需要,當然如果從網上抄錄的代碼自己本身不明白,僥倖用上了結果還沒出錯,那麼就該好好反思自己了。別人的代碼可以用但必須要明白,要不真做不長久。

希望能幫到你。


大學生編程指南


俗話說的好,“天下文章一大抄”。我們在工作時,新聞稿、會議紀要等等也是有一定的模板,我們只需要比著葫蘆畫瓢就行了。那麼,程序員從網上抄代碼這件事情,如果被發現,會面臨什麼樣的處置結果呢?

實際上,編寫代碼時最重要的一條,就是學會怎樣利用其他程序員的代碼和思路來解決問題。程序員寫程序抄代碼這件事情,也可以視情況分為三種:抄算法、抄框架、抄整個項目。


其實,簡單的算法可以自己寫,複雜的,比如一個大型遊戲,代碼多到足以讓全公司的程序員懷疑人生。而且一般這種複雜的代碼需要和大型的算法公司合作,也不是簡單的在網上隨便抄一抄就能抄到的。


抄一個應用或者是功能的的框架這件事情,好處也是顯而易見,減少了自身這個項目前期的重複工作,節省大量的人力物力,同事還能在現有的而基礎上做一些自己需求上的改進,何樂而不為呢?而且應該很少有程序員去真的從最基礎的時候一個字母一個字母的敲一整個程序的代碼吧。


但是!整個項目不做絲毫改動地把別人的代碼抄過來,這就涉及到一個版權和隱私的問題,嚴重的話是要負法律責任的。


所以說針對程序員從網上抄代碼這件事情,要面臨的結果無非下面兩種,要麼老闆置之不理,要麼被批評開除。


程序員要做的是在能抄到代碼的情況下,還能知道到哪裡抄代碼,知道應該抄什麼代碼,哪段代碼抄完之後能融入進去,並且還能解決問題,才是最重要的。


決勝網


第一,一般公司老闆從來不懂技術,也根本看不懂你是不是在搜資料還是copy。第二,就算髮現你抄,那也是正常,初級程序員抄代碼已是常態。關注一下再看下面的精彩哈。



文|科技黑洞宇文笑

本人是在某世界五百強企業,公司的老闆肯定是見不到的,部門總經理也幾乎從來不會在我們這些普通程序員這邊逛 ,而且不懂技術。至於所謂的老闆,應該是那些技術總監,可惜技術總監一般情況也不會碰你的答案。而技術總監下面一般是技術經理,普通程序員就歸技術經理管管,跟著做項目,即使他發現你抄代碼,也不會說什麼,只要你能完成自己手頭上的任務,無論你用什麼方法實現。甚至他會教你“抄”哪的,其實這是叫你借鑑代碼,這樣你才能完成你的左右。

現在程序員抄代碼,是比較普遍的,抄網上的,或者複製同事的。複製同事的函數直接不改,就有些無腦,而複用別人的代碼,反而是正確值稱讚的,這往往能提高代碼的整潔度。如果你抄網上的,一般是沒有現成可以用的代碼,只能借鑑其思路,然後結合自己的業務,寫一套自己的代碼,這種做法往往還需要程序員有不錯的基礎,不然你連別人的代碼都不懂利用。



程序員宇文笑一句話:

善“抄”代碼,反而是一種編程美學,不過請你優雅。覺得說的好賞個關注唄。


極客宇文氏


產品功能產出流程:

一、產品經理:需求調研、產品需求文檔、原型圖的產出。

二、商討需求可行性(移動端、前端、後端、UI、測試、產品)。

三、根據各個職能崗位意見以及需求產出時間成本等等條件因素,修改需求。

四、需求文檔、原型圖交由UI、後端、測試

1.UI根據需求文檔、原型圖設計效果圖、標註圖、切圖。

2.後端根據需求文檔、原型圖設計數據庫表結構、接口數據結構、接口文檔;

3.測試根據需求文檔、原型圖寫測試用例;

五、如上所產出(計效果圖、標註圖、切圖)(接口文檔)交由移動端和前端開發人員開發。

六、開發人員開發完成自測之後交由測試人員進行功能測試以及性能測試。

1.測試人員根據《測試用例》進行功能測試形成報告反饋(移動端、前端、後端、UI、測試、產品)進行BUG修復,需求完善,交互優化等。

2.性能測試包括後端壓力測試,移動端的內存等等。

七、最後進行灰度測試或者內部眾測。

八、最終產品更新上線。

如上表述,程序員在一個功能開發過程中,最重要的是保證產品功能穩定性、擴展性。至於怎麼實現如果沒有意外。領導不會關心你怎麼實現。而且在程序員這個行業工作要的是思路具體怎麼實現複製粘貼代碼是很經常的事情。so。。。你這個問題其實並不是問題。



程序猿王大膽


其實這根本就不是問題。

因為如何去構建代碼,在項目一開始就決定了。

比如,一開始分析項目需求,覺得可以利用現成已有的代碼實現,並且公司或者項目經理認可了,那麼基本上你就下載別人的源碼改就好了。

這種就無所謂抄不抄了,一般山寨野雞外包公司比較容易發生這種現象,項目也是幾萬的小項目。

第二種是要從零開始開發,這種情況一般都是比較大的項目或者業務公司自己的開發團隊。

這種情況是一個團隊來共同開發的,程序的構架,用什麼語言,什麼框架已經由團隊中的構架師或者其他主程序員決定好了。

這種情況一般一個人只負責一塊的內容,也就根本不存在所謂抄襲代碼的情況了,因為網上根本不可能有適合做的項目和代碼讓你抄。團隊協作的項目中,你很多開發工作都需要依賴其他同事,你怎麼可能直接複製粘貼呢?

最多是你找一找實現相似功能和代碼,照著寫。但是代碼最終還是要你轉換成適合自己的項目寫。

當然,有一些最基礎的代碼有可能直接複製,比如遞歸算法,到哪裡都基本一樣。但是類名,方法名,變量名你總要自己改吧。

所以這種是根本不可能存在抄襲代碼的情況,只要你能完成你自己的模塊,那肯定是你自己寫的。別人不可能預先知道你做的項目,然後寫好了放到網上讓你抄的。

但是除非是你不懂技術,不知道怎麼得就混好了技術總監或者項目經理和職位上了,然後你欺騙公司或者客戶,說你獨立開發的程序,結果你隨便網上找點源代碼改吧改吧就給人家了。

我覺得這就不叫程序員抄襲,這屬於詐騙行為。


shawn25


哈哈,我平時就經常抄代碼。

好程序員與差程序員的差別不是抄不抄代碼,而是抄下來的代碼能不能根據實際需要二次開發,修改成適合自己的。

曾經有一陣子,程序員圈子裡喜歡炫技,如果誰能用記事本寫代碼,哇,這就是叫了不起。後來大家覺得原來這才是大傻瓜。現在大家都在找好的IDE,稱那種自己寫代碼的行為叫做“重複造輪子”。這種以結果為導向的行為才是聰明的,正確的。


分享到:


相關文章: