主頁 > 軟體設計 > 老程式員教你如何提高開發效率、成為大神5——人性管理

老程式員教你如何提高開發效率、成為大神5——人性管理

2020-09-23 05:01:06 軟體設計

很多在職場中奮斗了3-5年,有一定技識訓累、人脈積累的程式員會慢慢轉向管理崗的作業,那么在管理的程序中,避免不了的就是對人性的管理,如果你讀到了這篇文章,那一定是你一生的幸運,因為相信不會再有人把團隊中的人性管理剖析的這么透徹,本篇文章從方法論的角度會給予你一些管理上的萬能鑰匙,

第五篇、人性管理

職場存在其社會的屬性,而社會必定會有利益沖突,有利益沖突,那就必定會有行動,有行動就會有相應的應對策略,因而太陽底下無新事,所有的事情都必定在世界的某個角落同樣發生著,因此學習這些策略便可以更好的應對管理上的挑戰,

一、管理程式員

這里的程式員指的是普通程式員,也就是自嘲為“碼農”、“IT民工”的程式員大眾,如果你作為管理者也是程式員出身,那么你手下的程式員必定會向你學習和模仿(模仿是人類的本能),

因此第一步,就要樹立一個良好的個人形象:你優秀,你的團隊才能優秀;你頹廢,你的團隊就會頹廢;你奸惡,你的團隊就會奸惡,作為管理者一般都會有一些特權,比如日常性的會議和培訓可以不參加、上班可以遲到、年假比別人多,但是一旦動用了這些特權,你的團隊成員便會認定會議是浪費時間的(反正自己的主張不會被管理者接收到)、培訓是可有可無的(主管都沒來,咱們散了吧)、遲到也會被容忍(領導都遲到,人力資源部不會說什么的)、正在進行中的專案并不重要(領導都休年假去了),

第二步就是要講究懲罰的藝術,大家生而為人,必定會犯錯,如果程式員驕傲自滿以至于技術止步不前,則應當及時私下指出,推向“絕望之谷”(詳見上篇),如果程式員由于非技術因素狂妄自大,處處透露著強勢,則應當及時斷掉其狂妄的根源(比如程式員主導了某專案,逢人必談,甚至要將管理層取而代之時,則應當眾把功勞奪讓給專案其他參與者,釜底抽薪),如果程式員對作業怠慢,則應當私下提醒,如果真的遇到什么問題了,協調資源積極解決,絕不能不管不顧,如果程式員犯錯,則一定要示眾,避免其他人犯同樣的錯誤,并且這程序要做到對事不對人,

第三步樹立合理的制度,管理者對于制度的態度自然是首當其沖去遵守,如果不能快速印證制度的有效性,則制度不如不立,另外水至清則無魚,如果制度把自己和他人限制太死了,團隊中必定會缺乏凝聚力(比如限制程式員利用公司資源接私活、即使加班到凌晨也要早上準時上班,前者是法務部的職責,后者是人力資源部的職責),制度無禁止皆可為,有些在制度框架內解決不了的事情,跳出制度外用一些手段也可以達到管理的目的(比如合理警告:“你若完成了專案,后面有類似的專案需要你在本地完成,你有經驗了,就駕輕就熟的事;若專案失敗,Q3就得去四線城市出差,待遇和獎金都會比現在低”),

二、管理技術進階中的程式員

進階程序中的程式員一般都會自傲,并自認為很優秀,對很多事情一知半解,看的不透,那么基于這樣的心態,進階中的程式員一定不會為無能的領導者賣命,因為在他們眼中,技術就是一切,

作為管理者,要時刻關注此類程式員的動向,避免走彎路、做錯事情,若不是認真對待,那么進階中的程式員會有極強的炫耀技術的風險,輕則動搖整個專案的軟體架構、代碼風格,重則可能會給服務器和程式留下后門,甚至以為他人無法調查,從而摧毀公司積累多年的成果,

進階中的程式員一旦屢屢遭遇技術挫折,會逐漸喪失作業的激情,他們不會認為是自己技術不佳,而是會認定公司的技術選型不好、公司沒有給合適的發展空間、公司原先的代碼可讀性差……,從此技術進階中的人要么是自己自動離開公司,去下家公司碰碰壁(或許換了一個解題思路,技術也得到了成長,但是絕不可能向原公司承認自己曾經錯了,畢竟好馬不吃回頭草);要么就是成為了職場老油條,因此管理者要對這些對作業失去激情的人要有足夠的親和力,試想,管理者代表著公司,哪個人會對親和自己的公司、關懷自己的公司心存怨念呢?

在安排作業前一定要認真了解各個員工的喜好和厭惡的事情,善于總結和歸類,分而治之,比如下屬有個公認的老色鬼,那么年輕漂亮的女程式員就不適合和此人一起共同做專案、加班,沒有什么比這種惡心人的事更能摧毀進階中程式員的上進心了,

進階中的程式員都渴望被別人承認和肯定,其在技術方面的三觀也是因管理者的引導而形成的,因此做事上不要講究過于完美,只要有了一定成果,要積極肯定,忽略了別人的勞動成果、指手畫腳,一定會被反感,

這個程式員在發展自己的程序中一定會在想:“我這么牛了,多要點薪水沒毛病吧”,正因為進階中的程式員對職場看的不透,因此會不斷試探待遇上的天花板,據不完全統計,86%的老程式員在首次進階到資料結構、演算法、設計模式的階段時,都會要求老東家給漲薪,那么這個待遇怎么給呢?對進階中的程式員一定要給的超出其預期、網上可查的行業平均水平,300、500的漲薪幅度那一定是在惡心人的,但是作為話術,平時要這樣滲透,突然每月給漲了2000塊錢薪水,至少能管1-2年,另外為何要高于網上可查的行業平均水平呢?其一,是因為網上可查的行業平均水平都是指起薪,事實上入職1年以上都會給大幅度調薪;其二,是因為沒有不透風的墻,假設銷售簽了個200萬的單子,要求5個程式員一個月做完,凈利潤可能有80萬,程式員每個月只能拿到5千,時間長了,將無人可用,翅膀硬了,不飛才是怪事,

建立三觀和向心力非常重要,因此對于進階中的程式員違反制度、犯錯時絕對不能網開一面,要注重對事不對人,

三、管理高級程式員

高級程式員是IT團隊中的核心,他們會左右和主導開發團隊的作業進展,因而很多經驗不足的管理者常常不愿去帶領高級程式員的隊伍,因而在IT團隊管理中,高級程式員的管理是重心,

管理高級程式員,主要是攻心,要充分交流情感,交流情感這一招可能很多管理課程都有所教,有陽謀,也有陰謀,這里就不做過多贅述,需要注意的是,交流情感一定要真誠,不能展現奸惡之相,比如說著說著說漏嘴了,把自己的管理策略、對別人的看法、公司的陰暗面展現出來,在對方看來,你的所有不真誠之處都有可能將來某一天針對他,

從管理方式上來說,需要給予高級程式員足夠的尊重,如果不敬著高級程式員,以其智慧必定會讓你深受其害,私下里去深入交流、禮遇他們才能成為朋友,不妨邀請去轟趴一下、對方要是開Github了給點個Star、搬家的時候帶著同事一起去、單身的幫忙介紹個物件、出差了給帶點小禮物、過節回不去家的找個地方喝一頓,相應的,如果不把他們放在眼里,他們一定會讓你的管理作業推進不下去,假設他們真的給你擺了一道,讓你很難堪,最后的底線是一定不能公開侮辱他們,沒有人會認為自己做的事情是不合理的,一旦你公開的侮辱了某個高級程式員,那么他一定會成為你的宿敵,

對高級程式員的處事風格一定要光明磊落,你使詐、使計謀,很大的概率會被瞬間洞穿,畢竟高級程式員在職場上都不是吃素的,多年的作業經驗也不是白攢的,即使有計謀上的籌劃,也一定要提早布局、首要目的是為了達成雙贏,震懾式交流一定不能當眾;而其余有關于技術、專案上的事情一定要拿到臺面上說,你不給這些“意見領袖”表現的機會,相當于自斷前程,你不把矛盾轉移給他們彼此,你就是團隊中的矛盾,也就陷入了“一言堂”狀態,

高級程式員在公司里的地位越高,你的地位也隨之提高;相反,如果高級程式員在公司里的地位越差,你的地位也將岌岌可危,

四、管理心腹

心腹的確認需要雙向,一方面是這個員工一定是一心只為你、力挺你,另一方面你也需要充分認可這個員工,也因此,對管理者來說心腹很難找尋,而對于員工來說,也很難成為管理者的心腹,

但一旦存在了心腹,你便會發現:心腹很容易直言,內心往往非常正直,但是如果不深入溝通,極可能走極端,將自己的主張奔走相告、或者是當眾反對你的決定(因為常常內心獨白是:顧不了那么多了,我不能讓領導走彎路),你需要提前和其解釋清楚(不必說真話,真話可能會傷人)你對作業、專案中的平衡和思考,否則會讓他人看笑話,以為你和心腹發生了內訌,

遇到事情,不要責備心腹,因為程式員的群體里沒有傻子,誰是你的心腹,基本上一眼就能看出來,如果當眾責備,則會被站在你對立面的人當做突破口,從而夸張、歪曲你的真實意圖,動搖管理根基,

不要過河拆橋,過河拆橋非君子所為,因此作為管理者更應當在借心腹之力實作了專案的成功后,大書特書心腹的豐功偉績,

如果你的心腹在團隊中孤立無援,應當伸以援手,心腹一旦被孤立,也意味著你在團隊中被孤立,當心腹在團隊中被誹謗(有人被誹謗、有人跟你講讒言將會是管理程序中的常事)的時候,則反其道而行之,你需要不斷的公開褒獎他、鼓勵他,因此便會讓謠言不攻自破,和心腹交流時不要帶有私心,也不要表現出自己有私心,要力求共贏,從某種程度上來說,你和心腹是一榮俱榮、一損俱損的,你的心腹就是你在團隊中的影子,你多公開褒獎、鼓勵他,團隊其他成員就會紛紛效仿,試圖成為你的心腹,

但心腹在團隊中一定是少數存在的,小圈子、站隊是真實存在的,合久必分,分久必合,如果下屬所有人都是你的心腹,那一定會有假情假意者,總有一天會開始產生內耗,

五、管理對立方

管理作業做的久了,就一定會有人對你產生各種不滿,這種心懷不滿的人如果放任不管,會使管理作業變成一盤散沙,

首先,我們要明確,對立方在團隊中始終存在,在處理這些人的問題上,要時刻小心謹慎,

針對對立方,有四種治理方式:1、通過利益轉化,將對立方的利益與你的利益捆綁在一起,便可化敵為友,2、時刻提防對立方傳播負能量、做有損于集體的事情,一旦發現有苗頭,要先暗中觀察,3、沒有突破點時,需要耐心的忍耐對立方,4、一旦發現對方有明顯有損于團隊、公司,甚至做出違法的事情時,一定要全力根除,治理不得當未能根除時,對立方便會加倍報復,

光明磊落的對立方一般不會主動算計他人,處理得當,甚至是可以轉化為心腹的,如果遭遇到斤斤計較的對立方,此人在失去有利地位、晉升空間時往往報復行動會不計后果、不擇手段,

對于無法轉化的對立方,處置方式應當是暗中觀察,在沒有觸及群眾的利益,僅觸及到你的利益時,大可放過,因為你如果要反制,必定會使其他人以為你在公報私仇,一旦當此人觸及群眾利益、引發眾怒的時候,要在眾怒未平息的時候,不留任何情面的清退對立方,

六、管理高智商人才

能夠管理好高智商人才的人只有兩種:其一,管理者本身就是智力高于其他人的高智商人才,其二,如果管理者自認為智不如人,便要有足夠的誠意來打動高智商人才(往往是真金白銀的高待遇),

高智商人才轉化為對立方的概率極高,主要原因是因為管理者稍有不慎,便會打破雙贏的邏輯鏈條,一旦這個邏輯鏈斷了,高智商人才就會用自己的方式去獲取自身利益,

管理高智商人才,不要試圖從智力上凌駕對方;不要從職級和勢力上壓迫對方;遇到反對意見的時候不要強迫對方接受并執行,

如果管理者沒有解決問題更好的思路和方法時,應當多咨詢一下團隊中的高智商人才應當如何解決,如果發現僅靠管理者自身無法完成一個專案或者作業任務時,要充分相信高智商人才的能力(即便是他接觸的是新技術、新領域,原本什么也不會),給予其和能力對等的授權或職位,往往他會做的非常出色,

因為高智商人才常常會做具備挑戰性和前瞻性的作業內容,創造類的作業就像是擠牙膏,擠不出來就真的擠不出來,和重復性的作業性質是不同的,因此管理者應當不計其失敗,只計其功勞,絕不應當將失敗當做笑談講于他人,高智商人才一般不會和承認自己智商高的管理者反目,

七、管理職場小白

職場小白為何最后說?那是因為對于管理者來說,職場小白是最聽話、也最好管理的,但也同時是最難完成作業的,沒有經驗的管理者會招募大量職場小白,以期望在公司中以人數優勢獲得上層重視,但經驗豐富的管理者只會招納精兵強將,

職場小白很難跟隨團隊中優秀者的腳步,而且甚至會說很多童言童語,從能力上來說,也并不出眾,管理者應當用啟發式方法不斷點化、詐出職場小白的能力和作業經驗,不痛便不會銘記,另外,職場小白都非常渴望在公司中立足,有一些人是可以作為收集管理資訊的重要渠道,但注意資訊的來源一定要互相印證,而且同一件事情上不能存在利益相關性,

職場小白因為不太懂作業流程、職場規則,適時的可以做一些善意的誤導、甚至裝傻,以激勵他們,比如:“你看,某某某來公司半年就可以做微服務架構了”、“我記得好像limit在Oracle里也可以用的”、“Tomcat我用過,但是在Linux上部署還真沒試過,你可以講講怎么做嗎”,

從待遇上來說,小恩小惠應當不斷,始終處于一個快速反饋、高頻次、低漲幅的獎勵系統中,在核心關鍵問題的解決上盡可能的不要用職場小白,但一定要用的時候,不要給予其重要的作業任務,

職場小白因為初入職場,會不斷試探管理者的底線和管理漏洞,因此,如果發現職場小白用了一些小聰明和計謀,從中獲得的好處一定不要給職場小白分配出去,

管理作業進展如果非常困難時,應當多與職場小白溝通,這里說不定會藏著哪個未來技術過硬的高級程式員,但是一旦管理作業進展的非常順利時,則應當遠離職場小白:本來非常好的團隊狀態,職場小白一旦參與其中,便會產生大量風險,

八、總結

不了解一個人的時候,不要盲目試圖去管理,團隊中的任何成員都可能在不同的環境下做出不同的選擇,從而發生身份的變化,這是管理者需要洞察的,人心是會變化的,心態搖擺不定的人也不要試圖去管理,

道德感強的人會拒絕作惡,勿以善小而不為;道德感差的人會經常作惡,因為會樂在其中,管理者應當見微知著,多善于與不熟悉的人合作,而管理能力不強的人也一般只會把重心放在和自己的心腹私交,

黃金定律:1、功勞和美名都歸于下屬,2、不在頭腦中記下屬的失誤和抱怨,3、敢于對下屬提高待遇、配給資源、宣傳名望,

那么相對于黃金定律,也有一些重大雷區不要碰:1、領導者當眾不給下屬面子, 2、保護不了心腹,這里包括聽信讒言以及管理者當眾拆臺,3、用自己的強項戳他人軟肋,

通過學習這些,想必你也知道了如何成為一名洞察人性、有豐富經驗的管理者,在追夢的道路上,相信你一定可以走出屬于自己的輝煌,加油!

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/109275.html

標籤:其他

上一篇:漫畫:什么是 “黑天鵝事件” ?

下一篇:離職,你想清楚了嗎?

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more