日常啰嗦
距離上一次更新博客有一段時間了，主要是因為最近有開發任務，另外，這段時間也在學習docker的相關知識，所以博客就沒有繼續寫了，推薦一本書《Docker技術入門與實戰》(第二版)，想體驗一下docker的朋友可以看一下。
按照計劃，第二階段主要是講一下項目優化上的一些東西，相關的工具已經在基礎篇介紹了一些，所以在本階段更多的是側重于代碼上，雖然做了一份粗略的計劃，但是第一篇該寫什么又犯了糾結，剛好有一次編寫代碼時看到一個方法中含有System.out.print()打印語句，這個方法大家都不陌生，第一份代碼應該都是"世界，你好"，所以本篇就講一下System.out.print與Log吧。
原因簡述
提到代碼優化呢，其實需要注意的有很多個地方，因為一個系統涉及到很多技術，針對每個技術也需要對應的優化方案，因此，這是一件時間跨度長且復雜的工程，所以優化篇的開始呢，就先從最開始的地方講起，打印語句，可能我們每個人都會在日常編碼過程中都存在的一個問題，就是對于程序中的一些輸出信息，喜歡使用System.out.print打印到控制臺上，而不采用日志記錄的方式輸出到對應的日志文件。
為什么要講這個事情呢？因為這個問題其實我也想了挺久的，就是System.out.print和log的區別在哪，區別到底有多大，剛好看到代碼里有一些System.out.print代碼，所以今天就寫了這篇文章。
System.out.print與Log比較
System.out.print的優點：直觀、方便。
Log的優點：異步、解耦、靈活、策略多。
提到System.out.print，除了感覺到方便之外，還會想到其他的優點嗎？似乎也就這個優點，syso快捷鍵瞬間就是一條打印語句，很順手的一件事，除了這個感覺外，似乎也沒有其他特別的感受了。
System.out.print和java運行程序運行在同一線程，也就是說，業務程序會等待System.out的動作，導致資源被占用，log4j、logback等日志工具進行調試信息的打印，這類工具是異步線程的，不會使程序處于等待狀態。
System.out.print是在控制臺輸出，只能輸出到控制臺，功能上線后，總不能一直盯著控制臺吧，而且日志文件需要保留，以供日后分析，是需要一套管理規范的，即便使用tomcat服務器，System.out會輸出到catalina.out文件，catalina.out文件也不會一直存在，需要定期清空，如果不清空，大文件的讀寫也是挺影響性能的。說到這里，System.out.print寫入的文件只有一個，對于一個文件的讀寫，這個io肯定會排隊寫，且System.out.print在當前線程，肯定對性能會有稍微的影響。
程序中充斥著大量的System.out.print打印代碼是相當不規范的。
補充說明
當然，說到影響服務器性能，必須是代碼中存在大量的System.out.print才會明顯的影響，而這個量需要有多大呢？考慮到系統體量、服務器版本、服務器配置這些因素，很難給一個固定的值，而且肯定也有很多人認為小量的不規范代碼不會使人察覺的，我也支持這個觀點，不過我們也要記得一句話，千里之堤潰于蟻穴，不能因為一件事是小事就選擇性忽略掉，對自己要求高一點，寫的代碼也一定要整潔且正確。
項目由小項目慢慢成長為大項目，對于系統的日志要求肯定也越來越苛刻，后期肯定也要搭建日志系統的，日志信息的采集和分析也肯定是用對應的Log框架及相關的技術去做，比如ELK技術棧，這個時候，再問自己一個問題，在控制臺上打印算是什么樣的一種感受呢？
針對于日志的靈活性，根據一些日志框架的特點，也可以定制自己的日志規范，日志輸出策略、日志存儲策略、日志維護策略，想怎么輸出怎么輸出，想怎么存儲怎么存儲，非常的靈活。不同團隊根據自己團隊的特點制定出自己的日志策略，而不是一味的System.out.print打印到控制臺上，與此相比，程序中充斥大量的System.out.print語句明顯黯然失色。
以上為個人觀點。
總結
今天講這個事情，主要的原因，是因為有一次在查找System.out.print和log的區別時發現講這個問題的文章比較少，所以自己整理了一下，另外一個方面，是覺得代碼規范這個事情還是很重要的，希望大家日常編碼工作中注意，并沒有其他的意思，因為其實寫順手了，System.out.print確實不好改掉。
這里引用代碼整潔之道中的一句話：
“進度可以重訂，需求可以修改，團隊動態可以修正，但糟糕的代碼只是一直腐敗發酵，無情的拖著團隊的后腿。”
這里所講的糟糕的代碼，不只是不規范的輸出語句，也包括了很多其他方面不規范和不整潔的代碼，改掉不良習慣，養成良好的編程習慣，共勉。
