整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
avaScript和Java有什么聯系
根據目前我自己的理解，不要被名字有相似字節所欺騙，這兩個語言其實沒有什么聯系，如果說有的話，應該就是關鍵字和對象的一些范疇有點相似或者說是有種模仿的感覺。但是實際上一個作為腳本的輕量語言[^7]，一個作為有完整體制的大型語言[^8],兩者是沒有任何可比性的。
JS的內鏈外鏈
內鏈
? JS的內鏈，也就是在html文件內的調用使用與css類似，也有兩種方式，即在html文件的<head></head>中書寫使用或是在<body></body>中使用。
<head></head>內書寫
? 在<head></head>中對JS的代碼進行書寫時，我們使用<script></script>對我們的JS代碼進行包裹，與html及CSS的法則一樣，其作用也是用來標明其JS的代碼塊屬性。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>test</title>
<script>
function displayDate(){
document.getElementById("demo").innerHTML=Date();
}
</script>
</head>
<body>
<h1>我的第一個 JavaScript 程序</h1>
<p id="demo">這是一個段落</p>
<button type="button" onclick="displayDate()">顯示日期</button>
</body>
</html>
###### <body></body>內書寫
? 與在<head></head>中類似的，我們在<body></body>中對JS的書寫和使用同樣是在<script></script>中實現，其作用也與上述的一致。
<!DOCTYPE html>
<html>
<body>
<script>
document.write("<h1>This is a heading</h1>");
document.write("<p>This is a paragraph.</p>");
</script>
</body>
</html>
外鏈
與css有些不同的，JS的外鏈同樣使用的是<script></script>標簽來實現。JS即可以出現本地的JS文件的鏈接，也可以調用網上的JS文件進行鏈接，但調用網絡上的文件有可能會受到目標文件服務器和網絡的影響，使用的頻率沒有本地的調用高。
? 調用本地JS文件：
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript" src="../js/js_for_Seat_selection_nterface.js" ></script>
</head>
<body>
</body>
</html>
調用網絡的JS文件：
<!DOCTYPE html>
<html>
<head>
<script src="http://www.lanrenzhijia.com/ajaxjs/jquery.min.js"> </script>
</head>
<body>
</body>
</html>
? JS的外鏈與css類似的，也可以在同個文件里調用多個JS文件使用。其中還有很多較css的相似部分就不在這里重復說了，可以參考之前的css部分內容。
JS的語法關鍵字
JS的語法關鍵字有很多很多，因為JS是一門以對象為基礎的語言，我們在使用會發現很多例如document.getElementById("demo").innerHTML=x;的語句，這里的getElementById(),innerHTML其實都是JS為我們已經封裝（可以理解為打包）好了的方法和方法中的參數。所以我們在這里主要介紹一些基本的關鍵字。
function
function的作用其實很簡單，就是聲明一個函數，表明我這里的是一個函數，我們用一個看例子來看：
function myFunction(){
var x="";
var time=new Date().getHours();
if (time<20){
x="Good day";
}
document.getElementById("demo").innerHTML=x;
}
上述的例子就是為我們聲明了一個叫做myFunction的的函數，其后的花括號中包含的就是函數中的內容。
var
在JS中，var的作用就是聲明一個變量，在JS中，對于變量的類型沒有嚴格的規定，所以JS也是一門弱語言，被定義的變量只有在第一次被賦值時才會被系統分配相應數據類型的空間。
var a;
a=10;
但實際上我們會發現，在實際使用時不僅僅是var可以聲明一個變量，$也可以成功聲明一個變量，甚至不需要任何的申明關鍵字也可以直接創建一個變量。但實際上是有非常大的差別的，$是JQ中的一個已經過定義的自定義函數名，而在單純的JS中是沒有任何意義的，一般是在你的文件已經引入了一個JQ數據庫后才出現$也可以創建變量的情況，而相較于不使用任何關鍵字而直接創建一個變量，其實質是在整個JS文件的最上層windows中創建了一個對象屬性，詳細的解釋我會在文末提供一個網絡來源的博客地址，其中對創建對象屬性有一個較為詳細的解釋。
所以我們在聲明創建變量時一定要使用var關鍵字，不使用任何關鍵字創建變量，雖然可行，但卻存在著語法錯誤。
new
與其它的面向對象方法一樣的，JS中創建對象所使用的個關鍵字也是new，我們通過它來創建一個對象。
person=new Object();
在上述的例子中，我們創建了一個名為person的對象，object我們在這里可以簡單的理解為一個類型為對象的數據結構。這句代碼的意思就是創建一個對象，對象名為person。
JS的結構語句
其實說是JS的結構語句，我們不難發現的，這些結構語句其實很多都是我們在其他語言中也能見到的語言語法，我們在這里也是將它們簡單的歸類再來說明一下。
###### if else
if else語句主要的作用其實也很簡單，就是做一個判斷，就像它的翻譯 一樣——如果….就….. 否則…..。
if(...){
...
}
else{
....
}
? 上述的就是它的基本格式，我們可以看到在if后面的小括號中會有一個判斷語句，其中的語句用來判斷真假來控制語句的執行部分。花括號中的就是滿足條件時執行的語句。
這一條語句是可以嵌套的，我們通過對它的嵌套來進行多層的判斷。
if(...){
if(...){
...
}
else{
....
}
}
else{
....
}
while
我們先來看它的格式：
while(...){
...
}
while是一個循環語句，在關鍵字后面的小括號中，也同樣是一條判斷語句，用來控制循環的執行。在花括號中是我們的循環內容。
do while
可能我們會發現，這條語句和上一條語句非常的相似，我們還是先來看它的格式：
do{
...
}while(...)
它一樣是一條控制循環的語句，不過和上一個語句有所區別的，它是先循環后判斷，而while是先判斷后循環，有的時候我們在不以言大哥情況下使用會達到不一樣的效果。
for
js for( var i=0;1<=10;i++){ ... }
for語句也同樣是一個循環語句，我們在上面舉出了一個實例，從例子中我們看到，for和它的循環語句是有區別的，我們需要在判斷的語句中定義變量，規定執行循環的條件，及控制循環的條件變化。
但實際上，有些時候我們只需要寫明控制循環的條件語句就可以了，其他的兩條語句可以不在括號中寫出。但要注意的，我們需要保留它的分號，不然會出現語法錯誤。
switch
js switch(...){ case '...': ...;break; case '...': ...;break; .... default:...; }
這是一個條件選擇語句，我們通過判斷語句來選擇到一個具體的分支，執行相應的語句。
有關于break,default 的作用，我們就不細說了，大家可以去網上查看它的詳細信息。
JS的效果實現(HTML的事件響應)
我們已經很簡單的介紹了一下JS的語法和關鍵字，那么我們下面來說在網頁中如何觸發JS的代碼，又或者說是如觸發相應的事件。
##### 點擊事件
點擊事件就是通過頁面點擊觸發的事件，我們要注意的，在網頁中其實不是只有按鈕才可以作為點擊事件的載體，基本上所有的網頁元素都可以作為點擊事件的載體。也就是說其實我們可以在任意一個元素中添加一個點擊事件。
? 下面我們來看常用的格式：
<html>
<body>
<input type="checkbox" name="ticket_seat"id="tucket_18" class="ticket_input"value="18"onclick="ticket_onclick()">
<script>
function ticket_onclick(){
...
}
</script>
</body>
</html>
? 在上述的例子中我們可以看到，在標簽中加入一個onclick屬性，在后面寫上要觸發的函數名。這樣我們在點擊網頁上的元素之后，我們就可以觸發相應的JS函數。
對于我們的onclick字段，我們可以像常規的函數調用來看待它，也就是說，我們也是可以通過它向函數傳入參數。
后記：對于大部分轉行的人來說，找機會把自己的基礎知識補齊，邊工作邊補基礎知識，真心很重要。
"我們相信人人都可以成為一個IT大神，現在開始，選擇一條陽光大道，助你入門，學習的路上不再迷茫。這里是北京尚學堂，初學者轉行到IT行業的聚集地。"
者 | Adrien Joly
譯者 | 張衛濱
策劃 | 丁曉昀
有時候，JavaScript（甚至帶有類型檢查的 TypeScript）會因為其不可預測的特性和缺乏約定而遭到批評。對于那些知道 JavaScript 是為 web 瀏覽器設計的腳本語言的人來說，這就不足為奇了。
但是，現在它已經成為開發全棧 web 的首選語言，也是跨平臺移動應用的熱門方案。那么，當開發人員的 JavaScript/TypeScript 代碼庫開始老化，由此帶來的復雜性痛苦地增長時，他們該采取什么行動才能最大限度地減少資源浪費并保持工作滿意度呢？
本文將基于我 10 多年來編寫 JavaScript 代碼的經驗和 5 年多拯救 JS/TS 項目的經歷，向讀者介紹如下內容：
在開發下一個特性時，每個警告、類型錯誤或非正常的測試都會讓開發人員浪費時間、精力和專注度。
代碼警告尤其令人討厭，因為開發人員會習慣性地忽略它們，“只要一切按預期運行就好”。因此，它們會迅速累積，當我們遇到缺陷、事故或系統的意外行為時，就很難將其作為有用的線索。
類型錯誤就是一個很好的樣例。當我們的用戶遵循“快樂路徑（happy path）”時，這些錯誤似乎無關緊要，因為軟件似乎能夠按照預期運行。所以，我們可能會使用@ts-ignore、any或類型斷言來暫時忽略它們。但是，這樣做的話，就意味著如果有一天用戶選擇不同的路徑，就會面臨運行時錯誤。
這樣的話，開發人員就需要調查、重現和修復一個新的缺陷，而這個缺陷恰恰是他們幾個月前允許走捷徑所造成的。如果你的代碼被各種警告和/或暫時忽略這些警告削弱了質量，那么找到這個捷徑將耗費大量的時間。
當生產環境的數據庫因“內存不足”錯誤而崩潰時，該警告可能會幫助開發人員找到崩潰的原因
警告和類型錯誤是查找缺陷和事故的線索。我們累積（或忽略）的警告和錯誤越多，開發人員就會花費越多的時間去調查。如果代碼是他們很久以前編寫的，那情況就會更糟糕了。
類型檢查器認為缺少一個預期的屬性。忽略這個錯誤將意味著要承擔持久化不一致數據的風險，在幾個月之后，你可能需要花費幾天的時間來調查和解決這個問題
有許多靜態代碼分析工具可供使用，最常用的包括：
警告也可能來自其他工具：依賴安裝器（如npm和yarn）、打包器（如webpack）、代碼處理器（babel、scss）和執行環境（CI 運行器）。不要忽視它們！
如果遵循這些建議會讓你的代碼變得非常冗長和/或復雜（比如防御式代碼），你可以需要對其進行重新設計。
"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'`"
},復制代碼
借助靜態代碼分析器和 npm 腳本，能夠讓開發人員輕松快速地探測有問題的代碼
安裝和配置靜態代碼分析工具是一個良好的開端，但這還不夠。
要想取得持續的成功，要確保開發團隊做到如下幾點：
如下幾種策略可能會提供幫助：
當某項職責沒有人負責時，集體責任往往會被其他“優先事項”所取代（比如，本周多交付一個特性，但是代價是忽略一個警告）。
定期輪換角色，確保每個人都能參與其中并保持積極性。
現在，我們有了一支致力于保持代碼庫整潔的團隊，我們相信用戶很少會遇到編程錯誤。
但是，業務邏輯中的錯誤該怎么辦呢？
例如，如果一個新添加的功能破壞了另一個功能該怎么辦？如果開發人員從一開始就誤解了該功能的預期行為，又該怎么辦？如果這樣的錯誤最終導致了嚴重的收入損失又該如何處理？
與編程錯誤類似，業務邏輯問題可能會在生產環境由用戶發現，但我們更希望盡早發現它們。因此，定期測試軟件非常重要，這個過程可以使用自動化和/或手動測試。
從業務角度看，測試有兩個作用：
確保功能性測試（也稱為“驗收測試”）涵蓋大多數關鍵業務特性，單元測試或集成測試涵蓋大多數關鍵技術組件。此外，確保持續集成在任何測試失敗時都能向開發人員提供可執行的反饋。
對于有些開發人員來說，將測試工作委托給其他人（如產品負責人或 QA 團隊）是很有誘惑力的做法。在每個新特性完成后，進行一次這樣的委托測試，以確保特性實現符合功能性需求，并進行協作迭代，這樣做可能是合理的。
但是，委托他人進行回歸檢測并不是一個好主意，原因包括：
回歸測試是一項痛苦且可能代價高昂的負擔，尤其是需要不同角色（如產品負責人和開發人員）必須協作的情況下。從長遠來看，回歸測試自動化意味著可以節省大量的時間，而且開發人員具有編寫自動化測試的技能，所以，開發人員首先要承擔起檢測回歸的責任，而不必讓其他角色參與進來，這符合他們的利益。
從最關鍵的業務特性開始。要找出這些特性，你可以問自己：“就收益和/或減少成本而言，在生產環境中可能發生的最糟糕的事情是什么？”
例如，電子商務網站的回答可能是如下的特性：
基于這些業務關鍵的用例，從它們開始編寫端到端的自動化測試肯定就是非常有意義的。
在每次代碼更新或添加到代碼庫之時，在將其部署到生產環境之前。
借助git hook，在每次提交時運行測試可能就足夠了，因為它能可靠地運行，而且其持續時間不會導致開發人員編寫更少的測試。
不管是否使用git hook，都要確保每次推送可用于生產環境的代碼時，測試能在某處運行（例如，最好是在持續集成環境中）。
在持續集成環境中，每次提交都會運行代碼檢查和自動化測試。
需要優化的變量包括：
如果你的團隊在編寫自動化測試和/或可測試代碼方面經驗不足，那么可以從一些端到端測試開始。然后，逐步增加對范圍更小的代碼單元的測試。這樣做可以激勵開發人員編寫易于測試的代碼。例如，通過隔離責任、減少耦合和/或將業務邏輯寫成純函數。遵循依賴注入架構是實現這一目標的好方法。（參見六邊形架構或簡潔架構）
自動化測試（如本文所述）的目的是探測團隊的功能性范圍內的回歸，而不是第三方的功能。基于這一點，在測試中 Mock 第三方是合理的。
也就是說：
探測自己的代碼中的問題和第三方 API 中的問題并不遵循相同的生命周期：
你需要持續監控第三方提供商是否能夠正常運行并達到預期效果。但是，第三方錯誤不一定能夠在發生之時就探測到，因此最好是定期監控，而不是在開發人員每次推送代碼變更的時候進行監控。
所以，需要搭建兩個專門的流水線：
為了編寫長期最有用、最健壯的測試，我建議遵循F.I.R.S.T.原則。確保開發人員不會濫用mock。
假設你的代碼庫已經或者將要開發數年的時間，那么隨著時間的推移，它很可能會在代碼風格和質量方面失去內聚力。更糟糕的是，由于技術債務、缺乏測試或意外復雜性的積累，某些組成部分的維護可能會變得很復雜。
在這種情況下，要像上文所建議的那樣，在整個代碼庫中對代碼實現一致的內聚預期可能會變得很復雜。不過，這也沒有關系。
你不希望看到的是期望值降低到一個最低的平均水準。這樣的話，你可以把代碼劃分為不同的范圍，并為每個范圍設置不同的期望水平。
例如，考慮一個即將為電子商務網站實現新特性的團隊。他們希望這個新特性能夠比代碼庫中的其他特性更健壯、更易于維護。為了實現這一點，他們在配置靜態代碼分析工具（如 ESLint 和 TypeScript）時采用比代碼庫的其他部分更嚴格的規則，并針對專門為該特性而創建的目錄使用覆蓋的方式啟用更多的規則。通過這種方式，團隊可以提高新代碼的質量，而不必急于對代碼庫中“遺留”的部分進行現代化處理。
"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"
}
}
]復制代碼
通過配置覆蓋，我們可以為不同的部分設置不同的 ESLint 規則
與之類似，如果要對整個代碼庫進行現代化改造，也要循序漸進。你可以創建一個具有更嚴格規則的專用目錄，并逐漸將遺留代碼遷移至該目錄，同時修復代碼的警告和類型錯誤。
有種方式是逐步將功能范圍中陳舊的部分遷移到更好的設計中。例如，選擇一個難以編寫自動化測試的特性，并將它的實現遷移到六邊形架構中，將業務/領域邏輯根據輸入命令（即“API”）和副作用（即“SPI”）分離開來。通過編寫自動化測試來指導遷移，并將新的實現放在具有更嚴格靜態代碼分析規則的專用目錄中。
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 })
);
});復制代碼
setAvatar特性經過了重新設計，由于采用了依賴反轉，使其易于單獨進行測試。下面是我們遷移另一項特性的過程，即播放列表刪除
如果你決定遵循這一路徑，如下是一些建議：
在遷移完每個限界上下文之后，你將會得到一個代碼庫，在代碼庫中 100%的代碼都應按照更嚴格的規則進行檢查。
盡管使用了靜態分析工具來檢測缺陷，使用了自動化測試來探測回歸，但用戶還是會在生產環境中發現問題。這是無法避免的。但是，有一種方法可以降低出現此類問題的概率，并縮短團隊修復問題的時間：
簡約版答案：因為DORA研究項目發現，大多數執行團隊每天都在進行部署，或者每天部署多次。
詳盡版答案：
在生產環境中出現意料之外的行為是可以的。在有些情況下，這甚至是一件好事。
當意料之外的行為給企業和/或開發團隊帶來巨大損失時（例如，網站中斷，導致幾個小時無法使用），開發人員應該采取措施防止類似的事件再次發生。
有多種方式可以探測生產環境中的問題：
無論是哪種情況，開發人員都需要以下信息：問題是什么、問題的具體表現（如錯誤信息）、如何重現問題（如環境+過程），以及用戶的初衷和期望是什么。
但是，如何在最糟糕的情況下獲得這些數據呢？這就是錯誤監控工具（如Sentry）的用武之地了。通過將它們注入到生產環境中運行的產品中，它們就能像探針一樣檢測運行時錯誤，并將它們匯總到已知錯誤的列表中，直到每個錯誤都被開發人員修復為止。此外，它們還會獲取有關錯誤上下文的數據（如用戶代理、所使用軟件的版本、操作系統、確切的時間戳等），以幫助開發人員重現錯誤。
但令人遺憾的是，與靜態代碼分析器類似，這些工具并不能解決問題。因此，與警告和類型錯誤一樣，要確保盡快處理每個錯誤。團隊讓錯誤累積得越多，使用這些工具的動力和效率就會越低。
此外，在使用這類監控工具時，請確保個人和/或機密數據不會從系統中泄露出去。
從戰術上講，有許多方法可供選擇。你可以讓一名開發人員負責修復生產環境的錯誤，并將其作為最優先的事項。這個角色可以定期輪換（比如每天），這樣可以激勵每個人都編寫更健壯的代碼。或者，也可以在每天的會議上將新錯誤單獨分派給志愿開發人員。
不必慌張！當生產環境中發生事故時，都要遵守如下程序：
避免重蹈覆轍的關鍵在于上述程序的最后一步。
這也是經常被忽視的過程。大多數情況下，是因為沒人覺得自己有責任這樣做。很多時候，是因為產品負責人（或產品團隊）向開發人員施壓，要求他們優先完成開發計劃中的特性，而不是保護現有代碼和/或調整開發流程。有時，開發人員自己也會決定開發更多的特性，而不是避免再次犯錯。
調查事故根本原因時的注意事項
在這個方面，“5 個為什么（5 WHY）”技巧是很有用的。例如：
在本例中，根本原因是整個網站都依賴于遺留的會話管理后端，這使得導航難以預測，有時還會導致生產環境崩潰。因此，除非團隊修復傳統的會話管理后端，否則類似的崩潰很可能很快就會在生產環境中再次發生。團隊現在應該修復遺留的會話管理后端嗎？也許不用。但是他們應該努力制定一個能夠實現該目標的補救計劃。
讓一位開發人員負責確保盡快發現生產中的意外行為（如運行時錯誤、缺陷、事故……），盡快修復，并采取措施防止今后再次發生各類問題。
通過這種方式，開發人員能夠感受到有能力在良好的條件下開展工作。例如，在生產過程中設置恰當的監控和日志，確保撰寫有用的事后報告，并采取預防措施。
當信心達到良好水平時，逐步增加部署頻率。
此時，開發人員就具備了編寫高質量軟件，并盡快發現缺陷的能力。這些缺陷最好是在設計或實現時發現，而不是在生產環境中。他們能夠快速發現并修正生產環境的錯誤，不會重復犯同樣的錯誤。他們對自己的代碼和開發流程充滿信心，因此每天都能在生產中實現改善。而且，他們在對軟件功能化范圍進行預期改善的同時，也會逐步改善代碼庫中最古老部分的設計和質量，使其保持健康、穩健并易于長期維護。
但是，令人遺憾的是，這種平衡很快就可能被瓦解。舉例來說：
防止或解決這類情況可能會非常困難，因為這需要良好的領導力和/或軟技能。
一個常見的錯誤是培養某種思維定式，即開發人員應該主要致力于實現優先的、計劃好的和設計好的特性。
這樣做是有問題的，因為：
下面是一些關于如何避免上述陷阱的建議：
JavaScript 語言及其不斷變化的軟件包和實踐組成的生態系統會使代碼庫迅速變得難以維護。正如我們在本文所討論的那樣，無需從頭重寫所有的內容，也無需暫停新特性的開發，就可以避免由此造成的開發速度和/或代碼質量的下降。
關于如何在 TypeScript 和 JavaScript 項目中應用這些推薦做法的更多實用建議，我建議你參考Yoni Goldberg的最佳實踐列表。它們是為 Node.js（后端）項目編寫的，但其中很多也適用于前端代碼庫。
原文鏈接：前端老手10年心得，JavaScript/TypeScript項目保養實用指南_架構/框架_InfoQ精選文章
TML+CSS學完好久了，一直沒啥時間總結，現在總結了下學的過程：
之所以放在一起總結，是因為HTML和CSS沒有啥很多的編程邏輯，都是需要去記住并且熟練使用的，熟練使用是得去一個個敲過一遍。所謂的代碼量積累好像就是這么回事，只有多敲才能會。
小白用的嗶哩嗶哩上的教程視頻，因為個人學習方法的原因，都是跟著那教程去敲的，當然課后練習的話，都是自己先摸索敲了一遍在去看的講解，小白覺得這樣可以加深印象。
還有就是沒有熟練之前要天天的去練，哪怕一天半小時也好。因為一旦一天沒有練就會忘掉，還得回去找之前的筆記來看。（因為有事耽擱了兩三天沒去學，結果又重頭的看了一遍，血淋淋的學習效率教訓。不管怎樣，貴在堅持。）
當然，因為小白基礎是真的差，沒有什么教程是可以完完全全都講完的，使用小白看完了嗶哩嗶哩的教程又跑去了網易云課堂找了一份HTML+CSS的教程來看，為的是查漏補缺。
有一種播放叫做1.5倍播放。看的過程，別跟播放器里一倍的速度看，調成1.5倍或是2.0倍播放速度，因為那些東西，多數都是理解使用的。哪怕忘了，百度一下就可以直接搞定了。打基礎階段所以還是記住熟練使用才好。
HTML小白也就看了兩天吧，用了半天做了下練習；CSS對于零基礎的人來說建議12-15天，當然小白之前有過這些概念，所以用了五天多點的時間。JS才剛剛開始學，所以不知道時間怎么算才好。因為前端三大基石：HTML+CSS+JS，HTML+CSS學習所使用的時間占比才百分之五，剩下的百分之九十五都是JS的學習時間。
找課程時記住，找一兩個課程，一個全心去學，一個查漏補缺就好，別一會兒這個課程看一下，那個課程看一下的。這樣子反而會使自己心浮氣躁沒法靜下心來去學。打基礎的視頻教程，其實都一樣的，沒啥有特別好的特別壞的。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
