從2023年5月到2023年5月，已經維護整一年。對於維護這件小事，是怎麼都愛不起來。2023年12月到2023年3月，短短幾個月的開發經驗，不足以面對浩瀚的**世界，想要展翅高飛，除了多鍛鍊讓翅膀豐盈，別無他法。
日常維護，對於資料庫的增刪改查，平均每天面對來自各個方向的30~40條記錄修改。常用sql語句放著，日日ctrl c+ ctrl v 。這是個，有你沒啥用，沒你又不行的位置。對，充其量就是個人手，連人力都算不上，更別說算人才了。
總結維護一年的個人感悟。維護三步走：
一、熟悉業務熟悉系統。免不了先看各種檔案，看系統，把各種流程親自過一遍。熟悉業務流程、熟悉系統。熟悉到什麼程度，沒人 給你標準，大家都不知道60分在**，所以，還是得靠自己。關於熟悉系統這個問題，個人認為，系統既然已經做出來了，最熟悉它的是架構師其次是開發核心人員，當然，他們一般都沒空教你。開發核心人員，簡單指對系統有個整體了解，知道系統的整體框架，以及各個表結構以及功能點。一般開發人員，這個基本可以不用問，一般開發人員，是在核心建好框框之後，在自己的一畝三分地辛勤耕耘的孩子們，對整體框架沒有完整了解，但是解決小問題還是很靠譜。我是經常問過，到底什麼是熟悉系統啊，標準是什麼，然而並沒有人回答我，因為這個沒有唯一標準。舉個具體的例子，熟悉系統，就是熟悉每個功能點具體是做什麼的，哪些可以操作，哪些是不可以操作的，每個頁面都有什麼內容。這是第一步。當別人問你，系統是用來做什麼，系統有什麼主要功能的時候，起碼能回答得上來。
二、解決具體問題，熟練掌握sql，熟悉每個頁面字段所屬表以及表結構。維護中總是會遇到很多稀奇古怪的問題，首先得在自己手上有個預判斷，哪些是使用者操作錯誤出現的問題，哪些是資料錯誤的問題，哪些是屬於系統問題需要告知開發人員進行修改的，學會辨別。不要每次遇到些問題就跳跳跳找開發人員改，他們鐵定會煩死你，當然，能夠自己解決的就不要麻煩別人，前提是，不會的一定要問啊。不會要問，這個很重要，自作主張改改改，改完了才發現錯了，系統資料恢復不回來，這個就大頭了，萬一跟新聞那小哥一樣，把一公司刪沒了，就不是個簡單的問題了。也出現過乙個比較自信的小哥，自己改了東西不打招呼，害得系統癱瘓了，通完簍子最後還不是維護人員繼續給補的，一堆人怨聲載道，這樣也不好。這個就是方法問題了，首先得先問過，確定了就放心大膽去做吧。具體說說熟練掌握sql問題，首先，擺出e-r圖熟悉表結構，這個就需要具體知道，哪個表包含哪個字段，哪個字段對應哪個頁面的問題。反過來，在熟悉頁面的情況下，要知道每個頁面內容包含幾張表，頁面上的這些資料是存在哪個表哪個欄位的。如果有**更好找，f12可以查詢頁面**，但是查不到表結構。目前根據頁面還沒有能連到對應字段對應表的查詢方式，我也只能在積極想辦法中。維護系統出現的基本都是資料問題，對應頁面資料表與資料丟失，都能通過直接運算元據庫得到恢復，正常情況下。維護遇到一些的的確確是系統問題，就要聯絡開發人員修改**了，比如，不合規範的彈框、不合業務邏輯的操作方式、操作後沒反應這些問題，都需要**改。進一步，維護人員如果可以動**，會給大家帶來很多方便。
三、修改**。維護人員在維護過程中，已經知道問題大致會出現在什麼地方，哪些需要完善的，可以親自去修改。基於已經熟悉了sql以及系統資料的表結構基礎上，可以把勢力範圍延伸到**，熟悉**可能需要一點時間，但是熟悉了基本系統框架後，找起問題來會變得特別迅速。可能會出現改錯或者部署不上去的問題，沒關係，還是要勇敢邁出這一步，這樣才可以進步。維護人員向一般開發人員的邁進，第一步。
表示現在還在第二與第三步的過渡，過程是向上的，這樣很好。
HTTP那些小事
這是一篇資訊整理文章，可以當作工具來看 http全稱是超文字傳輸協議，構建於tcp之上，屬於應用層協議。請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊被稱為中間人攻擊 man in the middle attack，mitm https是在通訊介面部分用 tls transport layer...
const的那些小事
關於const 為什麼需要const?請看以下語句 for int index 0 index 512 index 在此語句中有兩個問題 1 512這個常量含義不明確，也並不清楚index與512比較有什麼作用 2 假如在程式中多次使用到512這個常量時，在後來的工作需要把512改為111的話修改的...
談談React那些小事
而對於react的開發者來說，如何利用react構建現代化的前端專案，產出高質量的前端 才是學習react的重點。所以本文就我自己平時利用react開發專案的經驗和個人見解，來談談在react專案中需要了解和容易忽略的 小事 俗話說 千里之堤毀於蟻穴 在react開發中我們不能忙於進度而忽視了細節。...