程序員在等電梯的時候都在想什麼

⑴ 普通程序員的工作生活是怎樣的

通常我們進入公司以後，不會是重頭開始一個項目，而是在已有代碼的基礎上進行維護或新功能的開發，所以必須「讀代碼」。
讀有「泛讀」，了解系統架構、功能模塊，對系統有一個大致的認識，各個功能能找到相應代碼實現的位置。
還有「精讀」，通常就是調試了，在fix bug的時候使用。此外還包括審核：一些規范一點的公司，都會有code review，也是精讀，但不用debug。
對於一個成熟的項目來說，讀代碼——而不是寫代碼——可能是最耗時間的工作了。
寫注釋文檔
為了減少「讀代碼」的時間，我們不得不花時間「寫注釋」「寫文檔」——這個程序員最深惡痛絕的工作。所以現在「爛代碼才需要注釋」的聲音變得越來越強，但無論如何，文檔還是要寫的。（注意：要能區分注釋和文檔）
了解需求
好了，終於到了「寫代碼」的時間了。
然而，在動手開始寫代碼之前，你必須花時間「了解需求」。和自己寫個小程序玩玩不同，在公司，你是為別人寫代碼，所以你一定要了解別人究竟想實現什麼功能。通常，這並沒有你想像的那麼簡單，需要反復的溝通。
當然，也有一些團隊和個人，不願意在這上面「浪費時間」，通常他們的下場就是不斷的寫代碼，然後不斷的改代碼，加班加點的做大量的無用功，整個公司怨氣沖天一地雞毛。

⑵ 程序員都有哪些強迫症行為

1.喜歡考慮後果和臨界值。曾經寫過一個面向用戶的爬蟲，由於用戶有可能沒有任何計算機基礎，所以我不得不花很大的一部分精力來考慮用戶有可能產生哪些不該發生的操作。一開始是這樣的： - 程序君：欸？用戶，你介個樣子叫我很難做咩......後來乾脆： - 按鈕君：你看不見我你看不見我你看不見我 ...所以現在做一件事要比之前多考慮很多很多......2.養成了反思的好習慣。每次有bug了，不用想，肯定是自己的錯，盡管認為自己沒有錯，但是肯定是自己哪裡錯了。然後就仔細反思代碼的邏輯哪裡不對......所以生活中一件事情發生後我總是會反思自己哪裡做的不對，下次怎麼做。3.忍耐度變高了。曾經寫了一個上千行的JavaScript爬蟲，沒有面向對象沒有分層，亂的簡直是不堪入目，所以調試起來bug也是滿天飛，有時候風大丟能糊我臉上......曾經被一個bug困擾了整整1天，一天什麼都沒干，就為了調這個bug。而結果是，這個bug沒調好，反而倒是修復了很多其他奇奇怪怪的bug......而且還把我氣哭了好幾次......現在的我已經被bug調教的很聽話了。

⑶ 程序員一般的工作都是干什麼的

程序員的工作內容如下：

1、對項目經理負責，負責軟體項目的詳細設計、編碼和內部測試的組織實施，對小型軟體項目兼任系統分析工作，完成分配項目的實施和技術支持工作。

2、協助項目經理和相關人員同客戶進行溝通，保持良好的客戶關系。

3、參與需求調研、項目可行性分析、技術可行性分析和需求分析。

4、熟悉並熟練掌握交付軟體部開發的軟體項目的相關軟體技術。

5、負責向項目經理及時反饋軟體開發中的情況，並根據實際情況提出改進建議。

6、參與軟體開發和維護過程中重大技術問題的解決，參與軟體首次安裝調試、數據割接、用戶培訓和項目推廣。

7、負責相關技術文檔的擬訂。

8、負責對業務領域內的技術發展動態進行分析研究。

(3)程序員在等電梯的時候都在想什麼擴展閱讀：

數據顯示，近四成程序員處於單身狀態，明顯高於非互聯網從業者24%的比例。廣州、深圳、北京成為單身比例最高的三大城市。單身的程序員在擇偶方面也有區別於其他人的偏好，更注重對象的顏值、身材和家庭背景。

統計顯示，互聯網從業人員對買房有不小熱情。互聯網從業人員更勇於背負房貸，29%互聯網從業人員正背負房貸，這一比例兩倍於非互聯網從業人員。其中在各大城市排名中，杭州、北京、廣州位列前三大互聯網從業者背負房貸人數比例最高的城市。

在互聯網企業的一個特色是，沒有明確的上班時間和下班時間，靈活的工作時間和高強度的工作量，使得加班成了行業特色。在睡眠時間方面，程序員的睡眠時間集中在11點至凌晨1點之間，而非互聯網從業人員的睡眠高峰在10點至12點之間。

⑷ 程序員思維會給你的生活帶來哪些影響

比如：對於許多重復的、線性的事物，大腦將獨立於編程。我要檢查強迫症，反復檢查是必要的，比如鎖門，我會把鎖分為幾個步驟，順序執行，返回結果，因為方法執行起來也不例外，上班時會放心，我只好在這個檢查中進行治療。駕校實習，第二節考試，編譯程序，順序執行，突發情況，分行解決方案，滿分。

6。永遠想想2的力量

職業原因：計算機存儲信息的基本單位是位（位）。在二進制系統中，每個0或1是一個位。

日常行為：通常不是在10計算，而是在2計算。有些平凡的日子在程序員眼中也是神奇的。例如，程序員日是每年的第二百五十六天（2·8）。還建議每年使用10月24日作為程序員日（2？10）。

7。生活方式不健康

職業原因：程序員編寫半天程序，沒有電腦屏幕的眼鏡，甚至在靈感爆發時熬夜。

⑸ 電梯調度演算法...

不管你是在北上廣還是在港澳台，甚至三四線城市，凡是有規模的地區，高樓比比皆是。不管是寫字樓，還是大型商城，讓你最頭痛的就是乘電梯，尤其是在趕時間的時候。

每天早上，那些差5分鍾就遲到的程序員，在等電梯時，一般會做兩件事：

前者可能是寫字樓里上班族慣有的精神類疾病，但後者肯定是程序員的職業病。本文對「罵電梯」不給予任何指導性建議。

但說起電梯調度演算法，我覺得還是可以給大家科普一下，好為大家在等電梯之餘，打發時間而做出一點貢獻。

（電梯調度演算法可以參考各種硬碟換道演算法，下面內容整理自網路）

先來先服務（FCFS-First Come First Serve）演算法，是一種隨即服務演算法，它不僅僅沒有對尋找樓層進行優化，也沒有實時性的特徵，它是一種最簡單的電梯調度演算法。

它根據乘客請求乘坐電梯的先後次序進行調度。此演算法的 優點是公平、簡單，且每個乘客的請求都能依次地得到處理，不會出現某一乘客的請求長期得不到滿足的情況 。

這種方法在載荷較輕松的環境下，性能尚可接受，但是在載荷較大的情況下，這種演算法的性能就會嚴重下降，甚至惡化。

人們之所以研究這種在載荷較大的情況下幾乎不可用的演算法，有兩個原因：

最短尋找樓層時間優先（SSTF-Shortest Seek Time First）演算法，它注重電梯尋找樓層的優化。最短尋找樓層時間優先演算法選擇下一個服務對象的原則是 最短尋找樓層的時間。

這樣請求隊列中距當前能夠最先到達的樓層的請求信號就是下一個服務對象。

在重載荷的情況下，最短尋找樓層時間優先演算法的平均響應時間較短，但響應時間的方差較大 ，原因是隊列中的某些請求可能長時間得不到響應，出現所謂的「 餓死」現象 。

掃描演算法（SCAN） 是一種按照樓層順序依次服務請求，它讓電梯在最底層和最頂層之間連續往返運行，在運行過程中響應處在於電梯運行方向相同的各樓層上的請求。

它進行尋找樓層的優化，效率比較高，但它是一個 非實時演算法 。掃描演算法較好地解決了電梯移動的問題，在這個演算法中，每個電梯響應乘客請求使乘客獲得服務的次序是由其發出請求的乘客的位置與當前電梯位置之間的距離來決定的。

所有的與電梯運行方向相同的乘客的請求在一次電向上運行或向下運行的過程中完成， 免去了電梯頻繁的來回移動 。

掃描演算法的平均響應時間比最短尋找樓層時間優先演算法長，但是響應時間方差比最短尋找樓層時間優先演算法小， 從統計學角度來講，掃描演算法要比最短尋找樓層時間優先演算法穩定 。

LOOK 演算法是掃描演算法（SCAN）的一種改進。對LOOK演算法而言，電梯同樣在最底層和最頂層之間運行。

但 當 LOOK 演算法發現電梯所移動的方向上不再有請求時立即改變運行方向 ，而掃描演算法則需要移動到最底層或者最頂層時才改變運行方向。

SATF（Shortest Access Time First）演算法與 SSTF 演算法的思想類似，唯一的區別就是 SATF 演算法將 SSTF 演算法中的尋找樓層時間改成了訪問時間。

這是因為電梯技術發展到今天，尋找樓層的時間已經有了很大地改進， 但是電梯的運行當中等待乘客上梯時間卻不是人為可以控制 。

SATF 演算法考慮到了電梯運行過程中乘客上梯時間的影響 。

最早截止期優先（EDF-Earliest Deadline First）調度演算法是最簡單的實時電梯調度演算法，它的 缺點就是造成電梯任意地尋找樓層，導致極低的電梯吞吐率。

它與 FCFS 調度演算法類似，EDF 演算法是電梯實時調度演算法中最簡單的調度演算法。 它響應請求隊列中時限最早的請求，是其它實時電梯調度演算法性能衡量的基準和特例。

SCAN-EDF 演算法是 SCAN 演算法和 EDF 演算法相結合的產物。SCAN-EDF 演算法先按照 EDF 演算法選擇請求列隊中哪一個是下一個服務對象，而對於具有相同時限的請求，則按照 SCAN 演算法服務每一個請求。它的效率取決於有相同 deadline 的數目，因而效率是有限的。

PI（Priority Inversion）演算法將請求隊列中的請求分成兩個優先順序，它首先保證高優先順序隊列中的請求得到及時響應，再搞優先順序隊列為空的情況下在相應地優先順序隊列中的請求。

FD-SCAN（Feasible Deadline SCAN）演算法首先從請求隊列中找出時限最早、從當前位置開始移動又可以買足其時限要求的請求，作為下一次 SCAN 的方向。

並在電梯所在樓層向該請求信號運行的過程中響應處在與電梯運行方向相同且電梯可以經過的請求信號。

這種演算法忽略了用 SCAN 演算法相應其它請求的開銷，因此並不能確保服務對象時限最終得到滿足。

以上兩結介紹了幾種簡單的電梯調度演算法。

但是並不是說目前電梯調度只發展到這個層次。目前電梯的控制技術已經進入了電梯群控的時代。

隨著微機在電梯系統中的應用和人工智慧技術的發展，智能群控技術得以迅速發展起來。

由此，電梯的群控方面陸續發展出了一批新方法，包括：基於專家系統的電梯群控方法、基於模糊邏輯的電梯群控方法、基於遺產演算法的電梯群控方法、基於勝景網路的電梯群控方法和基於模糊神經網路的電梯群控方法。

本人設置的電梯的初始狀態，是對住宅樓的電梯的設置。

(1)建築共有21層，其中含有地下一層（地下一層為停車場）。
(2)建築內部設有兩部電梯，編號分別為A梯、B梯。
(3)電梯內部有23個按鈕，其中包括開門按鈕、關門按鈕和樓層按鈕，編號為-1，1，2，3，4……20。
(4)電梯外部含有兩個按鈕，即向上運行按鈕和向下運行按鈕。建築頂層與地下一層例外，建築頂層只設置有向下運行按鈕，地下一層只設置有向上運行按鈕。
(5)電梯開關門完成時間設定為1秒。電梯到達每層後上下人的時間設定為8秒。電梯從靜止開始運行到下一層的時間設置為2秒，而運行中通過一層的時間為1秒。
(6)在凌晨2：00——4：30之間，如若沒有請求信號，A梯自動停在14層，B梯自動停在6層。
(7)當電梯下到-1層後，如果沒有請求信號，電梯自動回到1層。

每一架電梯都有一個編號，以方便監控與維修。每一架電梯都有一實時監控器，負責監控電梯上下，向電梯升降盒發送啟動、制動、加速、減速、開關電梯門的信號。若電梯發生故障，還應向相應的電梯負責人發送求救信號。

電梯內部的樓層按鈕：

這樣就表示乘客將要去往此層，電梯將開往相應層。當電梯到達該層後，按鈕恢復可以使用狀態。

電梯內部開門按鈕：

如若電梯到了乘客曾經按下的樓層，但是無乘客按開門按鈕，電梯將自動在停穩後1秒後自動開門。

電梯內部關門按鈕：

電梯外部向上按鈕：

電梯外部向下按鈕：

你肯能意識到 哪個演算法都不是一個最佳方案，只是它確實解決了一定情況的問題 。但是對一個優秀的程序員而言，研究各種演算法是無比快樂的。也許你下一次面試，就有關於調度演算法的問題。