2017 年你的最後一行代碼寫了什麼？

01-07

2017年馬上要結束了，你打算最後一行代碼寫啥？真正的最後的一行代碼寫的是啥？

本問題已加入知乎圓桌 ?「2017 年度盤點」，更多討論歡迎關注。

當然是寫 shell：

mv 2017-todolist 2018-todolist

2018 年第一天上班，就優化了一把 [2333.jpg]：

xlzd: 2018年大家碼下的第一行代碼是什麼？

0 0 1 1 * /bin/mv $(($(date +%Y)-1)).todolist $(date +%Y).todolist

sed -i -b "/Copyright/s/2017/2018/" $(find . -name "*.?pp")

想去年的時候我還傻乎乎地手動一個一個改來著的 →_→

ag "TODO" &> hall_of_shame.txt

我以為昨天已經寫了2017年最後一行代碼，然而

剛剛2017年結束了，我終於可以確定地來回答這個問題了。我在剛才，2017年12月31日的最後幾分鐘，寫的幾行代碼是 matlab 代碼：

tmp_idx = unique(valid_meteor_idx); [~, tmp_idx] = setdiff(meteor_lbl, tmp_idx); meteor_lbl(tmp_idx) = -1;

這幾行代碼在做什麼呢？容我慢慢道來……

我時常自我吹噓是碼農里拍星空最好的、星空攝影師里寫代碼最溜的。在過去的2017年，我是寫了不少代碼的，比如根據星點對多張星空照片進行對齊降噪的小工具（詳見我的專欄相關文章《星野攝影降噪（2）：對齊疊加》），比如根據光譜曲線渲染 RGB 顏色的小工具（詳見我的專欄相關文章《光譜渲染的幾個例子》），比如經歷了日全食並且寫了很多代碼處理日全食的圖像，得到細節驚人的日食照片（詳見我的專欄相關文章《完美記錄驚人的細節！這張日全食照片是怎樣誕生的？【01】》，當然，這個話題目前並沒有寫完）……

不過，我個人最滿意的項目，還是最近策劃的，和朋友共同完成的 三維流星雨拍攝項目。

這個項目最初的想法，源自我和我的好友魂兒wlt 的討論，我們認為相距幾十公里的相機如果同時拍下了同一顆流星的照片，這兩張照片就能夠提供足夠的信息來給這顆流星定位。事實上類似的事情以前也有人做過，【分析報告】2013年08月13日華北火流星軌跡分析 | 觀星者小組 | 果殼網科技有意思這裡就有人根據兩地拍攝到的火流星照片，分析並計算了流星在三維空間中的位置。但我並不滿足於這樣的偶然，我希望是在一場流星雨中，對每一顆流星進行定位。恰好時逢年末，萬眾期待的雙子座流星雨即將來臨，與幾位好友商量後，我決定正式開始實施這個項目。

那一夜，我們 4 組人馬一共架起 12 台相機（佳能5D3、6D2、6D，還有一台6D天文改機），全部配上了適馬的 20mm/F1.4 和 18mm/F1.8 這樣的大光圈超廣角鏡頭（感謝SIGMA適馬提供鏡頭支持），覆蓋了東、南、西三個方向近240度範圍的天區，監測距離拍攝地點500公里以內的所有流星。從最終拍攝的大約3萬張照片中，保守估計可以定位超過400顆流星的三維位置。

這個項目，無論是目的、規模還是執行的完成度、獲得的數據量，都可以說是前所未有的。

如此大量的數據，分析和處理顯然不可能由人工來完成，因此我自己寫了大量的代碼，對拍攝到的圖片進行處理。識別出照片中的流星、將照片中的星空與星圖進行匹配、對流星進行定位。開頭寫的那幾行代碼，正是用於識別和匹配不同相機拍攝到的流星的。

雖然最後的數據還在處理中，不過我們目前已經剪輯了一些背後的花絮故事。這個項目拍攝過程中的艱難困苦，以及拍攝到流星時候的喜悅激動，都在裡面了，這裡放出來與君共享（我的專欄也發了一篇文章《三維流星雨背後的故事》）。我們後續的成果出來，我會第一時間在專欄發布文章的，敬請期待。

大家新年快樂！

祝知乎的各位好友，新年快樂(/ω·＼*)

2017年最後一行代碼

獻給了UE4的MATERIAL的CustomNode

（有人問我是什麼?其實最後一行是return b;} ）

特別之處在於，前面的視頻也展現出來了。

一個小的點雲渲染器

（200w數據量）

（120w數據量）

（500w數據量）

希望正如回答的開頭

今年不愉快的

都將在明年翻篇 (??????????????)

謝謝

補發幾個點雲數據

還是挺有趣的啦(???????????????????)???

NULL改成了nullptr

2017年最後一個星期，領導給我一個任務：把代碼規範化。就是將所有的代碼擼一遍，該有空格的地方加空格；該要換行的地方加上回車；該有花括弧的地方添上花括弧。

於是我2017年的最後一個星期，一直糾結於倆件事的抉擇：是寫個程序批量擼代碼，還是人肉手動擼代碼。

當我寫程序時，我在想這活寫代碼有多不靠譜，於是就轉做人肉擼代碼。當我人肉擼代碼時，我在想這活人肉擼有多少工作量，而且人肉乾肯定有漏擼的地方，於是又轉做寫代碼。編程的難點有倆個：一是if,for,while後面的語句要有大括弧加回車換行，單個的好解決，嵌套的就麻煩了。二是雙目運算符兩邊要有空格，例如*這個符號，得判斷它是乘號，是取地址符，是在注釋內，還是在字元串內。

就這樣一星期里，我不停地切換模式，終於在2017年的最後一個工作日，我把所有代碼人肉擼了一遍。

這周工作產能低，就是因為做事不專心。我本該一心一意地人肉擼代碼，頂多花兩天搞定的事，卻搞了一星期。

所以，2017年我的最後一行代碼是：回車換行。

我決定修好Erlang HiPE在amd64上不支持PIE的問題，現在只剩下LLVM後端那部分了。

如下：

rm -rf ./*

打算寫一行

//TODO:

實際上是：

忘了是哪一行了，反正這裡面的if...else..., &>, &< ，!, , ||……搞得我暈頭轉向，差不多花了一個多小時的時間調試來調試去……

我想，看我代碼直播的童鞋經常會有一種智商優越感：連飛哥這種傻子都能寫代碼，哈哈，我……

(￢_￢)，好吧，我承認，我是故意的。犧牲我一個，成全千萬家，阿彌陀佛，善哉善哉！

最終趕著把 一起幫 上這個「邀請好心人」和「周用戶榜」的功能一起發布了：

用戶一周收穫/支出的時間幣排行榜

看著新發布的網站，心潮有點小澎湃，寫了一篇溫暖的感覺：寫在2017年底2018年初·一起幫，把自己好好的感動了一把。

說一說寫代碼的事吧！

經常有初學者問：寫代碼是不是需要「深厚的數學功力」？

我只能說：

對於大量的（這量至少大到95%吧？）業務代碼，真的不需要，初中數學水平就足以完爆這所有的業務邏輯了。

這時候，最重要的，是清晰的邏輯能力；更更重要的，是把紛雜的業務邏輯清晰地表達出來的能力。

請仔細理解上面這句話。

所以，有人說：寫代碼就像寫文章；還有人說：代碼是寫給人看的。

雖然我通過代碼直播來講解「系統架構和項目管理」的想法破產了，同學們都說「跟不上」「太特么難了」……

好吧，是我之前太naive了一點。

但有一點我覺得現在偶爾能看看我直播的同學應該：

架構的核心問題是控制代碼的複雜度。

「一起幫」現在還是一個小網站，功能其實還還非常單薄，但是一些功能點的邏輯已經開始讓我們頭痛了，「寫到後面忘了前面」「按下了葫蘆浮起了瓢」的事情也發生了好幾起——以前好端端的代碼悄悄摸摸的就壞掉了，測試調試fix bug所花的時間和精力迅速的上升……

大家想想，這是：

我一個人
零零碎碎花了一年的時間，
完全按照自己的想法，
使用非常成熟和熟悉的語言和框架

開發的一個輕量級的小網站，就已經開始出現「複雜度」的問題。那麼，那些：

數十人數百人甚至數千人進場立場
花費數年甚至數十年的時間開發
需求在不斷的交流溝通和變更，
混雜著過時的流行的成熟的新興的各種不同語言框架和技術

的企業級應用，代碼的管理和維護是怎樣的一種噩夢？

再一次推薦 @蘿魏紫的回答：為什麼部分看起來不太複雜的網站，比如Facebook，需要大量頂尖高手來開發？

很多同學不理解我為什麼反對「性能至上論」（見：），我覺得主要就是因為他們沒有認識到：在企業級應用開發中，項目的複雜度才是最核心的問題。所謂的大數據，高並發，並不是企業級應用，支撐龐雜多變業務需求的應用才是企業級應用。

而且，處理業務邏輯的複雜度，一點也不比處理一些性能問題輕鬆。有過開發經驗的同學都知道，性能不行了，加塊內存條就可以解決；但進度趕不上了，加個人還不一定能行。

或許是因為性能的提升可以立竿見影，而代碼複雜度的管理和優化卻很難感覺到效果，甚至各種規矩條款讓放蕩不羈愛自由的程序猿感到厭煩，所以到處都能看到「演算法和數據結構」的追捧，兢兢業業的打理著各種if...else...攻城獅們被打上打上「碼農」「民工」的標籤，據說他們都不配叫做程序員。

我只能說，這其實是不對的。

哪怕從最世俗、最便於比較的、收入的角度，搞資料庫增刪改查的，也不見得比研究「數據結構和演算法」的低。因為收入是由市場需求決定的，而不是你自以為的逼格，市場不為逼格買單。

信或者不信，隨你的便，但不用在我的評論區里撕，謝謝。

+++++++++++++++++

收藏進：野生程序員，歡迎投稿、推薦和關注，O(∩_∩)O~

return 0；//上面我寫的東西不要動，我去買個橘子明年就回來

If (btc.price &< 10000.00) :

Users().get(「lidang」).act(「eat」).setTarget(me()).typeDeprecatedDoNotUse(「jj」)

給某本書做了個索引，代碼簡單得要命。

成果大概是這樣的：

{ "key": " ", "description": "古文正。從一足。足亦止也。止部曰。止爲足。" }, { "key": "乏", "description": "春秋傳曰。反正爲乏。左傳宣十五年文。此說字形而義在其中矣。不正則爲匱？。二字相郷背也。禮受矢者曰正。拒矢者曰？。以其禦矢謂之？。以獲者所容身謂之容。房法切。古音在七部。" }, { "key": "是", "description": "直也。直部曰。正見也。從日正。十目燭隱則曰直。以日爲正則曰是。從日正會意。天下之物莫正於日也。左傳曰。正直爲正。正曲爲直。五經文字是入曰部。則唐本從曰也。恐非。承旨切。旨當作紙。十六部。凡是之屬皆從是。" }, { "key": " ", "description": "籒文是。從古文正。按此知籒篆皆從日。" }, { "key": "韙", "description": "是也。古文尙書曰。時五者來僃。今文尙書作五是來僃。李賢於李雲荀爽傳皆引史記五是來僃可證。凡史記多用今文尙書也。荀爽對策曰。五韙咸僃。韙與是義同。六書之轉注也。李雲上書曰。五氏來僃。氏與是音同在十六部。六書之叚借也。從是。韋聲。於鬼切。十五部。春秋傳曰。犯五不韙。左傳隱十一年文。" }, { "key": "愇", "description": "籒文韙。從心。玉篇雲。愇、怨恨也。廣韻引字書。愇、恨也。皆不雲同韙。" }, { "key": "尟", "description": "是少也。易辭。故君子之道鮮矣。鄭本作尟。雲少也。又尟不及矣。本亦作鮮。又釋詁。鮮、善也。本或作尠。尠者尟之俗。是少、逗。俱存也。是少二字。各本譌作尟字。此釋上文是少之意。是、此也。俱存而獨少此。故曰是少。從是少。於其形得其義也。賈侍中說。此字說得諸侍中也。穌典切。十四部。" }, { "key": "辵", "description": "乍行乍止也。公食大夫禮注曰。不拾級而下曰？。鄭意不拾級而上曰栗階。亦曰歷階。不拾級下曰？階也。廣雅。？、奔也。從彳止。彳者乍行。止者乍止。丑略切。古音葢在二部。讀如超。凡辵之屬皆從辵。讀若春秋傳曰辵階而走讀若二字衍。春秋傳者、公羊宣二年文。今公羊作？。何休曰。？猶超遽不暇以次。" }, { "key": "跡", "description": "步處也。莊子云。夫跡、履之所出。而跡豈履也。從辵。亦聲。跡本作。朿聲。故音在十六部。小篆改爲亦聲。則當入五部。而非本部之形聲矣。李陽冰雲。李丞相持朿作亦。謂此字也。資昔切。古音在十六部。" }

PS:要不要把它上線掉呢？....

2018年的第一份代碼給了微信公眾號開發，成果如下：

正在寫一個 C 的 TOML parser，估計將成為今年最後的代碼了。

去年的npm install還沒結束

cout &<&< res &<&< endl;

做演算法題輸出結果時最常用的一行了。

每年年底12月30或者31號，codeforces上都會有有一局goodbye round。從2013年接觸演算法競賽開始，基本上每年的goodbye我都會參加。雖然水平一直都很菜，但是有空就會參加比賽玩玩，留下了很多美好的回憶。想想自己2013年的時候大半夜拼了命也只做出最簡單的題的笨拙樣子，真的就像是昨天。

四年彈指一揮。

希望以後還繼續喜歡這個遊戲，每年如此。

原計劃最後一行代碼是shell：

git push

結果發現SCI event _6F的2-tier GPE發生interrupt storm. 最後一行代碼變成了：

Method(_L6F) // 2-tier GPE event handler { /* If(LEqual(RTD3,1)) // if RTD3 enabled { }*/ }

哪裡出了問題就把那裡注掉，這是誰的ｃｏｄｉｎｇ哲學？然而，系統關機的問題算是解決了！然後懷著喜憂參半的心情回家過節。。。。。。

這裡有看得懂這段代碼的人嗎？