題:
如何在不失信譽的情況下處理多個錯誤?
cryptgen
2020-01-23 20:03:31 UTC
view on stackexchange narkive permalink

簡而言之:我一年內在計算軟件中犯了多個錯誤。這些錯誤不會造成任何傷害,但是如果我採用錯誤的方法,恐怕我將失去信譽。我真的很感謝在此問題上的一些建議,因為這是我大學畢業後的第一份工作。

詳細信息:自大約兩年以來,我在一家規模較大的公司(約100至200人)工作。在公司內部,我正在一個大約5個人的小組中工作。我全權負責10年之久的軟件的維護和錯誤修復(這是一團糟)。該軟件用於計算我們產品的安全裕度(例如,計算椅子最多可容納100公斤)。去年,有人報告了一個錯誤,該錯誤表明該程序計算出的一些數字沒有加起來。我發現了問題,事實證明那個人是對的。但是,這不是問題,因為該問題對我們有利(在主席的示例中,允許的重量為105kg而不是100kg)。因此,對客戶和我們都沒有造成任何傷害。我在公司年度內部更新會議中介紹了此修復程序(除其他事項外)。到目前為止,一切都很好。

今天,我開始寫一份有關我們去年出售產品的詳細報告,並仔細研究這些數字。我注意到似乎有些不對勁,所以我再次深入研究該程序,發現導致去年出現問題的同一錯誤仍然存在於代碼的不同部分,並且仍然導致數字略有下降。錯誤(椅子將容納107公斤,現在是正確的結果)。同樣,這不會對公司造成傷害或問題。但是,公司的不同部門都依賴於計算得出的數字,我將不得不對該問題進行全公司範圍的更新。

現在,我擔心這會導致我的同事和公司對我,軟件包和所提供的號碼失去信任。我不擔心失業,只擔心工作的信譽。您將如何處理該主題?您會在公司範圍內的更新中強調哪一點?

我對這個問題感到困惑。您說您負責錯誤修復。您正在修復錯誤,並在修復相似的錯誤時主動尋找它們。您正在按照您說的要付款的方式去做,那麼這裡需要解決的具體問題是什麼?
在我的理解中,@EricLippertop的任務是修復他所做的錯誤,但是沒有註意到他僅部分修復了該錯誤(該錯誤仍然存在於代碼的另一部分中),因此他擔心必須更新每個人,因為他們會認為自己沒有修復該錯誤。第一次正確。
您是在編寫帶有計算錯誤的代碼,還是在您在那里工作之前存在這些錯誤?
我同意埃里克·利珀特(Eric Lippert)的觀點,但我也想問一下,您是否為您的軟件提供了自動化測試套件?如果不是,那是一個很好的起點,因為現在您可以證明您正在積極採取措施避免錯誤(例如,通過在引入錯誤時發現錯誤或能夠以更正式的方式發現現有錯誤)來解決問題證明您確實很盡職:)
-1
我必須要問:您是否確定沒有像您所說的那樣故意將“錯誤”作為“安全餘量”包括在內?我當然希望聲稱可以支撐100公斤的東西不要立即摔壞,因為我把那101公斤放在上面;)
您是在參與原始實現,還是您從其他人那裡繼承來的代碼需要維護?
十二 答案:
Sourav Ghosh
2020-01-23 20:13:11 UTC
view on stackexchange narkive permalink

我在這裡沒有看到問題

  • 您發現了一個錯誤,[100〜105例]報告了該錯誤並提供了修復程序。
  • 一段時間後,您發現了另一個錯誤[105〜107一個](也可能是修復該錯誤的方法)。

一個人可以說,應該早已被發現,但是您實際上是發現此錯誤並提供解決方案的人。直到並且除非您獨自負責對整個應用程序 [*] sup>進行質量檢查並確保正確性-我要說,這是您在分配任務之外要做的額外工作。 / p>

繼續,以與上次相同的方式發布更新。

正如Richard U的另一個絕妙答案中提到的,

您不會因為承認(您的)錯誤而失去信譽,而是通過隱藏它們而失去了信譽。


[*]-維護和錯誤修復並不完全質量檢查(查找錯誤)。

@Chris,好的,我從未要求OP聲稱他們已經超越了我,我是在暗示他們沒有什麼可恥的。他們發現了錯誤並將要修復的事實是額外的,而不是更少。顯然,沒有什麼值得誇耀的,但也不是遺憾。
+1只是為了“您不會因承認錯誤而失去信譽,而是通過隱藏錯誤而失去信譽。”我真的花太多時間向我的同事們解釋這件事。
@LP154謝謝,如果這是紫外線的原因,請考慮對理查德的另一個回答重複此舉-我偷了他的話。
“您不會因承認錯誤而失去信譽,而是會通過隱藏錯誤而失去信譽。”-僅當您失敗時:)
“超出您分配的任務” –這就是我要關注的部分。那是員工應該做的事情嗎?
@Mazura無法對此發表評論,但是在這種情況下怎麼了?我認為這是對時間的充分利用。
基本上是星號。不是由我或您來決定什麼是對時間的有效利用,這取決於他們的經理。如果他們應該進行質量檢查,並且正在修正錯誤以使其成為英雄……或從事其他比他們更擅長的工作(或踩踏別人的腳趾,因為*您*擅長比他們更重要,而且他們與老闆有關係...)。
@Mazura和所有這些要點都歸於無能的經理/管理人員-此處的員工沒有過錯。在缺乏明確方向(即有空閒時間)的情況下,嘗試通過查找和修復錯誤來改進產品在我的規則書中是積極的。YMMV。
Old_Lamplighter
2020-01-23 20:50:14 UTC
view on stackexchange narkive permalink

您不會因為承認錯誤而失去信譽,而會因為試圖掩蓋錯誤而失去信譽。

在您的特殊情況下,您的計算器在計算重量容忍度方面比較保守,這只會增加安全,正如您所說,沒有造成任何傷害。

您自己發現錯誤並糾正錯誤的事實值得我們驕傲,而不是感到羞恥。

嘿。我發現了一個錯誤,並進行了修復。對我們或我們的聲譽無害。

我對發現錯誤的人比發現錯誤然後無視或悄悄解決錯誤的人更加自信,希望沒有人會注意。

指出並糾正自己的錯誤就意味著您可以被信任,而且,這比任何其他事情都更能證明您的信譽。

我也贊成,但是我不太喜歡第二句話。我認為計算器是“保守的”並不重要-純粹靠運氣是保守的,而且錯誤很可能是在另一個方向。我認為不應該對錯誤的確切方向給予任何關注(在技術討論中,必須進行一些更正的情況下除外)。
@Džuris錯誤的方向確定是否損壞
就是這個如果您想獲得更多的獎勵積分,請提出一些技術來防止/減少將來的這種情況,例如單元測試,集成測試,代碼審查,增加棘手部分的代碼審查員數量等。
確實是@dwizum。我借用了同樣的東西來補充我的答案。
正如我對Sourav的回答所說:+1只是為了“您不會因為承認錯誤而失去信譽,而是因為試圖隱藏錯誤而失去了信譽。”我真的花太多時間向我的同事們解釋這件事。
@Džuris不說任何有關方向的信息,這會讓人們感到疑惑(並希望問)“一切都很好,還是我們需要召回產品,因為它們不能承受指定的重量”。在最初的交流中包含這一事實表明,cryptgen正在考慮整個公司,而不僅僅是考慮他們正在維護的軟件,這將對他們產生積極的影響。
@RichardSaysReinstateMonica有人可能會說,錯誤的方向僅決定了所造成損害的類型。通過更加保守,計算可以說是迫使該公司使用多餘的材料,或者可能使用更昂貴的製造工藝來生產可以便宜地生產而不會低於安全閾值的椅子。
“錯誤的方向決定了是否損壞”是非常正確的。我聽到工程師說過這樣的想法:“任何白痴都可以設計一個永遠不會倒下的橋樑。秘密在於設計一個幾乎不會倒下的橋樑。”
@candied_orange“好的工程師永遠是保守的”。
@SamYonnou通過提高誤差幅度所花費的資金遠遠少於附帶懲罰性賠償的訴訟。這就是懲罰性賠償的原因。
優秀的工程師@RichardSaysReinstateMonica正確地掌握了數學原理,因此他們知道自己的保守程度。
@candied_orange“小心謹慎”對不起,我來自一個工程師和工匠家庭。
amcdermott
2020-01-23 21:48:57 UTC
view on stackexchange narkive permalink

就像其他人所說的那樣,您似乎已經找到了一個已存在的錯誤並已修復。如果我的團隊成員做到了這一點,我將感到非常高興。

為獲得額外的榮譽,請嘗試弄清楚如何更改流程以阻止此類事情在將來從網上溜走:

  • 您是否擁有設備測試?您的代碼覆蓋率統計如何?是否有涵蓋此場景的測試。考慮建議採取一致的措施,在應該已經存在的單元測試中進行改造,並確保為所有新代碼提供足夠的單元測試。
  • 您的錯誤修復過程是什麼樣的?我總是喜歡從編寫一個單元測試開始,該單元測試反映了導致問題顯現的條件。在實施錯誤修復之前,此操作將失敗。然後,如果再次發生問題,單元測試就在您的代碼庫中。您將知道。
  • 我的團隊完成的定義包含單元測試審查。在這裡,團隊的另一名成員(大多數是質量檢查人員-但可以是任何人)都要檢查為票證編寫的單元測試,以確保在所有可能的情況下至少有一個測試。
  • 質量檢查流程是否存在問題?那裡可以更改什麼?要求(或驗收標準)是否足夠詳細?
另外,尋找減少代碼重複的機會,因此,如果您在一個地方修復錯誤,那麼在另一個地方幾乎沒有相同的代碼和幾乎相同的錯誤。
此處同上:缺少可以補救的測試。將其描述為“我想將30%的時間用於代碼審查並建立一些可通過該軟件運行的可靠測試用例。是否有其他工程師可以協助驗證用於我的測試用例的參數?”。主動解決問題和增加驗證對人們來說都是巨大的獎金機會。我希望有人在我的團隊中這樣做-假設我沒有其他截止日期。
computercarguy
2020-01-24 00:18:21 UTC
view on stackexchange narkive permalink

以具有7年以上專業經驗,+ 25年的總體編程經驗以及幾年在大學學習中的經驗的軟件開發人員的身份來說,犯錯誤是很常見的,並且通常不會降低您的聲譽。

世界上每個軟件開發人員都犯了錯誤。 Linux的創始人Linus Torvalds犯了錯誤。蘋果,谷歌和微軟的工程師會犯錯誤。從字面上看,每個編寫軟件的人都會犯錯誤。如果沒有,那麼所有軟件都將是100%安全的,可以完美運行,而且除了添加新功能外,不需要更新。

在某些情況下,您的聲譽會受到損害。正如別人提到的那樣,隱藏錯誤是一個大問題。同樣,將錯誤歸咎於其他人也是一個問題,除非您可以實際證明是其他人(無論如何,這通常都是小事,除非您要為引起的問題而被解僱)。即使您經常犯錯誤,這也是您的第一份工作,並且您只有幾年的經驗。您仍在學習中並且期望會犯錯誤。只要您從錯誤中學習,通常就可以了。如果您仍然犯同樣的錯誤,那就成了問題。但是您在其他地方發現並最重要 已修復相同錯誤的事實表明您正在從錯誤中學習。

這些錯誤可能應該是被質量檢查人員抓到。既然不是這樣,可能很難找到它們,或者您的質量檢查部門缺乏。在知道了第一個問題之後的一年中,該軟件中沒有發現相同的錯誤這一事實表明,這不是一個容易發現的錯誤。建議改進流程將增加您的聲譽,而不是降低聲譽。

繼續學習,不斷努力改善自己,但是要意識到,因為你是人,所以你會犯錯誤。有多種方法可以自我校正,例如單元測試,自動測試和其他測試選項,因此請確保正確使用它們。只要您做出誠實的努力,並且您的經理&團隊知道這一點,就可以了。

是的,質量檢查在這裡有點問題。該軟件是由大約10年前的兩個人開發的,兩個人都從那以後離開了。但是,他們在公司中受到信任,該軟件本身非常龐大,並且是用LabView編寫的,因此,基本上,質量檢查部門中沒有人願意碰這件事。計算將進入檢查程序,並檢查結果的“一致性”。我是唯一查看代碼本身的人。我真的應該考慮一種方法,可以問我的主管,讓它進行一些質量檢查,即使只是程序的一點點。
@cryptgen,非常高興那些傢伙被信任,但是有一個非常真實的概念叫做“信任,但是驗證”,在軟件開發中非常重要,因為我敢肯定您已經知道或正在學習。無論他們是否喜歡,肯定都需要對此項目進行質量檢查。而且,當它們被引入時,可能會需要更多的開發時間,因為它可能會發現大量的錯誤。大多數軟件都會這樣做,尤其是在質量檢查人員從未接觸過它的情況下。
bobsbeenjamin
2020-01-24 07:21:28 UTC
view on stackexchange narkive permalink

比如說“記住我幾個月前修復的錯誤嗎?好吧,我在代碼庫的其他部分發現了一個類似的錯誤。此錯誤對我們有利,所以沒有人受到它的傷害。 ,一個bug就是一個bug,因此我將盡快推出修復程序。”

附帶說明一下,100-200名員工是中型公司。
Solar Mike
2020-01-23 21:00:26 UTC
view on stackexchange narkive permalink

因此,您正在查找並更正10年前(即加入公司8年之前)編寫的代碼中的錯誤。

這些不是您的錯。

因此,只需報告更正,以便所有人都可以知道。我確實想到了一點-代碼的其他部分現在可以報告不正確的值,因為您糾正的那些錯誤中的“容忍度”已經降低。

即使OP寫下了錯誤:每個人都會犯錯誤,這就是我們擁有單元測試,集成測試等的原因。良好的公司文化不會怪罪犯錯誤的人,而是試圖找出發生錯誤的原因以及如何避免錯誤。
-1
Kevin
2020-01-24 00:35:03 UTC
view on stackexchange narkive permalink

我將發布半均值答案:您已經在基地。您的同事 將至少對您的數字失去一點信心。這是很自然的-您說X為100,事實並非如此。您說Y是210,但實際上是224。所以現在當您說Z是70時,他們會想知道...實際上是70嗎?

是這樣嗎?不要從小丘上爬山。有時候是這樣的。給大家而且數字本身的絕對精度可能比它們對數字的影響更重要。

您應該解決的方法是:不要對此沒有什麼大不了的,並專注於讓您的工作前進的準確性有助於重新樹立您的數字正確的信念。他們要恢復信任“ Z為70”的唯一方法是如果您建立了提供準確數字的歷史記錄。

是的,在我開始聽到諸如“讓我們確保我們給予額外的時間來集成X,因為它相當不可靠”之類的消息之後,只需連續幾個錯誤。或“我們最好再次檢查這些數字。”您可以增加測試時間。您也可以進行基於證書的檢查。讓算法X給出答案。然後使用算法Y驗證答案(驗證答案通常比提出答案更容易)。如果兩種方法不同意,則報告錯誤而不是報告錯誤的答案。當我們一直在腦海中進行數學運算時,我們就會這樣做。
dan.m was user2321368
2020-01-23 22:51:32 UTC
view on stackexchange narkive permalink

寫一個單獨的答案,因為我想解決OP的問題中的一個問題(並且在某些回答中也得到了回應)。

除非您的系統經過精心設計,以使錯誤總是導致“保守主義” “因此增加了安全裕度,所有錯誤,無論它們是增加還是減少安全都同樣重要。

在對錯誤頻率等進行任何形式的分析時,您不應該支付費用對它們的毀滅性有太多的關注,而是對它們的破壞性有多大:僅僅因為你很幸運,並不意味著你下次會很幸運。

Minnie
2020-01-24 04:44:32 UTC
view on stackexchange narkive permalink

無時無刻不在發生,放鬆吧!

您應該為自己做的事情:

  • 弄清楚該錯誤是否已經存在當您接管該軟件時,或者在處理其他內容時介紹了該軟件。如果是您,請考慮如何在將來避免這種情況。

  • 如果系統要使用幾年,請考慮編寫大量可捕獲性能的單元測試。當前狀態,因此您可以查看新更改何時會破壞某些功能。確保您編寫的測試是理智的,也許您會發現一些額外的錯誤可以修復。

WGroleau
2020-01-24 14:06:57 UTC
view on stackexchange narkive permalink

如果僅是兩個錯誤(“多個”聽起來很糟糕,是吧?)的問題,那麼承認它比冒被人認為是藏匿東西的風險更好。

錯誤:計算錯誤,然後在其他地方無法檢查相同的錯誤,最後(如果確實是相同的錯誤)在兩個地方重複執行代碼而不是調用

技術寫作和軟件中的一句諺語是,“完全相同”的事物傾向於以證明墨菲正確的方式變得不完全相同。

Harper - Reinstate Monica
2020-01-26 04:33:42 UTC
view on stackexchange narkive permalink

正如其他人指出的那樣,這不會傷害您。

但是真正使您獲勝的是想出一個質量檢查系統來查找所有計算錯誤。含義軟件測試:一種軟件,它通過將一系列已知輸入集和已知答案集中起來來檢查軟件,並確保計算正確無誤。從來沒有做過;這就是為什麼這些錯誤會持續存在的原因。這可能是您戴上帽子的主要羽毛。

請注意,如果有質量保證職業,您應該這樣做。您可能會做很多事情。

Pete Danes
2020-01-24 20:30:39 UTC
view on stackexchange narkive permalink

同意之前的所有內容-不是您的錯,您是在做應該做的事情,是在尋找並解決其他人的舊錯誤,等等。

我的兩分錢值得補充的是,我將召集一次有關該問題的會議,因為您發現舊代碼中有兩個錯誤,所以您現在對整個程序包感到懷疑,並且您希望對整個程序進行徹底的分析。提出您將如何進行這項工作,以及進行什麼測試以確保您自己滿意,現在可以正確調試代碼了。甚至還有更多的錯誤-代碼中仍然存在潛伏狀態,並且您擔心反复宣布要修復的程序,然後不得不宣布它尚未修復,這是完全合理的。太多的事情確實損害了您的信譽。

要說您可以很好地解決單個問題,但是鑑於您在代碼中所看到的,您不能保證其正確性。整個程序包,除非您有機會徹底檢查它。不用說,我希望,如果給您這樣的機會,那麼最好確保您做對了。認真詳盡的測試,讓其他人(最好是其他幾個人)陪同您進行測試,讓其他人設計自己的獨立測試並驗證輸出等。

取決於該軟件對您的重要性公司。如果它很重要,並且您可以很好地使其達到現代標準,從而使每個人都對它產生的產品充滿信心,那麼這個“問題”實際上可能是一個很好的機會,展示您對公司的價值



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...