coding style - style教學 - 你如何告訴某人他們正在編寫錯誤的代碼?




javascript coding style (20)

我一直在與一小群人一起進行編碼項目以獲得樂趣。 這是一個有組織,相當有凝聚力的團體。 與我共事的人都擁有各種與編程相關的技能,但其中一些人使用較老的或完全錯誤的方法,例如全局變量過多,命名慣例不佳等等。 雖然事情有效,但實施情況很差。 在禮貌地詢問或介紹他們使用更好的方法論的過程中,如果沒有將他們的經驗和/或教育質疑(或侮辱)他們,這有什麼好方法?


介紹代碼標準的概念。 關於代碼標準最重要的是它提出了代碼庫中一致性的想法( 理想情況下 ,所有的代碼應該看起來像它是由一個人一次編寫的),這將導致更易於理解和維護的代碼。


他們可能會認為你的風格也很糟糕。 讓團隊一起討論一組一致的編碼風格指南。 同意某事。 是否適合你的風格並不是問題,只要它是一致的就可以解決任何問題。


以非對抗的方式提出更好的選擇。

“嘿,我想這種方式也會起作用,你們覺得呢?” [屏幕上明顯更好的代碼的手勢]


你必須解釋為什麼你的方式更好

解釋為什麼一個功能比切割和粘貼更好。

解釋為什麼一個數組比$ foo1,$ foo2,$ foo3更好。

解釋為什麼全局變量是危險的,局部變量會使生活更輕鬆。

簡單地去掉一個編碼標準,並說“做這個”是毫無價值的,因為它沒有向程序員解釋為什麼這是一件好事。


在Gerry Weinberg的“計算機編程心理學”一書中,有一些非常好的建議 - 他的“自我編程”的整個概念都是關於如何幫助人們接受批評他們的代碼而不是批評他們自己。



引入問題使他們意識到他們所做的是錯誤的。 例如,問這些問題:

你為什麼決定讓這個全球變量?

你為什麼給它這個名字?

那很有意思。 我通常這樣做,因為[插入原因你為什麼更好]

這種方式有效嗎? 我通常[插入你如何讓他們看起來很傻]

我認為這樣做的理想方式是巧妙地問他們為什麼要以某種方式進行編碼。 您可能會發現他們認為其他方法有益處。 除非我知道他們的編碼風格的原因是由於錯誤信息,否則我絕不會在沒有充分理由的情況下判斷我的方式更好。 最好的辦法就是問問他們為什麼選擇這種方式; 一定要對他們的推理感興趣,因為那是你需要攻擊的,而不是他們的能力。

編碼標準肯定會有所幫助,但如果它是每個軟件項目的答案,那麼我們都會在天堂的私人島嶼上啜飲雞尾酒。 實際上,我們都很容易出現問題,而軟件項目的成功率仍然很低。 我認為問題主要來自個人能力,而不是常規問題,這就是為什麼當問題出現醜陋的頭腦時,我建議通過解決問題來解決問題。

最重要的是, 不要立即假定你的方式更好 。 事實上,這可能是,但我們正在處理另一個人的意見,對他們來說,只有一個解決方案。 永遠不要說你的方式是更好的方法,除非你想讓他們看到你是一個自負的失敗者。


您可能希望關注不良代碼的影響 ,而不是將您的主觀看法看作是好還是不好的風格。


我和我一起工作的人有一個類似的塞納里奧..他們沒有像我那樣接觸編碼,但他們仍然在編碼方面很有用。

而不是讓我做他們想做的事,然後回頭編輯整個事情。 我通常只是坐下來向他們展示兩種做事的方式。 他們的方式和我的方式,從這裡我們討論每種方法的專業和缺點,從而更好地理解和更好地了解我們應該如何進行編程。

這是真正的翻新部分。 有時他們會提出即使我沒有答案的問題,經過研究,我們都會得到更好的方法論和結構概念。

  1. 討論。
  2. 告訴他們為什麼
  3. 甚至不認為你總是對的。有時甚至他們會教你新的東西。

那就是如果我是你,我會做什麼:D


我喜歡代碼,在我的生活中從來沒有關於信息學的任何課程,我開始非常糟糕,開始從例子中學習,但自從我讀了“四人幫”書以來,我一直記得併記住的是:

“每個人都可以編寫機器可以理解的代碼,但並不是所有人都可以編寫人類理解的代碼”

考慮到這一點,代碼中有很多工作要做;)


我沒有參加並開放一種社會方法。

以古典希臘哲學家蘇格拉底命名的蘇格拉底方法是一種哲學探究形式,提問者探究其他人立場的含義,刺激理性思考和闡釋思想。 這種辯證的方法往往涉及一種反對意見的討論,其中一種觀點的辯護與另一種觀點相抵觸; 一位參與者可能會以某種方式引導另一位自相矛盾,加強詢問者的自己的觀點。


我無法強調足夠的耐心。 我已經看到了這種完全相反的事情,主要是因為有人希望現在發生變化。 很多環境需要進化的好處,而不是革命。 而今天通過強制改變,它可能會給所有人造成一個非常不愉快的環境。

買入是關鍵。 你的方法需要考慮到你所處的環境。

這聽起來像你處於一個有很多“個性化”的環境中。 所以......我不會建議一套編碼標準。 它會遇到你想要把這個“​​有趣”的項目,並把它變成一個高度結構化的工作項目(哦,太棒了,接下來......功能性文檔?)。 相反,正如別人所說,你必須在一定程度上處理它。

保持耐心,並努力教育他人朝你的方向發展。 從邊緣開始(代碼與其他人交互的地方),並在與代碼交互時嘗試將它作為討論他們創建的接口的機會,並詢問它們是否可以與它們一起修改(通過你或他們)。 並充分解釋為什麼你想要這個改變(“它會幫助更好地處理改變的子系統屬性”或其他)。 不要挑剔並試圖改變你認為是錯誤的一切。 一旦你與其他人進行交流,他們應該開始看到它是如何使他們的代碼核心受益的(如果你有足夠的動力,更深入,真正開始討論現代技術和編碼標準的好處)。 如果他們仍然沒有看到它......也許你需要在自己內部處理這個問題(特別是在一個“有趣”的項目中)。

忍耐。 進化,而不是革命。

祝你好運。


效果可能稍晚一點,但這是商定的編碼標準是件好事。


是否讓相關人員針對他們編寫的代表性模塊的代碼準備向小組的其他成員發布演示文稿,並讓問答處理它(相信我,它會的,如果它是一個好團體,它甚至不應該變醜)。


沒有人喜歡聽別人說他們的工作很糟糕,但任何理智的人都會歡迎指導和避免不必要的工作。

一所教學學校甚至說,你不應該指出錯誤,而是把重點放在正確的方面。 例如,你不應該將難以理解的代碼指向不好,而應該指出他們的代碼特別容易閱讀。 在第一種情況下,你正在啟動其他人思考和行為像蹩腳的程序員。 在後一種情況下,你正在像一個熟練的專業人員那樣思考。


私下詢問一些“不好”的代碼段,著眼於它實際上是合理的代碼的可能性(不管你可能有多麼傾向於),或者有可能是情有可原的情況。 如果您仍然相信代碼非常糟糕 - 並且源代碼實際上就是這個人 - 那麼就馬上離開。 可能會發生以下幾種情況之一:1)該人注意並採取一些糾正措施; 2)該人不做任何事情(無視或不關心你)。

如果#2發生,或#1沒有從你的觀點來看有足夠的改善,並且它傷害了項目,並且/或者對你有足夠的衝擊,那麼可能是時候啟動一個運動來建立/執行標準團隊。 這需要管理層接受,但在基層煽動下最為有效。

祝你好運。 我感到你的痛苦兄弟。


而不是讓他們寫代碼,讓他們維護他們的代碼。

直到他們不得不保持他們熱氣騰騰的一堆意大利面,他們才會明白他們在編碼方面有多糟糕。


舉例來說。 向他們展示正確的方式。

慢慢來。 不要因為每一個小錯誤而鞭打他們,只要從真正重要的事情開始。


錯誤的命名實踐:始終不可原諒。

是的,不要總是認為你的方式更好......這可能很困難,但必須保持客觀性。

我有一個編碼器的經驗,這個編碼器有很多可怕的函數命名,代碼比不可讀的更糟糕。 這些功能對他們所做的事情撒了謊,代碼是無稽之談。 而且他們保護/抵制讓別人更改他們的代碼。 當他們非常有禮貌地對抗他們時,他們承認這個名字很糟糕,但是希望保留他們對代碼的所有權,並且會在“稍後的日期”回去修復它。 這是過去的現在,但你如何處理錯誤被確認,但受到保護的情況? 這持續了很長時間,我不知道如何突破這個障礙。

全局變量:我自己並不喜歡全局變量,但我知道有一些其他優秀的程序員喜歡他們很多。 以至於我認為在許多情況下它們並不是那麼糟糕,因為它們允許清晰,易於調試。 (請不要火焰/ downvote我:))歸結起來,我已經看到了很多非常好的,有效的,無錯的代碼,它使用全局變量(不是由我放入!)和大量的馬車,不可能讀取/維護/修復精心使用適當模式的代碼。 也許有一個地方(儘管可能縮小)的全球變數? 我正在考慮根據證據重新思考我的立場。


開始做代碼評論或結對編程。

如果團隊不會去那些,請嘗試每週的設計評論。 每週會見一小時,並討論一些代碼。 如果人們看起來很防守,那麼選擇舊的代碼,至少在開始的時候,再沒有人會情緒化。

正如@JesperE所說:專注於代碼而不是編碼器。

當你看到你認為應該有所不同的東西時,但其他人不會以同樣的方式看待它,然後從提出導致缺陷的問題開始,而不是指出它們。 例如:

全局 :你認為我們會想要有多於一種嗎? 你認為我們會想要控制對此的訪問嗎?

可變狀態 :你認為我們會想從另一個線程操縱它嗎?

我還發現把注意力放在可以幫助人們放鬆的限制上是有幫助的。 例如:

長時間的功能 :我的大腦不夠大,無法一次完成所有這一切。 我們如何製作可以處理的小片?

不好的名字 :當閱讀清晰的代碼時,我很容易感到困惑; 當名字有誤導性時,我就沒有希望了。

最終,您的目標不是讓您的團隊如何更好地編寫代碼。 這是為了在你的團隊中建立一種學習文化。 每個人都希望其他人幫助成為更好的程序員。





coding-style