貸款問題不用怕

 

2014年11月2日 星期日

?????? Soft_Job ?

FeedMyInbox
 

 

?????? Soft_Job ?
// via fulltextrssfeed.com

Re: [心得] 大陸互聯網公司產品開發流程
11/2/2014 3:45:19 AM

首先, 這個世界上並沒有一個"大陸版快速迭代waterfall". 全世界只要講到"快速迭代模式", 基本上就都是指的我所描述的那種快速迭代模式. 無論 是在北美還是在歐洲都一樣. 這並不是大陸的特產. 歐美業界提出並實行這個模式很多年 了. 詳見: https://en.wikipedia.org/wiki/Iterative_and_incremental_development 而快速迭代與waterfall的分別, 你需要注意其前提: 分而治之. 如果沒有需求的分解, 不 管你怎樣爆肝, 也不可能把waterfall壓縮到很短的週期. 傳統的waterfall並沒有這個步驟, 他們會在整個系統設計完成之後才開始coding, 整個系 統coding完成之後才開始testing. 這才是waterfall被詬病的地方. 這裏我要再強調一次, 在快速迭代模式中, 每一個迭代過程你既可以使用waterfall, 也可 以使用TDD或者別的什麼, 這並不衝突. CI也是一樣. 另外, 關於敏捷我要多說一句, 敏捷不是銀彈. 真的在大項目中實行一遍TDD, 你就知道 TDD的問題在哪裏了: 1. 工作量暴增. 2. 面對頻繁變化的需求, 你會很快厭倦編寫那麼多 測試代碼然後又看着這些代碼作廢. 這都是人力的浪費. 你看看前幾年TDD有多火, 近幾年 又如何? DHH當初那麼推崇TDD, 現在又如何? 敏捷的思想很重要. 但敏捷的具體方法, 無 論TDD還是SCRUM, 都需要推敲. 不過這是另一個話題了, 歡迎另開一串討論. 而至於大團隊概念, 這是另一個層面的問題, 與具體開發模式沒有直接關係. 就算你採用 TDD, TDD的T也只是指的UNIT TEST乃至MODULE TEST這個層面, 對於集成測試乃至系統測試 都沒有觸及. 所以, devops與是否採用敏捷模式沒有太大關係. 實際上, 快速迭代與敏捷方法乃至devops, 這三者相互之間都並不是完全在同一個層面上 的事物. 這三者通常是你中有我, 我中有你的. 現實世界中, 我並沒有看見哪個公司完全 按照教條只採用其中一種模式. ※ 引述《Wolfken ()》之銘言: : 基本上我接觸的所謂大陸版快速迭代waterfall,就我的看法就是單純把waterfall壓縮 : 到非常短的週期而已,有些人號稱這是Agile,但Agile的精神和practice他們根本沒有 : 用到,這種方法waterfall帶來的浪費還有低效率依然存在,之所以能壓得很快,說穿 : 了就是硬壓員工加班加到爆而已。但這種硬壓schedule的方法,技術債一定會不斷累積 : ,等到技術債累積到連每天加班到半夜都趕不上進度時,就是團隊壓力鍋爆炸的時候。 : 這種方法跟真Agile最大的差別在: : 1. 依然需要在開發後放一個手動測試的phase跟解bug的phase,而這兩個phase就是最 : 趕最亂技術債欠最多的phase。相較於Agile特別是XP,使用自動化,CI還有TDD把 : 測試拉到很前面,和開發幾乎同步,Waterfall無可避免的就是造成浪費時間在人工測 : 試,以及浪費在前期時測試人員的閒置。 : 2. 沒有團隊速度的概念,Scrum會要求了解每個sprint平均能消化多少story points : ,從而了解團隊速度並做出調整。Agile是固定時間和成本下,根據團隊速度決定要 : 開發多少feature,並根據現實狀況在每個sprint不斷調整,而不去做出無根據的預 : 估然後硬吃下根本不可能吃得下的feature量。Waterfall則是一開始什麼都沒有就要 : 做出毫無根據的預估,然後通常都過於樂觀,最後都會在成本,時程跟scope中間至少 : 無法達成其中一個。 : 3. 沒有end to end大團隊的概念,各個角色壁壘分明,互踢皮球的狀況非常常見 : 總之,大陸互聯網這種所謂的快速迭代waterfall,看似agile,甚至有人就稱這叫 : agile,但就我看來還是蠻土法煉鋼的一種軟體開發流程,跟歐美的軟體公司比, : 依然是落後相當的多。不過本來亞洲軟體公司的軟工就跟歐美公司有一段很大的落 : 差了,這也是很多台灣有在鑽研這塊的人很想讓台灣能趕上的一塊。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.246.87.152 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414915026.A.C86.html ※ 編輯: abadcafe (114.246.87.152), 11/02/2014 15:58:30

 

Re: [閒聊] 微軟就是爛?
11/2/2014 3:45:19 AM

※ 引述《MacPerson (Gary)》之銘言: : 在我的職涯中,發現似乎.NET工程師很喜歡「寫.NET罵.NET」, : 有些工程師寫過其他語言,回頭來罵.NET哪裡不完善,或直接 : 說哪個語言的哪個功能比.NET好用太多,這都還算理性討論。 : 但有些工程師,邊寫邊罵,問她說哪裡爛?他只說,阿就是很爛~ : 這個就無言了。 : 舉例:該工程師曾說MS SQL 爛死了,速度又慢。但問他說慢在哪,怎麼慢法後, : 得出來的答案是 他SQL寫的濫..... : 各位有興趣來舉例一下,.NET哪個功能最讓你嫌到不行? : 我開第一炮: : entiy 不小心按到存檔,你的模型驗證的屬性就被洗掉。 : ex:[required].... : (註:此篇沒有幫微軟護航,不好用總該有個邏輯,「邏輯」不就是工程師吃飯的傢伙?) 你說的沒錯。尤其是最後一句,總要有個邏輯,有個理由。如何分析一件東西好 或壞。但是,我們教育所製造的困境,是不問過程、只問結果,只講操作,不講方法。 .net工具,最資深的工程師,只有12年左右的年資而已。在12年之前就已經有軟體 基礎的人,能站在什麼基礎上談.net這是個好或壞的語言,或者,好或壞的工具, 就看他如何站在系統層面上,給彼此做個比較。 可是,要說.net是哪個語言呢?要說 VB.net ,由 VB 的基礎,我覺得除了 END 和 END If 二個保留字太混淆(想想若有十個以上的巢狀If...END If,最中間放了 一個End ......) 以外,其他都可以接受。要再提到 C# ,看起來 .net 只是 要把 C# 和 VB.net 二個語言變成同型,語言的格式上有一些對應,人可以使用 不同的語言,做出同樣一種軟體。 不過,從你的同事無法提出適當的理由來講,正好就是他的弱勢、無競爭力之處呀。 發現了有個人比你沒有競爭力,這是好事。但是,若要說一同成長,則有點麻煩。 有些人專講結果論,但是在過程中不加以討論細節,所以,沒有過程的結果, 就是爛結果。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.156.161 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414911233.A.A7C.html ※ 編輯: yauhh (118.160.156.161), 11/02/2014 14:57:36

robler: 有人知道這篇文章到底想講什麼嗎 11/02 14:54

yauhh: 寫一半不小心操作錯誤,貼出去了啊。 11/02 14:58

※ 編輯: yauhh (118.160.156.161), 11/02/2014 15:01:05

 

Re: [心得] 大陸互聯網公司產品開發流程
11/2/2014 3:45:19 AM

※ 引述《abadcafe (abadcafe)》之銘言: : 這個地方可能有些朋友產生了誤解. : 傳統的waterfall模式非常嚴謹, 整個系統從需求評審一直到最後測試上線, 要耗費大量的 : 時間. 因此不可能快速響應各種需求變更, 這在瞬息萬變的互聯網行業中是不可接受的. : 事實上, 在互聯網行業中, 最盛行的是waterfall模式的變種: 快速迭代模式. : 快速迭代模式講究的是分而治之, 把整個系統拆解成非常小的模塊, 然後針對每個模塊進 : 行waterfall, 並且若有需要還可以跳過某些階段. 每個waterfall的運行時間可能就只有 : 1周甚至更少. : 這種模式下, 產品經理在尚未弄清楚所有需求的情況下, 就可以從已經確定的部分開始一 : 輪迭代, 有新的需求就再下一輪迭代. 響應速度非常快. : 至於有朋友提到敏捷開發, 其實這與快速迭代並不衝突. : 雖然大多數情況下, 快速迭代在每一輪迭代中都是使用waterfall模式, 但你也完全可以根 : 據需要在每一輪迭代中使用敏捷模式. 或者這一輪是敏捷, 下一輪是waterfall. 這都可以 : 沒有什麼問題. 基本上我接觸的所謂大陸版快速迭代waterfall,就我的看法就是單純把waterfall壓縮 到非常短的週期而已,有些人號稱這是Agile,但Agile的精神和practice他們根本沒有 用到,這種方法waterfall帶來的浪費還有低效率依然存在,之所以能壓得很快,說穿 了就是硬壓員工加班加到爆而已。但這種硬壓schedule的方法,技術債一定會不斷累積 ,等到技術債累積到連每天加班到半夜都趕不上進度時,就是團隊壓力鍋爆炸的時候。 這種方法跟真Agile最大的差別在: 1. 依然需要在開發後放一個手動測試的phase跟解bug的phase,而這兩個phase就是最 趕最亂技術債欠最多的phase。相較於Agile特別是XP,使用自動化,CI還有TDD把 測試拉到很前面,和開發幾乎同步,Waterfall無可避免的就是造成浪費時間在人工測 試,以及浪費在前期時測試人員的閒置。 2. 沒有團隊速度的概念,Scrum會要求了解每個sprint平均能消化多少story points ,從而了解團隊速度並做出調整。Agile是固定時間和成本下,根據團隊速度決定要 開發多少feature,並根據現實狀況在每個sprint不斷調整,而不去做出無根據的預 估然後硬吃下根本不可能吃得下的feature量。Waterfall則是一開始什麼都沒有就要 做出毫無根據的預估,然後通常都過於樂觀,最後都會在成本,時程跟scope中間至少 無法達成其中一個。 3. 沒有end to end大團隊的概念,各個角色壁壘分明,互踢皮球的狀況非常常見 總之,大陸互聯網這種所謂的快速迭代waterfall,看似agile,甚至有人就稱這叫 agile,但就我看來還是蠻土法煉鋼的一種軟體開發流程,跟歐美的軟體公司比, 依然是落後相當的多。不過本來亞洲軟體公司的軟工就跟歐美公司有一段很大的落 差了,這也是很多台灣有在鑽研這塊的人很想讓台灣能趕上的一塊。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.25.207.30 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414911113.A.F24.html

 

Re: [心得] 大陸互聯網公司產品開發流程
11/2/2014 3:45:19 AM

這個地方可能有些朋友產生了誤解. 傳統的waterfall模式非常嚴謹, 整個系統從需求評審一直到最後測試上線, 要耗費大量的 時間. 因此不可能快速響應各種需求變更, 這在瞬息萬變的互聯網行業中是不可接受的. 事實上, 在互聯網行業中, 最盛行的是waterfall模式的變種: 快速迭代模式. 快速迭代模式講究的是分而治之, 把整個系統拆解成非常小的模塊, 然後針對每個模塊進 行waterfall, 並且若有需要還可以跳過某些階段. 每個waterfall的運行時間可能就只有 1周甚至更少. 這種模式下, 產品經理在尚未弄清楚所有需求的情況下, 就可以從已經確定的部分開始一 輪迭代, 有新的需求就再下一輪迭代. 響應速度非常快. 至於有朋友提到敏捷開發, 其實這與快速迭代並不衝突. 雖然大多數情況下, 快速迭代在每一輪迭代中都是使用waterfall模式, 但你也完全可以根 據需要在每一輪迭代中使用敏捷模式. 或者這一輪是敏捷, 下一輪是waterfall. 這都可以 沒有什麼問題. 而devops則又是另一個範疇的事情. 傳統軟件研發中, QA, OP, RD的角色非常分明並且各 司其職. 這樣就造成了一個問題就是三種角色會互相扯皮, QA講你RD東西做的爛不可測, RD講你QA什麼都不懂連搭建環境都要我幫忙, OP講你們QA RD不好好做事, 線上程序出問題 全部要我來擦屁股... 還有一個問題是, 沒有哪個OP和QA願意一輩子做OP和QA, 大家都想着要做RD, 工作積極性 就明顯不如RD高. devops強調的是, 不再區分這三種角色, 大家都是RD + QA + OP, 統稱RD. 有句俗話怎麼 講來的? 不會做QA的RD不是好OP. 那這種情況下, 又出來了一個問題, 就是對RD的要求非 常高. 之前三者的工作量全部壓到了一個人身上. 而相對應的解決辦法就是, 開發各種工 具協助RD快速進行QA和OP. 持續集成, XaaS, 等各種新技術新方法都可以大大減輕工作量. 而原有的QA和OP團隊, 則轉型成專職的平臺研發RD: 現在如日中天的amazon ec2就是 amazon的OP團隊厭倦了無休無止的機械操作而研發出來的. QA團隊則通常會轉型成持續集 成平臺以及其他質量保障平臺的RD. ※ 引述《blabla123 (念不停 煩不煩?)》之銘言: : CSDN: http://blog.csdn.net/shanwu1985/article/details/40482497 : 這是最近的工作心得,想和版裡的前輩請教/交流一下~謝謝大家 : 從開始上班到現在,也快滿一年了,在這,就談一下軟件開發的幾個階段。各公司應該有 : 不同的名稱,但是開發流程較完整的公司應該是會有下面的幾個階段。下面是我對這幾個 : 產品周期階段的理解還有心得,還請大家不吝指教~ : 需求評審 :   在此階段,產品經理(PM)會提出新的需求,比如說軟件的一些新功能,並解說此需求 : 的動機,完成產品需求文檔(Project Requirement Document)後招開相關會議;研發人員 : (RD)則會在會議上評估此項新需求是否可實現、所需要的工作日、對產品穩定度的影響, : 是否在既有產品已有相關功能等等;測試人員(QA)則會提出一些測試上的疑問及意見, : 方便後期進行 Case 評審。這個階段容易發生的問題,一般是產品經理和開發人員意見不 : 一致,或者是二者有信任問題而導致的。曾經見過衝突案例是這樣的:一位產品經理,因 : 為在前一家的公司,有做過類似的產品,便認為此項設計容易實現,而他不知的是,每家 : 公司的產品,其架構不見得類似,實現的困難度肯定是不大相同的,因此便開始質疑RD開 : 發能力,還有是不是想要偷懶之類的情緒性發言,於是衝突便發生了。私以為這種情況其 : 實是無解的,因為這和衝突雙方的個人特質及個性是極度相關的,唯有尊重對方的工作及 : 專業,並且注意自己的發言及語氣,才是專業化的表現。 : 開發階段 :   在需求明確了以後,RD即開始進行開發工作,在 FC (Function Complete)期限之 : 前將相關功能實現並且自測完畢。因為一個小功能,測試人員往往需要執行數個測數案例 : 以確保其功能正常,因此研發人員在進行開發工作時,一定要給自己留至少一天的自測時 : 間,確保在正常情況下的操作是沒有問題的,這樣不但減輕測試人員的工作量(當發現一 : 個 bug 時,在開發人員解完 bug 後,測試人員是需要復驗的),這樣連帶的也使自己的 : 名聲好聽一些,如此,何樂而不為呢? : Show Case :   在基本功能開發完成了以後,便會邀請其它小組人員觀看、評論新開發的功能,如果 : 有必要的話,做小幅度的調整。 : 測試案例評審 :   測試人員在完成自己編寫的測試案例,會將召集產品經理, 研發人員,以確保相關案 : 例(case)足以覆蓋此項新功能,新功能能正常地發揮該有的效果。研發人員在開測試 : case 評審時,應該想想自己的代碼邏輯,在更動的代碼部份,提出可能會遇到的情況, : 確保 test case 有完全覆蓋到這些改動造成的影響。 : 測試階段 :   在測試人員測試過每一條 test case,且開發人員完成 bug 的修改了以後,便可以 : 進入 RC (Release Complete)階段。而我們一般說的 RC 時間,便指的是 RD 該把 bug : 都修復的最後期限。在這邊有一點需要注意的是,進入RC前的測試階段,使用的測試環境 : 是線下測試環境,而進入 RC後,便開始使用線上測試環境進行測試。在測試階段,也是 : 研發人員容易和測試人員衝突的時候,常發生的場景如下: : 一、測試case 因某些 bug 而被 block 住,無法往下測,而再過多久便是期限了。遇到 : 這種情況,必須盡快解決 bug,否則會影響新版本的發行,一方面,可能也得注意自己的 : 語氣,緩合任一方的情緒,因為多和幾個人吵架,並不會讓進度變得更順利。 : 二、對bug的認知。某些情況下,是按照正常產品設計所產生的必然結果,而測試人員從 : 用戶的角度,自然便認為是個 bug,此時應和產品經理一起討論解決問題。 : 三、開發未完成自測,導致在進入測試階段後,立刻出現一堆 bug。 : 四、Bug修改導致其它地方出現問題。   :   其實,每個角色總是得以團隊為重,產品為上,所以必須克制一下自己因忙碌而產生 : 的負面情緒,不能因為這些負面情緒影響了工作的進行。但是如果遇到個別無法控制自己 : 情緒或行為的人員,也應兼持自己的為人処事原則,該怎麼辦就怎麼辦,不能事事忍讓對 : 方,有時也必須「站出來為自己的原則吵上一架」不管是在談話語氣方面,或是公事的 : mail往來方面,都是一種処理方式。有時候恰恰是因為你對原則的堅持,反而會得到對方 : 對你專業的尊重。 : 灰度 :   在這個版本進入 RC 狀態了以後,在線上環境測試沒問題了以後,測試人員會發布 : RC 報告,並進入灰度,灰度主要是先將新版本公開給一小部份的用戶,因為平台及使用 : 行為的差異,此時有可能會有一些產品的 crash 及用戶回報的問題,而依問題的嚴重性 : ,可能會有一次灰度,二次灰度等,然後便是全面發布,將產品公開給全部用戶使用,此 : 時全部的用戶便會收到相關的升級訊息。灰度期間主要的問題,應該是反饋的 bug 一般 : 比較不容易解決,不容易解決的原因主要是不容易復現,比如說沒有用戶所使用的平台, : 又比如說當時的操作環境可能是非常特別的等等各種不同的原因,這時我想就得靠經驗解 : 決了。 : 以上,就是我目前的心得~謝謝大家閱讀~請多多指教~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.246.87.152 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414908086.A.293.html ※ 編輯: abadcafe (114.246.87.152), 11/02/2014 14:06:10

 

Re: [請益] 我適合在科技業待下去嗎?
11/2/2014 3:45:19 AM

說那麼多也沒見你是要待怎樣的公司怎樣部門 軟韌體研發對你來說可能太硬了 但ERP,IT,CIM之類的 就沒你想像的那麼恐怖 我在科技業IT部門待過幾家公司 真的不要把coding看得那麼認真 一堆高級,資深工程師 連最基本的static這是幹甚麼的都不知道 也一堆不知道overload override OO threading 都看不懂也不會用 真的不誇張 一堆這種工程師 整天把javascript當java的也不在其數 雖然IT部門寫的程式不像軟體公司那麼講究軟工 但我說的那些不都是讀書就需要會的基本功嗎 每次看到一堆年薪百萬的工程師問我這些問題我都困惑了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.45.147.143 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414907138.A.8AF.html

abadcafe: 感覺你是在虎爛 11/02 14:15

hegemon: 這絕對不是唬爛..很多所謂的高級,資深只是剛好卡住位置 11/02 14:31

hegemon: 實力其實不怎麼樣.... 11/02 14:31

kinanson: 這思維其實不太對,那些技術非常落後又高薪的,就是掌 11/02 14:44

kinanson: 握公司系統或主要賺錢產品的人,但這樣的人一旦想跳槽就 11/02 14:44

kinanson: 沒啥競爭力,反正很多公司也只能將錯就錯下去 11/02 14:44

 

Re: [閒聊] 微軟就是爛?
11/2/2014 3:45:19 AM

※ 引述《MacPerson (Gary)》之銘言: : 在我的職涯中,發現似乎.NET工程師很喜歡「寫.NET罵.NET」, : 有些工程師寫過其他語言,回頭來罵.NET哪裡不完善,或直接 : 說哪個語言的哪個功能比.NET好用太多,這都還算理性討論。 : 但有些工程師,邊寫邊罵,問她說哪裡爛?他只說,阿就是很爛~ : 這個就無言了。 : 舉例:該工程師曾說MS SQL 爛死了,速度又慢。但問他說慢在哪,怎麼慢法後, : 得出來的答案是 他SQL寫的濫..... : 各位有興趣來舉例一下,.NET哪個功能最讓你嫌到不行? : 我開第一炮: : entiy 不小心按到存檔,你的模型驗證的屬性就被洗掉。 : ex:[required].... : (註:此篇沒有幫微軟護航,不好用總該有個邏輯,「邏輯」不就是工程師吃飯的傢伙?) 微軟提供的功能好不好見仁見智吧,IT 系統不是只看 功能。 從整個商品的生命週期角度,最讓我感到不太方便的地方如下: 1. 所有的產品都把太多技術細節包起來不給人改。 這對新手來說很爽,對高手來說很痛苦。 例如.NET 很愛把 AJAX、Web Socket 等等包成很簡單的做法, 資料庫與資料探勘很多細節都不能改。 是可以快速上手啦,但你要改細節或效能時,你就掛掉了。 2. 把同事弄笨。 很多人看到.NET 可開發任何軟體後,就完全沒思考能力了, 也不願意用開放的心態學習各種技術生態的優缺點。 一個問題出來,能想到的就是 .NET 有沒有套件可以用, 完全無思考與研發的能力。 對我來說使用微軟解決方案,最常出現這兩個大問題吧。 有得選擇一定盡量避開這兩種窘境,一整個思考退化。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.45.104.157 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1414903858.A.1E6.html

 

You are receiving this email because you subscribed to this feed at feedmyinbox.com

If you no longer wish to receive these emails, you can unsubscribe from this feed, or manage all your subscriptions

沒有留言:

張貼留言