作為一名程式員，相信好多人都見過形形色色的項目代碼，說實話，很少能見到一些特别完美，特别規範的代碼，特别是在一些小公司，我想有好多程式員朋友有這種感覺，對吧，其實，最初的設計都是好的，隻不過最後由于業務的擴充，需求的變更等複雜的因素造成目前看到的局面，雖然不想看到這樣的結果，但是也不得不硬着頭皮去繼續維護現在這團代碼，近期，一名程式員網友就吐糟了他們的項目代碼。
據這名程式員朋友說，他不确定大公司的代碼好看不好看，但是他看到他們公司的項目代碼跟shi一樣，一個函數一眼望不到頭，沒有注釋，邏輯混亂，真是無法直視了，我想他這樣的描述，好多程式員朋友也是很有體會吧，在項目中見到一個大長函數，或者一個類檔案上萬行的情況的确是有，接下來，我們看看其他網友們對他的狀況是如何了解的吧！
網友一：我們的工程也shi一樣，但不妨礙寫PPT時吹牛逼，反正升上去會有其他人接手填坑
上世是朵花：項目代碼的混亂其他人是看不到的，隻有程式員能看得到，其他人看到的是功能的對外呈現，項目混亂不混亂影響到的是程式員的維護體驗，隻要代碼效率能跟上去，對使用者的使用體驗是沒什麼影響的。
網友二：狗屎都差不多，哪有吃起來會香的
上世是朵花：大家這麼稱呼代碼，似乎對代碼不太尊重吧。
網友三：見過一個類裡就一個函數不？關鍵是這個類的代碼還是好幾萬行。。。你以為這就完了？no。。。這幾萬行就做了一個事情，那就是複制資料庫中的一條資料然後新插入資料。最關鍵的是這個代碼還是個博士生寫的。。。更更關鍵的是在這代碼開始之前我就跟他說過可以用java的反射機能結合資料庫查詢出來的表字段資訊實作。。。原本應該1000行左右能實作的邏輯硬是被搞成這個德行。。。。
上世是朵花：這樣的情況是挺糟糕的，有時候發現不好的代碼要及時改造，不要在不好的代碼上繼續累積代碼，否則就會發現維護的難度呈現指數上升，最後不得不走向重構的邊緣。
網友四：都是屎山堆屎，大小公司的差別無非是坐便還是蹲坑了
上世是朵花：這個比喻有點惡心了，還是麻煩尊重一下代碼吧。
網友五：哪裡的業務代碼都是屎
上世是朵花：在一定規模的軟體公司裡，代碼都是分好幾層的，一般像基礎資料層部門，他們的代碼都是很規範的，變動不是很大，到業務層部門，可能就相對混亂了，因為業務是随市場的變化不停調整的，總不能順應程式員的維護愛好業務不變動吧，是以業務變動對代碼結構的沖擊也是一種正常的現象，這就要求程式員們有足夠能力去應對業務的變動，對業務層代碼可以保持适度的混亂，這也是可以了解的。
網友六：一個檔案十幾個類，幾萬行代碼，一個函數要翻幾頁，了解一下
上世是朵花：說這樣的狀況，我相信，可能這個項目是比較老的項目了吧，估計現在誰在寫這麼長的函數一定被吐槽了。
從評論中，可以看出，大多數程式員網友們都遭遇代碼混亂的處境，這也不能怪誰啊，反正這樣的代碼都是自己或者自己的同僚們一點點累積起來的，是以要想改變這樣的局面，就要從自我做起了，養成良好的編碼習慣，遵守良好的編碼規範，如果你是公司的技術上司層，那就更好了，你應該建立起一個代碼管理流程，并確定這個流程制度能夠落實下去，隻要大家都能遵守并做到了，相信項目代碼的狀态也會好不少，另外，除了流程上管理，代碼的最初設計也是相當重要的，特别是業務層代碼的設計，要留出一些變動空間，要設計的足夠靈活，相信這樣業務變動對代碼的沖擊就相對小一點了。
以上所有圖檔均來之網際網路
大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步了解我，那就關注我吧！