回覆列表
  • 1 # 職場拉麵館

    潸然淚下

    十多年前的時候,我們一個專案組,做了兩三個專案,那時候我還是一個菜鳥。後來專案上線了,那些教我程式設計的好同事,好哥們,一個個都走了,留下我一個人維護程式碼,我看到他們寫的程式碼,睹物思人,感激寫下這些程式碼的那個人教會我這個初入職場不久的人那麼多程式碼技巧,想起一起加班,一起出去吃快餐,一起吐槽的美好時光。當然後來我也走了。那些程式碼留給了從來沒有見過程式碼作者的人來維護了。當然公司的一份線上程式碼,最好還是作者本人維護比較好,後面來的人修修補補,後面再看那些專案,其實基本上也沒有多少壽命了。曾經的作者也在別的地方飛黃騰達了。

    驚為天人

    後來遇到過幾次編碼天才的年輕同事,感慨技不如人,整潔美觀,漂亮大方,字字珠璣。

    只能自愧不如人,只有學習請教的份兒。

    不過如此

    當很多技術都受制於框架模式之後,就沒有什麼特別的體驗了,不過是按照框架的約定實現一些增刪改查調介面這些東西了,當然這是好事,這是軟體工程的優勢,大家都讀得懂搞得定,公司業務不會因為換了個人讀不懂程式碼而無法運作。當然很多程式設計師也就變成可替換的零件。內卷就慢慢開始了。

    當然還有哭爹喊娘,感天動地,指桑罵槐,推倒重來等等體驗,看官各自體會吧。

  • 2 # 小碼農薛堯

    程式設計師,看同事程式碼,怎麼說呢?

    首先,你在工作中肯定會看同事的程式碼。因為,開發某個功能的時候會和同事的其他功能有相同之處。有的時候你看同事的程式碼你會有點懵,就是有點亂,不知道怎麼說,嗯,就是程式碼你完全看不懂。雖然同事寫的程式碼有點亂,不過它完全實現了業務邏輯功能。

    而且最主要的是,你千萬不要修改同事的程式碼。因為在你還沒有看懂某個功能上下的邏輯的時候,千萬不要修改某部分程式碼,因為你一改某一個部分,整個功能就會出現錯誤,所以千萬不要改同事了。

    而且某些同事,也不希望其他人修改自己的程式碼,因為你改他也改,最後都不知道是誰改的了。然後,一開始這個邏輯測試透過,現在經過其他人修改,又要重新測試,重複浪費時間。如果你要修改程式碼你需要通知同事,並且和同事說,你修改了哪個部分。

    特別是同事的那些業務判斷,千萬不能修改,去掉一個判斷,也許某個功能就出現bug,還是少改同事的程式碼,如果你知道某個部分有問題,你可以讓同事自己修改。

    我覺得你應該去看看同事的程式碼,特別要看一些技術比你好的同事的程式碼,他的程式碼可以讓你學到很多東西。你可以從中學到,然後融入到自己的程式碼中,提高自己的能力。

  • 3 # 小小的期待

    要看什麼對方是什麼人了,假如對方與你關係不錯,直接懟你的程式碼真垃圾。如果對方是你不熟的人,你的程式碼有深度看不懂

  • 4 # 美麗E然

    作為一個曾經的程式媛,我也接手過不少其他同事的程式碼,有的因為跳槽,有的因為工作需要到其他專案去了,有的因為內部調整等原因。

    說實在話,每一個程式設計師打心裡都不願意接手別人的程式,但是又沒辦法,只能硬著頭皮去接。

    在專案一開始的時候,每一個專案經理都有要求,比如檔案的命名規則,變數的命名規則,每個子系統的字首等,還有比如要寫註釋等,但是有些程式設計師就是不願意按照要求,畢竟從事這個工作的人裡面有不少是很有個性的。

    對於一些不寫註釋的同事程式碼,就是一把心酸淚;

    當然,一些寫得比較好的,還是很賞心悅目,還有很有收穫,會覺得,原來還可以這麼寫。

    當然,有時候也會發現裡面有BUG,我自己的程式也會被其他人接手後發現過;

    到了後來,就感覺接手就接手吧,就算要修改程式,有一些也可以憑感覺改的,不一定要完全看懂裡面的演算法。

  • 5 # 陪娃的資訊系統專案管

    和看自己寫的差不多。

    進來我們專案組,第一件事情,先熟悉我們組的編碼模式。

    架構已經做好了,剩下的按業務邏輯寫清楚來。

  • 6 # 六六的大粉絲

    以我的經歷來說,我在某單位it部門工作,工作職責就是保證所負責系統的執行正常,出現問題要能及時解決,所以必須得了解對應系統的程式碼,而且要能修改和最佳化,所以看同事的程式碼,是經常的事情。

    有的同事程式碼寫的好,規範,有註釋,後面最佳化起來也方便;有的用到了設計模式,程式碼簡潔,看起來就優雅;對於某些複雜功能的實現,看看同事的程式碼,也能跟著學點東西,幫助解決工作中的問題。

    也遇到過同事程式碼寫的糟糕的,沒有註釋的,程式碼重複編寫的,不注意效能的等等,沒遇到問題還好,遇到問題查詢起來就較困難些,有種分分鐘想要最佳化的感覺。之前就有一個外包同事寫的程式碼,迴圈裡有多個sql查詢資料庫,功能執行起來慢,效率極低,給使用者的體驗很不好,工作職責所在,這種情況下只有硬著頭皮去最佳化。

    總結起來就是,如果必須看同事的程式碼,學會取其精華,去其糟粕。當然對於it部門,還是建議能進行程式碼規範培訓和建立審查機制,儘量讓每個開發人員都能提交較高質量的程式碼,不然人離職了,留下的就是一個個巨坑。。

  • 7 # 碼農45

    我覺得挺好啊,以前我啃過一個古老的ERP,上面有spring,strust,mybatis,hibernate等各種技術,不知道是經過了多少手的,啃了一個月後我就上手進行二次開發了。

    一般我帶隊開發的話,都是讓下面的人隨便寫,只要能實現功能就行,看不懂算我輸。

  • 中秋節和大豐收的關聯?
  • 蘋果樹冬季怎樣管理?