首先說軟件開發專業，從整體上來講的話屬于軟工，主要是根據需求來設計程序和應用，來滿足用戶需求。主要專業中的科目可能會比較多一些，一般在大學第一年下半年或者第二年開始學習專業知識，會涉及程序語言學習、數據庫、數據機構以及應用開發方面，一般會用到的就是搭建基礎開發環境比如：Visual Studio、PyCharm、Eclipse、Sublime Text、Android Studio等集成開發環境軟件，再有就是跑跑虛擬機之類的，虛擬機稍微對電腦配置有一定的要求，不過一般做開發或者學習Linux系統之類的入門級的筆記本電腦基本上是夠用的。
總體上說下來就是本身軟工相關的學習基本上對于筆記本的要求沒有那么高，所以選擇的時候可以略微考慮自己的預算，一般大學四年夠用就OK了，以后工作基本上都要換。考慮到上學期間肯定會有一定的娛樂功能，所以可以考慮配置稍微高一些，能夠玩玩游戲相關的都可以。如果考慮到電腦比較扛折騰的話，可以考慮搞個臺式機，對于玩開發和玩系統的話可以使勁倒騰。
聯想小新Pro13 2020新品13.3英寸2.5K分辨率全面屏
聯想（Lenovo）筆記本小新air14銳龍版2020新款
四千多可以拿下，可以考慮選購主流配置就OK了。
華為(HUAWEI)MateBook 13 2020款全面屏輕薄性能筆記本
聯想(Lenovo)小新15 2020性能版輕薄本
個人建議還是可以考慮五千以內就差不多了，具體可以根據自己的實際需要來進行選購，如果預算不足，可以考慮參考2020年筆記本選購指南中三四千價格區間的吧筆記本。
合程序員的筆記本電腦首先應該滿足小巧輕便這個需求，然后才是性能因素，一個標準的程序員必定能夠隨時隨地改BUG，所以可以優先考慮蘋果MacBook Pro，由于其 MacOS 就是Linux內核，做開發無疑是最佳的選擇。當然還有非常多的Windows筆記本，性價比更高，可以裝烏班圖、CentOS等各種Linux系統也基本不是問題，其性能更高，選擇更多。
01 ThinkPad X1 Carbon 2021款
參考價格：10499元
機型配置：11代酷睿i5-1135G7 16G 512G /4G版/16:10微邊框
ThinkPadX1Carbon 2021款作為主打高端，服務于高端商務人士的產品，其硬件配置也很強悍。我手里這款搭載了酷睿i5-1135G7處理器，并通過了英特爾Evo平臺認證。
Evo認證不只是對處理器及顯卡的性能認證，更是對整機硬件環境的一種綜合能力認證：必須搭載酷睿11處理器，并內置英特爾銳炬Xe核顯，并搭載Wi-Fi6無線網卡，藍牙5.0以及Thunderbolt4接口，并且搭載不小于256GB容量的PCIe/NVMeSSD和不小于8GB的雙通道內存。此外揚聲器、麥克風、像頭等功能性設備也有嚴格的評定標準。所以看到Evo認證基本就可以認定這是一款整機表現更穩定、綜合性能更高的產品。
02 聯想YOGA 14s
參考價格：6299元
機型配置：8核 R7-5800H 16G 512G 2.8K 90Hz高刷屏
YOGA14s是聯想的高端輕薄本，所以屏幕配備的是16：10長寬比、2880×1800分辨率的高色域屏，還支持90Hz刷新率，單獨拿出來每一個規格參數都可以當賣點。標配16GB內存，是LPDDR4X-4266規格，不可升級，硬盤則是512GB SSD，筆記本的最大賣點就是AMD平臺配上了MX450獨顯，是25W的大杯型號，整體上沒有明顯的短板。
03 惠普戰66 四代
參考價格：7099元
機型配置：i7-1165G7 16G 1TB MX450 2G獨顯 高色域 一年上門+意）
惠普戰66四代的好評主要集中在這幾方面：輕薄、顏值、性能。多數用戶表示“始于顏值，忠于性能”，這幾點正好是當下選購筆記本最為重要的考量標準，而惠普戰66四代在各方面均得到了相當高的認可。
此外，惠普戰66四代在日常商務使用方面，也廣受用戶好評。如下面這位用戶就表示惠普戰66四代的軍工品質，能抗能打。據官方信息顯示，惠普戰66四代還通過了業界嚴苛的19項美國MIL-STD-810H軍標測試，簡單來說，就是無論何時何地，不管使用環境多么嚴峻，都能隨時進行辦公。
04 雷蛇靈刃15 標準版
參考價格：8299元
機型配置：10代I7-10750H 官配16G/512G/RTX2060/144HZ
雷蛇靈刃15是專為 PC 游戲玩家提供的游戲本，通過專注于游戲硬件和外圍設備的公司生產的。但許多程序員喜歡這個設備，因為它外觀時尚，功能強大，而且相當專業。也就是說，與其他游戲筆記本電腦相比，沒有多少視覺金光閃閃，而且它也很薄。不僅能夠滿足編程工作，也能夠游刃有余的玩游戲，何樂不為呢？
(7756534)
早，每個人都需要在 Linux 系統上配置軟件。而且，盡管有很多方法可以做到這一點，但值得慶幸的是，您可以遵循一個通用的模式來獲得您想要的結果。在 Linux 上，這尤其常見；因為 Linux 中的許多標準工具遵循“小而精的工具”的哲學，趨勢是支持廣泛的配置，提供大量小型、強大的程序。
在本章中，您將了解設計良好的程序傾向于使用的配置層次結構。無論您是需要查看手冊頁以找到一個單一命令的命令行參數，還是想要設置一個環境變量，使其適用于您在 shell 中運行的所有命令，您都將看到如何做到這一點。
從這里開始，我們將向您展示幾乎所有 Unix 軟件使用的通用配置層次結構，以便當程序的行為不符合您基于所給配置的預期時，您總是知道在哪里進行檢查。
最后，您將看到這些配置如何轉化為通過 systemd 管理的程序，這是 Linux 上最受歡迎的服務管理工具。
總結來說，本章將涵蓋以下主題：
配置層次結構 在 Linux 上運行程序時，您將做的第一件事之一就是根據您的特定需求調整它們。實際上，您已經這樣做了：通過向 ls、grep 等命令傳遞參數，您已經改變了這些程序的行為。
您可能對如何工作有一個直觀的感覺，因為您一生都在使用軟件。例如，您可能認為傳遞命令行參數會覆蓋程序的默認設置：ls -l 給出的輸出與 ls 的默認輸出不同。
現在，讓我們更嚴格地了解一下這種直覺，并看看我們是否可以為 Unix 環境中配置通常如何工作制定一些啟發式規則。大多數標準的 Unix 命令行程序遵循特定的配置層次結構，其中先前的值會被后續值覆蓋。如果您曾經編寫過接受用戶配置的軟件，您可能以前已經創建過這樣優先級層次結構：
每個連續的級別都更接近于特定時刻運行軟件的用戶，因此每個連續的級別優先于前一個級別。
例如，如果您的軟件檢測到配置文件和程序啟動時傳遞給程序的 CLI 參數之間存在沖突值，它應該優先選擇命令行參數中的值。換句話說，靠近程序調用的值“遮蔽”（在遮蔽或替換的意義上）遠離執行的值。命令行參數值替換配置文件值，因為配置文件比程序啟動時傳遞給程序的參數更遠。這應該符合直覺：如果軟件忽略您的命令行標志，而偏愛程序默認值，您就無法依賴軟件。ls -l 不應該給出與 ls 相同的輸出。
大多數 Linux 軟件在有多種配置方式時遵循此層次結構。請記住，并非所有軟件都使用我們將在這里展示的所有配置路徑，也并非所有軟件都完全遵守這種配置順序。
讓我們再次看看這個層次結構，但這次將其與 nginx Web 服務器程序的具體實際例子聯系起來。您可能在職業生涯的某個時候會使用 nginx，因為它是世界上最流行的 Web 服務器之一，用于前端各種動態 Web 應用程序。讓我們看看我們剛剛涵蓋的優先級層次結構的每個部分如何映射到實際的 nginx 配置：
現在您已經看到了這個配置層次結構與您在 Linux 上運行的所有程序以及您可能為其編寫的所有程序的理論和實踐方面，讓我們逐步通過配置層次結構，仔細查看每個級別。我們將從最直接和強大的配置形式開始，它覆蓋了所有其他內容：在調用程序的時刻傳遞命令行參數。
命令行參數 您已經熟悉配置程序的最常見方式：使用命令行參數。這些在作為 shell 命令調用時配置程序。
要查找程序的有效命令行參數，請從命令的手冊（manual）頁開始。除了最基礎的系統外，Unix 軟件都附帶了手冊頁，記錄了大多數程序、解釋可用的標志，并——通常在末尾——列出了其他類型的配置方法，如配置文件。
讓我們看看 find 命令的手冊頁內容的開頭：
man find
FIND(1) General Commands Manual FIND(1)
NAME
find – walk a file hierarchy
SYNOPSIS
find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]
find [-H | -L | -P] [-EXdsx] -f path [path ...] [expression]
DESCRIPTION
The find utility recursively descends the directory tree for each path listed, evaluating an expression (composed of the "primaries" and "operands" listed
below) in terms of each file in the tree.
The options are as follows:
-E Interpret regular expressions followed by -regex and -iregex primaries as extended (modern) regular expressions rather than basic regular expressions
(BRE's). The re_format(7) manual page fully describes both formats.
-H Cause the file information and file type (see stat(2)) returned for each symbolic link specified on the command line to be those of the file
referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself. File
information of all symbolic links not on the command line is that of the link itself.你可以看到，這個手冊頁面主要記錄了運行find命令時可用的各種命令行參數。自第一章以來，你已經使用了很多命令行參數，所以這些應該都很熟悉。
讓我們來看下一個，稍微遠一點的配置類型：環境變量。
環境變量 盡管命令行參數很強大，但它只適用于它所參與的單個程序調用。當你輸入ls -l時，只有那個ls命令會有長格式輸出。但如果你想讓一個配置值在多次調用命令時持續存在呢？這在寫腳本時非常有用，例如，你正在編寫一個腳本，在幾個不同的點安裝包，你想要一次性設置一個配置選項，而不是每次運行包安裝命令時都要一遍又一遍地添加它作為命令行參數。這就是環境變量的用武之地。
作為一個開發人員，無論你編寫什么類型的軟件，你很可能都知道環境變量：與任何其他編程語言中的變量類似的shell值。這些與命令行參數不同，因為它們在更高的層次上操作。環境變量給你更多的杠桿作用：一旦你在shell中設置了配置變量，它就會應用于在該shell會話中啟動的所有程序。設置一次，每次運行查找環境變量的程序時，它都會尊重它，直到變量改變或你結束shell會話。
注意
我們將在第12章，“使用Shell腳本自動化任務”中更深入地探討環境變量，但本節涵蓋了基礎知識。
大多數標準的Unix環境使用環境變量作為指定對許多不同程序都相關的公共配置的一種方式，而不僅僅是一個程序。例如，環境變量跟蹤用戶家目錄的位置（$HOME）、當前工作目錄是什么（$PWD）、默認應使用哪個shell（$SHELL）、在哪里查找與通過CLI接收的命令相對應的可執行文件（$PATH）等。
現在就隨意檢查它們；你可以通過使用echo命令打印出特定環境變量的值來查看它：
$ echo $SHELL
/bin/zsh或者你可以使用env命令查看當前設置的所有環境變量：
$ env
...
# 你的每個環境變量都有多行輸出 ...要在當前shell中設置一個環境變量，只需使用=進行賦值（確保等號周圍沒有空格）：
MYVAR=fruitloops你已經為當前shell設置了它：
$ echo $MYVAR
fruitloops要使這個變量對任何你啟動的子shell持久化（例如，當你運行一個腳本時），請使用export內置命令：
export MYVAR=fruitloops你將在第12章，“使用Shell腳本自動化任務”中了解更多，但上述命令是你將需要傳遞給大多數你交互的程序的環境變量配置的范圍。
回到find的例子：如果你在上一節中我們查看的find手冊頁面上滾動得足夠遠，你會看到一個標題為“環境”的部分：
環境
LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES 和 LC_TIME 環境變量影響 find 實用程序的執行，如 environ(7) 所述。這是不同層次的配置——它們不是在運行時作為命令參數傳遞，而是可以從shell環境變量中讀取的配置指令。
為什么程序應該將環境變量與參數區別對待？讓我們仔細思考一下：命令行參數-H非常具體，因為它是在命令調用級別定義的。因此，它只適用于在那個瞬間運行的命令。
另一方面，環境變量不那么具體。它們在shell級別定義，因此可用于從該shell運行的所有命令。
讓我們繼續向上走配置層次結構：如果值沒有在運行時作為命令行參數設置，或者作為程序啟動的shell會話中的環境變量設置，那么配置來自哪里？
配置文件 程序查找配置的下一個位置是其配置文件。程序查找配置的位置可能會有很大差異，但有一些標準的地方可以查找。
系統級配置在/etc/ 首先，/etc/目錄是一個很好的開始。在第5章，“介紹文件”中，你已經見過這個目錄。/etc/programname——其中programname是你想配置的程序的名稱——是軟件保留系統范圍配置的常見選擇。對于許多程序來說，這就足夠了。例如，nginx web服務器是一個系統級程序：不同的用戶通常不會在單個機器上運行自己的web服務器實例，因此只需要系統范圍的配置。
也就是說，對于大型或復雜的程序，配置仍然可以拆分在/etc/programname目錄內。Nginx是一個很好的例子；它的主配置文件位于/etc/nginx.conf，附加的配置文件來自/etc/nginx/conf.d/目錄中的附加文件。
用戶級配置在~/.config 對于那些有重要每用戶配置的程序——想想文本編輯器、開發工具、游戲等——用戶的主目錄內的~/.config目錄被使用。回想一下第1章，“命令行如何工作”，~是“當前用戶的主目錄”的簡寫，并且目錄名以句點字符（"."）開頭的目錄在沒有傳遞-a標志的情況下不會出現在ls輸出中。~/.config目錄是XDG基礎目錄標準的一部分，你可以在這里查看概述：https://wiki.archlinux.org/title/XDG_Base_Directory。
作為一個例子，我的neovim配置與其他開發人員的配置有顯著的不同，但是一個單一的neovim二進制文件在系統上可以同時支持數百名開發人員工作，因為每個開發人員調用neovim時使用的是他們用戶特定的配置文件，這些文件保存在~/.config/nvim/中。這很好！
你可以想象，如果只有/etc/中一個單一的系統范圍的地方來配置這個程序，那將會引起怎樣的混亂——每個開發人員在運行neovim編輯器之前都必須設置無數的環境變量，或者使用無數的命令行標志調用編輯器命令。
現在，你已經走過了Unix程序的經典配置來源，讓我們看看一個Linux特有的復雜情況，你應該了解一下：通過環境文件和CLI參數管理通過systemd控制的程序的配置。
systemd單元 在大多數Linux發行版中——除了Docker容器——systemd是主導。我們已經在本書中介紹了systemd的基礎知識（見第3章，“使用systemd管理服務”），在本節中，我們將快速看看systemd如何為程序管理配置。
首先，快速回顧一下，以防第3章看起來非常遙遠：在systemd管理的Linux環境中，服務被打包成systemd單元文件，這些文件包裝并控制實際的可執行二進制文件、它的參數、用于啟動、重啟和停止單元的命令等等。
我們已經介紹過許多systemd單元類型，但我們在這里對服務單元類型感興趣。
我們已經介紹過單元文件可以存在于幾個不同的目錄中，這取決于它們的目的，但你自己的自定義systemd單元通常位于/etc/systemd/system。
為了理解一個systemd單元如何讓你影響我們在本章中介紹的配置層次結構，讓我們通過為我們想象中的程序yourprogram編寫自己的systemd單元來創建一個systemd管理的服務。
創建自己的服務 作為一個開發者，您可能需要將您正在編寫的程序封裝成一個服務，這樣可以比手動（交互式）調用程序更容易管理。這本身就非常有用，但在本章中，我們將深入探討systemd單元如何為您提供額外的控制，以便您控制程序的配置方式和位置。讓我們通過創建一個systemd單元文件來包裝一個二進制文件，從而創建一個服務。
首先，確保您已經將一個可執行文件復制到默認的$PATH中的某個位置：/usr/local/bin/yourprogram。如果您想充分利用這一點，請使用像上一章“管理已安裝的軟件”中創建的htop二進制文件這樣的手動編譯程序，并將想象中的yourprogram替換為htop。
現在，在/etc/systemd/system/yourprogram.service創建以下systemd單元文件：
[Unit]
Description=Your program description.
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/yourprogram -clioption=1 –clioption2
EnvironmentFile=-/etc/yourprogram/prod_defaults
Restart=on-failure
[Install]
WantedBy=multi-user.target您能找到這個單元文件中的兩條與配置相關的行嗎？
您可以看到，ExecStart行指定了當有人啟動這個systemd服務時程序是如何被調用的。我們使用systemd單元文件來向程序傳遞命令行參數，以確保無論何時有人啟動服務，程序都會以我們想要的確切選項運行。每當有人運行systemctl start yourprogram時，我們都確保yourprogram將使用-clioption=1和-clioption2被調用。
其次，EnvironmentFile行指定了systemd要檢查的文件路徑，它期望在這個路徑中設置與此程序相關的環境變量。這個文件將由systemd使用的shell解析；它應該包含像這樣的shell變量賦值：
# yourprogram environment variables
ENV=production
DB_HOST=localhost
DB_PORT=5432讓systemd重新讀取其配置文件，以確保它看到了您定義的新服務單元：
$ sudo systemd daemon-reload現在，您可以像管理任何其他systemd服務一樣管理它：
systemctl start yourprogram
systemctl status yourprogram
systemctl stop yourprogram
systemctl enable yourprogram
systemctl disable yourprogram您知道每次啟動此服務時，將使用位于/etc/yourprogram/prod_defaults的環境文件來源環境變量，并且ExecStart行將傳遞您指定的CLI選項。
我們在這里向您展示了一個非常簡單的服務，只是為了讓您了解如何使用systemd來控制程序配置，但這里還可以傳遞許多其他配置指令。如果您手頭有更復雜的服務，請花些時間閱讀systemd單元文檔（https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#%5BUnit%5D%20Section%20Options)。
快速說明：Docker中的配置 在本章前面，我們提到Docker在配置方面通常是特例。因為Docker容器是一個更小的環境，它們沒有許多傳統Unix系統中的額外二進制文件、服務和配置文件。但是，由于現在軟件開發者創建的許多軟件都在容器中運行，而不是在傳統的、完整的操作系統環境中，我們想在這里介紹一些基礎知識，以確保您對Docker容器中的配置有何不同有一個直觀的認識。我們將在第15章“用Docker容器化應用程序”中更深入地探討Docker容器。
在容器環境中——無論是Docker還是其他容器運行時——您所處理的是戲劇性更小的環境。安裝的程序和實用程序非常少，systemd的替代品是一個戲劇性簡化的init，并且文件系統更小，沒有我們在這里提到的許多目錄。
盡管如此，配置層次結構的原則仍然適用。大多數容器化應用程序期望從以下來源獲取其配置：
容器文件系統的某個位置的配置文件，通常由容器調度程序在容器啟動前不久動態創建 由容器調度程序或啟動它的操作員傳遞的環境變量 命令行參數 盡管這是配置層次結構的簡化版本，您會注意到它基本上與我們在完整的非容器Linux系統中探索的層次結構相同。
我們將在第15章“用Docker容器化應用程序”中更深入地探討容器。
結論 本章為您提供了Linux配置層次結構的概述以及它如何適用于您將每天使用（和編寫）的程序。您了解了命令行參數、環境變量以及適合程序從中獲取配置的更大層次結構中的所有其他內容。
如果您跟隨了本章的內容，您甚至創建了一個systemd服務，該服務包裝了一個程序，并允許您以更統一的方式管理其配置。