程序員觀看新人代碼

⑴ 程序員新人周一優化一行代碼，周三被勸退

這周一，公司新來了一個同事，面試的時候表現得非常不錯，各種問題對答如流，老闆和我都倍感欣慰。

這么優秀的人，絕不能讓他浪費一分一秒，於是很快，我就發他了需求文檔、源碼，讓他先在本地熟悉一下業務和開發流程。

結果沒想到，周三大家一塊 review 代碼的時候就發現了問題，新來的同事直接把原來 @Transactional 優化成了這個鬼樣子：

就因為這一行代碼，老闆（當年也是一線互聯網大廠的好手）當場就發飆了，馬上就要勸退這位新同事，我就趕緊打圓場，畢竟自己面試的人，不看僧面看佛面，是吧？於是老闆答應我說再試用一個月看看。

會議結束後，我就趕緊讓新同事復習了一遍事務，以下是他自己做的總結，還是非常詳細的，分享出來給大家一點點參考和啟發。相信大家看完後就明白為什麼不能這樣優化 @Transactional 註解了，純屬畫蛇添足和亂用。

事務在邏輯上是一組操作， 要麼執行，要不都不執行 。主要是針對資料庫而言的，比如說 MySQL。

只要記住這一點，理解事務就很容易了。在 java 中，我們通常要在業務裡面處理多個事件，比如說編程喵有一個保存文章的方法，它除了要保存文章本身之外，還要保存文章對應的標簽，標簽和文章不在同一個表裡，但會通過在文章表裡（posts）保存標簽主鍵（tag_id）來關聯標簽表（tags）：

那麼此時就需要開啟事務，保證文章表和標簽表中的數據保持同步，要麼都執行，要麼都不執行。

否則就有可能造成，文章保存成功了，但標簽保存失敗了，或者文章保存失敗了，標簽保存成功了——這些場景都不符合我們的預期。

為了保證事務是正確可靠的，在資料庫進行寫入或者更新操作時，就必須得表現出 ACID 的 4 個重要特性：

其中，事務隔離又分為 4 種不同的級別，包括：

需要格外注意的是： 事務能否生效，取決於資料庫引擎是否支持事務，MySQL 的 InnoDB 引擎是支持事務的，但 MyISAM 就不支持 。

1）編程式事務

編程式事務是指將事務管理代碼嵌入嵌入到業務代碼中，來控制事務的提交和回滾。

你比如說，使用 TransactionTemplate 來管理事務：

再比如說，使用 TransactionManager 來管理事務：

就編程式事務管理而言，Spring 更推薦使用 TransactionTemplate。

在編程式事務中，必須在每個業務操作中包含額外的事務管理代碼，就導致代碼看起來非常的臃腫，但對理解 Spring 的事務管理模型非常有幫助。

當然了，要想實現事務管理和業務代碼的抽離，就必須得用到 Spring 當中最關鍵最核心的技術之一，AOP，其本質是對方法前後進行攔截，然後在目標方法開始之前創建或者加入一個事務，執行完目標方法之後根據執行的情況提交或者回滾。

Spring 將事務管理的核心抽象為一個事務管理器（TransactionManager），它的源碼只有一個簡單的介面定義，屬於一個標記介面：

通過 PlatformTransactionManager 這個介面，Spring 為各個平台如 JDBC(DataSourceTransactionManager)、Hibernate(HibernateTransactionManager)、JPA(JpaTransactionManager)等都提供了對應的事務管理器，但是具體的實現就是各個平台自己的事情了。

參數 TransactionDefinition 和 @Transactional 註解是對應的，比如說 @Transactional 註解中定義的事務傳播行為、隔離級別、事務超時時間、事務是否只讀等屬性，在 TransactionDefinition 都可以找得到。

返回類型 TransactionStatus 主要用來存儲當前事務的一些狀態和數據，比如說事務資源（connection）、回滾狀態等。

TransactionDefinition.java：

Transactional.java

說到這，我們來詳細地說明一下 Spring 事務的傳播行為、事務的隔離級別、事務的超時時間、事務的只讀屬性，以及事務的回滾規則。

當事務方法被另外一個事務方法調用時，必須指定事務應該如何傳播 ，例如，方法可能繼續在當前事務中執行，也可以開啟一個新的事務，在自己的事務中執行。

TransactionDefinition 一共定義了 7 種事務傳播行為：

01、 PROPAGATION_REQUIRED

這也是 @Transactional 默認的事務傳播行為，指的是如果當前存在事務，則加入該事務；如果當前沒有事務，則創建一個新的事務。更確切地意思是：

這個傳播行為也最好理解，aMethod 調用了 bMethod，只要其中一個方法回滾，整個事務均回滾。

02、 PROPAGATION_REQUIRES_NEW

創建一個新的事務，如果當前存在事務，則把當前事務掛起。也就是說不管外部方法是否開啟事務，Propagation.REQUIRES_NEW 修飾的內部方法都會開啟自己的事務，且開啟的事務與外部的事務相互獨立，互不幹擾。

如果 aMethod()發生異常回滾，bMethod()不會跟著回滾，因為 bMethod()開啟了獨立的事務。但是，如果 bMethod()拋出了未被捕獲的異常並且這個異常滿足事務回滾規則的話,aMethod()同樣也會回滾。

03、 PROPAGATION_NESTED

如果當前存在事務，就在當前事務內執行；否則，就執行與 PROPAGATION_REQUIRED 類似的操作。

04、 PROPAGATION_MANDATORY

如果當前存在事務，則加入該事務；如果當前沒有事務，則拋出異常。

05、 PROPAGATION_SUPPORTS

如果當前存在事務，則加入該事務；如果當前沒有事務，則以非事務的方式繼續運行。

06、 PROPAGATION_NOT_SUPPORTED

以非事務方式運行，如果當前存在事務，則把當前事務掛起。

07、 PROPAGATION_NEVER

以非事務方式運行，如果當前存在事務，則拋出異常。

3、4、5、6、7 這 5 種事務傳播方式不常用，了解即可。

前面我們已經了解了資料庫的事務隔離級別，再來理解 Spring 的事務隔離級別就容易多了。

TransactionDefinition 中一共定義了 5 種事務隔離級別：

通常情況下，我們採用默認的隔離級別 ISOLATION_DEFAULT 就可以了，也就是交給資料庫來決定，可以通過 SELECT @@transaction_isolation; 命令來查看 MySql 的默認隔離級別，結果為 REPEATABLE-READ，也就是可重復讀。

事務超時，也就是指一個事務所允許執行的最長時間，如果在超時時間內還沒有完成的話，就自動回滾。

假如事務的執行時間格外的長，由於事務涉及到對資料庫的鎖定，就會導致長時間運行的事務佔用資料庫資源。

如果一個事務只是對資料庫執行讀操作，那麼該資料庫就可以利用事務的只讀屬性，採取優化措施，適用於多條資料庫查詢操作中。

這是因為 MySql（innodb）默認對每一個連接都啟用了 autocommit 模式，在該模式下，每一個發送到 MySql 伺服器的 SQL 語句都會在一個單獨的事務中進行處理，執行結束後會自動提交事務。

那如果我們給方法加上了 @Transactional 註解，那這個方法中所有的 SQL 都會放在一個事務里。否則，每條 SQL 都會單獨開啟一個事務，中間被其他事務修改了數據，都會實時讀取到。

有些情況下，當一次執行多條查詢語句時，需要保證數據一致性時，就需要啟用事務支持。否則上一條 SQL 查詢後，被其他用戶改變了數據，那麼下一個 SQL 查詢可能就會出現不一致的狀態。

默認情況下，事務只在出現運行時異常（Runtime Exception）時回滾，以及 Error，出現檢查異常（checked exception，需要主動捕獲處理或者向上拋出）時不回滾。

如果你想要回滾特定的異常類型的話，可以這樣設置：

以前，我們需要通過 XML 配置 Spring 來託管事務，有了 Spring Boot 之後，一切就變得更加簡單了，只需要在業務層添加事務註解（ @Transactional ）就可以快速開啟事務。

也就是說，我們只需要把焦點放在 @Transactional 註解上就可以了。

雖然 @Transactional 註解源碼中定義了很多屬性，但大多數時候，我都是採用默認配置，當然了，如果需要自定義的話，前面也都說明過了。

1）要在 public 方法上使用，在類的computeTransactionAttribute方法中有個判斷，如果目標方法不是public，則TransactionAttribute返回null，即不支持事務。

2）避免同一個類中調用 @Transactional 註解的方法，這樣會導致事務失效。

在測試之前，我們先把 Spring Boot 默認的日誌級別 info 調整為 debug，在 application.yml 文件中 修改：

然後，來看修改之前查到的數據：

開搞。在控制器中添加一個 update 介面，准備修改數據，打算把沉默王二的狗腿子修改為沉默王二的狗腿：

在 Service 中為方法加上 @Transactional 註解並拋出運行時異常：

按照我們的預期，當執行 save 保存數據後，因為出現了異常，所以事務要回滾。所以數據不會被修改。

在瀏覽器中輸入 http://localhost:8080/user/update 進行測試，注意查看日誌，可以確認事務起效了。

當我們把事務去掉，同樣拋出異常：

再次執行，發現雖然程序報錯了，但數據卻被更新了。

這也間接地證明，我們的 @Transactional 事務起效了。

看到這，是不是就明白為什麼新同事的優化純屬畫蛇添足/卵用了吧？

⑵ 程序員是如何看待始祖代碼的

就只是看看，不能改。有時候看到一些奇怪的邏輯，不要慌張，這裡面一定有一個很長的故事。

⑶ 軟體開發公司如何帶新人

1 給新人制定學習成長目標
新人剛畢業，都會急切的想證明自己，我剛畢業的時候也是這樣的。希望急切的進入到項目中。但成長是一個循序漸進的過程。比如制定成長目標：能夠獨立的承擔系統的設計任務。包括前端，資料庫，等等。制定一個月目標；三個月目標；半年目標；一年目標等等。
2 新人的目標需要細化與量化
新人剛畢業，需要學習的東西有很多，但是又很迷茫，需要學習的東西太多了，不知道那些是對工作有用的。這個時候，師傅需要給新人指點一些。將新人的需要學習的目標，細化到周為單位.
3 給新人的學習需要定時的檢查與指導
新人最近學習的怎麼樣了？學習的時候有沒有遇到什麼困難？這個需要及時的和新人進行溝通和交流。
4 review新人寫的代碼，這點很重要
如果學習的過程中，新人也參與到項目的開發。那麼需要review新人寫代碼。我在用smart svn中review新人寫的代碼的時候，就會發現新人在開發項目的時候，他們會犯一些自己不容易發現的問題。他們認為自己的代碼寫的沒有問題，但老人一讀就會發現，他們代碼在效率，可讀性，擴展性等，都會有很大的問題，需要及時指導。（師傅應該在早期時間內，對徒弟的代碼應該抱有一種懷疑的態度，如果剛開始就很信任，那麼代碼上線後，有可能你就會等著哭吧。。。）
5 讓新人去獨當一面
新人學習到一定階段，他有自信可以完成任務之後，可以嘗試讓他負責一個項目的所有過程。只有實戰才是檢驗他學習的成果。實戰後，他也會發現自己哪些欠缺，然後及時充電。
5 演示與練習相結合
模仿是最快速的入門學習方法。
當新人看了一定的技術書籍後，新人肯定特別希望能夠做出東西，但是也不能著急；這時候師傅可以演示一個表的增，刪，改查的操作；然後讓
新人按照這個例子去練習；然後再逐漸加深難度的演示。
7 思想境界的提高才是王道
對新人技術與技能提高只是方式和方法問題。但是我個人覺得思想境界的提高才是王道。比如輸送程序員的基本素養，公司的企業文化，程序員遇到復雜問題的心態，程序員對項目負責等等。（這方面我一直在思考這個問題，自己感覺做的也不是特別好，今後要加強。。。）

⑷ 為什麼老程序員的效率如此高

程序員老師傅的解決問題能力要比初級甚至是普通的程序員都要高出很多倍，所以每個軟體公司都會在保留1,2個經驗豐富的資深級軟體工程師，這樣在遇到項目或者產品難點的時候能夠力挽狂瀾，這種水準的程序員也是很多公司追求的對象，而且和年齡沒有太直接的關系，編程最終的就是給出解決問題的方案，從解決問題的角度出發解決方案還是非常多，但是在不同的人會給出不同的解決方案，但是有經驗的程序員在解決問題的時候就會思考的比較多，不容易導致引入新的問題。

編程能力最直接的表現不是寫代碼的能力，因為隨著時間的推移時間積累夠了代碼能力自然就上去了，很多程序員在工作多年之後雖然代碼能力得到極大的提升，但是還是不具備獨立的框架或者功能復雜的模塊設計能力，所以很多人在工作多年之後工資一直不能得到上漲，這是主要原因編程的關鍵還是思路問題，關鍵點還是在於有正確的解決問題的思路，思路的切實性是需要經過項目實戰的積累。

所以優秀的程序員一定是身經百戰的經歷過項目的洗禮，只有經歷過項目才能真正意義上懂得編程是怎麼回事，而且每次經歷的項目都能夠獲取足夠多的營養出來，越是優秀的程序員經歷過項目之後知識體系構建越是完善，越是老程序員越是覺得程序深奧之初，所以老程序員輕易不動手都會思前想後把事情搞明白之後才去真正動手，所以講老程序員真正動手寫代碼的時間還是非常短，大部分的時間都是在構思其可行性，真正動手的時間會非常短所以大家看到老程序員大部分的時間都是在看代碼或者看一些資料，甚至有些人很少看到老程序員在大塊的時間寫代碼。

越是老程序員對於編程語法看的越是淡薄，編程語言到了一定層面就是工具般的存在，就是為了編程思想服務，如果還在為了編程功能實現代碼而煩惱證明了還在初級的學習階段，度過了這個階段之後就要考慮如何駕馭架構以及如何錘煉自己的編程思想了，編程的學習過程是需要循序漸進的不要覺得距離自己老程序員有非常遙遠的距離，從開始入行就要慢慢去積累不斷打磨自己的思想，希望能幫到你。

25年老程序員，20年CTO，來解答一下：

1、經驗、教訓使然，所謂虧吃多了，也就不吃虧了。

2、長久工作，養成了一定良好的習慣。

3、代碼量到一定程度，自然而然會更熟練。

4、一些非技術的經驗知識，還是需要時間來積累。

5、老程序員的思維經過多年的訓練，更有利於直達本質。

6、他們的方案可行性更高，這樣減少返工。

7、代碼質量高，測試通過率高，考慮的因素更周全。

8、代碼改起來更容易，找問題也相對容易。

9、對任務的理解更全面，能夠從更多的角度去設計程序，權衡效率、速度、性能、擴展性等各方面的因素。

10、也不是所有的老程序員都能這樣，這個還是跟這人的學習能力有關系，所以大家是能3年變成老程序員，還是10年，就看自己的個人努力了。

在IT編程開發的過程中，老程序員開發的效率會非常高。比如：一個網站模板，新程序員可能要花上一個星期的時間才可以完成，而老程序員卻可能只需要1-2天就可以做好。這是為什麼？莫非他們天生就有神相助。非也，這所以會這樣，據我分析，主要有以下幾點。

因為長期的編寫代碼，所以，會碰到非常多的問題，然後就會去解決這些問題，這就讓老程序員有了豐富的實戰經驗。反觀新程序員，碰到一個問題，因為以前沒碰到過，所以要花大量時間去解決。而老程序員碰到問題，因為以前解決過，所以，很快就會弄好。

在IT編程中，很多的代碼都是可以用來搬運的。因為長期的工作，老程序員會把一些功能代碼記錄或儲存下來，以備後期使用。也就是說，他們就像記筆記一樣，把一些功能代碼記下來，以備不時之需。所以，在新的編程中需要用到時，他們就可以直接拿來就用，自然效率就高，開發就快。

老程序員在編寫代碼時，一般都會對代碼的規范和格式比較重視，使用代碼清晰有條理，閱讀代碼時就不費力氣，而且還會做好每個功能代碼的注釋。這樣，不管是對現有開發，還是對後期維護，都是非常有利的。如有代碼出現bug，可以很容易地找到，這同樣節省了大量的時間。

老程序員在編寫代碼時，會先從大處著手，把大的框架給弄好，然後，再對整個編程的細節有針對性地編寫。這就好比開發一個高樓大廈，開發商會先把主體框架搭建好，然後，再一層一層地去弄每一層樓的細節。這樣，往往目標會更加清晰，只要按步就班地執行計劃，就可以很快完工。

熟能生巧

為什麼老程序員的效率如此高？

首先， 敲代碼的效率 != 工作效率

並不是老程序員效率就高，而是程序員要提高效率需要一些方法，這些 方法的學習和掌握需要一定的時間 ，結果就是老程序員的效率會相對要高一些。

我經常會看到一些新手程序員在寫代碼的時候需要頻繁的去查看文檔或者是網路搜索各種介面的用法，有時寫一個功能要查個幾十次，很多時間都浪費在了搜索上，真的寫代碼的時間很少。

而一個在這門語言浸淫了幾年甚至是十幾年的程序員，對這些介面瞭若指掌，使用的時候信手拈來，還知道介面裡面的實現機制，可能會碰到哪些坑也一清二楚，減少了很多bug的出現。

你是不是有把那些介面拿出來反復琢磨，去研究它的源碼，認真地了解它呢？

工欲善其事，必先利其器。

一個好的編程工具有很多可以幫助程序員減少工作量的功能，比如代碼重構、自動格式化、語法檢查、代碼提示和補完等等，掌握這些也能大大提高開發效率。

隨著IDE的發展和進步，現在很多工具都不需要太復雜的學習就可以操作，所以這個是一個投入小而回報很高的事。

代碼是為業務服務的，我們首先得理清楚業務邏輯，才能知道要怎麼寫代碼，而新手對業務不熟悉的時候，光是弄明白業務需求是什麼可能都需要不少時間，有時候還可能會錯誤理解需求，導致寫出的代碼文不對題，只能重寫。

所以多思考，多問，多討論，不會花太多時間卻會減少很多時間的浪費。

寫出來的代碼還需要經過測試，如果有bug就需要調試了。

很多新手只重視寫代碼的工作，對於怎麼調試卻忽略了，有的人甚至只會使用列印功能一步步通過排查找bug，並且對寫出來的代碼沒有概念，連bug大概可能在什麼地方也不清楚。

老練的程序員不只是靠列印，有時候只看報錯信息就能知道bug大概在什麼位置，配合上列印還有斷點功能很快就可以找到bug的位置，更不要說他們很清楚怎麼寫出容易調試的代碼。他們會在寫代碼的時候就對可能出問題的邊界條件進行檢查，並且會利用自動化測試來減少工作量。

新手很容易犯的一個錯誤就是拿到功能需求馬上就開始寫代碼，可能寫到一半會發現前面的代碼有問題需要推翻重來，或者是寫錯了方向。

老程序員寫代碼之前會先進行構思，把功能需求拆解，分成不同的小模塊，甚至會在紙上把這些想法畫下來，基本上在這一步就把問題已經解決了，寫代碼只是把解決方案用代碼表達出來而已。

所以，如果你也想做一個十倍程序員，記得不要只是埋頭寫代碼，還要刻意去練習這些提高效率的好方法！

在寫代碼前，代碼差不多已經刻在腦子里了，寫代碼的時候，總覺得雙手敲鍵盤的速度趕不上腦子的速度，寫出的代碼幾乎不需要調試，你說效率高不高？

因為老程序員經歷多了，一些常規性的BUG基本不會出現，對用戶需求也能做到最大的完善，還有對需求增加和修改有個大概了解，會提前預留介面和模塊，還有對用戶的硬體有了解，在程序上會有相對優化。所以老程序員寫的程序不一定美觀，也不一定最簡化，但是可能是最合適的，可惜中國的程序員剛成熟就要面臨失業。年輕的程序員啥都不懂，片面追求性能，美觀簡潔的程序，在兼容性和實用性上大打折扣，不顧用戶的使用情況和硬體情況，項目一上線問題多。

老程序員分為兩種，一種是年紀老，常常被換做「老X」，一種是能力老，常被人換做「x老師」。

老程序員之所以效率高，離不開幾點：

程序員是一份高強度的腦力工作，能成為老程序員者，智力，體力無一不是同齡人中佼佼者。能夠更加效率的工作自然是理所應當，方符合家有一老，如有一寶的普世價值。

祝廣大碼農早日修煉成為這樣的老程序員。

老程序員，碼代碼速度並不見得比年輕人快。但老程序再面對需求時，能很快抓住技術關鍵點，難點，重點，如何突破都瞭然於胸。當出現問題，老程序員有經過實踐的診斷定位排錯的邏輯思路與手段 。其實這些熟能生巧是一方面，學習與實踐 領悟是另外的方面。年輕人觀察能力強 悟性高，也會青出於藍

老成員就是圖書館，硬碟存滿了各種經過調試且運行過的程序，只需要復制粘貼，效率肯定高

⑸ 程序員在上班時，允不允許大量的看說明文檔來幫助寫程序

程序員日常開發工作，基本是上離不開閱讀文檔，這也是很多程序員喜歡兩個顯示器的原因。

項目方面

技術方面
是不是很多人都認為，如果在開發過程中，還要不斷地翻技術文檔，說明他的開發能力不扎實。其實不是這樣的。

首先IT行業技術升級換代的速度太快，當我們大多數公司還在用Java8的時候，Java11都已經出來了。如果非得要程序員熟知每一個類、每一個方法，是很不現實的。

很多時候我們只需要了解有這么一個東西，作用是干什麼的，具體的細節可以在用的時候再去翻文檔，比如方法名字是什麼？參數有幾個，都是什麼類型的？

所以我們都習慣至少兩個電腦屏幕，一個屏幕寫代碼，一個屏幕看文檔；如果豪一些的話，再加一個屏幕展示日誌信息。

看文檔的屏幕要買豎屏！

我們團隊
我這幾年也帶過幾個團隊，對於每個團隊成員，我對他們的要求是：實現需求的前提下，最好能對所用的技術有一定的了解，千萬不要從網上抄過來一段代碼就用，這樣是很危險的行為。所以鼓勵大家多找一些資料，最好是閱讀框架的官方文檔。

現在的團隊，我已經這樣要求了：代碼寫累了，或者覺得自己沒有狀態寫代碼，可以找點兒自己有興趣的技術文檔學習學習，這個技術甚至是可以跟現在的項目沒有關系的。

首先，我不是程序員，我是一個設計工作者，不過我來說一下我的觀點：很多人以為程序員像電影里的一樣，啪啪啪幾下鍵盤，屏幕數據颼颼的變，其實真實情況是程序員寫代碼就像學生寫作文，也會遇到不會的詞語跟修辭手法，那這個時候就要停下來想一想，查一查，看看例子是怎樣寫的怎樣用的，寫錯了還要劃掉（刪掉）再來，至於這個大量不大量看的情況，如果這個是個新手，那肯定是可以的，那如果是個老手，還需要大量時間查說明文檔，那就說明這個項目肯定不會小，不是一兩天能做完的，那一個用月做單位的項目，用一個天做單位的時間來查文檔，不過分吧！程序員也是人，不是因為他的工作高端，就覺得這個人萬能，他也會當機，要吃飯，要休息，也會忘記一些東西，所以請各位多多體諒，能一起工作實屬不易，感恩2018，謝謝。

這個問題怎麼說呢，開發過程中會遇到各種各樣的問題，沒有一個人是全能的，也沒有人可以絕對的說自己在整個項目中不會遇到一點問題，不去查東西，自己大腦里的東西完全可以讓我把這個項目測測底底的做完，並且沒有任何bug。

上班的時間，也沒有老闆或者誰在後面一直看著你去做東西，大家都挺忙。文檔是幹嘛的，文檔本身就是用來看的，甚至很多項目開始之前，總監都會讓你去搜集一些這個項目可能會遇到的bug，可能會用到的效果，盡量在之前找到比較好用的插件，這樣會節省很多時間，自己如果寫代碼的話不可能百分百的確定沒有人和bug，但插件不一樣很多插件都是前輩通過很長時間慢慢完善出來的插件，所以很多人才會用。所以你提問的可以肯定的回答你允許。

程序員上班的主要工作就是看說明文檔，根據說明文檔編碼。如果實在沒有說明文檔，有時還得親自披掛上陣寫說明文檔。

寫介面的有API文檔，寫通訊協議的有協議欄位說明文檔，寫資料庫的有資料庫規範文檔，

總之任何一個大公司文檔扮演的一個至關重要的問題，因為形不成文檔，公司管理就會陷入混亂不堪的局面，當某個核心員工離職後，下一個接盤的程序員會丈二和尚摸不著頭腦，一頭霧水，邊填坑邊罵娘，有了文檔就可以看文檔結合代碼，了解其中模塊邏輯以及結構，包括哪些坑不能踩等等好處。有些公司會專門有文檔工程師這個職位來專門負責整理各種文檔，並且保存在伺服器上。

好的文檔都是程序員等人智慧的結晶，是一盞指路明燈，是一條通往光明的道路。程序員不能看說明文檔等於在黑暗裡摸爬滾打，有了說明文檔才迎來了黎明的曙光。

說個我遇到的2個真事吧，

第一個，公司找的外包公司寫項目程序，已經要交付了，發現有幾個功能沒做，產品經理和開發那邊都找我，我一個搞運維的又不懂，只能讓他們去對開發文檔，我也就順便看了看，開發文檔中明確的寫明怎麼做，然後就讓他們就重新按開發文檔繼續寫，

另一個，由於 歷史 原因業務系統處於託管狀態，只有部分參考文檔可用，開發那邊只能按當前已有文檔進行開發參考，開發那邊也一直在根據現有相關文檔進行開發，杯具的是這幫子不仔細看，有問題總想著我能直接給他們答案，我也只是會用而已，開發我還真搞不來，然後和他們一起看開發文檔，加密演算法部分給她們指出後，問題解決了。

所以我覺得，開發團隊在開發中很有必要閱讀開發文檔，這可以避免繞圈子，也會清楚開發文檔中提供的內容。

先說觀點，我認為看文檔沒什麼問題，但是「大量」這個程度很難衡量，按照需要看文檔是個非常重要的事情。
需要花費時間的情況 不需要花費大量時間的情況 小結
在工作中閱讀文檔其實也是工作內容的一部分，而且現在大多數互聯網公司都靠KPI進行考核，平時就算你把時間都用來看文檔沒關系，最後KPI沒完成一樣會被公司淘汰。所以公司不會阻攔你花費時間看文檔，最多你老闆會提醒你浪費這么多時間看文檔而沒有實際的產出會對你年終考核造成影響罷了。

題主對文檔的定義不是很明確
第一個是需求說明文檔
這個是在開發過程中必不可少的文檔，只有清楚了開發需求，程序員高效率的開發，程序員一天的工作時間並不是都是在寫代碼，而是在看文檔，了解需求，理清思路，只有什麼都清楚了，寫代碼或許只要十幾分鍾。

再者對於一個項目新人來說不看文檔了解需求，沒人給你從頭到尾的在講一遍需求，你不看文檔自己發揮？進入項目是和別人共同開發，你不肯能不顧及之前的代碼規范。
第二個是開發文檔
就拿微信開發來說，微信開發不是每個程序員必須會的東西，但是用到了怎麼辦，還不是去看他們的開發文檔，只有將開發文檔思路理清楚了，才可以進行下一步開發。
第三個是API文檔
在前後端分離的開發模式中API文檔是必不可少的文檔。不看API不知道數據是什麼樣。也就是不可能順利的和後端進行結合。

兄dei，假設你是程序員，你在寫程序時，旁邊會有人守著你嗎？

假設你不是程序員，你在做本職工作時，旁邊會有人守著你看你怎麼做事嗎？

答案肯定是沒有的。誰會閑著招個人去監督你，看你用什麼方式去完成給你的任務。

所以，其實你看不看大量文檔，沒有人會在乎，關鍵是你自己，建議自己寫東西時，不要一味的復制粘貼，要有自己的想法。太依賴文檔對於自己成長很不利

當然允許看文檔。

要知道，隨便哪個類庫，都有無數的類和方法，每個方法又有若干參數，鬼知道它們都是什麼意思，誰的腦子能記得那麼多內容。別說是人家提供的類庫，就是自己寫的代碼，過一段時間也不記得什麼意思了。沒有注釋和文檔，怎麼看懂代碼？

如果沒有需求分析文檔，程序員怎麼理解正在開發的這個軟體的基本業務流程？

如果沒有架構設計文檔，程序員怎麼理解軟體各個功能模塊之間的功能與業務邏輯？

如果沒有介面文檔，那麼多類和方法，都怎麼調用，會返回什麼值，難道靠猜？

……

在日常開發工作中，不僅允許看文檔，還會強迫你寫文檔。如果你寫的文檔別人看不懂，別怪領導罵你不認真。文檔對於軟體開發的重要性是不言而喻的。

還有一個秘密告訴你，那些經常寫文檔的程序員，要比不寫文檔的程序員工資更高。

真的！！！

迎娶白富美，從會寫文檔開始！

這個問題要根據具體開發的功能模塊來看，不過原則來說，花大量的時間看說明文檔，至少給人的印象是經驗不夠豐富，開發能力有待提高。

具體來說，如果是普通的功能開發，技術挑戰不大，這種如果還要看文檔，會被認為是開發能力問題。如果是有一定的技術挑戰，公司在這方面的積累比較少，開發團隊也對此有共識，這種問題看文檔無可厚非，當然如果能業余時間學習相關的知識，會給團隊留下開發能力強的印象。對於一些前瞻性研究，公司沒有任何技術積累，或者全新的技術方向，這個看說明文檔是加分的，甚至可以要求公司購買相關書籍或者在線培訓，當然，自己啃下來會更NB。

⑹ 剛入職的java程序員新人在公司已經看了兩個禮拜的代碼了

不能指望有人手把手的帶你，你要自己學習，有不懂的網上都可以搜到，實在不行搭個老學員請教怎麼學習，程序員沒有自己學習的能力是不行的，雖然你底子不咋樣，但有人發著工資養你你還不學，要怎麼學呢？覺得你不行會開你的，你也不會有什麼損失。我在動力節點學五個月底子比較好，沒有遇到你說的情況，你要是底子實在差可以也去一下，聽深圳有新校區了。

⑺ 我是新入職的java程序員快一個月了,還感覺什麼都不會,怎麼辦，經理一天就叫我看需求，看代碼

還要提一句的是，你在建立SSM的進程中，可能會常常接觸到一個叫maven的東西。這個東西也是你往後作業傍邊幾乎是有必要要運用的東西，所以你在建立SSM的進程中，也能夠趁便了解一下maven的常識。 動力節點咨詢一下，現在深圳有個新校區，

⑻ IT公司的項目組入職了新的程序員，如何帶好這些新員工

不少軟體開發團隊每年都有新的開發人員要加入，其中以初級程序員居多，要想讓這些初級程序員能夠快速融入開發團隊並實現價值，需要從以下三個方面入手：

第一：以開發實踐能力進行人員劃分。 新入項目組的准程序員往往有兩種情況，一種情況是剛剛走出大學校門的計算機專業畢業生，另一種情況是自主學習通過面試的非計算機專業畢業生。這兩種准程序員在進入崗位之前可以根據實踐能力進行人員劃分，實踐能力較強的可以直接安排進項目組中，而實踐能力較差的准程序員則安排到實習崗位上。按照 歷史 經驗來看，不少實踐能力較差的程序員如果直接安排到開發崗位上，往往會導致其放棄這份工作。

第二：老帶新。 按照 歷史 經驗來看，讓程序員快速成長的方式無非就是通過實際項目的鍛煉，對於學習能力較強的程序員來說，如果有專人指導的情況下會很快融入到開發團隊中，有的程序員在一個月之內就可以完成功能模塊的開發。老帶新的原則有三點，其一是軟體開發團隊所使用的技術結構要交代清楚；其二是軟體開發過程中所使用的開發工具和開發流程要交代清楚；其三是給出具體的參考案例。

第三：安排清晰的工作任務。 對於初入項目組的開發人員來說，由於其自身的專業知識積累還比較少，在項目理解力上還有待提高，所以在安排具體開發任務的時候一定要詳細，越詳細越好，同時要給出明確的功能邊界，防止出現不可控的事情發生，比如哪些數據是不能動的，哪些功能和資源是不能調用的等等。有的時候「無知」是最可怕的敵人，不少初級程序員進行的「刪庫」等操作都是在「實驗」的心態下完成的。

如果有互聯網、大數據、人工智慧等方面的問題，或者是考研方面的問題，都可以在評論區留言！

我是程序員出身，現在也管理著一個項目，手下最多的時候也有十幾號人；但是說實話，在管理方面，我還是比較欠缺的，我也一直在學習和摸索；當項目組入職了新的程序員的話，我經常會這樣做：
先溝通，大方向要保持統一
每當項目組入職了新的程序員，我會第一時間和他們溝通，主要讓對方快速地知曉項目的基本信息，並了解我們大的方向、觀點、風格，我是希望在某些地方能和組員保持一致，例如：

制定計劃
下面就要給新人制定計劃了，這一點在前期很重要，否則新人就會面臨無事可做的尷尬；

安排開發任務
通常，我們一兩周後就會給新人安排一些開發任務，當然這個過程也是從易到難：

代碼檢查
對於新人，代碼檢查一定要做；如果是工作時間段的新人，每一行代碼都檢查一遍都不為過。

最後，我會給新人一些成長方面的建議，讓他們覺得在這個項目中能學到東西；畢竟我沒有權利給他們漲工資，只能通過這種方式留住員工了。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

建議從以下幾方面考慮：

1、人員能力考查和培養。人員的能力參差不齊，需要根據崗位進行有目標的培養；

2、業務技能提升。想把工作做好，不了解業務，不理解自己做的東西，早晚要出現與預期偏差較大的情況。

3、工作態度和心態的培養。

4、盡早了解項目內容和項目團隊，將人員在項目中的定位和需要的技術提前告知，告知項目計劃和提示工作的難點。

5、組織一點團隊活動，早點融入項目。

第一：熟悉你們開發工具、開發環境、運營環境……

第二：熟悉上下開發工序對接組別和責任人……比如開發該項目的前端、後台、測試等不同組別以及其他開發外項目組外的不同部門打交道的人員。

第三：項目說明書、整體功能、進程，所負責的分割模塊……要完完全全提供出來。
每個人都是從新人成長過來的，在我工作的五年間也帶過很多新人，最近剛好有個畢業生來公司實習，領導讓我帶，這邊就分享一下我具體是怎麼操作的(開發的角度):
總而言之，帶新人還是比較累的，對大部分公司而言，技術要求並不是很高，所以新人真的比較難上手的不是技術，而是業務和表結構邏輯的不熟悉，作為新人，公司的打算就是從零開始培養，因此基礎並不是最重要的，學習的態度才是公司看重的。

以上為個人觀點，歡迎在評論中發表自己不同的觀點，喜歡的加個關注，謝謝。

以十人以下的團隊來說一下。首先是和員工相處好，其實這一點做到並不難，就是正常的相處，怎麼愉快怎麼來（當然不能壞規矩）。我做的最大尺度一次是這樣：有個畢業生干著干著就哭了，一問之後知道直接原因是程序員的工作內容和自己原來想的不一樣，主要原因是剛到北京體會到了巨大的壓力。當時我就拉著她到對面肯德基去坐會了，點了飲料和薯條，聊了一下，順便開導開導她，舒緩一下情緒，這事就這么解決了。其次，作為領導請安排劃分好工作內容，不要頻繁變更，否則影響威望值。這也是保證工作可以順利開展的基礎。安排工作時請考慮員工的能力和經驗，還要考慮員工的興趣，這點也很重要，很大程度影響積極性。

在小團隊中只要工作能順利完成了，一般問題就不會很大了。其它：可以觀察一下每個人的喜好，然後看機會適度的介紹這方面的內容。比如我就專門給一個員工培訓過數據結構，而她也很願意介紹自己認識的人來工作，雙贏的結果。員工做好的地方及時表揚，自己做錯的地方及時承擔責任，等等。總之將心比心的對待員工，小團隊還是好帶的。

教會徒弟，餓死師傅，等你教會他們，你就該退了，理由：你三十多，奔四了，負擔大，不能加班，養不起你！中國現狀，保留必要絕活，留幾招吧！為養家！

先讓他做點小項目，鍛煉一下，把以前已經完成客戶的項目拿出來給他做，練手，看看功底如何

如果功底好，則主要鍛煉他的思維能力

如果功底不好則多鍛煉他的技能

首先是能力要過關，之後就是交流要能順暢，其他的問題都不是問題，只是經驗和熟悉而已。

⑼ 有哪些老程序員都知道對新手很有用的經驗

一說到程序員，想必大家的第一印象就是頭發少，很大程度上就是因為壓力大導致的，有生活壓力，也有工作壓力。

今天說說工作方面的壓力，想必看到這個問題的小夥伴都有一個認知，就是一個項目往往比預期的要長，說不定從哪天開始就加班了，一出現BUG真的要人命。此時，考研新老選手心態的時候和經驗的時候了，老程序員或許能從容應對，新手可能完全不知錯所。

七、個人信息一定要保管好

這些信息包括戶口檔案、社保、公積金等信息，程序員新手可能跳槽比較頻繁，有人甚至還換個城市工作。除了戶口可能其他的信息都亂了，可能當時覺得不那麼重要，但是十年、二十年後，可能會非常重要。

八、幾條名言

·工作日誌可以提升腦容量；

·不要先寫框架再寫實現，要反過來；

·重構/優化/修復Bug，不要同時做；

·簡化開發流程，加快迭代速度；

·紙筆是最好的工具，其次是markdown；

·畫出結果，一目瞭然。

·首選明文文本，二進制、加密、壓縮等到時候再加；

·要學會進行清晰的命名；

·問問題前先調查，要問到點上。

·不要小看程序員