99IT數(shù)據(jù)中心微信賬戶：i199IT

編譯：房ny_nicole

大數(shù)據(jù)發(fā)展至今已被推上了時代的風(fēng)口浪尖，社會對其的評價褒貶不一。雖然它給我們帶來了很多好處，但也有人會發(fā)出這樣的聲音：“ 大數(shù)據(jù)的人快離開我的地盤！ ”

即便如此 ，Scott Brinker仍相信，若大數(shù)據(jù)被正確運用，它將會在現(xiàn)代市場營銷領(lǐng)域產(chǎn)生無可估量的積極影響。在數(shù)字化時代，單純依靠直覺和經(jīng)驗而做出的營銷決策往往是不可信的。因此，企業(yè)若希望占據(jù)市場有利地位，就要在客觀數(shù)據(jù)分析和人類直覺判斷中找到均衡點。

Gord Hotchkiss，一名市場營銷專欄作家，他近期寫了一篇文章 《在中間地帶的市場營銷》( Marketing in the Middle ) ，表明他也支持該論點——在中間地帶找均衡點。

“市場營銷沒有所謂的絕對。我們需要那些有大構(gòu)想、執(zhí)行力強(qiáng)、敢于堅持的人去鍥而不舍地去實施我們的構(gòu)想，將我們的營銷手段發(fā)揮到極致。但我們也需要那些善于變通的、有許多奇思妙想的人去引導(dǎo)我們穿過那些灰暗的中間地帶。實際上，我在市場營銷領(lǐng)域中鉆研的時間越長，我對中間地帶的理解越明了——我們所有動作實際上都是在中間地帶發(fā)生的，無論是質(zhì)量和數(shù)量的抉擇，策略和大數(shù)據(jù)的選擇，品牌創(chuàng)意和直接營銷的取舍，甚至是科學(xué)和藝術(shù)之間的權(quán)衡。”

那么，我們怎么做才能將數(shù)據(jù)有效地利用起來呢？在此，Scott將為大家提供一些14條使用數(shù)據(jù)的經(jīng)驗法則，讓大家開始學(xué)會用數(shù)據(jù)驅(qū)動營銷，同時也避免淪為數(shù)據(jù)主義或使用不實數(shù)據(jù)進(jìn)行營銷。

1. 用戶驅(qū)動優(yōu)于數(shù)據(jù)驅(qū)動

數(shù)據(jù)驅(qū)動營銷固然是好事。但是我們要牢記在心，營銷的目的是獲取并保有用戶，因此“用戶驅(qū)動”更有利于達(dá)到營銷目的。話雖如此，“數(shù)據(jù)驅(qū)動”和“用戶驅(qū)動”并非相互排斥。相反，二者為過程與結(jié)果的關(guān)系，前者為過程而后者為結(jié)果。該條法則意在提醒我們，在運用數(shù)據(jù)的時候，記得思考：“該舉措是否有利于為公司贏得用戶？”

2. 引用準(zhǔn)確和相關(guān)的數(shù)據(jù)

當(dāng)我們在討論一個絕對真理的時候，引用數(shù)據(jù)是說服他人的最佳手段。然而，在大數(shù)據(jù)時代，各種數(shù)據(jù)應(yīng)有盡有，任何一方都可以搜集相應(yīng)數(shù)據(jù)，并“合理”地運用該數(shù)據(jù)去說服對方。在這種情況下，數(shù)據(jù)的相關(guān)性和準(zhǔn)確性顯得尤為重要。因此，人們往往以為大數(shù)據(jù)可以讓市場營銷人員更好地去了解用戶，然而真相是，其實他們也許對用戶一無所知。因此，我們不僅要引用數(shù)據(jù)，還要引用最為精確及相關(guān)的數(shù)據(jù)。

3. 數(shù)據(jù)只能體現(xiàn)過去發(fā)生的事實

毫無爭議地，數(shù)據(jù)能夠體現(xiàn)過去發(fā)生的事實，然而其對未來發(fā)展是否意義則有待考究。誠然，我們可以從過去的數(shù)據(jù)中推斷出未來趨勢（有時候甚至非常精確）。然而，現(xiàn)今社會是瞬息萬變的，過去是過去，它不一定能夠告訴我們未來的日子將會發(fā)生什么變化，有時候我們的預(yù)測會出現(xiàn)與預(yù)期完全相反的結(jié)果，正如歷史上數(shù)次發(fā)生的 黑天鵝事件 ，往往具有意外性，且無法被人為預(yù)測和解釋。

4. 數(shù)據(jù)總是不完整的

在某個特定集合內(nèi)的數(shù)據(jù)是完整的，如過去三年每個季度的銷售額。然而并非所有事物都可以歸納到一個特定的集合內(nèi)的，因此，每當(dāng)我們在做決策的時候，會發(fā)現(xiàn)僅引用已有數(shù)據(jù)是遠(yuǎn)遠(yuǎn)不夠的，我們還需要引用更多的數(shù)據(jù)，因為它們都和我們要做的決策息息相關(guān)。于是你會發(fā)現(xiàn)，數(shù)據(jù)的引用是個巨大的黑洞，因為你永遠(yuǎn)也無法將所有的數(shù)據(jù)收入囊中。因此，盡管我們在大數(shù)據(jù)的支持下為企業(yè)做出了一個決策，但這個決策往往如同印象派的畫作一般，只描繪出了個大概，和真實情況仍相距甚遠(yuǎn)。

5. 數(shù)據(jù)是客觀的，但千萬個讀者就有千萬種解釋

沒錯，數(shù)據(jù)是客觀的，如一張凈推薦值(Net Promoter Score)表格中，顯示的凈推薦值均為7。然而除此之外，其他內(nèi)容都是主觀的。一方面，其主觀性體現(xiàn)在過程中——收集信息的內(nèi)容不同，收集信息的時間地點不同，甚至采訪對象的選擇也有因人而異。另一方面，主觀性也體現(xiàn)在結(jié)果中——相同的數(shù)據(jù)，每個人的解讀方式也不一樣。詳情案例可參閱 《Hidden biases in big data》 。

6. 數(shù)據(jù)可以讓故事變得更具有說服力

市場營銷人員往往是一個講故事的人。我們在講故事的時候引用相關(guān)數(shù)據(jù)，將會使得我們的故事更為動聽及具有說服力。然而，正因為數(shù)據(jù)的解讀具有主觀性，我們可以更加自如的將符合我們期望值、具有說服力的故事說給用戶聽。盡管如此如何運用數(shù)據(jù)由我們說了算，但在講述故事的時候，我們?nèi)砸侠淼睾拓?fù)責(zé)任地運用相關(guān)數(shù)據(jù)。

7. 好的數(shù)據(jù)支持我們做明智的選擇

決策為企業(yè)和個人做選擇提供一個框架，而數(shù)據(jù)則有利于為做選擇提供相應(yīng)信息。好的數(shù)據(jù)將會引導(dǎo)人們做出明智的選擇。反之，不好的數(shù)據(jù)將會成為我們成功道路上的絆腳石。

8. 用實驗來證實數(shù)據(jù)之間的因果關(guān)系

大數(shù)據(jù)時代一個非常重要的詞語是“相關(guān)性”，然而我們要清楚，相關(guān)性并非因果關(guān)系。作為市場營銷人員，在了解到企業(yè)行為和消費者行為之間相關(guān)關(guān)系后，我們接下來應(yīng)當(dāng)考察該關(guān)系是否為因果關(guān)系——做實驗。保持其他變量不變，檢驗相關(guān)變量去證實或證偽我們的猜想。谷歌每年都會進(jìn)行超過一萬次的實驗，其實驗產(chǎn)生了巨大的數(shù)據(jù)量為谷歌服務(wù)，也因此說明了， 大量的實證實驗優(yōu)于純粹以數(shù)量取勝的數(shù)據(jù) 。

9. 平衡數(shù)據(jù)與用戶體驗之間的關(guān)系

Gord曾用過一個非常生動形象的比喻： “營銷如同開車，儀表盤則如同營銷過程中所產(chǎn)生的各種數(shù)據(jù)（如營業(yè)額等），擋風(fēng)玻璃則如同用戶體驗。” 顯然在行車時，儀表盤上的數(shù)字和擋風(fēng)玻璃外的世界，我們二者都要兼顧。同理，在營銷過程中數(shù)據(jù)和用戶體驗均很重要。

10. 數(shù)據(jù)具有時效性

隨時間推移，當(dāng)下數(shù)據(jù)的保留價值越來越低。例如，在我想買車的時候，車商視我為目標(biāo)客戶，定期向我推送相關(guān)信息。然而，在我買車后的六個月，他們就開始對我不理不睬。這個例子在一定程度上說明，數(shù)據(jù)是具有時效性的，因而掌握有效和準(zhǔn)確的數(shù)據(jù)對于運用數(shù)據(jù)的市場營銷人員來說至關(guān)重要。

11. 數(shù)據(jù)運用的“是什么”和“為什么”

在運用數(shù)據(jù)做營銷決策的時候，我們需要考慮到這些數(shù)據(jù)“是什么”(confirmation)和“為什么”會得出這些數(shù)據(jù)(exploration)。當(dāng)我們在考慮“是什么”的時候，會了解到：事物是否發(fā)生，或發(fā)展到什么程度了；而當(dāng)我們在考慮“為什么”的時候，我們想要去尋求新的發(fā)展模式，新的事業(yè)和新的偉大構(gòu)想。另，同樣的數(shù)據(jù)，我們不僅可以用它去探討“是什么”，同樣可以探討“為什么”，這取決于市場營銷人員所要研究的命題。

12. 擁有兩塊手表并不能準(zhǔn)確的判斷時間，反而會制造混亂

手表定律 是每個市場營銷人員都需要掌握的定律之一。這個世界被各種矛盾的數(shù)據(jù)充斥著，用不一樣的數(shù)據(jù)或研究方法去討論同一個問題可能會得出截然不同的答案。面對這種情況我們可以做的有兩件事，一件是既然數(shù)據(jù)已經(jīng)不一樣，那么我們就去了解是什么因素讓數(shù)據(jù)呈現(xiàn)出兩種不同的結(jié)果，通過此舉我們往往會有意想不到的新發(fā)現(xiàn)；另外，不要為一分一毫的數(shù)據(jù)偏差而過于糾結(jié)，我們需要的不是完美的數(shù)據(jù)，而是利于我們做出明智決策的、準(zhǔn)確地恰如其分的數(shù)據(jù)。

13. 模型并非現(xiàn)實

模型并非現(xiàn)實，它充其量是現(xiàn)實的反映，有時候它甚至?xí)崆爽F(xiàn)實。一名哲學(xué)家兼科學(xué)家Alfred Korzybski曾經(jīng)說過：“地圖并非實際地形。”偉大的科學(xué)家George E.P. Box也曾說過：“所有模型都是錯誤的，只有一些是有用的。”。因此，在實際運用當(dāng)中，我們要正確看待數(shù)據(jù)，不能“唯數(shù)據(jù)主義”，除了數(shù)據(jù)，我們?nèi)詰?yīng)對其它信息保持高度的警惕，特別是那些體現(xiàn)現(xiàn)實生活的信息。正如同Swiss Army Aphorism所說：“如果地圖和實際地形不符，選擇地形。（畢竟地圖沒有辦法完全顯示出那懸崖峭壁。）”

14. 數(shù)據(jù)可視化是把雙刃劍

數(shù)據(jù)可視化（包括但不限于圖形和表格）是一把雙刃劍。就目前來說，數(shù)據(jù)可視化在數(shù)據(jù)運用中發(fā)揮著積極的作用——使人們更加直觀地讀懂?dāng)?shù)據(jù)，方便做決策。然而，無論是有意或無心，它可以為我們呈現(xiàn)有效的信息，同樣也可以為我們呈現(xiàn)無效的信息，其弊端也許日后會日益顯現(xiàn)。若想要了解更多有關(guān)數(shù)據(jù)可視化的內(nèi)容并掌握這門技巧，可參閱 Stephen Few , Kaiser Fung , Edward Tufte , Nathan Yau , and Fernanda Viégas and Martin Wattenberg

總的來說，雖然大數(shù)據(jù)發(fā)展已久，但 數(shù)據(jù)運用也許在當(dāng)今市場營銷領(lǐng)域中仍欠缺開發(fā)利用 。因此，我們應(yīng)正視數(shù)據(jù)的作用，并開始有效的利用它。

『 WeMedia 』自媒體聯(lián)盟覆蓋千萬人群，『199IT-互聯(lián)網(wǎng)數(shù)據(jù)中心』為其成員。( 賬戶：i199IT)

者 | Adrien Joly

譯者 | 張衛(wèi)濱

策劃 | 丁曉昀

有時候，JavaScript（甚至帶有類型檢查的 TypeScript）會因為其不可預(yù)測的特性和缺乏約定而遭到批評。對于那些知道 JavaScript 是為 web 瀏覽器設(shè)計的腳本語言的人來說，這就不足為奇了。

但是，現(xiàn)在它已經(jīng)成為開發(fā)全棧 web 的首選語言，也是跨平臺移動應(yīng)用的熱門方案。那么，當(dāng)開發(fā)人員的 JavaScript/TypeScript 代碼庫開始老化，由此帶來的復(fù)雜性痛苦地增長時，他們該采取什么行動才能最大限度地減少資源浪費并保持工作滿意度呢？

本文將基于我 10 多年來編寫 JavaScript 代碼的經(jīng)驗和 5 年多拯救 JS/TS 項目的經(jīng)歷，向讀者介紹如下內(nèi)容：

• 如何評估 JS/TS 代碼庫的質(zhì)量和風(fēng)險。
• 對于需要修復(fù)的部分，該如何確定其優(yōu)先級。
• 有哪些非破壞性的方法可以讓 JS/TS 代碼庫逐漸變得更健康。

清理工作臺

在開發(fā)下一個特性時，每個警告、類型錯誤或非正常的測試都會讓開發(fā)人員浪費時間、精力和專注度。

代碼警告尤其令人討厭，因為開發(fā)人員會習(xí)慣性地忽略它們，“只要一切按預(yù)期運行就好”。因此，它們會迅速累積，當(dāng)我們遇到缺陷、事故或系統(tǒng)的意外行為時，就很難將其作為有用的線索。

類型錯誤就是一個很好的樣例。當(dāng)我們的用戶遵循“快樂路徑（happy path）”時，這些錯誤似乎無關(guān)緊要，因為軟件似乎能夠按照預(yù)期運行。所以，我們可能會使用@ts-ignore、any或類型斷言來暫時忽略它們。但是，這樣做的話，就意味著如果有一天用戶選擇不同的路徑，就會面臨運行時錯誤。

這樣的話，開發(fā)人員就需要調(diào)查、重現(xiàn)和修復(fù)一個新的缺陷，而這個缺陷恰恰是他們幾個月前允許走捷徑所造成的。如果你的代碼被各種警告和/或暫時忽略這些警告削弱了質(zhì)量，那么找到這個捷徑將耗費大量的時間。

當(dāng)生產(chǎn)環(huán)境的數(shù)據(jù)庫因“內(nèi)存不足”錯誤而崩潰時，該警告可能會幫助開發(fā)人員找到崩潰的原因

警告和類型錯誤是查找缺陷和事故的線索。我們累積（或忽略）的警告和錯誤越多，開發(fā)人員就會花費越多的時間去調(diào)查。如果代碼是他們很久以前編寫的，那情況就會更糟糕了。

我們能做些什么呢？

1. 確保開發(fā)人員在開發(fā)過程中能夠盡快看到警告和類型錯誤。這不應(yīng)該花費額外的成本。如果可能的話，集成到他們的 IDE 中。
2. 不要讓警告和類型錯誤累積。盡快修復(fù)它們。
3. 提高信噪比。如果團(tuán)隊一致認(rèn)為某條引發(fā)警告和類型錯誤的規(guī)則沒有用處的話，就干脆禁用它。
4. 如果你確信需要在代碼的特定部分忽略掉某條規(guī)則的話（也就是，使用 code>@ts-ignore、any或類型斷言），請?zhí)砑幼⑨屢杂涗浐雎栽撘?guī)則的原因。
5. 不要在運行時添加 try-catch 代碼塊來捕獲編程錯誤（比如，業(yè)務(wù)邏輯中意料之外的未定義值）。而是要使用這種代碼塊來處理外部系統(tǒng)的預(yù)期錯誤（如輸入/輸出異常、校驗、環(huán)境問題等）。在開發(fā)過程中，應(yīng)使用靜態(tài)代碼分析和單元測試來捕獲編程錯誤。
6. 不要讓帶有警告和類型錯誤的代碼進(jìn)入生產(chǎn)環(huán)境。使用持續(xù)集成流水線來強(qiáng)制要求這一規(guī)則。

類型檢查器認(rèn)為缺少一個預(yù)期的屬性。忽略這個錯誤將意味著要承擔(dān)持久化不一致數(shù)據(jù)的風(fēng)險，在幾個月之后，你可能需要花費幾天的時間來調(diào)查和解決這個問題

我們可以使用哪些工具來實現(xiàn)這一目標(biāo)呢？

有許多靜態(tài)代碼分析工具可供使用，最常用的包括：

• ESLint，能夠用來探測代碼中的語法錯誤和反模式；
• TypeScript（啟用嚴(yán)格的規(guī)則），借助.ts文件或JSDoc注解以探測類型錯誤；
• 除此之外，SonarCloud、SourceGraph、Codacy或類似的在線工具服務(wù)也有助于跟蹤共享代碼庫中多個代碼質(zhì)量度量指標(biāo)的變化情況。

警告也可能來自其他工具：依賴安裝器（如npm和yarn）、打包器（如webpack）、代碼處理器（babel、scss）和執(zhí)行環(huán)境（CI 運行器）。不要忽視它們！

如果遵循這些建議會讓你的代碼變得非常冗長和/或復(fù)雜（比如防御式代碼），你可以需要對其進(jìn)行重新設(shè)計。

 "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "lint:errors": "eslint . --quiet",
    "lint:typescript": "tsc --noEmit --skipLibCheck",
    "lint:jsdoc-typing": "tsc --noEmit --allowJs `find ./ -name '*.js' -name '*.d.ts'`"
  },

復(fù)制代碼

借助靜態(tài)代碼分析器和 npm 腳本，能夠讓開發(fā)人員輕松快速地探測有問題的代碼

后續(xù)該怎么辦？

安裝和配置靜態(tài)代碼分析工具是一個良好的開端，但這還不夠。

要想取得持續(xù)的成功，要確保開發(fā)團(tuán)隊做到如下幾點：

• 充分認(rèn)識到部署不含編程錯誤的代碼的重要性，并相信靜態(tài)代碼分析可以幫助他們實現(xiàn)這一點；
• 充分理解 TypeScript 的運行原理（參見TypeScript: Handbook）
• 定期修復(fù)警告和類型錯誤，起碼要比引入它們的頻率更高；
• 保持這些措施，永不間斷。

如下幾種策略可能會提供幫助：

• 獎勵提高代碼質(zhì)量的代碼貢獻(xiàn)行為，從而激勵開發(fā)人員。其中，有種方法是使用可插入持續(xù)集成流水線的工具來跟蹤開發(fā)人員推送的每個變更的代碼質(zhì)量變化，例如可以使用 SonarCloud 和/或 Codacy。
• 讓一名開發(fā)人員負(fù)責(zé)確保代碼質(zhì)量永不下降。
• 讓另一名開發(fā)人員負(fù)責(zé)定期更新依賴，從而能夠讓團(tuán)隊能夠從它們的邏輯和安全修復(fù)中受益。

為何要把每個角色都交給一個專門的人？

當(dāng)某項職責(zé)沒有人負(fù)責(zé)時，集體責(zé)任往往會被其他“優(yōu)先事項”所取代（比如，本周多交付一個特性，但是代價是忽略一個警告）。

定期輪換角色，確保每個人都能參與其中并保持積極性。

使用（恰當(dāng)類型的）測試覆蓋關(guān)鍵的業(yè)務(wù)邏輯

現(xiàn)在，我們有了一支致力于保持代碼庫整潔的團(tuán)隊，我們相信用戶很少會遇到編程錯誤。

但是，業(yè)務(wù)邏輯中的錯誤該怎么辦呢？

例如，如果一個新添加的功能破壞了另一個功能該怎么辦？如果開發(fā)人員從一開始就誤解了該功能的預(yù)期行為，又該怎么辦？如果這樣的錯誤最終導(dǎo)致了嚴(yán)重的收入損失又該如何處理？

與編程錯誤類似，業(yè)務(wù)邏輯問題可能會在生產(chǎn)環(huán)境由用戶發(fā)現(xiàn)，但我們更希望盡早發(fā)現(xiàn)它們。因此，定期測試軟件非常重要，這個過程可以使用自動化和/或手動測試。

從業(yè)務(wù)角度看，測試有兩個作用：

• 符合功能性需求：每個特性的實現(xiàn)都能滿足開發(fā)時的需求。
• 檢測回歸：在對代碼進(jìn)行任何修改后，所有現(xiàn)有的特性都能按照預(yù)期運行。

確保功能性測試（也稱為“驗收測試”）涵蓋大多數(shù)關(guān)鍵業(yè)務(wù)特性，單元測試或集成測試涵蓋大多數(shù)關(guān)鍵技術(shù)組件。此外，確保持續(xù)集成在任何測試失敗時都能向開發(fā)人員提供可執(zhí)行的反饋。

對于有些開發(fā)人員來說，將測試工作委托給其他人（如產(chǎn)品負(fù)責(zé)人或 QA 團(tuán)隊）是很有誘惑力的做法。在每個新特性完成后，進(jìn)行一次這樣的委托測試，以確保特性實現(xiàn)符合功能性需求，并進(jìn)行協(xié)作迭代，這樣做可能是合理的。

但是，委托他人進(jìn)行回歸檢測并不是一個好主意，原因包括：

• 它增加了合并代碼和部署代碼之間的延遲。
• 它增加了發(fā)現(xiàn)回歸問題和修正它們之間的延遲。
• 隨著功能性范圍的不斷擴(kuò)大，檢測回歸所需的時間也會隨之增長。如果負(fù)責(zé)這些測試的人沒有將其自動化，他們最終可能會跳過越來越多的測試。因此，一段時間之后，出現(xiàn)回歸測試未發(fā)現(xiàn)問題的風(fēng)險就會越來越高。

回歸測試是一項痛苦且可能代價高昂的負(fù)擔(dān)，尤其是需要不同角色（如產(chǎn)品負(fù)責(zé)人和開發(fā)人員）必須協(xié)作的情況下。從長遠(yuǎn)來看，回歸測試自動化意味著可以節(jié)省大量的時間，而且開發(fā)人員具有編寫自動化測試的技能，所以，開發(fā)人員首先要承擔(dān)起檢測回歸的責(zé)任，而不必讓其他角色參與進(jìn)來，這符合他們的利益。

如果要涵蓋的功能范圍很大該怎么辦？

從最關(guān)鍵的業(yè)務(wù)特性開始。要找出這些特性，你可以問自己：“就收益和/或減少成本而言，在生產(chǎn)環(huán)境中可能發(fā)生的最糟糕的事情是什么？”

例如，電子商務(wù)網(wǎng)站的回答可能是如下的特性：

• “信用卡購物”特性每分鐘可以帶來大約 1000 美元的收入。
• 如果銷售人員必須要求首席技術(shù)官手動將產(chǎn)品添加到數(shù)據(jù)庫中，則“將產(chǎn)品添加到目錄中”特性每小時的成本約為 500 美元。
• 如果客戶支持團(tuán)隊需要手動處理訂單，那么“打印條形碼以退回訂單”將使我們每天損失 500 美元。

基于這些業(yè)務(wù)關(guān)鍵的用例，從它們開始編寫端到端的自動化測試肯定就是非常有意義的。

何時運行測試？

在每次代碼更新或添加到代碼庫之時，在將其部署到生產(chǎn)環(huán)境之前。

借助git hook，在每次提交時運行測試可能就足夠了，因為它能可靠地運行，而且其持續(xù)時間不會導(dǎo)致開發(fā)人員編寫更少的測試。

不管是否使用git hook，都要確保每次推送可用于生產(chǎn)環(huán)境的代碼時，測試能在某處運行（例如，最好是在持續(xù)集成環(huán)境中）。

在持續(xù)集成環(huán)境中，每次提交都會運行代碼檢查和自動化測試。

我們應(yīng)該編寫什么樣的測試？

需要優(yōu)化的變量包括：

• 測試所覆蓋的功能性和技術(shù)性范圍的大小。
• 從測試中獲得反饋的時間。
• 修復(fù)失敗測試所報告的問題所需的時間。
• 因為誤報而損失的時間（即由于隨機(jī)原因?qū)е率〉臏y試）。

如果你的團(tuán)隊在編寫自動化測試和/或可測試代碼方面經(jīng)驗不足，那么可以從一些端到端測試開始。然后，逐步增加對范圍更小的代碼單元的測試。這樣做可以激勵開發(fā)人員編寫易于測試的代碼。例如，通過隔離責(zé)任、減少耦合和/或?qū)I(yè)務(wù)邏輯寫成純函數(shù)。遵循依賴注入架構(gòu)是實現(xiàn)這一目標(biāo)的好方法。（參見六邊形架構(gòu)或簡潔架構(gòu)）

我們是否應(yīng)該 Mock 第三方 API？

自動化測試（如本文所述）的目的是探測團(tuán)隊的功能性范圍內(nèi)的回歸，而不是第三方的功能。基于這一點，在測試中 Mock 第三方是合理的。

也就是說：

• Mock 應(yīng)始終與當(dāng)前 API 的行為相匹配。這意味著開發(fā)人員需要持續(xù)關(guān)注 API 的變化，并相應(yīng)的更新它們的 Mock。
• 當(dāng)實際 API 的行為與預(yù)期不符時，你可能依然希望得到警告。

探測自己的代碼中的問題和第三方 API 中的問題并不遵循相同的生命周期：

• 每次代碼進(jìn)行變更時，所涉及的范圍都應(yīng)該進(jìn)行測試。
• 僅在第三方的代碼發(fā)生變更的時候，才應(yīng)該對其進(jìn)行測試。（也就是說，每次提交代碼變更都測試第三方依賴是沒有什么意義的）。

你需要持續(xù)監(jiān)控第三方提供商是否能夠正常運行并達(dá)到預(yù)期效果。但是，第三方錯誤不一定能夠在發(fā)生之時就探測到，因此最好是定期監(jiān)控，而不是在開發(fā)人員每次推送代碼變更的時候進(jìn)行監(jiān)控。

所以，需要搭建兩個專門的流水線：

• 你自己的 CI 流水線會在你的代碼發(fā)生變更的時候測試自己的范圍。
• 另外一個 CI 流水線定期檢查第三方所涉及的范圍是否按照預(yù)期運行。

為了編寫長期最有用、最健壯的測試，我建議遵循F.I.R.S.T.原則。確保開發(fā)人員不會濫用mock。

細(xì)致保護(hù)代碼庫中新的/現(xiàn)代化的部分

假設(shè)你的代碼庫已經(jīng)或者將要開發(fā)數(shù)年的時間，那么隨著時間的推移，它很可能會在代碼風(fēng)格和質(zhì)量方面失去內(nèi)聚力。更糟糕的是，由于技術(shù)債務(wù)、缺乏測試或意外復(fù)雜性的積累，某些組成部分的維護(hù)可能會變得很復(fù)雜。

在這種情況下，要像上文所建議的那樣，在整個代碼庫中對代碼實現(xiàn)一致的內(nèi)聚預(yù)期可能會變得很復(fù)雜。不過，這也沒有關(guān)系。

你不希望看到的是期望值降低到一個最低的平均水準(zhǔn)。這樣的話，你可以把代碼劃分為不同的范圍，并為每個范圍設(shè)置不同的期望水平。

例如，考慮一個即將為電子商務(wù)網(wǎng)站實現(xiàn)新特性的團(tuán)隊。他們希望這個新特性能夠比代碼庫中的其他特性更健壯、更易于維護(hù)。為了實現(xiàn)這一點，他們在配置靜態(tài)代碼分析工具（如 ESLint 和 TypeScript）時采用比代碼庫的其他部分更嚴(yán)格的規(guī)則，并針對專門為該特性而創(chuàng)建的目錄使用覆蓋的方式啟用更多的規(guī)則。通過這種方式，團(tuán)隊可以提高新代碼的質(zhì)量，而不必急于對代碼庫中“遺留”的部分進(jìn)行現(xiàn)代化處理。

"rules": {
    "prettier/prettier": "error",
    "deprecation/deprecation": "warn"
  },
  "overrides": [
    {
      // Tolerate warnings on non critical issues from legacy JavaScript files
      "files": ["*.js"],
      "rules": {
        "prefer-const": "warn",
        "no-inner-declarations": ["warn", "functions"],
        "@typescript-eslint/ban-ts-comment": "warn",
        "@typescript-eslint/no-var-requires": "off"
      }
    },
    {
      // Enforce stricter rules on domain / business logic
      "files": ["app/domain/**/*.js", "app/domain/**/*.ts"],
      "extends": ["async", "async/node", "async/typescript"],
      "rules": {
        "prefer-const": "error",
        "no-async-promise-executor": "error",
        "no-await-in-loop": "error",
        "no-promise-executor-return": "error",
        "max-nested-callbacks": "error",
        "no-return-await": "error",
        "prefer-promise-reject-errors": "error",
        "node/handle-callback-err": "error",
        "node/no-callback-literal": "error",
        "node/no-sync": "error",
        "@typescript-eslint/await-thenable": "error",
        "@typescript-eslint/no-floating-promises": "error",
        "@typescript-eslint/no-misused-promises": "error",
        "@typescript-eslint/promise-function-async": "error"
      }
    }
  ]

復(fù)制代碼

通過配置覆蓋，我們可以為不同的部分設(shè)置不同的 ESLint 規(guī)則

與之類似，如果要對整個代碼庫進(jìn)行現(xiàn)代化改造，也要循序漸進(jìn)。你可以創(chuàng)建一個具有更嚴(yán)格規(guī)則的專用目錄，并逐漸將遺留代碼遷移至該目錄，同時修復(fù)代碼的警告和類型錯誤。

從何處開始？

有種方式是逐步將功能范圍中陳舊的部分遷移到更好的設(shè)計中。例如，選擇一個難以編寫自動化測試的特性，并將它的實現(xiàn)遷移到六邊形架構(gòu)中，將業(yè)務(wù)/領(lǐng)域邏輯根據(jù)輸入命令（即“API”）和副作用（即“SPI”）分離開來。通過編寫自動化測試來指導(dǎo)遷移，并將新的實現(xiàn)放在具有更嚴(yán)格靜態(tài)代碼分析規(guī)則的專用目錄中。

import { makeFeatures }=from './domain/features';
import { userCollection } from './infrastructure/mongodb/UserCollection';
import { ImageStorage } from './infrastructure/ImageStorage.js';








/** @type {import('./domain/api/Features').Features} Features*/
const features=makeFeatures({
  userRepository: userCollection,
  imageRepository: new ImageStorage(),
});








routes.post('/avatar', (request, response)=> {
  features
    .setAvatar(request.session.userId, request.files[0])
    .then(
      ()=> response.json({ ok: true },
      (error)=> response.json({ ok: false })
    );
});

復(fù)制代碼

setAvatar特性經(jīng)過了重新設(shè)計，由于采用了依賴反轉(zhuǎn)，使其易于單獨進(jìn)行測試。下面是我們遷移另一項特性的過程，即播放列表刪除

如果你決定遵循這一路徑，如下是一些建議：

• 如果你的團(tuán)隊沒有重新設(shè)計遺留特性的經(jīng)驗，那么就從簡單的小特性開始。否則的話，請選擇一個未來幾周或幾個月內(nèi)要實現(xiàn)的特性最依賴的那個特性。
• 在編碼之前，明確范圍、業(yè)務(wù)事件和路徑。例如，與你想重新設(shè)計的領(lǐng)域（或限界上下文）所涉及的專家一起組織一次事件風(fēng)暴。
• 可視化要遷移范圍的當(dāng)前架構(gòu)，例如使用像ARKit、Dependency-Cruiser或類似的依賴分析工具，并寫明不想在目標(biāo)架構(gòu)中重復(fù)出現(xiàn)的問題，以免重蹈覆轍。
• 如果有疑問的話，請使用軟件設(shè)計工具（如時序圖、狀態(tài)機(jī)圖、ADR）協(xié)作完成恰當(dāng)?shù)脑O(shè)計。

在遷移完每個限界上下文之后，你將會得到一個代碼庫，在代碼庫中 100%的代碼都應(yīng)按照更嚴(yán)格的規(guī)則進(jìn)行檢查。

每日部署，但同樣的錯誤不要犯兩次

盡管使用了靜態(tài)分析工具來檢測缺陷，使用了自動化測試來探測回歸，但用戶還是會在生產(chǎn)環(huán)境中發(fā)現(xiàn)問題。這是無法避免的。但是，有一種方法可以降低出現(xiàn)此類問題的概率，并縮短團(tuán)隊修復(fù)問題的時間：

• 每日部署（前提是你確信失敗的風(fēng)險很低）。
• 同樣的錯誤不要犯兩次。

為何要每日部署？

簡約版答案：因為DORA研究項目發(fā)現(xiàn)，大多數(shù)執(zhí)行團(tuán)隊每天都在進(jìn)行部署，或者每天部署多次。

詳盡版答案：

• 因為這能夠讓開發(fā)人員更快地找到在生產(chǎn)環(huán)境中出現(xiàn)新缺陷的根本原因。也就是說，部署越頻繁，最新部署和上次部署之間的提交次數(shù)就越少。
• 基于相同的原因，如果最新版本不能按照預(yù)期運行，回滾到上一個版本的成本會更低（就回滾代碼提交的次數(shù)而言）。
• 因為這能鼓勵團(tuán)隊將工作分成更小、更安全的增量。DORA 認(rèn)為，這也是表現(xiàn)最好的團(tuán)隊所遵循的做法。

如何確保相同的錯誤不犯兩次？

在生產(chǎn)環(huán)境中出現(xiàn)意料之外的行為是可以的。在有些情況下，這甚至是一件好事。

當(dāng)意料之外的行為給企業(yè)和/或開發(fā)團(tuán)隊帶來巨大損失時（例如，網(wǎng)站中斷，導(dǎo)致幾個小時無法使用），開發(fā)人員應(yīng)該采取措施防止類似的事件再次發(fā)生。

如何探測生產(chǎn)環(huán)境中的問題？

有多種方式可以探測生產(chǎn)環(huán)境中的問題：

• 理想情況：開發(fā)人員發(fā)現(xiàn)問題并立即修復(fù)。
• 常規(guī)情況：員工發(fā)現(xiàn)問題并向開發(fā)團(tuán)隊報告。
• 更糟糕的情況：用戶向開發(fā)團(tuán)隊報告問題。
• 最糟糕的情況：用戶發(fā)現(xiàn)了問題，但并沒有報告。

無論是哪種情況，開發(fā)人員都需要以下信息：問題是什么、問題的具體表現(xiàn)（如錯誤信息）、如何重現(xiàn)問題（如環(huán)境+過程），以及用戶的初衷和期望是什么。

但是，如何在最糟糕的情況下獲得這些數(shù)據(jù)呢？這就是錯誤監(jiān)控工具（如Sentry）的用武之地了。通過將它們注入到生產(chǎn)環(huán)境中運行的產(chǎn)品中，它們就能像探針一樣檢測運行時錯誤，并將它們匯總到已知錯誤的列表中，直到每個錯誤都被開發(fā)人員修復(fù)為止。此外，它們還會獲取有關(guān)錯誤上下文的數(shù)據(jù)（如用戶代理、所使用軟件的版本、操作系統(tǒng)、確切的時間戳等），以幫助開發(fā)人員重現(xiàn)錯誤。

但令人遺憾的是，與靜態(tài)代碼分析器類似，這些工具并不能解決問題。因此，與警告和類型錯誤一樣，要確保盡快處理每個錯誤。團(tuán)隊讓錯誤累積得越多，使用這些工具的動力和效率就會越低。

此外，在使用這類監(jiān)控工具時，請確保個人和/或機(jī)密數(shù)據(jù)不會從系統(tǒng)中泄露出去。

從戰(zhàn)術(shù)上講，有許多方法可供選擇。你可以讓一名開發(fā)人員負(fù)責(zé)修復(fù)生產(chǎn)環(huán)境的錯誤，并將其作為最優(yōu)先的事項。這個角色可以定期輪換（比如每天），這樣可以激勵每個人都編寫更健壯的代碼。或者，也可以在每天的會議上將新錯誤單獨分派給志愿開發(fā)人員。

如何降低復(fù)發(fā)風(fēng)險？

不必慌張！當(dāng)生產(chǎn)環(huán)境中發(fā)生事故時，都要遵守如下程序：

1. 保留事故發(fā)生前、發(fā)生時和發(fā)生后的痕跡，以幫助你進(jìn)行事后分析（注意：在事故發(fā)生前做好充分的監(jiān)控和日志收集工作）。
2. 在內(nèi)部和外部就事故進(jìn)行溝通。
3. 穩(wěn)定生產(chǎn)環(huán)境，例如，回滾到之前能正常運行的版本。
4. 編寫并部署修正版本，以修復(fù)問題。
5. 查找并解決導(dǎo)致問題的根本原因，并采取預(yù)防措施。

避免重蹈覆轍的關(guān)鍵在于上述程序的最后一步。

這也是經(jīng)常被忽視的過程。大多數(shù)情況下，是因為沒人覺得自己有責(zé)任這樣做。很多時候，是因為產(chǎn)品負(fù)責(zé)人（或產(chǎn)品團(tuán)隊）向開發(fā)人員施壓，要求他們優(yōu)先完成開發(fā)計劃中的特性，而不是保護(hù)現(xiàn)有代碼和/或調(diào)整開發(fā)流程。有時，開發(fā)人員自己也會決定開發(fā)更多的特性，而不是避免再次犯錯。

調(diào)查事故根本原因時的注意事項

如何查找事故的根本原因？

在這個方面，“5 個為什么（5 WHY）”技巧是很有用的。例如：

• 生產(chǎn)系統(tǒng)為什么會崩潰？——因為一個未登錄的用戶訪問了頁面 B。
• 用戶為什么能夠訪問頁面 B？——因為主頁上有一個鏈接。
• 用戶在訪問頁面 B 的時候為什么沒有看到登錄頁面？——因為在頁面渲染時，后端還不知道登錄狀態(tài)。
• 為什么頁面渲染時還不知道登錄狀態(tài)？——因為我們的會話管理后臺很慢，等待這個狀態(tài)會大大降低我們的網(wǎng)絡(luò)性能指標(biāo)。
• 為什么會話管理后端很慢？——因為它使用的是未經(jīng)優(yōu)化的遺留數(shù)據(jù)庫。

在本例中，根本原因是整個網(wǎng)站都依賴于遺留的會話管理后端，這使得導(dǎo)航難以預(yù)測，有時還會導(dǎo)致生產(chǎn)環(huán)境崩潰。因此，除非團(tuán)隊修復(fù)傳統(tǒng)的會話管理后端，否則類似的崩潰很可能很快就會在生產(chǎn)環(huán)境中再次發(fā)生。團(tuán)隊現(xiàn)在應(yīng)該修復(fù)遺留的會話管理后端嗎？也許不用。但是他們應(yīng)該努力制定一個能夠?qū)崿F(xiàn)該目標(biāo)的補(bǔ)救計劃。

在實踐中，如何實現(xiàn)低故障率的日常部署呢？

讓一位開發(fā)人員負(fù)責(zé)確保盡快發(fā)現(xiàn)生產(chǎn)中的意外行為（如運行時錯誤、缺陷、事故……），盡快修復(fù)，并采取措施防止今后再次發(fā)生各類問題。

通過這種方式，開發(fā)人員能夠感受到有能力在良好的條件下開展工作。例如，在生產(chǎn)過程中設(shè)置恰當(dāng)?shù)谋O(jiān)控和日志，確保撰寫有用的事后報告，并采取預(yù)防措施。

當(dāng)信心達(dá)到良好水平時，逐步增加部署頻率。

以正確的激勵機(jī)制調(diào)整產(chǎn)品開發(fā)團(tuán)隊

此時，開發(fā)人員就具備了編寫高質(zhì)量軟件，并盡快發(fā)現(xiàn)缺陷的能力。這些缺陷最好是在設(shè)計或?qū)崿F(xiàn)時發(fā)現(xiàn)，而不是在生產(chǎn)環(huán)境中。他們能夠快速發(fā)現(xiàn)并修正生產(chǎn)環(huán)境的錯誤，不會重復(fù)犯同樣的錯誤。他們對自己的代碼和開發(fā)流程充滿信心，因此每天都能在生產(chǎn)中實現(xiàn)改善。而且，他們在對軟件功能化范圍進(jìn)行預(yù)期改善的同時，也會逐步改善代碼庫中最古老部分的設(shè)計和質(zhì)量，使其保持健康、穩(wěn)健并易于長期維護(hù)。

但是，令人遺憾的是，這種平衡很快就可能被瓦解。舉例來說：

• 如果開發(fā)人員失去了長期保持高設(shè)計標(biāo)準(zhǔn)和/或代碼質(zhì)量的動力。
• 如果部分開發(fā)人員不遵循團(tuán)隊的質(zhì)量準(zhǔn)則，造成系統(tǒng)性返工、挫折和延誤。
• 如果開發(fā)人員誤解了功能性需求，而急于修復(fù)無法達(dá)到預(yù)期效果的特性，從而犧牲了長期的技術(shù)責(zé)任。
• 如果有人（如經(jīng)理、產(chǎn)品負(fù)責(zé)人或其他人）向開發(fā)人員施壓，要求他們每周發(fā)布更多的特性，或在緊急的期限內(nèi)完成任務(wù)。
• 如果激勵和/或獎勵開發(fā)人員的績效指標(biāo)與其代碼庫的長期質(zhì)量和健壯性不一致。例如，根據(jù)每周交付的特性數(shù)量確定晉升獎金。

防止或解決這類情況可能會非常困難，因為這需要良好的領(lǐng)導(dǎo)力和/或軟技能。

一個常見的錯誤是培養(yǎng)某種思維定式，即開發(fā)人員應(yīng)該主要致力于實現(xiàn)優(yōu)先的、計劃好的和設(shè)計好的特性。

這樣做是有問題的，因為：

• 它要求開發(fā)人員處于這樣一種狀態(tài)，即對軟件做的每一項變更都要有精確和明確的規(guī)范。這可能會導(dǎo)致開發(fā)人員無法與負(fù)責(zé)制定這些規(guī)范的人員進(jìn)行健康的雙向合作。對于那些喜歡整天獨自工作的開發(fā)人員來說更是如此。
• 它讓開發(fā)人員處于這樣一種境地，即難以衡量那些與功能性路線圖沒有直接貢獻(xiàn)的開發(fā)活動，如更新依賴、提高代碼質(zhì)量、培訓(xùn)更好的設(shè)計和編碼技術(shù)。
• 這很容易讓人傾向于根據(jù)指標(biāo)（如用戶故事的開發(fā)速度）來跟蹤開發(fā)人員的績效（或“生產(chǎn)力”），而忽略了對可持續(xù)開發(fā)實踐的投資，即代碼質(zhì)量、阻礙回歸、錯誤管理等。

下面是一些關(guān)于如何避免上述陷阱的建議：

• 在詳細(xì)闡述業(yè)務(wù)問題的解決方案時，至少讓一名開發(fā)人員參與設(shè)計過程。這將提高開發(fā)人員的責(zé)任心，使他們能夠為一個充分理解的問題實現(xiàn)一個好的解決方案。有時，由于開發(fā)人員了解當(dāng)前的建模和實現(xiàn)方式，他們會提出替代解決方案，從而在滿足需求的同時節(jié)省大量的開發(fā)時間。
• 確保產(chǎn)品和技術(shù)代表能夠公開、友好地協(xié)商功能性和技術(shù)性項目的優(yōu)先級和規(guī)劃。例如，如果開發(fā)人員需要重新設(shè)計代碼庫的某個部分，那么他們就應(yīng)該說服其他人相信這一點的重要性，解釋這將為下一個特性的開發(fā)帶來哪些具體的改善，以及延遲該項目的風(fēng)險和成本是什么。同樣的建議也適用于產(chǎn)品經(jīng)理如何對即將開發(fā)的功能改善進(jìn)行優(yōu)先排序和規(guī)劃：通過解釋來說服開發(fā)團(tuán)隊并讓他們參與進(jìn)來。這樣做可以增強(qiáng)參與設(shè)計和實現(xiàn)特性的所有員工的信任、協(xié)作和參與度。
• 在管理方面，確保開發(fā)人員不會得到這樣的激勵，即“每周盡可能多地發(fā)布特性”。找到使每個開發(fā)人員的職業(yè)目標(biāo)與團(tuán)隊的短期和長期期望相匹配的發(fā)展軌道。這樣做的目的是防止出現(xiàn)開發(fā)人員理直氣壯地只從事短期改善相關(guān)工作的情況。
• 最后，確保為開發(fā)人員提供資源和指導(dǎo)，以不斷提高他們的軟硬技能。為他們提供培訓(xùn)和/或指導(dǎo)資源。鼓勵他們通過結(jié)對和/或群體編程的方式共同完成任務(wù)。鼓勵他們與其他/非開發(fā)人員角色進(jìn)行良好的協(xié)作，包括領(lǐng)域?qū)＜摇a(chǎn)品負(fù)責(zé)人、產(chǎn)品設(shè)計師、客戶支持團(tuán)隊、終端用戶等。

結(jié)論

JavaScript 語言及其不斷變化的軟件包和實踐組成的生態(tài)系統(tǒng)會使代碼庫迅速變得難以維護(hù)。正如我們在本文所討論的那樣，無需從頭重寫所有的內(nèi)容，也無需暫停新特性的開發(fā)，就可以避免由此造成的開發(fā)速度和/或代碼質(zhì)量的下降。

關(guān)于如何在 TypeScript 和 JavaScript 項目中應(yīng)用這些推薦做法的更多實用建議，我建議你參考Yoni Goldberg的最佳實踐列表。它們是為 Node.js（后端）項目編寫的，但其中很多也適用于前端代碼庫。

原文鏈接：前端老手10年心得，JavaScript/TypeScript項目保養(yǎng)實用指南_架構(gòu)/框架_InfoQ精選文章

聞 法 訊

（第16期）

法訊回歸，如聞為您帶來最新法律動態(tài)～

一、法律動態(tài)

1. 2023年9月20日，國家金融監(jiān)督管理總局發(fā)布《保險銷售行為管理辦法》（“《辦法》”），將于2024年3月1日。《辦法》共6章50條，重點對銷售人員資質(zhì)、跨區(qū)域展業(yè)、產(chǎn)品分級制度、產(chǎn)品宣傳、離職后責(zé)任等方面進(jìn)行了細(xì)化性規(guī)范。《辦法》旨在完善行為監(jiān)管制度體系、構(gòu)建保險銷售行為監(jiān)管框架，全文刊載于國家金融監(jiān)督管理總局網(wǎng)站：http://www.cbirc.gov.cn/cn/view/pages/rulesDetail.html?docId=1129945&itemId=4214&generaltype=1

2.2023年9月25日，最高人民法院發(fā)布《最高人民法院關(guān)于優(yōu)化法治環(huán)境促進(jìn)民營經(jīng)濟(jì)發(fā)展壯大的指導(dǎo)意見》（“《指導(dǎo)意見》”）。《指導(dǎo)意見》從六個方面對審判執(zhí)行工作提出了明確要求，重點對保護(hù)民營企業(yè)產(chǎn)權(quán)和企業(yè)家合法權(quán)益、嚴(yán)厲打擊惡意“維權(quán)”侵犯民營企業(yè)合法權(quán)益的行為、對中小微民營企業(yè)的融資、股東不當(dāng)行為等給予司法保障等，提出了相關(guān)意見。《指導(dǎo)意見》全文刊載于最高人民法院網(wǎng)站：https://www.court.gov.cn/zixun/xiangqing/413942.html

3. 2023年10月16日，國務(wù)院發(fā)布了《未成年人網(wǎng)絡(luò)保護(hù)條例》（“《條例》”），將于2024年1月1日實施。《條例》從提升未成年人網(wǎng)絡(luò)素養(yǎng)、加強(qiáng)網(wǎng)絡(luò)信息內(nèi)容規(guī)范、拒絕網(wǎng)絡(luò)欺凌、預(yù)防和干預(yù)未成年人沉迷網(wǎng)絡(luò)、保護(hù)未成年人信息以及對未成年人網(wǎng)絡(luò)消費數(shù)額進(jìn)行限制等六個方面，提出了規(guī)范要求。《條例》是我國出臺的第一步專門性的未成年人網(wǎng)絡(luò)保護(hù)綜合立法，旨在進(jìn)一步完善互聯(lián)網(wǎng)領(lǐng)域治理體系，為健全青少年健康成長提供重要的法治保障。《條例》全文刊載于中國政府網(wǎng)：https://www.gov.cn/zhengce/zhengceku/202310/content_6911289.htm

4. 2023年11月10日，香港特別行政區(qū)政府確認(rèn)《關(guān)于內(nèi)地與香港特別行政區(qū)法院相互認(rèn)可和執(zhí)行民商事案件判決的安排》（“《安排》”）將于2024年1月29日生效并實施。《安排》在管轄判定、適用范圍、具體認(rèn)可和執(zhí)行的判斷標(biāo)準(zhǔn)和程序等方面的規(guī)定，較現(xiàn)行有效的《最高人民法院關(guān)于內(nèi)地與香港特別行政區(qū)法院相互認(rèn)可和執(zhí)行當(dāng)事人協(xié)議管轄的民商事案件判決的安排》更加完善，有效擴(kuò)大互相認(rèn)可和執(zhí)行判決的民商事爭議范圍、遏制惡意規(guī)避法院執(zhí)行判決的行為。《安排》全文刊載于最高人民法院網(wǎng)站：https://www.court.gov.cn/fabu-xiangqing-139501.html

5. 2023年11月15日，最高人民法院發(fā)布《最高人民法院關(guān)于綜合治理類司法建議工作若干問題的規(guī)定》（“《規(guī)定》”）。《規(guī)定》旨在落實“抓前端、治未病”的重要指示精神，對提出司法建議的名義、事前溝通、協(xié)同落實、文書規(guī)范等進(jìn)行規(guī)定，以規(guī)范司法建議工作，引導(dǎo)人民法院結(jié)合審判執(zhí)行工作依法能動履職。《規(guī)定》全文刊載于最高人民法院網(wǎng)站：http://courtapp.chinacourt.org/zixun/xiangqing/417752.html

6. 2023年11月21日，司法部發(fā)布《行政復(fù)議普通程序聽取意見辦法（征求意見稿）》和《行政復(fù)議普通程序聽證辦法（征求意見稿）》并向社會公開征求意見。相關(guān)文件系為規(guī)范行政復(fù)議普通程序聽取意見和聽證工作，進(jìn)一步提高行政復(fù)議工作質(zhì)效，更好的保護(hù)公民、法人、其他組織的合法權(quán)益。意見反饋截止日期為2023年11月30 日，意見征求公告及草案刊載于司法部官網(wǎng)：http://www.moj.gov.cn/pub/sfbgwapp/zwgk/tzggApp/202311/t20231121_490029.html

作者 陳曉燕

責(zé)編 高萍

往期推薦

01

知網(wǎng)被罰8760萬，“知識壟斷”不可為

02

案外人提出異議后，還能另行提起確權(quán)之訴嗎？

03

雙語|一文讀懂新婦保法，企業(yè)該做些什么？（下）

特別聲明

• 本文為如聞原創(chuàng)，如需轉(zhuǎn)載，請聯(lián)系本公眾號后臺。
• 本公眾號的信息僅作一般性參考，不應(yīng)視為如聞律師事務(wù)所或其律師針對特定事務(wù)出具的正式法律意見或建議。如您有意就相關(guān)議題進(jìn)一步交流或探討，歡迎與本所聯(lián)系。

掃碼關(guān)注我們

上海如聞律師事務(wù)所

《金剛經(jīng)》卷首語：“如是我聞”，如聞律師事務(wù)所藉此得名。“盛世法，如聞人”是本所之銘。法律的精神在于維護(hù)社會的公平與正義。但，“徒法不足以自行”。法律的正確實施，公平價值得以實現(xiàn)，離不開一位好律師來為您的權(quán)益保駕護(hù)航。愿我們能和您一起，在這個新時代里，追逐夢想，實現(xiàn)夢想。所有的如聞人，以鉆研精神，飽含著無限熱情，踐行著法律者的初心，為所有如聞的朋友們，做好專業(yè)的服務(wù)。

我們的精神就是：如你所需，如聞永遠(yuǎn)和你在一起。