0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

一位國外開源工程師七年的工作感悟

工程師人生 ? 來源:網(wǎng)絡(luò)整理 ? 作者:工程師吳畏 ? 2018-07-30 18:45 ? 次閱讀

幾百個人排成一個隊伍,候在你家門外。他們耐心等待你去解答問題、聽他們的抱怨、回復(fù) Pull Request 和 Feature Request 。

你想去幫他們所有人,但你一直拖到現(xiàn)在。也許你辛苦工作了一整天,或者你累了,再或者你只是想跟家人和朋友享受周末。

但你如果登陸 github.com/notifications,Notification 會不斷提醒有多少人在等著你:

當(dāng)你設(shè)法找到一些空閑時間,你開門迎接第一個人(即處理第一個問題,其中可能包含不止一個人,下同)。他們足夠善意;他們想使用你的項目,但在 API 上陷入一些困惑。他們把代碼粘貼到 GitHub 評論上,但是忘記了或者不知道怎么格式化代碼,結(jié)果代碼一團糟。

還好,你編輯了他們的評論以添加代碼塊,把代碼格式化了。但仍有許多代碼需要讀。

另外,他們對問題的描述有些讓人難以理解。也許英語不是他們的母語,或者他們在書面表達(dá)上能力不足。不管怎樣,你努力去理解他們提交的文本段落。

你疲倦地看了一眼,排在隊伍后面等待的另外幾百個人。你可以花半個小時去理解這第一個人的代碼,或者你可以只是瀏覽一遍然后給出一些教程或者文檔的鏈接,說不定可以幫助他們解決問題。你還愉快地建議他們嘗試 Stack Overflow 或者 Slack 。

第二個人皺著眉頭,臉上露出不悅的神情。他們不斷抱怨你的項目如何浪費了他們生命中的兩小時,因為某個 API 沒有宣傳中的效果。他說的話很刻薄,讓你很不舒服。

你沒有在這個人身上浪費太多時間。你簡單地說道,“這是一個開源項目,且由志愿者維護。如果代碼中有 Bug,請?zhí)峤灰粋€可復(fù)現(xiàn)的測試案例或者 PR ?!?/p>

第三個人遇到的是一個很常見的錯誤,解決方法很簡單。你之前看到過幾次這個錯誤,但是一時想不起解決方法在哪。Stack Overflow?維基?郵件列表?在谷歌搜索了幾分鐘后,你粘貼上了一個鏈接然后關(guān)閉了這個 Issue 。

第四個人是一個定期的貢獻者。你從多個社區(qū)討論會和兄弟項目( sibling project )中識出了他們的名字。他們陷在一個十分晦澀的 Issue ,并提交了一個 Pull Request 來解決它。很不幸這個 Issue 很復(fù)雜,所以他們的 PR 中包含許多枯燥的段落,來解釋問題。

再一次地,你瞥了一眼還在排隊等待的幾百號人,你知道這第四個人在他們的解決方案上花了很多工夫,并且可能這個解決方案是合理的。Travis 測試通過,所以你打算只評論句“LGTM”,然后合并掉這個 Pull Request 。

然而,你之前被這類情況傷過。在過去,你合并了一個 PR 但沒有經(jīng)過充分的評價,最終因為一些你沒有預(yù)見到的問題,它導(dǎo)致了新的麻煩。也許是測試通過了,但性能下降了 10% ?;蛘咚l(fā)了一個內(nèi)存泄漏?;蛘呖赡苓@個 PR 讓新用戶對項目感到困惑,因為它使得 API 看起來過于復(fù)雜。

如果現(xiàn)在你合并了這個 PR,以后可能會有更多的問題,因為你為解決這個人的問題而打斷了另一個人的工作流程。所以你把它放在次要位置,等有了更多時間再去處理它。

第五個人發(fā)現(xiàn)了一個新 Bug,但你知道實際上它是兄弟項目中的一個 Bug 。他們說這阻礙了他們啟動 App 。你知道這是個大問題,但只是眾多問題中的一個,所以你此刻沒有時間去修復(fù)它。

你回應(yīng)道,這看起來是一個真實的問題,但是它更適合在另一個 Repo 中打開。所以你關(guān)閉了他們的 Issue,把它復(fù)制到了另一個 Repo,然后你添加一個評論提示,在代碼中從哪里開始修復(fù)它。盡管你懷疑他們實際上會這個做。很少人會。

第六個人只說道“現(xiàn)在是什么情況/狀態(tài)?”你不知道他們在談?wù)撌裁?,所以你看一下上下文。關(guān)于項目中的一個長期存在的 Bug,他們在冗長的 GitHub 線程上進行了評論。許多人不同意這個問題目前的解決方案,所以產(chǎn)生了許多討論。

在這個特定 Issue 下有超過 20 條評論,要讀完并記住,需要花費你很長的時間。所以你僅僅回應(yīng)道,“對不起,這個 Issue 開放了一段時間了,但還沒有人解決它。我們?nèi)栽囍ダ斫鈫栴}的范圍,最好是開一個 Pull Request !”

第七個人只是個 GreenKeeper 網(wǎng)站機器人。他們的問題很簡單,除了這個特殊的 Repo 中有相當(dāng)碎片化的測試,且這個測試由于看起來像是謬誤的原因失敗了,所以你不得不重新測試看是否通過。你重啟了這個測試,并試圖讓自己記住在 Travis 有機會運行后再去觀察一下。

第八個人開了一個 Pull Request,但所在的 Repo 相當(dāng)活躍,另一個維護者已經(jīng)做出反饋。你看了一眼線程,你相信其他維護者會處理好,所以你標(biāo)記它為已讀,然后走開繼續(xù)。

第九個人遇到的似乎是個 Bug,而你之前也沒見過。但不幸的是,他們對“這個問題實際是如何發(fā)生的”沒有提供足夠的細(xì)節(jié)。是什么瀏覽器下出現(xiàn)的?哪個 Node 版本?哪個版本的項目?他們用什么代碼來復(fù)現(xiàn)它?你讓他們做出澄清,然后關(guān)掉這個標(biāo)簽。

問題不斷涌進

不一會兒,你接待了 10 到 20 個這樣的人。仍有 100 多個在排隊等待。但此刻你感到精疲力盡;每個人不是抱怨,就是有問題要解答或者是有增強的請求。

在某種程度上,這些 GitHub 通知就是不斷涌出你項目中差的一面。當(dāng)他們滿意你的工作時,就不會有人建立一個 Issue 或 Pull Request。只有當(dāng)他們發(fā)現(xiàn)有所缺失,才會如此。即使你只花了一點時間閱讀這些通知,在精神和情感上都是消耗。

你妻子觀察到在例行完這些公事之后你總是暴躁易怒。也許你發(fā)現(xiàn)自己總是沒緣由地對她厲聲呵斥,僅僅是心情不好。她問你:“如果開源工作這么讓你憤怒,為什么你還要做它?”你找不到一個好的答案。

你可以暫停;事實上目前你可能已經(jīng)有所體會了。在過去,你曾從 GitHub 休假過一兩個星期,只為了精神健康。但最后因為有幾百個人在耐心等待(你去處理問題),不得不停止休假。

如果你過去持續(xù)跟進 GitHub 通知,你可能每天要處理 20-30 條。相反,你讓它們堆積,所以現(xiàn)在攢了幾百條。你感到內(nèi)疚。

在過去,由于這樣或那樣的原因,你確實讓這些 Issue 堆積。你或許看到一條數(shù)個月都沒人應(yīng)答的 Issue 。通常,當(dāng)你返回找到那個Issue,提出這個 Issue 的人從不回應(yīng)。或者他們這么回應(yīng),“我們放棄了你的項目而用了另一個,這樣我的問題就解決了?!?這讓你感覺很糟,但你明白他們的挫敗感。

你從經(jīng)驗中得知,對于這些陳舊的 Issue,最實用的回應(yīng)往往是只說句,“我要關(guān)閉這些舊的 Issue,如果這對你仍是個問題,或者你能提供更多的細(xì)節(jié),請重新開一個 Issue ?!蓖ǔ]有人回應(yīng)。有時候有,也僅是一個憤怒的評論,抱怨怎么讓他們等這么久。

所以現(xiàn)在你想更勤快地處理你的通知收件箱。幾百條太多。你渴望這個數(shù)字縮減到一百,幾十,或者甚至是神話般地清空。所以你奮力前行。

吸引新的貢獻者

在處理完足夠多這樣的 Issue 后,即使你的收件箱最終被清空,最后可能仍會積壓大量的 Bug 和 Pull Request 。標(biāo)簽可以起到作用——例如,你可以把 Issue 標(biāo)記為“需要復(fù)現(xiàn)”或“有測試用例”或者“很贊的首個補丁”?!昂苜澋氖讉€補丁”尤其有幫助,因為他們常??梢晕叫碌呢暙I者。

然而,你發(fā)送能吸引到新貢獻者的那一類 Issue ,往往是處理起來非常簡單的那一類,這一類 Issue 由新的志愿者去記錄,比你親自去做更有價值。你創(chuàng)建了一些這類的 Issue,因為你知道它的價值所在,讓新人參與到開源,當(dāng)這條 Pull Request 的作者告訴你“這是我在開源社區(qū)做的第一個貢獻?!?你感覺很棒。

但你知道他們回來的希望很渺茫;通常這些朋友不會成為定期貢獻者或維護者。你懷疑是不是你哪里做錯了,你在哪方面改進,才能吸引住新的貢獻者來幫你減輕負(fù)擔(dān)。

你有一個項目幾乎就是靠自身維持的。你多年沒碰了,但有一幫維護者會回應(yīng)每一個 Issue 和 PR ,所以你不必親自去。你非常感激這些維護者。但你不知道你做了什么才使得這么多貢獻者投入這個項目,而其他項目最后都是你,且只有你自己負(fù)責(zé)。

向前看吧

你不愿去創(chuàng)建新項目,因為你知道它只會增加你的維護負(fù)擔(dān)。事實上,這里有一種反效應(yīng),你做得越成功,在 GitHub 通知上得到的“懲罰”就越多。

你仍能回想起這種創(chuàng)建的快感,從零開始寫一個新項目以及解決一個之前未解決問題的喜悅。但是現(xiàn)在你開始衡量這種喜悅,因為任何新項目必定會從舊項目中奪走時間。你不知道是否是時候該正式摒棄你的一個舊 Repo,或者把它標(biāo)記為 Unmaintained。

你不知道在你倦怠之前,這樣的情況還要持續(xù)多久。你曾考慮將開源工作作為你的白天工作,但是自從你和真正從事開源為生的朋友交流后,你知道這通常意味著,讓一個特定的開源項目作為你的白天工作。這對你無益,因為你有幾十個跨越多個領(lǐng)域的項目,這些都在爭奪你的時間。

你最想要的是更多的項目可以自身獨立維持,你嘗試去遵守所有的最佳實踐:你有 CONTRIBUTING.md 和行為指導(dǎo),你熱情地交出擁有的特權(quán),給任何提交高質(zhì)量 PR 的人。然而每個項目都這么做,也很耗費精力,所有你沒有你期望的那樣勤奮。

你也為此感到內(nèi)疚,因為你知道開源常常被看做是有特權(quán)的白人男性(比如你自己)的專屬俱樂部。所以你擔(dān)心你做的還不夠,去解決那樣的問題。

更重要的是,你感到內(nèi)疚:內(nèi)疚來自于你知道你本可以幫助有些人解決他們的問題,但你讓他們的 Issue 在關(guān)閉前被無視了好幾個月,或者有人在你的 Repo 開了他們第一條 Pull Request,但你沒有時間去回應(yīng),這可能因此讓他們沮喪到永遠(yuǎn)不想再參與開源。你的內(nèi)疚是因為你已做的事情,也是因為你沒做過的事情,以及因為你沒能招募到更多的人分享你的不幸而有負(fù)罪感的經(jīng)歷。

集中到一起

以上我說的一切都是基于我自己的經(jīng)驗。我不能聲稱自己代表所有開源軟件工作者,這是我自己的感覺。

我從事開源工作已經(jīng)有很長一段時間了(大約 7 年),我一直不愿去抱怨任何這些牢騷,因為我擔(dān)心會被理解為是本應(yīng)了解更多的前輩在這里夸張地發(fā)牢騷。畢竟,這種處境不是我自己造成的嗎?我可以隨時離開 GitHub;我沒有跟任何人簽合約。

還有,我不該感激嗎?我從事的開源工作幫助我在社區(qū)樹立了地位。我獲得了在會議做演講的邀請。在 Twitter 上我有幾千號粉絲,他們傾聽我的想法,并對我的意見給予很高的評價??梢哉f,我得到微軟的工作是因為我的開源經(jīng)歷。我還有什么可抱怨的?

然而,我知道許多其他處在與我同樣位置的人都已倦怠?;锇閭円捕荚鵁崆榈睾喜?Pull Request ,處理 Issue,寫博客展示他們的項目,之后就消失得無影無蹤。對于其中有些人,我甚至不愿在他們的 Repo 中開 Issue 。因為我知道他們不會回應(yīng),我不反對他們,但我擔(dān)心自己會變成他們一樣。

我已經(jīng)采取了大量的自我保護措施。我不再使用 Github 通知接口——我使用電子郵件過濾器,這樣我可以基于項(Unmaintained 這一類可以忽略)或者通知的類別(提到過的或者我評論過的線程通常會有優(yōu)先權(quán))來分類通知。因為是電子郵件,這也有助于我離線工作和在同一處管理事務(wù)。

我常常會出乎意料地收到在項目上請求支持的郵件,而這個項目我停止維護已經(jīng)很久了(例如這個項目,我仍至少每月會收到一封),而通常我都是不回應(yīng)。我還選擇忽視我博文下的評論,不回應(yīng) Stack Overflow 的回答和郵件列表下的問題。我還積極地取消關(guān)注了那些我認(rèn)為其他人維護得足夠好的 Repo 。

這種情況如此令人沮喪的另一個原因是,你越來越發(fā)現(xiàn)處理 Issue 從項目實際維護中奪去太多時間,換句話說,我通常只有足夠讀取Issue,然后說“對不起,我此刻沒有時間看”的時間。僅僅是回應(yīng)的行為,就會占據(jù)我為開源預(yù)留的大部分時間。

Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、Sauce Labs… 有太多技術(shù)工具可以處理開源維護問題,我很感激有這些工具。如果沒有這些自動化工具,我就不可能保持頭腦清醒。但在某些時候,你會遇到很多 Issue,它們里面涉及的社會性問題比技術(shù)性問題更多。一個人不足以說明。我甚至沒有進到前100位 npm 維護者榜單,我就已經(jīng)累覺不愛了;我無法想象那 100 個人是什么體會。

我已經(jīng)告訴我妻子,如果當(dāng)我們打算開始要孩子,我還是放棄開源工作為好,我覺得自己沒有能力兼顧撫養(yǎng)家庭和維護開源項目,我預(yù)料到,放棄開源才是我核心問題的解決方案。我只希望它會以一種積極的形式到來,就如開始我人生新的篇章,而不是以一種消極的形式,比如毫不客氣地倦怠。

最后的一點思考

如果讀到這里,你對困擾開源社區(qū)的問題和潛在的解決方案感興趣,你可能會想研究下 Nadia Eghbal 的《Roads and Bridges》。它可能是對該問題最清晰最深入的分析。

我也樂于接受建議,盡管我在心中牢記我不愿在開源項目中把金錢和勞動混在一起(也許是出于天真的理想主義)。但我曾在其他項目中看到它是有效的。

請注意,盡管上文表達(dá)了開源消極的一面,但我仍覺得它是我生活里一個有價值的補充,我沒有任何后悔。但我希望這篇文章對大家有幫助,讓你們看到成為自身成功的犧牲者是什么感受,以及你會因為未完成的工作而感到沉重。

我從參與開源的經(jīng)歷中學(xué)到的一點就是:你參與越多,對你的要求就越多。我意識到這樣的問題,并沒有解決方法。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 工程師
    +關(guān)注

    關(guān)注

    59

    文章

    1571

    瀏覽量

    68607
收藏 人收藏

    評論

    相關(guān)推薦

    硬件工程師工作前VS工作后!抱歉!是我想的太簡單了!# #電工 #電子愛好者

    硬件工程師
    MDD辰達(dá)半導(dǎo)體
    發(fā)布于 :2025年01月08日 18:15:18

    硬件工程師工作必備書籍推薦

    硬件工程師工作必備書籍推薦
    的頭像 發(fā)表于 09-24 16:07 ?1002次閱讀
    硬件<b class='flag-5'>工程師</b>找<b class='flag-5'>工作</b>必備書籍推薦

    尋求專業(yè)工程師幫助設(shè)計USB多口充電器

    嗨, 我正在開發(fā)款USB多口充電器,現(xiàn)尋求一位專業(yè)工程師或產(chǎn)品設(shè)計的幫助。希望能夠與有經(jīng)驗的工程師合作,共同完成產(chǎn)品設(shè)計。以下是我們的需
    發(fā)表于 08-05 12:03

    正是拼的年紀(jì)|65歲電子工程師上班VLOG #65歲退休 #電子工程師 #搞笑 #上班vlog

    電子工程師
    安泰小課堂
    發(fā)布于 :2024年07月25日 11:31:02

    嵌入式軟件工程師如何提升自己?

    ,可以為自己的職業(yè)生涯打下堅實的基礎(chǔ),并實現(xiàn)個人的職業(yè)目標(biāo)。愿每一位嵌入式軟件工程師都能在這個充滿挑戰(zhàn)和機遇的領(lǐng)域中取得成功!
    發(fā)表于 06-12 11:20

    嵌入式軟件工程師和硬件工程師的區(qū)別?

    和通信協(xié)議,以及熟練掌握種或多種編程語言和開發(fā)工具。 主要負(fù)責(zé)的任務(wù)和領(lǐng)域 嵌入式軟件工程師工作涉及到各種任務(wù),主要包括: * 系統(tǒng)設(shè)計:包括確定系統(tǒng)功能、分配資源、優(yōu)化性能等。 * 軟件編程:包括編程
    發(fā)表于 05-16 11:00

    大廠電子工程師常見面試題#電子工程師 #硬件工程師 #電路知識 #面試題

    電子工程師電路
    安泰小課堂
    發(fā)布于 :2024年04月30日 17:33:15

    為何國外工程師偏愛使用for(;;)來實現(xiàn)MCU死循環(huán)?

    一位工程師發(fā)現(xiàn),國外工程師在給demo在做死循環(huán)時用的是for(;;),而不是常用的while(1)。這僅僅是個人習(xí)慣的問題,還是有更深層次的含義?
    發(fā)表于 04-01 11:26 ?703次閱讀
    為何<b class='flag-5'>國外</b><b class='flag-5'>工程師</b>偏愛使用for(;;)來實現(xiàn)MCU死循環(huán)?

    如何搞崩個硬件工程師心態(tài)?試試對ta說這幾句

    硬件工程師
    揚興科技
    發(fā)布于 :2024年02月20日 18:05:49