CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章  👉 上自學課程  👉 討論區交流
最新出爐作業包
⭐ 邁向資深之路：非同步 JS 訓練（二）—— 各種寫法的錯誤處理、收尾處理
⭐ 邁向資深之路：非同步 JS 訓練（一）—— 從 Callback Hell 到 Promise 介面
⭐ Github Desktop 新手入門教學 —— 用漂亮的 GUI 介面來學習 Git 基本觀念
⭐ 邁向資深之路：後端 JS 訓練（二）—— 玩玩看 Express，用純後端做做看部落格
⭐ 邁向資深之路：後端 JS 訓練（一）—— 玩玩看 Node，做做看老派 CLI 應用程式

🔍 搜尋結果：給新手

🔍 搜尋結果：給新手

給新手開發者的 Git 指南

🩺 醫生有聽診器。 🔧 機械師有扳手。 👨‍💻 我們開發人員，有 Git。 您是否注意到 Git 對於程式碼工作來說是如此不可或缺，以至於人們幾乎從未將其包含在他們的技術堆疊或簡歷中？假設你已經知道了，或至少足以應付，但你知道嗎？ Git 是一個版本控制系統（VCS）。無所不在的技術使我們能夠儲存、更改程式碼並與他人合作。 > 🚨 作為免責聲明，我想指出 Git 是一個很大的話題。 Git 書籍已經出版，部落格文章也可能被誤認為是學術論文。這不是我來這裡的目的。**我不是 Git 專家**。我的目標是寫一篇我希望在學習 Git 時擁有的 Git 基礎文章。 作為開發人員，我們的日常工作圍繞著閱讀、編寫和審查程式碼。 Git 可以說是我們使用的最重要的工具之一。身為開發人員，掌握 Git 提供的特性和功能是您可以對自己進行的最佳投資之一。 讓我們開始吧 ![git](https://media4.giphy.com/media/v1.Y2lkPTc5MGI3NjExMXZqODl2Zjk5cTUzYWo3Nnptam1qYWdqYm4xcmY5dXEyY2RzZWZrbCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/m0HehxSuVPd9CE3L4H/giphy.gif) > 如果您覺得我錯過了或應該更詳細地了解特定命令，請在下面的評論中告訴我。我將相應地更新這篇文章。 🙏 --- 當我們談論這個話題時 ---------- 如果您希望將 Git 技能運用到工作中並願意為 Glasskube 做出貢獻，我們於 2 月正式推出，我們的目標是成為 Kubernetes 套件管理的預設預設解決方案。有了您的支持，我們就能實現這一目標。表達您支持的最佳方式是在 GitHub 上為我們加註星標 ⭐ [![連小貓也喜歡送星星](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nzaxhc3f53sggz7v3bw4.jpeg)](https://github.com/glasskube/glasskube) --- 讓我們打好基礎 ------- Git 有沒有讓你感覺像 Peter Griffin 一樣？ 如果您沒有以正確的方式學習 Git，您可能會不斷地摸不著頭腦，陷入同樣的問題，或者後悔有一天在終端中出現另一個合併衝突。讓我們定義一些基本的 Git 概念來確保這種情況不會發生。 ![git-2](https://media4.giphy.com/media/v1.Y2lkPTc5MGI3NjExNjBqNHlnNjgwZHl4ZmdtMW8wbGJjYWJ5MmQyN2x4YXJpeXAxNWFsZCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/jcKiy2CqRIYM8W3E4p/giphy.gif) ### 分公司 在 Git 儲存庫中，您會發現一條開發主線，通常名為「main」或「master」（ [已棄用](https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-created-repositories-is-now-main/)），其中有幾個[分支](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)分支。這些分支代表同時的工作流程，使開發人員能夠在同一專案中同時處理多個功能或修復。 ![Git 分支](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t3p5q80hldckku20urm0.png) ### 提交 Git 提交作為更新程式碼的捆綁包，捕獲專案程式碼在特定時間點的快照。每次提交都會記錄自上次記錄以來所做的更改，共同建立專案開發旅程的全面歷史。 ![Git 提交](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dcjp286j11bqkx0k9w35.png) 當引用提交時，您通常會使用其唯一標識的加密[雜湊](https://www.mikestreety.co.uk/blog/the-git-commit-hash/)。 例子： ``` git show abc123def456789 ``` 這顯示了有關該哈希提交的詳細資訊。 ### 標籤 Git[標籤](https://git-scm.com/book/en/v2/Git-Basics-Tagging)充當 Git 歷史中的地標，通常標記專案開發中的重要里程碑，例如`releases` 、 `versions`或`standout commits` 。這些標籤對於標記特定時間點非常有價值，通常代表專案旅程中的起點或主要成就。 ![Git 標籤](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/06uilykiq1ky6dtnr3ez.png) ### 頭 目前簽出分支上的最新提交由`HEAD`指示，充當儲存庫中任何引用的指標。當您位於特定分支時， `HEAD`指向該分支上的最新提交。有時， `HEAD`可以直接指向特定的提交（ `detached HEAD`狀態），而不是指向分支的尖端。 ### 階段 了解 Git 階段對於導航 Git 工作流程至關重要。它們代表文件更改在提交到儲存庫之前發生的邏輯轉換。 讓我們深入研究一下 Git 階段的概念： ![Git 階段](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/96ndc8w183kh0tcb3uxb.png) #### 工作目錄👷 `working directory`是您編輯、修改和建立專案文件的位置。表示本機上檔案的目前狀態。 #### 暫存區🚉 `staging`區域就像一個保留區域或預提交區域，您可以在其中準備更改，然後再將更改提交到儲存庫。 > 這裡有用的指令： `git add` > `git rm`也可用於取消暫存更改 #### 本地儲存庫🗄️ 本機儲存庫是 Git 永久儲存已提交變更的位置。它允許您查看專案的歷史記錄，恢復到以前的狀態，並與同一程式碼庫上的其他人進行協作。 > 您可以使用以下指令提交暫存區域中準備好的變更： `git commit` #### 遠端儲存庫🛫 遠端儲存庫是一個集中位置，通常託管在伺服器（例如 GitHub、GitLab 或 Bitbucket）上，您可以在其中與其他人共用專案並進行協作。 > 您可以使用`git push`和`git pull`等命令將提交的變更從本機儲存庫推送/拉取到遠端儲存庫。 Git 入門 ------ 好吧，你必須從某個地方開始，在 Git 中那就是你的`workspace` 。您可以`fork`或`clone`現有儲存庫並擁有該工作區的副本，或者如果您在電腦上的新本機資料夾中全新開始，則必須使用`git init`將其轉換為 git 儲存庫。不容忽視的下一步是設定您的憑證。 ![Source: Shuai Li](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fqr8mylqjo91zurb7gmi.png) ### 憑證設定 當執行推送和拉取到遠端儲存庫時，您不想每次都輸入使用者名稱和密碼，只需執行以下命令即可避免這種情況： ``` git config --global credential.helper store ``` 第一次與遠端儲存庫互動時，Git 會提示您輸入使用者名稱和密碼。之後，您將不再收到提示 > 請務必注意，憑證以純文字格式儲存在`.git-credentials`檔案中。 若要檢查已配置的憑證，您可以使用下列命令： ``` git config --global credential.helper ``` ### 與分公司合作 在本地工作時，了解您目前所在的分支至關重要。這些命令很有幫助： ``` # Will show the changes in the local repository git branch # Or create a branch directly with git branch feature-branch-name ``` 若要在分支之間轉換，請使用： ``` git switch ``` 除了在它們之間進行轉換之外，您還可以使用： ``` git checkout # A shortcut to switch to a branch that is yet to be created with the -b flag git checkout -b feature-branch-name ``` 若要檢查儲存庫的狀態，請使用： ``` git status ``` 始終清楚了解當前分支的一個好方法是在終端機中查看它。許多終端插件可以幫助解決這個問題。這是[一個](https://gist.github.com/joseluisq/1e96c54fa4e1e5647940)。 ![終端視圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nycmbxgrtplax7q83g3n.png) ### 使用提交 在處理提交時，使用 git commit -m 記錄更改，使用 git amend 修改最近的提交，並盡力遵守[提交訊息約定](https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13)。 ``` # Make sure to add a message to each commit git commit -m "meaningful message" ``` 如果您對上次提交進行了更改，則不必完全建立另一個提交，您可以使用 --amend 標誌來使用分階段變更來修改最近的提交 ``` # make your changes git add . git commit --amend # This will open your default text editor to modify the commit message if needed. git push origin your_branch --force ``` > ⚠️ 使用`--force`時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。 > 根據經驗，最好經常提交，以避免遺失進度或意外重置未暫存的變更。之後可以透過壓縮多個提交或進行互動式變基來重寫歷史記錄。 使用`git log`顯示按時間順序排列的提交列表，從最近的提交開始並按時間倒推 操縱歷史 ---- 操縱歷史涉及一些強大的命令。 `Rebase`重寫提交歷史記錄， `Squashing`將多個提交合併為一個，而`Cherry-picking`選擇特定提交。 ### 變基和合併 將變基與合併進行比較是有意義的，因為它們的目標相同，但實現方式不同。關鍵的差異在於變基重寫了專案的歷史。對於重視清晰且易於理解的專案歷史的專案來說，這是理想的選擇。另一方面，合併透過產生新的合併提交來維護兩個分支歷史記錄。 在變基期間，功能分支的提交歷史記錄在移動到主分支的`HEAD`時會被重組 ![狐狸](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ytea832muxycodnkdlma.png) 這裡的工作流程非常簡單。 確保您位於要變基的分支上並從遠端儲存庫取得最新變更： ``` git checkout your_branch git fetch ``` 現在選擇您想要變基的分支並執行以下命令： ``` git rebase upstream_branch ``` 變基後，如果分支已推送到遠端儲存庫，您可能需要強制推送變更： ``` git push origin your_branch --force ``` > ⚠️ 使用`--force`時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。 ### 擠壓 Git 壓縮用於將多個提交壓縮為單一、有凝聚力的提交。 ![git 擠壓](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/owzri2ufj3meqhtjjpc0.png) 這個概念很容易理解，如果使用的統一程式碼的方法是變基，則特別有用，因為歷史記錄會被改變，所以注意對專案歷史記錄的影響很重要。有時我很難執行擠壓，特別是使用互動式變基，幸運的是我們有一些工具可以幫助我們。這是我首選的壓縮方法，其中涉及將 HEAD 指標向後移動 X 次提交，同時保留分階段的變更。 ``` # Change to the number after HEAD~ depending on the commits you want to squash git reset --soft HEAD~X git commit -m "Your squashed commit message" git push origin your_branch --force ``` > ⚠️ 使用`--force`時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。 ### 採櫻桃 櫻桃採摘對於選擇性地合併從一個分支到另一個分支的更改非常有用，特別是當合併整個分支不合需要或不可行時。然而，明智地使用櫻桃選擇很重要，因為如果應用不當，可能會導致重複提交和不同的歷史記錄 ![採櫻桃](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wxe90o4u26mikikee9f1.png) 要先執行此操作，您必須確定要選擇的提交的提交哈希，您可以使用`git log`來執行此操作。一旦確定了提交哈希，您就可以執行： ``` git checkout target_branch git cherry-pick <commit-hash> # Do this multiple times if multiple commits are wanted git push origin target_branch ``` 高級 Git 指令 --------- ### 簽署提交 對提交進行簽名是一種驗證 Git 中提交的真實性和完整性的方法。它允許您使用 GPG (GNU Privacy Guard) 金鑰對您的提交進行加密簽名，從而向 Git 保證您確實是該提交的作者。您可以透過建立 GPG 金鑰並將 Git 配置為在提交時使用該金鑰來實現此目的。 步驟如下： ``` # Generate a GPG key gpg --gen-key # Configure Git to Use Your GPG Key git config --global user.signingkey <your-gpg-key-id> # Add the public key to your GitHub account # Signing your commits with the -S flag git commit -S -m "Your commit message" # View signed commits git log --show-signature ``` ### 轉發日誌 我們還沒有探討的一個主題是 Git 引用，它們是指向儲存庫中各種物件的指針，主要是提交，還有標籤和分支。它們可作為 Git 歷史記錄中的命名點，允許使用者瀏覽儲存庫的時間軸並存取專案的特定快照。了解如何導航 git 引用非常有用，他們可以使用 git reflog 來做到這一點。 以下是一些好處： - 恢復遺失的提交或分支 - 除錯和故障排除 - 糾正錯誤 ### 互動式變基 互動式變基是一個強大的 Git 功能，可讓您以互動方式重寫提交歷史記錄。它使您能夠在將提交應用到分支之前對其進行修改、重新排序、組合或刪除。 為了使用它，您必須熟悉可能的操作，例如： - 選擇（“p”） - 改寫（“r”） - 編輯（“e”） - 壁球（“s”） - 刪除（“d”） ![互動式變基](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/98sngs9j2dl5awcmm8dt.png) 這是一個有用的[影片，](https://www.youtube.com/watch?v=qsTthZi23VE)用於學習如何在終端中執行互動式變基，我還在部落格文章的底部連結了一個有用的工具。 與 Git 協作 -------- ### 起源與上游 **來源**是複製本機 Git 儲存庫時與本機 Git 儲存庫關聯的預設遠端儲存庫。如果您分叉了一個儲存庫，那麼預設情況下該分叉將成為您的「原始」儲存庫。 另一方面，**上游**指的是您的儲存庫分叉的原始儲存庫。 為了讓您的分叉儲存庫與原始專案的最新更改保持同步，您可以從「上游」儲存庫中 git 取得更改，並將它們合併或變基到本機儲存庫中。 若要查看與本機 Git 儲存庫關聯的遠端儲存庫，請執行： ``` git remote -v ``` ### 衝突 不要驚慌，當嘗試合併或變基分支並檢測到衝突時，這只意味著存儲庫中同一文件或文件的不同版本之間存在衝突的更改，並且可以輕鬆解決（大多數情況下）。 ![合併衝突](https://media3.giphy.com/media/v1.Y2lkPTc5MGI3NjExbXRiM3o5cWd0OGZ3Z2NudGhlb2gyaXhheTRmcGx0bW5sN3UzNXJhYSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/cFkiFMDg3iFoI/giphy.gif) 它們通常在受影響的文件中指示，Git 在其中插入衝突標記`<<<<<<<` 、 `=======`和`>>>>>>>`以突出顯示衝突部分。 決定保留、修改或刪除哪些更改，確保產生的程式碼有意義並保留預期的功能。 手動解決衝突檔案中的衝突後，刪除衝突標記`<<<<<<<` 、 `=======`和`>>>>>>>`並根據需要調整程式碼。 對解決方案感到滿意後，請儲存衝突文件中的變更。 > 如果您在解決衝突時遇到問題，該[影片](https://www.youtube.com/watch?v=xNVM5UxlFSA)可以很好地解釋它。 流行的 Git 工作流程 ------------ ![git 工作流程](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x955re263jtueig35kyg.png) 存在各種 Git 工作流程，但需要注意的是，不存在通用的「最佳」Git 工作流程。相反，每種方法都有其自身的優點和缺點。讓我們來探索這些不同的工作流程，以了解它們的優點和缺點。 ![git 工作流程](https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExeTY0eTI3anV6YnJ3Y2Y3bzd6ZTE5dHJ6OG9hdDNsM3hwcW1ubHZiMCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/dSetNZo2AJfptAk9hp/giphy.gif) ### 功能分支工作流程🌱 每個新功能或錯誤修復都是在自己的分支中開發的，然後在完成後將其合併回主分支。 > - **優點**：隔離變更並減少衝突。 > - **弱點**：可能變得複雜並且需要勤奮的分行管理。 ### Gitflow 工作流程 🌊 Gitflow 定義了嚴格的分支模型，為不同類型的開發任務提供了預先定義的分支。 它包括長期分支，例如 main、develop、feature 分支、release 分支和 hotfix 分支。 > - **優點**：適合定期發布、長期維護的專案。 > - **缺點**：對於較小的團隊來說可能過於複雜 ### 分岔工作流程🍴 在此工作流程中，每個開發人員都會複製主儲存庫，但他們不會將變更直接推送到主儲存庫，而是將變更推送到自己的儲存庫分支。然後，開發人員建立拉取請求以提出對主儲存庫的更改，從而允許在合併之前進行程式碼審查和協作。 這是我們在開源 Glasskube 儲存庫上進行協作的工作流程。 > - **優點**：鼓勵外部貢獻者進行協作，而無需授予對主儲存庫的直接寫入存取權。 > - **弱點**：維持分支和主儲存庫之間的同步可能具有挑戰性。 ### 拉取請求工作流程 ⏩ 與分叉工作流程類似，但開發人員不是分叉，而是直接在主儲存庫中建立功能分支。 > - **優點**：促進團隊成員之間的程式碼審查、協作和知識共享。 > - **弱點**：對人類程式碼審查員的依賴可能會導致開發過程延遲。 ### 基於主幹的開發🪵 如果您所在的團隊專注於快速迭代和持續交付，您可能會使用基於主幹的開發，開發人員直接在主分支上工作，提交小而頻繁的變更。 > - **優勢**：促進快速迭代、持續集成，並專注於為生產提供小而頻繁的變更。 > - **缺點**：需要強大的自動化測試和部署管道來確保主分支的穩定性，可能不適合發佈時間表嚴格或功能開發複雜的專案。 ### 什麼叉子？ 強烈建議在開源專案上進行分叉，因為您可以完全控制自己的儲存庫副本。您可以進行變更、嘗試新功能或修復錯誤，而不會影響原始專案。 > 💡 我花了很長時間才弄清楚，雖然分叉存儲庫作為單獨的實體開始，但它們保留了與原始存儲庫的連接。此連接可讓您追蹤原始專案中的變更並將您的分支與其他人所做的更新同步。 這就是為什麼即使您推送到原始存儲庫也是如此。您的變更也會顯示在遙控器上。 Git 備忘錄 ------- ``` # Clone a Repository git clone <repository_url> # Stage Changes for Commit git add <file(s)> # Commit Changes git commit -m "Commit message" # Push Changes to the Remote Repository git push # Force Push Changes (use with caution) git push --force # Reset Working Directory to Last Commit git reset --hard # Create a New Branch git branch <branch_name> # Switch to a Different Branch git checkout <branch_name> # Merge Changes from Another Branch git merge <branch_name> # Rebase Changes onto Another Branch (use with caution) git rebase <base_branch> # View Status of Working Directory git status # View Commit History git log # Undo Last Commit (use with caution) git reset --soft HEAD^ # Discard Changes in Working Directory git restore <file(s)> # Retrieve Lost Commit References git reflog # Interactive Rebase to Rearrange Commits git rebase --interactive HEAD~3 ``` --- 獎金！一些 Git 工具和資源可以讓您的生活更輕鬆。 -------------------------- - 互動式變基[工具](https://github.com/MitMaro/git-interactive-rebase-tool)。 - [Cdiff](https://github.com/amigrave/cdiff)查看豐富多彩的增量差異。 - 互動式 Git 分支[遊樂場](https://learngitbranching.js.org/?locale=en_US) --- 如果您喜歡這類內容並希望看到更多內容，請考慮在 GitHub 上給我們一個 Star 來支持我們🙏 [![連小貓也喜歡送星星](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nzaxhc3f53sggz7v3bw4.jpeg)](https://github.com/glasskube/glasskube) --- 原文出處：https://dev.to/glasskube/the-guide-to-git-i-never-had-1450

0個讚   0留言 78瀏覽

給新手的建議：寫程式的 10 個注意事項

作為一名軟體工程師，您希望確保您的程式碼高效、可讀且可維護。為了幫助您實現這些目標，我列出了您在編碼時應該加入的 10 件最重要的事情。 這些有價值的技巧將提高您的編程技能並使您的程式碼更加健壯。 因此，讓我們深入探討每個軟體工程師都應該考慮的基本要素。 原文出處：https://dev.to/dhruvjoshi9/top-10-things-you-should-add-while-coding-valuable-tips-for-programmers-4m3n ### 1. 有意義的變數名 選擇描述性且有意義的變數名稱對於編寫乾淨且可維護的程式碼至關重要。不要使用“var1”或“temp”等通用名稱，而是選擇反映變數用途的名稱。 這種做法提高了程式碼的可讀性並減少了引入錯誤的機會。 ### 2. 簡潔的註解 註釋在程式碼文件中起著至關重要的作用。它們為複雜的程式碼部分提供了額外的上下文和解釋。通過加入註釋，您可以使您自己和將來可能參與該專案的其他開發人員更容易理解您的程式碼。 請記住保持您的評論簡潔、相關且最新。 ### 3. 一致的程式碼格式 程式碼格式的一致性可以增強可讀性，並使其他人更容易理解您的程式碼。遵循您所使用的編程語言的既定編碼約定和風格指南。 一致的縮進、間距和命名約定使您的程式碼看起來專業且可維護。 ### 4. 錯誤處理和異常管理 錯誤處理是編碼的一個關鍵方面。正確處理錯誤和異常可以提高程式碼的可靠性和健壯性。辨識潛在的錯誤場景並實施適當的錯誤處理機制。 使用 try-catch 塊或異常處理技術來優雅地處理異常並防止程序崩潰。 ### 5.優化的資料結構 高效的資料結構是性能良好的軟體應用程式的支柱。根據程序的具體要求選擇合適的資料結構。了解不同資料結構的優點和缺點將使您能夠優化內存使用並提高程式碼的整體效率。 ### 6.高效的算法設計 算法是解決問題的逐步過程。設計有效的算法對於實現最佳程序性能至關重要。考慮算法的時間和空間複雜性，並努力尋求最有效的解決方案。 分析程式碼中是否存在任何不必要的循環或冗餘操作，並重構它們以提高效率。 ### 7. 模塊化和可重用的程式碼 模塊化程式碼提高了程式碼的可重用性和可維護性。將程式碼分解為更小的、獨立的模塊或執行特定任務的函數。這種方法允許您在程序的不同部分重用程式碼，並在必要時更輕鬆地除錯和更新功能。 ### 8. 測試和除錯 徹底的測試和除錯是開發過程中不可或缺的一部分。建立全面的測試用例以確保您的程式碼在不同場景中的行為符合預期。使用除錯工具和技術來辨識和修復任何問題或意外行為。 定期測試和驗證您的程式碼，以便及早發現潛在的錯誤。 ### 9. 版本控制 版本控制系統（例如 Git）是軟體開發專案中管理程式碼更改和協作的重要工具。使用版本控制來跟踪修改，根據需要恢復到以前的版本，並與其他團隊成員有效協作。 熟悉常見的版本控制命令和工作流程，以簡化您的開發流程。 ### 10.持續學習 編程是一個快速發展的動態領域。秉持持續學習的心態，及時了解最新技術、編程語言和最佳實踐。探索在線資源，參加研討會或會議，並與編程社區互動，以擴展您的知識並提高您的編碼技能。 ## FAQ ### 問：為什麼有意義的變數名稱在編碼中很重要？ 答：有意義的變數名可以增強程式碼的可讀性，並且更容易理解變數的用途。它們提高了程式碼的可維護性並減少了引入錯誤的可能性。 ### 問：註釋對程式碼文件有何幫助？ 答：註釋為複雜的程式碼部分提供了額外的上下文和解釋。它們使開發人員更容易理解程式碼並充當文件的形式。 ### 問：為什麼我們應該遵循一致的程式碼格式？ 答：一致的程式碼格式可以提高程式碼的可讀性和可維護性。它使原始開發人員和將來可能參與該專案的其他開發人員更容易理解程式碼。 ### 問：編碼中錯誤處理的重要性是什麼？ 答：錯誤處理對於防止程序崩潰和提高程式碼的可靠性至關重要。正確的錯誤處理可以從錯誤中正常恢復，並增強軟體的整體穩健性。 ### 問：資料結構如何影響程序的性能？ 答：高效的資料結構可以優化內存使用，提高程序的整體性能。根據程序的具體要求選擇適當的資料結構對於實現最佳性能至關重要。 ### 問：為什麼模塊化程式碼在編程中很重要？ 答：模塊化程式碼提高了程式碼的可重用性和可維護性。將程式碼分解為更小的、獨立的模塊可以更輕鬆地管理和更新功能，從而生成更清晰、更易於維護的程式碼。 ## 最後 將這 10 件事納入您的編碼實踐將顯著提高您的編程技能，並幫助您建置更好的軟體應用程式。 通過關注有意義的變數名、清晰的註釋、一致的程式碼格式、錯誤處理、優化的資料結構、高效的算法設計、模塊化的程式碼、徹底的測試、版本控制和持續學習，你將成為一名更加熟練的軟體工程師。 請記住，編程是一個不斷改進的旅程，因此請接受這些有價值的技巧，並在編碼工作中追求卓越。

0個讚   0留言 454瀏覽

給新手工程師的建議：每天工作都在查 ChatGPT 會不會很糟？

給新手工程師的建議：每天工作都在查 ChatGPT 會不會很糟？ 看到滿多年輕工程師提問：工作時經常查 ChatGPT，感覺不太踏實，沒關係嗎？ 讓我簡單談論一下這件事 --- 首先，讓我們把時間倒回 2000 年代 google 剛出來的時候 當時一定也是這樣，年輕工程師遇到問題狂查 google 資深工程師則覺得 google 可有可無，真的有問題，桌上的工具書大概要翻到第幾頁他也都知道，翻一下不用 10 秒就有答案 時間快轉到今天，年輕工程師遇到問題狂問 ChatGPT 資深工程師則覺得 ChatGPT 可有可無，真的有問題，google 關鍵字怎麼組合、stackoverflow or reddit or 某某技術論壇，找一下不用 10 秒就有答案 --- 新科技的出現，讓一些「死背類型」的任務變得「毫無意義」 比方說現在沒人會去背歷史事件的年份了，因為要用時 google 一下就有 同理，現在的工程師，所用程式語言的某些語法、函式名稱、API 用法，沒背起來，根本沒關係 （不信的話，問問看用 Linux 的工程師，怎麼解壓縮檔案，看看有幾個人可以不查 google 打出指令） ``` tar -xzvf 壓縮檔名稱.tar.gz ``` 所以 AI 的出現，如果讓很多以往工程師視為 knowhow、design pattern、convention 的東西，降格為「死背類型」 那麼這些東西當然不用靠肌肉記憶去記住了，每次遇到就去問 AI 即可 --- 我認為工程師這行業的重點在於，你知道「某些問題在技術上可不可能被解決」、「解決方案的大方向是什麼」、「不同解決方案的成本跟考量分別是什麼」 如果你都知道大方向，但是細節語法常常忘記，那習慣性問 AI 當然沒問題 但如果每次查完，你都是把一大堆你自己根本不知道在幹嘛的程式碼複製貼上，那就很有問題 簡單講，這些新科技「可以減少打字的時間、減少查詢的時間、減少翻閱的時間」 但是「無法減少你學習的時間」 # 結論 所以，用 ChatGPT 沒問題，但是你要知道自己拿到的程式碼，到底實際上在做什麼 這樣用了之後，出問題才能除錯、必要時才能擴充、才能加功能 以上，簡單分享，大家有什麼問題，可以多多提問，我盡量回答

5個讚   0留言 461瀏覽

給新手參考：前端專案的檔案架構範例

在開發 Web 應用程式時建立可維護的檔案結構很重要，良好的架構有助於組織程式碼，並使其他開發人員了解您的 Web 應用程式結構。 原文出處：https://dev.to/noruwa/folder-structure-for-modern-web-applications-4d11 ### 設計檔案結構的一些技巧 - 了解您的 Web 專案的目的：為了弄清楚如何組織您的 Web 專案，您需要很好地了解專案需求 - 為您的文件夾和文件使用正確的命名慣例，它們應該描述您的 Web 應用程式的用途 ### 結構及說明 **Assets** assets 包含將在您的 Web 應用程式中使用的所有圖像、圖示、css 文件、字體文件等。自定義圖像、圖示、付費字體都放在這個文件夾中。 ![資產](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bosdpni04f4rhoscokrl.PNG) **Contexts** 當使用 React Js 作為您的前端 ui 庫時，context 文件夾存放所有跨元件和多個頁面使用的 react context 檔案。 ![上下文](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/34ah8q7qbthfe5pbkcbf.PNG) **Components** components 文件夾包含應用程式的 UI。包含我們所有的 UI 元件，如導航列、頁腳、按鈕、視窗、卡片等等。 ![元件](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0fsm5cd609kxc1ydcv4b.PNG) ** Composables** 在 Vue 應用程式中，“Composables”是一種利用 Vue 的組合 API 來封裝和重用有狀態邏輯的功能。 **Data** 用來放會在不同部分和頁面中作為 JSON 文件使用的文本資料。這樣做將使資訊更新更容易。 ![資料 JSON](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/74ey2c253fveerw4ox3y.PNG) ![資料](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mybd8n92pxns26feb6qt.PNG) **Features** 包含每個頁面（身份驗證、主題、視窗）會用到的功能。例如，每個頁面可能都會用到視窗功能。 ![功能](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gljjlh0jgarivzabdamm.PNG) **Hooks** 讓 React 元件有狀態和生命週期特性的函數。我們還可以建立名稱以“use”開頭的自定義掛鉤，並可用於呼叫其他掛鉤。 ![掛鉤](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a84dq8pahtjgff63ru7e.PNG) **Layouts** 在定義網頁的總體外觀時，Layouts 文件夾會派上用場。它用於放置佈局的元件，例如側邊欄、導航欄和頁腳。如果您的 Web 應用程式有很多佈局，這個文件夾是保存它們的好地方。 ![佈局](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6h73gy0uruci8qlq5sjl.PNG) **Modules** Modules 文件夾處理應用程式中的特定任務。 ![模塊](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/boeni6zfudcg14201s87.PNG) **Pages** pages 目錄包含您的 Web 應用程式畫面。 Next Js 和 Nuxt Js 等前端框架中的頁面目錄，會讀取目錄中的所有文件並自動為您建立路由設定。 ** Public** 直接在伺服器根目錄提供服務，包含不會更改的公共文件，例如 favicon.ico。 **Routes** routes 文件夾只是你的 web 應用程式中的一個地方，用於存放到不同頁面的路由路徑。 ** Utility/Utils** 該文件夾用於存放所有實用函數，例如 auth、theme、handleApiError 等。 ** Views** Views 文件夾類似於 pages 文件夾，用來放頁面的重複部分。 ### 結論 良好的檔案結構可以讓您和其他開發人員更快地找到文件並更輕鬆地管理它們。希望這篇文章對您有幫助！

0個讚   1留言 2,133瀏覽

關於自學教材的未來發展

經營這網站主要是想做新手友善論壇 本想隨手寫2-3份入門教材，簡單給新手一些方向 結果居然寫了8份，而且我發現後面還有滿多要教的東西 所以我打算把自學教材改成「付費教材」，我乾脆長期研發新教材好了 - JavaScript 系列前兩課免費 - 每個系列售價$199 - 現有會員不受影響（今天之前註冊的會員，所有教材維持免費） 以上規劃跟大家分享，希望中長期來說，可以變成最優質、最便宜的前端系列教材 然後就可以跟討論區功能相輔相成，讓新手有個持續進修的好地方

5個讚   1留言 399瀏覽

德國資深架構師：給新手工程師的幾點建議

一名資深的德國軟體架構師 Jeroen De Dauw，寫了一篇很好的文章，給新手工程師一些寫程式的建議。 - 原文出處：https://dev.to/jeroendedauw/advice-for-junior-developers-30am --- ## 給新手工程師的一般建議 ### 1. 程式碼不是重點 作為開發者，我們喜歡寫程式。大多數工程師希望收到的任務明確，可以不用管技術之外的事情，專心解決有趣的技術挑戰。 請花足夠的心力去確認，您正在解決正確的問題。引用管理學大師 Peter Drucker 的話：高效率地去做一件根本沒必要的事情，結果依然是完全沒意義。儘早、經常去搜集回饋，透過「持續交付」來向真正的用戶互動，成為敏捷（Agile）的工程師。 軟體開發成本高昂，現實世界專案的絕大部份工作都是在維護而已。再加上目標應該是對用戶、對生意有幫助，所以結論就是：寫程式最好的方法，經常是完全不寫。引用比爾蓋茲的話：用程式碼有幾行來衡量工程進度，就像用重量來衡量飛機的製造進度。 另請參閱：YAGNI 原則、KISS 原則、The Last Responsible Moment 文章。 ### 2. 軟體設計很重要 在我開發生涯的前五年，我以為軟體設計是架構師或其他特殊職位的人在做的事。我以為開發者專注在完成任務即可，以為軟體設計、最佳實踐、寫測試這些，都不關我的事。我的程式能跑，我的生產力很高，我以為這樣就對了。 直到我閱讀了 Robert C. Martin 的 Clean Code，這書刺激了我對軟體設計的關注，並包含許多範例與啟發。其中最啟發我的是：走得快的唯一方法，就是走得好。也就是說，如果你把事情搞得一團糟，結果只會讓你速度更慢。 學習寫出設計良好的乾淨程式碼，需要時間和精力。而且剛開始的時候，會寫比較慢，並且會犯錯誤。 ### 3. 使用最佳實踐 寫測試通常會有幫助。雖有例外，但大多數時候，寫自動化測試會大有幫助。寫測試就是一種最佳實踐。 如果你不太會寫測試，請遵循最佳實踐並為所有內容寫測試。**開始時，盲目遵循最佳實踐比遵循自己弱弱的判斷要好**。一段時間之後，您將知道怎麼寫測試比較有效，並能夠區分您搞砸了和不值得編寫測試的情況。因為 bug 變少了、重構起來更輕鬆了，您將開始理解測試帶來的深入的價值。**到有了自己的判斷力後，您將能夠超越最佳實踐**。 此建議適用於您在學習任何最佳實踐的新手時期。自動化測試只是一個例子。 有個陷阱要注意，明智的最佳實踐，與荒謬、適得其反的做法之間，只有一線之隔。因為大多數程式碼都很亂，而且大多數開發者（包括資深人員）不了解軟體設計的基礎知識，因此事情就更複雜了。有一個好的指導者很重要。除此之外，根據我自己的經驗，要小心只存在您的語言、框架社群的最佳實踐。尋找那些已經存在了幾十年的長青建議比較好。 --- ## 給新手工程師的技術建議 ### 4. 寫測試 寫自動化測試。也許在寫程式之前先寫測試，例如運用測試驅動開發（TDD）。這讓您可以輕鬆反覆驗證幾段程式是否正確，而不用一直手動跑測試、除錯。 > 你覺得先寫測試很煩嗎？但之後再忙著抓 bug 有比較好？ 更重要的是，測試為您重構時提供了額外保障。你需要持續重構來保持程式乾淨。沒有可靠的測試保障，程式碼就可能越變越亂。 如果您的程式碼設計不佳，例如使用繼承進行重用，或使用靜態函數，則編寫測試會很困難。另一方面，如果您有遵循 SOLID 原則、沒有全局依賴項，那麼寫出好的測試並不困難。 設計好測試也很重要，因為糟糕的測試只會拖慢開發速度。避免將測試綁定到被測程式碼的實作細節或系統結構。 ### 5. 不要用繼承來做到程式碼重用 這是讓人以為是最佳實踐的其中一個反例。我的建議是：剛開始時，根本就不要用繼承來做到程式碼重用。這通常都幫助有限，而且帶來一大堆麻煩。請多用組合、少用繼承（關鍵字：composition over inheritance）。 ### 6. 寫出 OOP 程式碼 學習 SOLID 原則，避免寫出 STUPID 原則的程式碼 ( https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ )。理解這些原則和反模式非常有價值。 創造一些真正的物件。只有靜態方法的類別，根本不算是物件導向。盡量避免完全使用靜態寫法。 ### 7. 寫出函數式程式碼 不要把函數式程式設計，跟指令式程式設計搞混了。 重點不是完全切換到函數式語言。而是學習使用函數式風格的優點。例如減少狀態、讓函數專心一件事。另請參閱：https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell ### 8. 程式碼稍微重複沒關係 將一大塊程式碼到處複製貼上當然很不好。有尊嚴的開發者很快就發現這一點，並開始遵循某種形式的：不重複自己原則 Don't Repeat Yourself （DRY）。不幸的是，對 DRY 的追求往往會導致過度工程和額外的複雜性。所以會有一條新原則：寫兩次原則 Write Everything Twice（WET）。也就是僅在第三次出現重複時，才動手改善重複段落。 ### 9. 型別、命名、註解 試著寫一些能夠表達自我的程式碼，避免寫註解。 > 每次寫註解時，都應該要皺一下眉頭，感受到自己的表達能力有點失敗。 —— Robert C. Martin 註解很危險，因為有可能說謊。程式碼可以不更新註解就修改，那一開始的註解就變錯誤了。這種情況下，註解不但沒幫助，還會誤導到別人。 要寫出能夠表達自我的程式碼： - **一個函數只做一件事** 因為只做一件事，就能給一個清楚的命名。 - **減少狀態** - **使用型別** 定義清楚的型別，加上跑測試，能讓系統更穩定。 - **減少混合型別** 避免可以同時是整數、布林值或字串的參數或回傳值。如果讓每個函數專心一件事，這自然會做到。 - **寫測試** 良好的全面測試，也同時會是程式碼的使用說明範例。 Robert C. Martin 的書 Clean Code 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上，希望對大家有幫助！

1個讚   0留言 13,256瀏覽
歡迎發文
💡 記錄日常工作的實踐、心得
💡 發表對生活和職場的感悟
💡 針對感興趣的事件發表隨筆或者雜談
💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣
💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）
熱門文章
🔥 「自學網頁の嬰兒教材：HTML與CSS作業分享」
🔥 想請教一下前端新手工作內容
🔥 關於接案這回事
🔥 [小技巧分享] vue.js 動態替換 iframe src，如何解決 browser history 被修改問題
🔥 Promise vs async/await 有趣的辯論
  近期留言
熱門搜尋： local 網頁 % github 語言 使用 題 開發 學習 JAVA user 遊戲 工程師 1 c 前 架構 2 React GIT Ai 4 工作 網站 作為 技術 C 套件 前端 . go 專案 id console 分享 分離 Java 第一 20 git 10 JS api class AI html 50 資料庫 jav 測試 with 系列 AWS ＣＳＳ app 主題 Line 結構 java 研究 Node 作業 ` CSS javascript 後端 搜尋 練習 CD Html js REACT 非同步 作業分享 react ci cn ui Git Python 自學 nodejs 日期 rest this error 履歷 新創 JavaScript module JavaScript 系列 .NET " solid oop HTML Facebook for node.js tla
🛡️ 隱私及網站安全：本站註冊過程「不須提供任何個資」，只要 E-Mail 與帳密即可註冊，請安心註冊！線上付款過程使用「綠界科技 ECPay 」第三方專業金流廠商，全程在「綠界科技 ECPay 」網站進行付款程序，本站「不會紀錄任何信用卡資訊」，請放心付款、解鎖課程！您隨時可以透過 FB 粉專或者 Email 聯絡站長，請求刪除網站上的個人資料。