程序員對自己開發出來的功能都不甚了解這個在業內是正常的嘛？？
程序員對自己開發出來的功能都不甚了解這個在業內是正常的嘛？因為我一問安卓某某頁面上呈現的數據在什麼時候有+1，什麼時候清零？他給我的答覆 我不知道，這個你需要問後台，數據是從後台傳過來的！要不然就是要我問產品經理，還有的開發居然說我也不知道，都是按照產品經理來的！這，就是目前我司程序員的表現 我想知道這個正不正常在業內？？對自己開發出來的產品邏輯都不清楚？？？
實名撕一下 @暗滅
實在想不到，在知乎這麼一個程序員的大本營里，居然有程序員敢如此把無知當成水平高的表現。
看看他的行文
你覺得你做不到，那是你的問題。我覺得一個程序員要做到，而且必須做到這一點，做不到就是渣渣，這是我的想法。
我帶Team的時候，說的最多的一句話就是，別跟我扯什麼前後端的問題，Demo沒通過，東西沒做好，整個Team一塊背鍋，一個都少不了。不要跟自己說，這不是我的問題，這是別人的問題。記著每一個工程師的責任都是保證自己的產品是一個可用的，好用的產品。記著要至少測試100遍，實打實的100遍去測試。每天都在測試，一個Story一個Story的去做。不要全部做完再全部調介面，不要全部做完再全部調介面。如果你不懂業務邏輯，不懂為什麼這麼做，為什麼這麼設計，如果不是對業務邏輯理解的透徹並且認可這種做法，不要去做開發。
乍一看，好有道理，好有進取心，好有責任心。這真是一個好上進的好程序員，我們做不到的實在是渣渣呀。哈哈哈，我真想大笑三聲，這一股濃濃的雞湯味，怎麼這麼眼熟。@暗滅，你確定你不是段子手，而是程序員嗎？是不是在微信灌雞湯文灌多了，跑知乎來灌了。
哪個程序員渣不服氣的，反對的，隨時歡迎反對+沒有幫助+舉報。但是，在我眼裡，你們就是程序渣，從頭到尾的混子，無論做什麼行業，做什麼內容，都是渣渣。
我要吐了，這一看就是從沒團隊合作經驗的人，編了一套雞湯文來知乎博眼球來了。一個程序員能夠把前端後端一肩挑，這不是什麼稀奇的事，但這有兩個條件，第一，這個項目只有一個程序員，第二，這是一個小項目。請注意，二人以上的團隊，請務必學會分工。
任何人都有體會，如果專註於一件事情，那麼就會進度很快，如果不時的分心做別的事，做事的效率就會極差。
亞當斯密的國富論里，描述了這樣的一個場景，製作一個扣針需要18個步驟，如果分工合作，十個工人每日就可成針四萬八千枚。而不分工合作，每個人都獨立合作，那末，他們不論是誰，絕對不能一日製造二十枚針，說不定一天連一枚針也製造不出來。他們不但不能制出今日由適當分工合作而製成的數量的二百四十分之一，就連這數量的四千八百分之一，恐怕也製造不出來。
這就是我們為什麼要分工的理由。分工是保證工作效率的必須條件，前端的歸前端，後端的歸後端，哪怕你技術全能，也不要做任何你不該做的事。
在程序上這叫解耦。在工作上，我們同樣也需要解耦，每個人負責的模塊是獨立的，而不是和其它人高耦合的，這是一種先進的程序思想。如果耦合太高，未來更改需求時，程序員會想打死產品經理的。
此外，程序員的時間是很寶貴的，做為一個程序員，最討厭的應該就是重複工作，什麼測試一百遍的傻話扔一邊去。做為團隊，有專門的測試工程師，測試工程師會更了解如何尋找產品的bug。這也是分工的一部分，每個人做最擅長的，才是提高工作效率的最好辦法。
最後，回答題主的問題，這種情況，答不出是正常表現，換複雜點的項目，上百個介面，不翻文檔根本不知道這個介面幹啥的。更不用說介面的某個數據了。
--------------------------------------------------------------------------------------------------------------------
居然有更新了，哈哈，這是多不靠譜的項目，30%時間用來重構。話說，有程序員會每個項目都要重構嗎？你前面20%設計的時間是去夢遊了嗎？不過我很能理解，只有不懂解耦重要性的程序員寫的程序才需要不斷重構。還有，讀別人代碼時間呢？不讀代碼怎麼找錯？「在一個靠譜的項目里，20%的時間用來做設計，30%的時間來編碼，20%的時候來測試，30%的時候來重構。」
這個完全正常，而且可以說是刻意追求的這種效果，前台就是不應該了解這些東西。因為這樣可以保證前後端兩個部分之間是充分「解耦」的。
就拿你題目里的這個例子來說吧「某某頁面上呈現的數據在什麼時候有+1，什麼時候清零」對於前台來說，這個功能就是要麼顯示+1要麼清零，至於具體什麼時候做，等待指令，具體的邏輯是屏蔽掉的。因為如果他一旦去關心了後台功能的實現，就有可能不自覺的去針對具體的實現進行優化。有人說，優化不好么？有的時候確實是不好的。因為有可能會導致，兩部分之間的功能高度耦合。這樣的話，在需求頻繁變動的時候，你需要修改的部分就不是後端一處，而是前後端兩處了。因為前端優化過的部分有可能在新的需求下失效甚至崩潰。這樣不僅僅會帶來開發人員工作量的增加，連帶著還有版本的更新問題，因為伺服器端自己更新就可以了，然而客戶端卻需要用戶手動更新。那是不是在所有用戶更新到新的版本之前伺服器端要運行兩套邏輯呢？顯然這樣又有一致性的問題。等等等，會導致一系列的問題。以及還有溝通成本的增加（謝@徐澈提醒）。所以，前端的做法是沒問題的。這裡面有個關鍵信息：
題主不是PM。對數據呈現感興趣的，可能是運營人員。如果推斷成立，那麼題主你的確找錯了人，PM才是你需要找的對象。作為需求的提出方（之一），整理方和發布方，PM應當科學的將業務邏輯成立成可供開發使用的文檔（如果沒有或該部分缺失，應當詢問PM原因或進行補充），因此每個部分的業務邏輯PM都應當了解並形成參考文檔。當產品（功能）沉澱已久，追問起來各方可能都無法給出直接回答，查詢文檔是可以解決問題的。若是通過口頭相授提出的需求，也不能指望開發人員能夠追蹤到原委。
再如果因為種種原因導致PM缺席，題主也要知道程序員不是只有一種，不能籠統的認為只要是與開發相關的問題都可以找程序員，而且由於功能拆分，同一類型的程序員也會領取不同的開發任務。因此如果找錯了人，得到未知的答案也是意料之中的。這一點也是其他答案所提到的。
最後，題主你實際上提了一個偽問題，那就是：功能不是『程序員自己』開發出來的，而是基於需求開發出來的。= =後台功能前台當然不知道了，你要講道理好伐
對前台來說，這個功能就是，他說+1的時候+1，他說清零就清零，遠程控制的好伐就算你電腦開著遠程協助，你自己也不知道滑鼠啥時候動了好伐自己去問後台開發不就好了所以說，其實是你自己不懂邏輯別說編程了，我上星期寫的ppt，這星期就不知道是什麼了
假設，你想跟我們訂製一台電腦，最簡單情況，電腦分成主機和顯示器。我們團隊有三個人，並非一起製造主機，再一起製造顯示器，再一起製造連接線。而是分工的，我去製造顯示器，同事A製造主機，同事B製造連接線。三部分製造完整，把所有的連接在一起，一台電腦就造好了。
現在，我把電腦給你，你如果問我，顯示器的工作邏輯，如何顯示紅色，如何顯示綠色，我一定會清楚的告訴你，因為顯示器是我做的，我必須清楚，不然就是矇騙。但是你現在問我，什麼時候顯示紅色，什麼時候顯示綠色，顯然我是不知道的。因為我不管什麼時候顯示，數據線傳來的是紅色，我就顯示紅色，至於什麼時候數據線會傳來紅色，那得問製造主機的那個人。製造主機的是同事A。
這時候，我就是前台，同事A是後台。如果現在還不明白，沒關係，等你成功轉成研發，客戶對你咆哮的時候再回來看這個答案。正常，也不正常。具體正不正常要看開多少工資。
從題主的問題來看，題主很可能是運營或者商務。首先，商務或者運營跳過產品去找開發，本身就是對項目非常不利的一件事。因為基礎開發並不知道整體的項目進展和排期，所以對運營和商務提出的建議無法給出響應，其次，開發往往很好說話，這也是為什麼運行和商務喜歡找開發直接溝通但是公司又往往禁止溝通的原因。因為開發一旦聽從建議，私自修改內容，會導致一系列的問題，比如測試因為結果和文檔不一致無法測試，開發對需求理解錯誤產生的糾紛，私自調整內容導致的延期，等等。另外，前端開發不動數據產生的邏輯，這很正常。在整個系統中，每個人的職責就是做好自己的模塊，把別人開發的所有內容視為絕對正確的的黑盒子，給一個指定的輸入，就產生相應的輸出，除了架構師之外，不需要關心別人的實現。這樣的好處是，降低了各個模塊之間的耦合，一旦某個模塊發生了變動，只要保證輸入輸出的介面沒有發生變化，就不需要更新其他的內容。這就好比你在用知乎，知乎只要不改變操作界面，對你來說，它內部的調整，比如加了台伺服器之類的，這種改動並不影響你的操作。另外，在項目出現問題是，也比較方便定位和判定責任。再則，開發與開發之間的技術壁壘，還是很高的，不同職責，不同模塊的區別其實還是很大的，除了級個別的高級開發和架構師。基礎的研發要搞清楚其他模塊的技術細節，並沒有那麼容易。而且就算能搞明白，也沒時間去做。所以，綜上，如果需要了解系統的內部細節，請先找產品，然後由產品告訴你去找誰確認。如果找不到產品或者產品不給力，就找架構師。如果沒有架構師，請找研發總監，如果研發總監不清楚，那就問問開發，這個功能具體是誰實現的，然後去找實現的那個人。
仔細想了一下，大膽猜測下題主的想法：這是一個業務邏輯，而這個程序員則是負責這一塊的開發人員，按照道理，前端的開發應該熟悉這一個模塊的所有業務，最少能知其然。 但是呢，還是要從實際出發去看待事情。 1.這個+1的邏輯，既然放在的服務端，那麼產品這樣子定義肯定有他的理由，肯定不會白白消耗伺服器的資源，很有可能就是這個+1的邏輯是隨著業務的開展而變動的，而APP因為發布的繁瑣，一般是不會進行這種邏輯處理的。對於一個後台隨時會變動的邏輯，APP端真的有去了解當前邏輯的必要麼？ 2.加班是程序員被外界所知的最鮮明的特點之一，為什麼加班？因為工作量非常集中，一個版本的開發，流程一路走下來，開發總是最後一步（這裡測試沒有算作開發流程），假如前期設計費時較多，就是開發吃苦了。在這種背景下，一個只需要APP展示的欄位，不包含任何邏輯的處理，開發人員是不會去管你後台如何運作的，沒時間也沒必要，除非影響了後續本地代碼的邏輯。 其他的很多答主提到的各司其職，分工合作的觀點，本人也是很贊同的，他們說的很清楚，也就不用贅述了。 然後題主最後好像提到某些開發連自己的代碼的邏輯也不清楚，這個也還是要看情況的，首先，正處於開發周期時候，這個是必然不能出現的，不然就是不合格。然後，項目已完結後的一段時間，代碼邏輯是會被遺忘的，但是，經過閱讀代碼，也是能較快的理清自己的邏輯的（注釋齊全的話）。這時候假如開發做不到，要麼就是能力不行，要麼就是習慣不好（沒有做好注釋且定義方法類名時不規範）偏偏又邏輯複雜。
程序員的需求是根據產品經理的需求來開發的。不是程序員自己決定的。
所以難道不是程序員來問你業務邏輯嗎？業務文檔難道不是你來寫的嗎？
最後，不了解自己寫的功能當然不正常，但是不了解自己依賴的模塊/介面的內部邏輯很正常。你做個菜，你當然知道菜怎麼做，但是我問你醬油是怎麼做的，食材是怎麼運輸的，牛是怎麼屠宰的，你為什麼要知道？那不是你的事情。
你應該沒有技術背景，並且沒有任何一點虛心請教學習的態度，否則客戶端調用介面，客戶端與服務端邏輯分離這麼基本的事情，怎麼會不理解。客戶端只是展示交互。大部分複雜業，比如推薦列表怎麼排序，這個單子怎麼算價錢，都在服務端完成，客戶端不關心內部邏輯很正常，客戶端要的只是最終結果。如果人人必須都了解大工程的事無巨細的邏輯，那還要分工做什麼，要職位做什麼。
如果客戶端非要了解事無巨細的服務端細節才能工作，那你們的團隊一定非常糟糕了，沒有效率可言。
回答里有技術人員認為應該知道的，你大概沒有參與過大型項目吧。作為一個python新手後端程序員回答下你的問題吧。先說結論，功能不了解很正常，但是我覺得不應該這樣，程序員需要熟悉自己所做的業務。
不知道題主注意過一個現象沒有，就是很多程序員對技術問題比較關心，但是對公司業務不太在意，只是按照需求實現功能。我是後端程序員，每次做項目之前都是項目經理整理需求，然後有了需求文檔和我們對需求，之後我們再去設計實現。前端一般不太關心業務問題，因為業務邏輯一般是在後台實現，前端基本上就是對照原型圖做展示，調介面。後台的話就要對業務需求比較了解了，不然資料庫和介面沒法合理設計和實現。不知道你有沒有聽過一個詞叫做『領域驅動設計』，可以這麼說，幾乎所有的技術都是為了業務服務的，不然技術就沒了價值。但是程序員一般技術比較在行，一般涉及到產品開發就需要和相關領域的人打交道，熟悉領域知識和產品業務需求。很多人不關心公司業務，不關心產品，不關心盈利模式，實際上這才是和你工資直接掛鉤的東西。（我自己就因為需求不熟悉延誤過進度，naive。。。。。。）我看有些人貼了類似於幾個月之前寫的代碼就看不懂了說法，這種在小公司還是挺常見的，很多小公司流程不規範，導致後來堆積不少技術債務。比如我正在工作的這家公司，剛來的時候感覺代碼太難看了，沒有文檔，沒有注釋，代碼風格不統一，以至於後台編碼規範是我這個剛進公司不久的人寫的，後來我專門寫個博客吐槽python項目免坑指南。我覺得程序員有時候技術實力反倒是次要的，但是一定得保持專業性，比如文檔，注釋，單元測試等。
當然題主沒有得到問題的答案，可能是問錯人了，現在很多大項目是很多人協作的結果，可能一個人並不熟悉另一個寫的代碼和功能，但是如果你直接問實現或者維護相關功能的程序員，如果他也不熟悉，那我就懷疑這個人是不是職業素養不夠了。（解決方案就是：你直接問這個後台介面哪個傢伙寫的，直接找他）你問的這個屬於業務範疇，前端知道當然最好，不知道也不奇怪，畢竟他的主要責任不是搞業務，而是搬磚。
謝邀。這個問題讓我想起了前一些天有點火的一個報道。
題目是
馮小剛開炮：劇組除了主創都是民工
然後有人在知乎問了個相關的問題。
有個回答中說到，某導演叫燈光師看監視器，因為看了監視器才能知道燈光打的好不好，燈光師不看，說我就是幹活的，你讓我怎麼干就怎麼干。印象很深刻。我首先說一下結論，完全正常。一看題主就是那種沒有任何技術背景的。像這種需要和伺服器交互的，最終的數據肯定是來源於伺服器，問題中的程序員已經解釋得很清楚了，你直接去問伺服器端的就行。——分割線，以下言論不針對題主，也不針對PM，而是針對那些開發做不了，測試也干不來，於是只能當PM的那波人——你完全不懂技術你還有理了？不是說要你自己親自上陣寫代碼，但是你了解一下基本原理有那麼難？C/S的基本概念也不知道還振振有詞了？程序員應該有良好的溝通能力，這句話是對的。但是PM能不能也提高下溝通能力？啥也不知道就開始上需求定方案，對產出投入比一無所知，優先順序自己都弄不清楚，決策就拍腦袋，還一副領導樣天天催這個逼那個，誰鳥你？暗地裡他們會暗罵:SB！以下是我一些關於程序員職業方面的回答：在你的專業領域，你覺得最悲哀最無奈的事是什麼？ - Edward Shine 的回答 - 知乎我想問下所謂的C++程序員到底是做什麼的？ - Edward Shine 的回答 - 知乎程序員發現 Bug 的時候是怎樣一種心境？Win 10 下用什麼寫 C++ ？
在我看來，其實是你自己不懂，你要譴責工程師，這樣不好。如果工程師知道的話，他會告訴你的。
前後端要分別處理自己的邏輯，前後分離，減少耦合，提高效率。而這個邏輯的設計者正是產品經理。所以建議你問產品經理，或者技術負責人。
另外，通過產品的表現，去分析這塊應該是前端做的，這塊應該是服務端做的，這塊應該是前端寫死的，應該是後端傳過來的，也是一種能力。
比如你發現：頁面上點贊數量是 100，點擊了按鈕，點贊數量變成了 101，瞬間刷新了一下頁面，又變成了 100，過了 30 秒刷新一下，變成了 101，感到不理解，你可以向技術負責人「虛心地」討教一下。
1 秒內有 1 個人點贊和 1 秒內有 100 萬人點贊，完全不是一個概念。
換個角度思考下，工程師問你，功能我做好了，銷售額什麼時候提高 10 倍？你怎麼回答。這非常正常.
就像你去百度抓一個程序員,然後就想問出來點了搜索按鈕之後結果怎麼出來的,為什麼某一條結果排在另一條之前一樣,你覺得合理嗎?
你不明白產品如何使用.這是因為你們產品設計時文檔缺失.
就像蓋房子,你告訴我房間的長寬高,門開在那邊,牆要什麼顏色.我負責蓋出來.至於這個房間用來幹什麼,蓋房子的是不知道的,也不需要知道.程序員負責的是實現,程序員厲不厲害體現在開發速度是否快,軟體運行時是否流程,開發的軟體bug多不多.業務熟悉程度從來不應該是評價程序員好壞的條件.還有軟體是否解決了用戶的問題,軟體使用起來順不順手,這些問題請不要甩鍋給程序員.程序員當然會記不起自己做的，非常正常，外行不理解。舉個例子，程序員並不是一個字一個字的寫一篇文章，是一筆一划的畫對一個個字，來組成整篇文章，然後你問他某一章節某一段中的男主角追求女主角的說的話前文有沒有呼應。(⊙o⊙)?，寫程序的哥們還在想上次畫的那幾個字順序不錯，我這次還按這樣順序畫，對的概率大，靠這段是這啥的來著？忘記了，看一下文檔，哦，繼續畫。你不記得昨天中午吃了什麼，對吧，前天中午吃的呢？吃什麼飯到肚子里都不知道，還好意思再吃飯啊。開個玩笑啊，相互理解，他的意思很有可能是這樣的，這裡面的邏輯非常複雜，雖然你看得到＋1，但是相信我，非常複雜，複雜到他都覺得解釋給你聽很無力，且，你要基於他的解釋去做一個決定。所以最負責的方法是幫你理出來如何判斷是否＋1，但是以我的經驗，你會你會先放棄，並不耐煩。所以他做了一個預判，乾脆不這樣做。最有效的方法就是把你推到後台身上，他們從邏輯上決定如何組織數據來實現，所以更加接近你的問題。所以，這是一個非常有依據支撐的有理由的推諉。是的，他能告訴你顯示這個1的時候，那幾個變數被放到了哪幾個函數里，使用了哪幾個庫，可能有幾種異常，等等等，而為什麼要顯示這個1，這個真有可能不在考慮範圍。
謝邀，如果還在開發周期，那肯定是清楚的，不然出了問題卻不能確定是客戶端還是後台還是產品邏輯的問題咋辦？然而，如果隔了那麼十幾二十天，突然抽出某個界面的值問我，什麼情況加一什麼情況減一的話……
就你舉的例子而言，是正常的.因為安卓程序員他旨在開發前端顯示，和業務相關的數據操作邏輯都由後台程序員編在程序裡面，處理成結果了給了這個安卓程序員.----------------------------------------------如果後台程序員不理解業務是不可能的.它需要根據業務來做出最終結果.----------------------------------------------什麼叫前台，什麼叫後台.像網站或者系統，你看得到的界面是前台，把數據按業務邏輯整理後輸出叫後台.（姑且這樣解釋）你說的安卓程序員，他一個做表現的，套別人給的數據展示給你看，不知道是正常的.
太正常！多數的程序員在你所給的用例無論多麼詳細，他們都是按照1，2，3的方式來做事情。
比如；1、增加XX功能1）規則12）規則23）規則3..所以你如果問的剛好是第三個而他正好也在做第三個，那他肯定是可以回答你的。如果你問的是第二個，他可能就不知道了，或許要再回頭去看看用例。
這種被典型的稱為；只做不想的人。推薦閱讀：
※安卓應用開發中Login，Maintaining Login，Logout的最佳實踐是怎樣？
※產品經理如何做電話訪談？怎麼整理結果？
※如何正確的理解和分析用戶需求？
※如果要從事項目經理/產品經理這條職業道路，需求的技能是哪些？存在什麼先後順序嗎？或者說如何開始？