大數(shù)據(jù)工程師2023版 駿骨折西風(fēng)

download：https://www.51xuebc.com/thread-593-1-1.html

編寫pull request

Pull requests（PRs）是任何項(xiàng)目的根本面。它們是代碼檢查的中心。假如沒有好的描繪，代碼檢查很快就會(huì)成為團(tuán)隊(duì)性能的瓶頸。

一個(gè)好的PR描繪總結(jié)了正在停止的更改以及為什么停止這些更改。大型項(xiàng)目通常有一個(gè)拉取懇求模板

## Proposed changesDescribe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.## Types of changesWhat types of changes does your code introduce to Appium? - [ ] Bugfix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - ...## Checklist - [ ] I have read the CONTRIBUTING doc - [ ] I have signed the CLA - [ ] Lint and unit tests pass locally with my changes## Further commentsIf this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…

防止含糊的PR標(biāo)題

請(qǐng)防止下面這些標(biāo)題：

• Fix build.

• Fix bug.

• Add patch.

這些以至沒有嘗試描繪我們正在處置的構(gòu)建、錯(cuò)誤或補(bǔ)丁是什么。關(guān)于構(gòu)建的哪個(gè)局部停止了修復(fù)、哪個(gè)錯(cuò)誤被處理，或者添加了哪個(gè)補(bǔ)丁，略微提供一些額外的細(xì)節(jié)能夠大大促進(jìn)與同事之間更好的溝通和協(xié)作。它能夠使人們達(dá)成共識(shí)并站在同一個(gè)起點(diǎn)上。

Pull Request 標(biāo)題通常運(yùn)用祈使語(yǔ)態(tài)書寫。它們是整個(gè) Pull Request 的單行摘要，并應(yīng)描繪 Pull Request 所做的工作。

以下是一些好的示例：

• Support custom srcset attributes in NgOptimizedImage

• Default image config to 75% image quality

• Add explicit selectors for all built-in ControlValueAccessors

防止冗余的PR

一個(gè)大的PR意味著一個(gè)宏大的描繪，沒有人愿意檢查成百上千行的代碼，有時(shí)只是為了最終駁回整個(gè)代碼！

相反，你應(yīng)該：

• 與你的團(tuán)隊(duì)經(jīng)過(guò) Issues 停止溝通，

• 制定方案，

• 將問(wèn)題合成成較小的局部，

• 或者每個(gè)局部都有本人的 PR 。

如今是不是潔凈了許多？

在PR正文中提供細(xì)節(jié)

與 PR 標(biāo)題不同，PR 正文是包含一切細(xì)節(jié)的中央，包括：

• 為什么要停止這個(gè) PR？

• 為什么這是最佳辦法？

• 該辦法任何缺乏之處，以及處理計(jì)劃

• 相關(guān)的 bug 或跟蹤單號(hào)，基準(zhǔn)測(cè)試結(jié)果等等。

報(bào)告bug

Bug 報(bào)告是任何項(xiàng)目中最重要的方面之一。一切優(yōu)秀的項(xiàng)目都樹立在用戶反應(yīng)的根底上。通常來(lái)說(shuō)，在無(wú)數(shù)次測(cè)試之后，依然是用戶發(fā)現(xiàn)了大局部 Bug。用戶也是巨大的理想主義者，有時(shí)他們會(huì)提出功用方面的想法，請(qǐng)傾聽他們的意見！

關(guān)于技術(shù)項(xiàng)目，一切這些都是經(jīng)過(guò)報(bào)告 issue 來(lái)完成的。一個(gè)寫得好的 issue 能夠讓另一個(gè)開發(fā)人員輕松地找到問(wèn)題并停止回應(yīng)。

比方，大多數(shù)大型項(xiàng)目都有一個(gè)

### Subject of the issue Describe your issue here. ### Your environment * version of angular-translate * version of angular * which browser and its version ### Steps to reproduce Tell us how to reproduce this issue. ### Expected behavior Tell us what should happen. ### Actual behavior Tell us what happens instead.

搜集截圖

假如是 CLI 程序的截圖，請(qǐng)確保文本明晰可見。假如是 UI 程序，請(qǐng)確保截圖捕捉到正確的元素和狀態(tài)。

你可能需求捕獲一個(gè)實(shí)踐的交互過(guò)程來(lái)展現(xiàn)問(wèn)題。假如是這種狀況，請(qǐng)嘗試運(yùn)用屏幕錄制工具來(lái)錄制 GIF 動(dòng)畫。

如何重現(xiàn)問(wèn)題

當(dāng) Bug 在程序員的電腦上呈現(xiàn)時(shí)，處理起來(lái)要容易得多。這就是為什么一個(gè)好的提交信息應(yīng)該附帶可以準(zhǔn)確重現(xiàn)問(wèn)題的步驟。

下面是一個(gè)例子：

Update: you can actually reproduce this error with objects:<div *ngFor="let value of objs; let i = index"> ? <input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $event)" /></div>export class OneComponent { ? obj = {v: '0'}; ? objs = [this.obj, this.obj, this.obj, this.obj]; ?setObj(i: number, value: string) { ? ? this.objs[i] = {v: value}; ?} } The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values.

倡議緣由

作為捕獲 Bug 的人，你能夠?yàn)闉楹纬尸F(xiàn)這個(gè) Bug 提供一些潛在的緣由。或許 Bug 只在遇到某個(gè)特定事情后發(fā)作，或者只在挪動(dòng)設(shè)備上發(fā)作。

探究源碼也沒有什么害處，或許能夠找出招致問(wèn)題的緣由。然后，你的 issue 會(huì)更快地被關(guān)閉，而且你有可能被分配到相關(guān)的PR。

與客戶溝通

你可能是一名獨(dú)立的自在職業(yè)者，或者可能是一個(gè)小團(tuán)隊(duì)里的主要開發(fā)人員。在任何一種狀況下，假定你擔(dān)任與客戶在項(xiàng)目上停止溝通。

現(xiàn)往常，程序員的呆板印象是我們不擅長(zhǎng)溝通。我們以過(guò)于技術(shù)化的術(shù)語(yǔ)表達(dá)本人，通知他人什么是可能的，什么是不可能的，以至當(dāng)有人質(zhì)疑我們的辦法時(shí)，我們會(huì)變得有防御性。

那么，如何緩解這種呆板印象？訊問(wèn)客戶想要什么，并一直聽取他們的反應(yīng)。以下是如何做到這一點(diǎn)的辦法。

訊問(wèn)正確的問(wèn)題

首先要確保你和客戶的想法是分歧的：

• 您的目的受眾是誰(shuí)？

• 網(wǎng)站的目的是什么？

• 您最近的競(jìng)爭(zhēng)對(duì)手是誰(shuí)，他們做對(duì)了什么？

發(fā)問(wèn)也是以積極的方式寫作的好辦法，特別是不同意客戶的反應(yīng)或決策的狀況下。發(fā)問(wèn)迫使對(duì)方支持本人的主張，而不是經(jīng)過(guò)為本人的立場(chǎng)辯護(hù)來(lái)攻擊他們：

• 您對(duì)此能否稱心，即便它帶來(lái)額外的性能本錢？

• 挪動(dòng)組件能否有助于更好地完成我們的目的？

• 太好了，誰(shuí)擔(dān)任在啟動(dòng)后維護(hù)它？

• 您曉得這兩種顏色之間的比照能否契合 WCAG AA 規(guī)范嗎？

采購(gòu)本人

假如你要向潛在的客戶停止采購(gòu)，你就需求壓服他們雇用你?？蛻魹槭裁磻?yīng)該選擇你？提出以下內(nèi)容很重要：

• 你是誰(shuí)

• 你在做什么

• 為什么你很合適這份工作？

• 你所做過(guò)的相關(guān)工作的鏈接

一旦你得到了工作并需求起草合同，請(qǐng)記住沒有比一堆法律術(shù)語(yǔ)更令人生畏的內(nèi)容了。即便它是為設(shè)計(jì)項(xiàng)目編寫的

你對(duì)細(xì)節(jié)的關(guān)注可能是你和其他開發(fā)者贏取同一項(xiàng)目的區(qū)別。依據(jù)我的經(jīng)歷，客戶容易雇用他們以為會(huì)喜歡與之協(xié)作的開發(fā)者，而不是技術(shù)上最有才能或經(jīng)歷最豐厚的開發(fā)者。

編寫微文案

微文案是編寫用戶友好的UI信息的一門藝術(shù)，例如錯(cuò)誤音訊。我敢打賭，作為開發(fā)人員，你有時(shí)不得不編寫錯(cuò)誤音訊，由于它們不斷被放置到發(fā)布時(shí)間。

這可能就是為什么我們有時(shí)會(huì)看到這樣的錯(cuò)誤：

Error: Unexpected input (Code 693)

錯(cuò)誤是你最不希望用戶遇到的問(wèn)題。但它們的確會(huì)發(fā)作，我們無(wú)能為力。以下是一些進(jìn)步微文案技藝的技巧。

防止技術(shù)術(shù)語(yǔ)

大多數(shù)人不曉得什么是效勞器，而程序員100%曉得。這就是為什么在錯(cuò)誤音訊中會(huì)看到像 API 或超時(shí)執(zhí)行這樣的不常見術(shù)語(yǔ)。

除非你面對(duì)的是技術(shù)客戶或用戶群體，否則你的大局部用戶可能沒有上過(guò)計(jì)算機(jī)科學(xué)課程，不曉得互聯(lián)網(wǎng)是如何工作的，也不曉得為什么某個(gè)特定的東西不起作用。

因而，一個(gè)好的錯(cuò)誤音訊不應(yīng)該解釋為什么呈現(xiàn)問(wèn)題，由于這樣的解釋可能需求運(yùn)用令人生畏的技術(shù)術(shù)語(yǔ)。這就是為什么防止運(yùn)用技術(shù)術(shù)語(yǔ)十分重要。

不要責(zé)怪用戶

想象一下：我正在嘗試登錄你的平臺(tái)。我翻開閱讀器，訪問(wèn)你的網(wǎng)站，輸入我的細(xì)致信息。然后我被告知：“您的電子郵件/密碼不正確?！?/p>

雖然以為這個(gè)信息是敵對(duì)的似乎很夸大，但它在潛認(rèn)識(shí)里讓我覺得本人很愚笨。微文案表示，千萬(wàn)不要責(zé)怪用戶。嘗試將你的音訊更改為責(zé)備性更少的內(nèi)容，例如：“負(fù)疚，該電子郵件密碼組合不正確。我們能夠協(xié)助您恢復(fù)帳戶?！?/p>

我還想補(bǔ)充一點(diǎn)，防止運(yùn)用全大寫字母和感慨號(hào)十分重要！當(dāng)然，它們能夠用來(lái)傳達(dá)興奮的心情，但在微文案中運(yùn)用會(huì)給用戶帶來(lái)一種敵對(duì)感。

不要讓用戶手足無(wú)措

在微文案中運(yùn)用詼諧是個(gè)好主見！它能夠緩解心情，是減少負(fù)面影響的簡(jiǎn)雙方法。

但是，假如你運(yùn)用不當(dāng)，詼諧也有可能會(huì)讓用戶感到蔑視和凌辱。這是一個(gè)宏大的風(fēng)險(xiǎn)。

不要不顧一切地去開玩笑 - 強(qiáng)行詼諧可能比不詼諧更糟糕。假如你不肯定，請(qǐng)堅(jiān)持耿直的表情。

編寫無(wú)障礙標(biāo)志

我們能夠輕松地撰寫一篇關(guān)于無(wú)障礙性，以及與技術(shù)寫作相關(guān)的文章。事實(shí)上，無(wú)障礙性通常包含在內(nèi)容款式指南中

作為開發(fā)者，你可能曾經(jīng)十分理解無(wú)障礙性。你以至可能是很勤奮的開發(fā)者之一，將無(wú)障礙性作為工作流程的中心局部。但是，無(wú)論我們覺得無(wú)障礙性是多么重要，無(wú)障礙性依然是低優(yōu)先級(jí)。

因而，假如你發(fā)現(xiàn)本人正在將別人的文案編寫到代碼中，為其他開發(fā)者編寫文檔，以至本人編寫UI文案，要留意一些根本的無(wú)障礙最佳理論，由于它們完善了一切其他技術(shù)寫作的倡議。

一些需求留意的事項(xiàng)包括：

• 盡可能運(yùn)用語(yǔ)義標(biāo)簽（例如?、、?等）

• 遵照邏輯的標(biāo)題構(gòu)造

• 為圖片添加 alt 文本

• 留意行內(nèi)語(yǔ)義

總結(jié)

這些是展現(xiàn)技術(shù)寫作和開發(fā)互相關(guān)聯(lián)的六種方式。固然這些例子和倡議可能不是什么深邃的技術(shù)，但我希望你可以發(fā)現(xiàn)它們有用，無(wú)論是與其他開發(fā)人員協(xié)作、維護(hù)本人的工作、在緊急狀況下編寫本人的副本，或者起草項(xiàng)目提案等等。