我們時常在網路上搜尋一些問題的解法，例如：如何從Request讀取IP，如何使用Proxy...等。我們會在Stackoverflow找到答案，我們也會在其他論壇上看到別人分享的解法。以從Reuqest讀取IP為例，當我們在Stackoverflow中找到Best Anwser並複製這些解法，稍微修改一下參數與回傳值，把它放到自己的產品代碼中試一試，按下執行後並成功跑出結果。

var result = string.Empty;

if (_httpContextAccessor.HttpContext.Request.Headers != null)
{
    var forwardedHeader = _httpContextAccessor.HttpContext.Request.Headers["X-Forwarded-For"];
    if (!StringValues.IsNullOrEmpty(forwardedHeader))
        result = forwardedHeader.FirstOrDefault();
}

if (string.IsNullOrEmpty(result) && _httpContextAccessor.HttpContext.Connection.RemoteIpAddress != null)
    result = _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();

return result;

雖然不是很懂這段代碼在做什麼，不過程式跑起來很正常，很開心解決了一個問題。然後...就沒有然後了。包括我自己在內，在剛學寫程式的一兩年裡，也時常這麼做。心想著代碼可以工作就好，但是沒有替未來著想，萬一他出問題的時候該怎麼辦？如果今天是公司的產品代碼，那還得考慮別人是否也有辦法可以維護，更糟的情況是Best Answer還有bug，那情況就更複雜了。

在網路上尋找解法時，最理想的狀況是能理解這個解法的每一行的意義。不過通常解法會使用到自己不熟悉的作法或API，此時也是最好的學習時機點，學習並了解每一個不熟的作法或API的功能與其限制。甚至強迫自己註解找到的解法，並透過一行一行的了解代碼並反註解，直到了解整個解法。

當了解解法之後，有時需要的是重構一下代碼。因為網路上的作法很多時候是為了展示解法的使用方式，並不是為了更乾淨的或更好閱讀的目的而寫的，所以當了解作法之後重構也是十分必要的步驟。