[Experience] 程式語言裡的goto真有這麼可怕!?

這幾天看到網路上又有人在吵goto的問題，這讓我想起之前工作同事間的爭執，A同事在他改的程式碼裡使用goto做錯誤處理， B同事看到A改的程式碼就要求A把goto的程式碼全改掉，理由是別人都說不要用所以不該這樣寫， 但是B卻說不出不該用的原因所以兩人就發生了激辯，其實goto也沒那麼恐怖而且也不是不能用。

以下節錄EFI1.10 Driver Writer's Guide的內容 (3.11.7):
In general, the goto construct is not used. However, it is acceptable to use goto for error handling and thus exiting a routine in an error case. A goto allows the error exit code to be contained in one place at the end of a routine. This location reduces software life cycle maintenance issues, as there can be one copy of error cleanup code per routine. If a goto is not used for this case, then the error cleanup code tends to get replicated multiple times, which tends to induce errors in code maintenance.

另外不該使用goto的原因和正確的使用時機clean code這本書也說得很清楚:
 Some programmers follow Edsger Dijkstra’s rules of structured programming. Dijkstra said that every function, and every block within a function, should have one entry and one exit. Following these rules means that there should only be one return statement in a function, no break or continue statements in a loop, and never, ever, any goto statements. While we are sympathetic to the goals and disciplines of structured programming, those rules serve little benefit when functions are very small. It is only in larger functions that such rules provide significant benefit. So if you keep your functions small, then the occasional multiple return, break, or continue statement does no harm and can sometimes even be more expressive than the single- entry, single-exit rule. On the other hand, goto only makes sense in large functions, so it should be avoided.

[Job Experience] OEM/ODM UEFI/BIOS工程師工作內容 簡介

介紹OEM/ODM UEFI BIOS工程師的工作內容之前，先分享當年面試時幾位系統廠主管講的話：

A公司主管： 當我們需要H.264 Decoder時，我們不會去花時間去研究和改code而是直接用買的，因為自己改code的performance未必會比用買的好，其實系統廠主要做的事情就是做系統整合。
B公司主管：Embedded System bootloader這塊是屬於比較乏味的部分。
C公司主管：比起一般寫driver的韌體工程師，做BIOS才更有價值，因為要懂得東西很多，厲害的公司才有辦法讓BIOS的開機速度比別人快。

回正題，會走BIOS主要是受C公司主管的影響，因為如果以走底層來說，學得越多接觸的越廣自然是好事一件，我想對於想走韌體方面的工作的人來說，主要原因不外乎是覺得寫driver驅動硬體很有趣或是比起純軟體，軟硬都會能讓自己變的更有價值，但是我認為想踏入這行的人必須先瞭解產業的概況，以免工作後才驚覺落差與自己的期望甚大，尤其對一綁就是三年的研替來說更是重要。所以才在此分享OEM/ODM UEFI/BIOS的工作內容。
基本上絕大部分系統廠(華碩、技嘉、微星...等公司稱之)的UEFI/BIOS都是用買的，賣UEFI/BIOS code的公司叫做BIOS Vendor (AMI, Phoenix, Insight...等公司)，只有極少數的公司才會開發自家的UEFI/BIOS (或是說只有極少數的公司有這能力和資源，例如DELL)。通常進系統廠擔任UEFI/BIOS工程師公司都會先讓你進行一些基本的Training，然後開始看從Vendor那買來的BIOS code，所以你首先要做的就是瞭解BIOS code的架構以及跑code的流程，這樣你才會知道要如何改code，在看code的過程中當然得搭配UEFI、眾多晶片組以及一些工業標準的技術文件交替看才有辦法看得懂Vendor的code，所以要摸到非常熟悉UEFI/BIOS勢必需要數年以上的時間。再來，一年會開數個案子到數十個案子不等，開案時PM就會定好相關的時程，所以UEFI/BIOS的工作SOP就是要在打板回來前根據硬體上的設計準備好你的UEFI/BIOS，這部分你要做的就是套用相關UEFI/BIOS 功能模組到你的案子、包入device OpRom、Intel 提供的相關資源以及更改一些專案裡硬體參數設定...等事項，打板回來做完開機測試後，你還得做一些基本的測試(例如基本的UEFI/BIOS功能測試、灌OS、ACPI S345...等測項)，以及之後諸多更繁雜的主機板測試 (這點其實依各公司的工作分配而定，分工明確的公司就不需做太多的測試)，這也是開始爆出一堆issue的時候，這時你就得開始釐清是硬體設計問題還是你做的UEFI/BIOS有問題，在釐清你的UEFI/BIOS的過程中(複製和釐清issue也是個累死人的過程)，你還得確認你或你同事改的code、Vendor code和 Intel提供的東西哪裡有問題；還是其它的原因造成的 (例如device OpRom或是特定晶片組的問題)，然後開始解問題和re回報問題給相關廠商請他們解 (系統廠是較無力的，通常90%以上的問題都是得靠相關的廠商來解)，因為相關的時程都已經被PM定好了，所以責任制就會這樣找上門，另外講到這你應該也能瞭解到UEFI/BIOS工程師在porting、追蹤廠商解issue的進度和做測試及驗證所佔的比重是非常重的，寫新的程式碼的機會其實偏少且多是以改改幾行程式碼為主，而且PM一直開案的話每天的事情會都很多、多到讓你感覺總是在處理雜務。再來提一下這行的轉職概況，基本上要轉職就只能轉去那幾家手指數的完的系統廠或是外商，外商的話就像是去Intel當FAE或是到BIOS Vendor裡工作，整體而言出入較窄。現在回頭看A公司主官說的話，系統廠的UEFI/BIOS主要也是在做整合，但也像C公司主管說的，可以讓你有機會學的很廣、懂很多底層的東西，不過待久了寫程式的能力可能會退化不少，而且依系統廠的工作生態，勢必會讓人感到分身乏術，另外個人認為這份工作其實蠻讓人感到乏味的，雖然UEFI/BIOS不是什麼熱門的職缺，但一直都很缺人(理由自己想)，如果看完這篇勸世文後還是對這行很有興趣的話，那我還是說聲歡迎來到煉獄，不過請盡量選擇進BIOS Vendor，對於未來的發展和實力的培養才會比較好。