成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

Eventloop不可怕,可怕的是遇上Promise

olle / 2834人閱讀

摘要:就是每次傳入的函數(shù)最后是的任務(wù)之后,開(kāi)始執(zhí)行,可以看到此時(shí)會(huì)批量執(zhí)行中的函數(shù),而且還給這些中回調(diào)函數(shù)放入了一個(gè)這個(gè)很顯眼的函數(shù)之中,表示這些回調(diào)函數(shù)是在微任務(wù)中執(zhí)行的。下一模塊會(huì)對(duì)此微任務(wù)中的插隊(duì)行為進(jìn)行詳解。

有關(guān)Eventloop+Promise的面試題大約分以下幾個(gè)版本——得心應(yīng)手版、游刃有余版、爐火純青版、登峰造極版和究極{{BANNED}}版。假設(shè)小伙伴們戰(zhàn)到最后一題,以后遇到此類問(wèn)題,都是所向披靡。當(dāng)然如果面試官們還能想出更{{BANNED}}的版本,算我輸。

版本一:得心應(yīng)手版
考點(diǎn):eventloop中的執(zhí)行順序,宏任務(wù)微任務(wù)的區(qū)別。

吐槽:這個(gè)不懂,沒(méi)得救了,回家重新學(xué)習(xí)吧。

setTimeout(()=>{
   console.log(1) 
},0)
Promise.resolve().then(()=>{
   console.log(2) 
})
console.log(3) 

這個(gè)版本的面試官們就特別友善,僅僅考你一個(gè)概念理解,了解宏任務(wù)(marcotask)微任務(wù)(microtask),這題就是送分題。

筆者答案:這個(gè)是屬于Eventloop的問(wèn)題。main script運(yùn)行結(jié)束后,會(huì)有微任務(wù)隊(duì)列和宏任務(wù)隊(duì)列。微任務(wù)先執(zhí)行,之后是宏任務(wù)。

PS:概念問(wèn)題

有時(shí)候會(huì)有版本是宏任務(wù)>微任務(wù)>宏任務(wù),在這里筆者需要講清楚一個(gè)概念,以免混淆。這里有個(gè)main script的概念,就是一開(kāi)始執(zhí)行的代碼(代碼總要有開(kāi)始執(zhí)行的時(shí)候?qū)Π?,不然宏任?wù)和微任務(wù)的隊(duì)列哪里來(lái)的),這里被定義為了宏任務(wù)(筆者喜歡將main script的概念多帶帶拎出來(lái),不和兩個(gè)任務(wù)隊(duì)列混在一起),然后根據(jù)main script中產(chǎn)生的微任務(wù)隊(duì)列和宏任務(wù)隊(duì)列,分別清空,這個(gè)時(shí)候是先清空微任務(wù)的隊(duì)列,再去清空宏任務(wù)的隊(duì)列。

版本二:游刃有余版

這一個(gè)版本,面試官們?yōu)榱丝简?yàn)一下對(duì)于Promise的理解,會(huì)給題目加點(diǎn)料:

考點(diǎn):Promise的executor以及then的執(zhí)行方式

吐槽:這是個(gè)小坑,promise掌握的熟練的,這就是人生的小插曲。

setTimeout(()=>{
   console.log(1) 
},0)
let a=new Promise((resolve)=>{
    console.log(2)
    resolve()
}).then(()=>{
   console.log(3) 
}).then(()=>{
   console.log(4) 
})
console.log(4) 

此題看似在考Eventloop,實(shí)則考的是對(duì)于Promise的掌握程度。Promise的then是微任務(wù)大家都懂,但是這個(gè)then的執(zhí)行方式是如何的呢,以及Promise的executor是異步的還是同步的?

錯(cuò)誤示范:Promise的then是一個(gè)異步的過(guò)程,每個(gè)then執(zhí)行完畢之后,就是一個(gè)新的循環(huán)的,所以第二個(gè)then會(huì)在setTimeout之后執(zhí)行。(沒(méi)錯(cuò),這就是某年某月某日筆者的一個(gè)回答。請(qǐng)給我一把槍,真想打死當(dāng)時(shí)的自己。)

正確示范:這個(gè)要從Promise的實(shí)現(xiàn)來(lái)說(shuō),Promise的executor是一個(gè)同步函數(shù),即非異步,立即執(zhí)行的一個(gè)函數(shù),因此他應(yīng)該是和當(dāng)前的任務(wù)一起執(zhí)行的。而Promise的鏈?zhǔn)秸{(diào)用then,每次都會(huì)在內(nèi)部生成一個(gè)新的Promise,然后執(zhí)行then,在執(zhí)行的過(guò)程中不斷向微任務(wù)(microtask)推入新的函數(shù),因此直至微任務(wù)(microtask)的隊(duì)列清空后才會(huì)執(zhí)行下一波的macrotask。
詳細(xì)解析

(如果大家不嫌棄,可以參考我的另一篇文章,從零實(shí)現(xiàn)一個(gè)Promise,里面的解釋淺顯易懂。)
我們以babel的core-js中的promise實(shí)現(xiàn)為例,看一眼promise的執(zhí)行規(guī)范:

代碼位置:promise-polyfill

PromiseConstructor = function Promise(executor) {
    //...
    try {
      executor(bind(internalResolve, this, state), bind(internalReject, this, state));
    } catch (err) {
      internalReject(this, state, err);
    }
};

這里可以很清除地看到Promise中的executor是一個(gè)立即執(zhí)行的函數(shù)。

then: function then(onFulfilled, onRejected) {
    var state = getInternalPromiseState(this);
    var reaction = newPromiseCapability(speciesConstructor(this, PromiseConstructor));
    reaction.ok = typeof onFulfilled == "function" ? onFulfilled : true;
    reaction.fail = typeof onRejected == "function" && onRejected;
    reaction.domain = IS_NODE ? process.domain : undefined;
    state.parent = true;
    state.reactions.push(reaction);
    if (state.state != PENDING) notify(this, state, false);
    return reaction.promise;
},

接著是Promise的then函數(shù),很清晰地看到reaction.promise,也就是每次then執(zhí)行完畢后會(huì)返回一個(gè)新的Promise。也就是當(dāng)前的微任務(wù)(microtask)隊(duì)列清空了,但是之后又開(kāi)始添加了,直至微任務(wù)(microtask)隊(duì)列清空才會(huì)執(zhí)行下一波宏任務(wù)(marcotask)。

//state.reactions就是每次then傳入的函數(shù)
 var chain = state.reactions;
  microtask(function () {
    var value = state.value;
    var ok = state.state == FULFILLED;
    var i = 0;
    var run = function (reaction) {
        //...
    };
    while (chain.length > i) run(chain[i++]);
    //...
  });

最后是Promise的任務(wù)resolve之后,開(kāi)始執(zhí)行then,可以看到此時(shí)會(huì)批量執(zhí)行then中的函數(shù),而且還給這些then中回調(diào)函數(shù)放入了一個(gè)microtask這個(gè)很顯眼的函數(shù)之中,表示這些回調(diào)函數(shù)是在微任務(wù)中執(zhí)行的。

那么在沒(méi)有Promise的瀏覽器中,微任務(wù)這個(gè)隊(duì)列是如何實(shí)現(xiàn)的呢?

小知識(shí):babel中對(duì)于微任務(wù)的polyfill,如果是擁有setImmediate函數(shù)平臺(tái),則使用之,若沒(méi)有則自定義則利用各種比如nodejs中的process.nextTick,瀏覽器中支持postMessage的,或者是通過(guò)create一個(gè)script來(lái)實(shí)現(xiàn)微任務(wù)(microtask)。最終的最終,是使用setTimeout,不過(guò)這個(gè)就和微任務(wù)無(wú)關(guān)了,promise變成了宏任務(wù)的一員。

拓展思考:

為什么有時(shí)候,then中的函數(shù)是一個(gè)數(shù)組?有時(shí)候就是一個(gè)函數(shù)?

我們稍稍修改一下上述題目,將鏈?zhǔn)秸{(diào)用的函數(shù),變成下方的,分別調(diào)用then。且不說(shuō)這和鏈?zhǔn)秸{(diào)用之間的不同用法,這邊只從實(shí)踐角度辨別兩者的不同。鏈?zhǔn)秸{(diào)用是每次都生成一個(gè)新的Promise,也就是說(shuō)每個(gè)then中回調(diào)方法屬于一個(gè)microtask,而這種分別調(diào)用,會(huì)將then中的回調(diào)函數(shù)push到一個(gè)數(shù)組之中,然后批量執(zhí)行。再換句話說(shuō),鏈?zhǔn)秸{(diào)用可能會(huì)被Evenloop中其他的函數(shù)插隊(duì),而分別調(diào)用則不會(huì)(僅針對(duì)最普通的情況,then中無(wú)其他異步操作。)。

let a=new Promise((resolve)=>{
     console.log(2)
     resolve()
})
a.then(()=>{
    console.log(3) 
})
a.then(()=>{
    console.log(4) 
})
 

下一模塊會(huì)對(duì)此微任務(wù)(microtask)中的“插隊(duì)”行為進(jìn)行詳解。

版本三:爐火純青版

這一個(gè)版本是上一個(gè)版本的進(jìn)化版本,上一個(gè)版本的promise的then函數(shù)并未返回一個(gè)promise,如果在promise的then中創(chuàng)建一個(gè)promise,那么結(jié)果該如何呢?

考點(diǎn):promise的進(jìn)階用法,對(duì)于then中return一個(gè)promise的掌握

吐槽:promise也可以是地獄……

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})
按照上一節(jié)最后一個(gè)microtask的實(shí)現(xiàn)過(guò)程,也就是說(shuō)一個(gè)Promise所有的then的回調(diào)函數(shù)是在一個(gè)microtask函數(shù)中執(zhí)行的,但是每一個(gè)回調(diào)函數(shù)的執(zhí)行,又按照情況分為立即執(zhí)行,微任務(wù)(microtask)和宏任務(wù)(macrotask)。

遇到這種嵌套式的Promise不要慌,首先要心中有一個(gè)隊(duì)列,能夠?qū)⑦@些函數(shù)放到相對(duì)應(yīng)的隊(duì)列之中。

Ready GO

第一輪

current task: promise1是當(dāng)之無(wú)愧的立即執(zhí)行的一個(gè)函數(shù),參考上一章節(jié)的executor,立即執(zhí)行輸出[promise1]

micro task queue: [promise1的第一個(gè)then]

第二輪

current task: then1執(zhí)行中,立即輸出了then11以及新promise2的promise2

micro task queue: [新promise2的then函數(shù),以及promise1的第二個(gè)then函數(shù)]

第三輪

current task: 新promise2的then函數(shù)輸出then21和promise1的第二個(gè)then函數(shù)輸出then12

micro task queue: [新promise2的第二then函數(shù)]

第四輪

current task: 新promise2的第二then函數(shù)輸出then23

micro task queue: []

END

最終結(jié)果[promise1,then11,promise2,then21,then12,then23]。

變異版本1:如果說(shuō)這邊的Promise中then返回一個(gè)Promise呢??

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    return new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})

這里就是Promise中的then返回一個(gè)promise的狀況了,這個(gè)考的重點(diǎn)在于Promise而非Eventloop了。這里就很好理解為何then12會(huì)在then23之后執(zhí)行,這里Promise的第二個(gè)then相當(dāng)于是掛在新Promise的最后一個(gè)then的返回值上。

變異版本2:如果說(shuō)這邊不止一個(gè)Promise呢,再加一個(gè)new Promise是否會(huì)影響結(jié)果??

new Promise((resolve,reject)=>{
    console.log("promise1")
    resolve()
}).then(()=>{
    console.log("then11")
    new Promise((resolve,reject)=>{
        console.log("promise2")
        resolve()
    }).then(()=>{
        console.log("then21")
    }).then(()=>{
        console.log("then23")
    })
}).then(()=>{
    console.log("then12")
})
new Promise((resolve,reject)=>{
    console.log("promise3")
    resolve()
}).then(()=>{
    console.log("then31")
})

笑容逐漸{{BANNED}},同樣這個(gè)我們可以自己心中排一個(gè)隊(duì)列:

第一輪

current task: promise1,promise3

micro task queue: [promise2的第一個(gè)thenpromise3的第一個(gè)then]

第二輪

current task: then11,promise2,then31

micro task queue: [promise2的第一個(gè)then,promise1的第二個(gè)then]

第三輪

current task: then21,then12

micro task queue: [promise2的第二個(gè)then]

第四輪

current task: then23

micro task queue: []

最終輸出:[promise1,promise3,then11,promise2,then31,then21,then12,then23]

版本四:登峰造極版
考點(diǎn):在async/await之下,對(duì)Eventloop的影響。

槽點(diǎn):別被async/await給騙了,這題不難。

相信大家也看到過(guò)此類的題目,我這里有個(gè)相當(dāng)簡(jiǎn)易的解釋,不知大家是否有興趣。

async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}

async  function async2() {
    console.log( "async2");
}

console.log("script start");

setTimeout(function () {
    console.log("settimeout");
},0);

async1();

new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
});
console.log("script end"); 

async/await僅僅影響的是函數(shù)內(nèi)的執(zhí)行,而不會(huì)影響到函數(shù)體外的執(zhí)行順序。也就是說(shuō)async1()并不會(huì)阻塞后續(xù)程序的執(zhí)行,await async2()相當(dāng)于一個(gè)Promise,console.log("async1 end");相當(dāng)于前方Promise的then之后執(zhí)行的函數(shù)。

按照上章節(jié)的解法,最終輸出結(jié)果:[script start,async1 start,async2,promise1,script end,async1 end,promise2,settimeout]

如果了解async/await的用法,則并不會(huì)覺(jué)得這題是困難的,但若是不了解或者一知半解,那么這題就是災(zāi)難啊。

此處唯一有爭(zhēng)議的就是async的then和promise的then的優(yōu)先級(jí)的問(wèn)題,請(qǐng)看下方詳解。*

async/await與promise的優(yōu)先級(jí)詳解
async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}
async  function async2() {
    console.log( "async2");
}
// 用于test的promise,看看await究竟在何時(shí)執(zhí)行
new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
}).then(function () {
    console.log("promise3");
}).then(function () {
    console.log("promise4");
}).then(function () {
    console.log("promise5");
});

先給大家出個(gè)題,如果讓你polyfill一下async/await,大家會(huì)怎么polyfill上述代碼?下方先給出筆者的版本:

function promise1(){
    return new Promise((resolve)=>{
        console.log("async1 start");
        promise2().then(()=>{
            console.log("async1 end");
            resolve()
        })
    })
}
function promise2(){
    return new Promise((resolve)=>{
        console.log( "async2"); 
        resolve() 
    })
}

在筆者看來(lái),async本身是一個(gè)Promise,然后await肯定也跟著一個(gè)Promise,那么新建兩個(gè)function,各自返回一個(gè)Promise。接著function promise1中需要等待function promise2中Promise完成后才執(zhí)行,那么就then一下咯~。

根據(jù)這個(gè)版本得出的結(jié)果:[async1 start,async2,promise1,async1 end,promise2,...],async的await在test的promise.then之前,其實(shí)也能夠從筆者的polifill中得出這個(gè)結(jié)果。

然后讓筆者驚訝的是用原生的async/await,得出的結(jié)果與上述polyfill不一致!得出的結(jié)果是:[async1 start,async2,promise1,promise2,promise3,async1 end,...],由于promise.then每次都是一輪新的microtask,所以async是在2輪microtask之后,第三輪microtask才得以輸出(關(guān)于then請(qǐng)看版本三的解釋)。

/ 突如其來(lái)的沉默 /

這里插播一條,async/await因?yàn)橐?jīng)過(guò)3輪的microtask才能完成await,被認(rèn)為開(kāi)銷很大,因此之后V8和Nodejs12開(kāi)始對(duì)此進(jìn)行了修復(fù),詳情可以看github上面這一條pull

那么,筆者換一種方式來(lái)polyfill,相信大家都已經(jīng)充分了解await后面是一個(gè)Promise,但是假設(shè)這個(gè)Promise不是好Promise怎么辦?異步是好異步,Promise不是好Promise。V8就很兇殘,加了額外兩個(gè)Promise用于解決這個(gè)問(wèn)題,簡(jiǎn)化了下源碼,大概是下面這個(gè)樣子:

// 不太準(zhǔn)確的一個(gè)描述
function promise1(){
    console.log("async1 start");
    // 暗中存在的promise,筆者認(rèn)為是為了保證async返回的是一個(gè)promise
    const implicit_promise=Promise.resolve()
    // 包含了await的promise,這里直接執(zhí)行promise2,為了保證promise2的executor是同步的感覺(jué)
    const promise=promise2()
    // https://tc39.github.io/ecma262/#sec-performpromisethen
    // 25.6.5.4.1
    // throwaway,為了規(guī)范而存在的,為了保證執(zhí)行的promise是一個(gè)promise
    const throwaway= Promise.resolve()
    //console.log(throwaway.then((d)=>{console.log(d)}))
    return implicit_promise.then(()=>{
        throwaway.then(()=>{
            promise.then(()=>{
                console.log("async1 end");
            })
        }) 
    })
}

ps:為了強(qiáng)行推遲兩個(gè)microtask執(zhí)行,筆者也是煞費(fèi)苦心。

總結(jié)一下:async/await有時(shí)候會(huì)推遲兩輪microtask,在第三輪microtask執(zhí)行,主要原因是瀏覽器對(duì)于此方法的一個(gè)解析,由于為了解析一個(gè)await,要額外創(chuàng)建兩個(gè)promise,因此消耗很大。后來(lái)V8為了降低損耗,所以剔除了一個(gè)Promise,并且減少了2輪microtask,所以現(xiàn)在最新版本的應(yīng)該是“零成本”的一個(gè)異步。
版本五:究極{{BANNED}}版

饕餮大餐,什么{{BANNED}}的內(nèi)容都往里面加,想想就很豐盛。能考到這份上,只能說(shuō)面試官人狠話也多。

考點(diǎn):nodejs事件+Promise+async/await+佛系setImmediate

槽點(diǎn):筆者都不知道那個(gè)可能先出現(xiàn)

async function async1() {
    console.log("async1 start");
    await  async2();
    console.log("async1 end");
}
async  function async2() {
    console.log( "async2");
}
console.log("script start");
setTimeout(function () {
    console.log("settimeout");
});
async1()
new Promise(function (resolve) {
    console.log("promise1");
    resolve();
}).then(function () {
    console.log("promise2");
});
setImmediate(()=>{
    console.log("setImmediate")
})
process.nextTick(()=>{
    console.log("process")
})
console.log("script end"); 

隊(duì)列執(zhí)行start

第一輪:

current task:"script start","async1 start","async2","promise1",“script end”

micro task queue:[async,promise.then,process]

macro task queue:[setTimeout,setImmediate]

第二輪

current task:process,async1 end ,promise.then

micro task queue:[]

macro task queue:[setTimeout,setImmediate]

第三輪

current task:setTimeout,setImmediate

micro task queue:[]

macro task queue:[]

最終結(jié)果:[script start,async1 startasync2,promise1script end,process,async1 end,promise2,setTimeout,setImmediate]

同樣"async1 end","promise2"之間的優(yōu)先級(jí),因平臺(tái)而異。

筆者干貨總結(jié)

在處理一段evenloop執(zhí)行順序的時(shí)候:

第一步確認(rèn)宏任務(wù),微任務(wù)

宏任務(wù):script,setTimeout,setImmediate,promise中的executor

微任務(wù):promise.then,process.nextTick

第二步解析“攔路虎”,出現(xiàn)async/await不要慌,他們只在標(biāo)記的函數(shù)中能夠作威作福,出了這個(gè)函數(shù)還是跟著大部隊(duì)的潮流。

第三步,根據(jù)Promise中then使用方式的不同做出不同的判斷,是鏈?zhǔn)竭€是分別調(diào)用。

最后一步記住一些特別事件

比如,process.nextTick優(yōu)先級(jí)高于Promise.then

參考網(wǎng)址,推薦閱讀:

有關(guān)V8中如何實(shí)現(xiàn)async/await的,更快的異步函數(shù)和 Promise

有關(guān)async/await規(guī)范的,ecma262

還有babel-polyfill的源碼,promise

后記

Hello~Anybody here?

本來(lái)筆者是不想寫這篇文章的,因?yàn)橛蟹N5年高考3年模擬的既視感,奈何面試官們都太兇殘了,為了“折磨”面試者無(wú)所不用其極,怎么{{BANNED}}怎么來(lái)。不過(guò)因此筆者算是徹底掌握了Eventloop的用法,因禍得福吧~

有小伙伴看到最后嘛?來(lái)和筆者聊聊你遇到過(guò)的的Eventloop+Promise的{{BANNED}}題目。

歡迎轉(zhuǎn)載~但請(qǐng)注明出處~首發(fā)于掘金~Eventloop不可怕,可怕的是遇上Promise

題外話:來(lái)segmentfault試水~啊哈哈哈啊哈哈

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/103054.html

相關(guān)文章

  • 【前端面試分享】- 寒冬求職上篇

    摘要:記錄下我遇到的面試題,都有大佬分享過(guò),附上各個(gè)大佬的文章,總結(jié)出其中的主要思想即可。推薦黑金團(tuán)隊(duì)的文章前端緩存最佳實(shí)踐推薦名揚(yáng)的文章淺解強(qiáng)緩存和協(xié)商緩存狀態(tài)碼重點(diǎn)是等,要給面試官介紹清楚。前言 在這互聯(lián)網(wǎng)的寒冬臘月時(shí)期,雖說(shuō)過(guò)了金三銀四,但依舊在招人不斷。更偏向于招聘高級(jí)開(kāi)發(fā)工程師。本人在這期間求職,去了幾家創(chuàng)業(yè),小廠,大廠廝殺了一番,也得到了自己滿意的offer。 整理一下自己還記得的面試...

    shinezejian 評(píng)論0 收藏0
  • js學(xué)習(xí)之異步處理

    摘要:學(xué)習(xí)開(kāi)發(fā),無(wú)論是前端開(kāi)發(fā)還是都避免不了要接觸異步編程這個(gè)問(wèn)題就和其它大多數(shù)以多線程同步為主的編程語(yǔ)言不同的主要設(shè)計(jì)是單線程異步模型。由于異步編程可以實(shí)現(xiàn)非阻塞的調(diào)用效果,引入異步編程自然就是順理成章的事情了。 學(xué)習(xí)js開(kāi)發(fā),無(wú)論是前端開(kāi)發(fā)還是node.js,都避免不了要接觸異步編程這個(gè)問(wèn)題,就和其它大多數(shù)以多線程同步為主的編程語(yǔ)言不同,js的主要設(shè)計(jì)是單線程異步模型。正因?yàn)閖s天生的與...

    VioletJack 評(píng)論0 收藏0
  • 精讀《async/await 是把雙刃劍》

    摘要:本周精讀內(nèi)容是逃離地獄。精讀仔細(xì)思考為什么會(huì)被濫用,筆者認(rèn)為是它的功能比較反直覺(jué)導(dǎo)致的。同時(shí),筆者認(rèn)為,也不要過(guò)渡利用新特性修復(fù)新特性帶來(lái)的問(wèn)題,這樣反而導(dǎo)致代碼可讀性下降。 本周精讀內(nèi)容是 《逃離 async/await 地獄》。 1 引言 終于,async/await 也被吐槽了。Aditya Agarwal 認(rèn)為 async/await 語(yǔ)法讓我們陷入了新的麻煩之中。 其實(shí),筆者...

    2shou 評(píng)論0 收藏0
  • 為什么找到工作的是你,技術(shù)差的還是你?

    摘要:當(dāng)然是否需要培訓(xùn)這個(gè)話題,得基于兩個(gè)方面,如果你是計(jì)算機(jī)專業(yè)畢業(yè)的,大學(xué)基礎(chǔ)課程學(xué)的還可以,我建議不需要去培訓(xùn),既然有一定的基礎(chǔ),那就把去培訓(xùn)浪費(fèi)的四個(gè)月,用去實(shí)習(xí),培訓(xùn)是花錢,實(shí)習(xí)是掙錢,即使工資低點(diǎn),一正一負(fù)自己算算吧。 上周一篇《程序員平時(shí)該如何學(xué)習(xí)來(lái)提高自己的技術(shù)》火了之后,「非著名程序員」微信公眾號(hào)的后臺(tái)經(jīng)常收到程序員和一些初學(xué)者的消息,問(wèn)一些技術(shù)提高的問(wèn)題,而且又恰逢畢業(yè)季...

    yeyan1996 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

閱讀需要支付1元查看
<