A. 程序員刪除流氓軟體
電腦在網上下載一些東西時經常被捆綁下載很多流氓軟體，導致電腦是不是跳出一些彈窗廣告，煩不勝煩。經過努力奮斗終於把流氓軟體都刪除了，下面介紹幾個刪除流氓軟體的經驗。
1、如果軟體不是安裝在C盤，可以使用bitloacker給D盤加密，這樣開機就不能自啟，就可以刪除了。不過bitlocker是windows專業版才有。
2、按win + R打開運行，輸入gpedit.msc打開它,
在這里插入圖片描述
如果你的windows是家庭版，會報錯gpedit.msc找不到,
這時需要自己寫腳本打開pgedit.msc功能，步驟如下：
先運行notepad，
在這里插入圖片描述
輸入如下代碼：
@echo off
pushd 「%~dp0」
dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~3*.mum >List.txt
dir /b C:\Windows\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~3*.mum >>List.txt
for /f %%i in (『findstr /i . List.txt 2^>nul』) do dism /online /norestart /add-package:「C:\Windows\servicing\Packages%%i」
pause
在這里插入圖片描述
另存為gpedit.cmd文件，
在這里插入圖片描述
以管理員身份運行，等待運行完成即可。
在這里插入圖片描述
然後就可以使用gpedit.msc打開軟體策略了。
在這里插入圖片描述 選擇其它規則，
在這里插入圖片描述
右鍵新增哈希規則（散列規則），
在這里插入圖片描述
點擊「瀏覽」選擇你要禁止自啟動的項，比如exe、dll等應用程序，點擊確定，然後重啟電腦，你的流氓軟體就不會開機自啟動，就可以刪除了。
3、如果有一些dll無法通過gpedit.msc禁止，比如LDSGameMaster文件夾下SpSvc.dll每次開機都被其它進程啟動，任務管理器根本找不到該進程，gpedit.msc也禁止不了。這時有個很簡單的辦法，直接修改dll的後綴，比如在dll末尾加apk，然後重啟電腦，這時因為dll被修改後綴，進程無法鏈接到它，這個dll就可以被刪除了。
4、有些軟體卸載後還有一些功能殘留，比如iPDF，這時可以先卸載iPDF，然後運行regedit打開注冊表，然後按ctrl + F搜索iPDF，把所有包含iPDF的項全部刪除即可。
5、有些文件夾是空的，刪除時彈出文件正在其它程序中打開，這是流氓軟體把可執行程序隱藏了，可以下載Unlock打開該文件夾並刪除它，也可以使用360進行刪除
B. 工作一到五年的Java程序員遇到瓶頸應該如何提升
工作了5年的Java程序員，該如何提升,做了3~5年Java開發，你已經積累了不少項目經驗，擴寬了技術廣度，也許已發力成為團隊管理者。到了這個階段，大家卻常有這種感受：感覺自己卡在瓶頸進步緩慢，技術水平很難像早期一樣實現大幅突破？
其實大家往往忽略了這一點——提升自己的架構認知（工作5年左右程序員必須重視架構認知的提升，這會很大程度上推動你今後的成長）。架構的本質在於面對業務場景給出優雅的解決方案，使得業務能夠快速迭代和持續交付，從而達到降本增效的目標。提升架構認知高度，就像達克效應所描述的一樣，要敢於從愚昧之巔跳到絕望之谷，通過爬升開悟之坡，從而達到架構認知的巔峰時刻。到達巔峰時刻也就掌握了架構背後設計的哲學，面對具體業務場景在架構層面你便能夠輕松應對，以無招勝有招。
提升架構認知，要緊抓3個關鍵點：業務洞察力、技術視野、原創力（執行力）。
1.業務洞察力是技術戰略層面的問題，在當下能夠做出合理的判斷，清楚公司做什麼事情收益最大；
2. 技術視野即技術選型能力，是技術戰術層面的問題，在清楚做什麼事情後，需要進一步解決怎麼做的問題，也就是能夠給出合理的技術選型方案：是完全基於開源的方案，還是基於開源二次開發的方案，還是完全自研的方案；
3. 原創力（執行力）是技術落地執行層面的問題，一旦技術設計方案確定後，需要能夠快速Rush完成。
這3點層層遞進，最重要的是先把技術戰略問題思考清楚，然後再進一步解決技術戰術問題，最後是快速落地執行的問題。
工作5年左右的程序員，在原創力（執行力）層面比較有競爭力，往往欠缺技術視野以及業務洞察力。後面2點更加重要，這2點解決的是架構設計哲學問題，是架構師能夠持續擁有競爭力和影響力的立身之道。
舉個場景的例子來詳細說明：一提到分布式鎖問題，大多數人想到的方案是基於Redis的Master-Slave模式來實現。這個實現方案行不行？分布式鎖本質是一個CP需求，基於Redis的實現是一個AP需求，乍一看基於Redis的實現是無法滿足的。脫離業務場景來談架構都是耍流氓。
從技術戰略的需求層面來看，如果分布式鎖在極端情況下獲取鎖的不一致，社交業務場景能夠接受，那麼基於Redis的實現是完全可行的。如果業務是交易場景，分布式鎖在極端情況下獲取鎖的不一致性無法接受，那麼基於Redis的實現方案是不可行的。在鎖強一致性的場景下，需要採取基於CP模型的etcd等方案來實現。