Re: [討論] 關於敏捷越來越深入台灣職場
這就是莫明其妙的點,兩位沒啥實績的人,出了一本書,胡鄒一個方法。
然後一群人拿來當聖經在拜。
這就是外國的和尚會唸經的概念,要是像人月神話的作者這種有實績就算了。
偏偏沒有還當神,就是一堆不沒開發過軟體的人,拿來唬人用,然後病毒式傳開。
說實在的,還真的跟紅衛兵沒兩樣。
至於code review,這個也是一個很妙的妙論。
是review 什麼? 格式/style? framework/pattern? 正確性?
還是說,科舉的殿試,皇上出題,大家來寫,皇上來評?
不然,誰有這種美國時間來評?
格式,有formatter。
有沒有用OOXX 無敵framework,還是有沒有design pattern一下? 啊你能call 不就好了正確性? 哪要K 他的SPEC? 不會吧。
anything else?
--
open source projects:
https://github.com/terrylao/
--
所以問題其實是人 好的人才能把概念落實到實務
上篇DrTech板友就指出來了
這行不就這樣,一陣子就有新東西,敏捷就剛好名稱取
個好,下一個猜是low code no code
的*
問題是人是一定的了,哪有一種法規是自己會執行的?
但重點是,這是兩位沒實績的人寫出來的東西。
low code我看是不行了啦 他要炒作的時機點剛好在GPT問
市之前一點 GPT一出來聲量就沒救了 錯過炒作時機
一個公司的共同 code style 跟老屁股告訴你有甚麼好用
的共同方法庫之類的吧
像是產 json 的方法那麼多,各自都用各自的方法的話有
問題的時候又是一筆時間成本
用什麼framework 不是在案子開始時定好的?
low code怎會不行,一堆搭上gpt的low code來推銷,似乎蠻好用
初看當然好用阿,但真的用下去就知道了...
說到low code 之前的Dreamweaver算不算一種
labview winform 算不算 low code==
Code review當然是正確性優先啊!幫忙抓沒考慮到的ca
se,還有是否有遵守共同的style ,其實最主要是互相
抓對方的blind spot
至於可讀性很主觀,但我通常會示範怎麼寫比較簡單易
懂,取得共識
很多人亂用資料結構,演算法亂寫,你用code scan tool上
找不出問題呀,這時候只能靠code review
你看過一堆人檢查是否存在用list在那邊contains 然後在那
邊納悶為什麼效能很差就會覺得需要code review
正確性,就需要讀需求,就是一份工作兩人分。至於
效能問題,嗯,台灣的問題不大。
你list都能放進APP了,效能能差到哪...又不是刷題
你沒遇過有人把10萬個items放進list,然後用contains去找
新進來的有沒有在list內?還看過更神的還用for loop去做e
quals比對找item?這樣效能不會有問題?
以現在的PC來說,10萬不算數字。要能讓你明顯感覺到基
本是50萬起。再說contains 的行為和for loop 何異?
另外,是否存在,別以為用hash 就一定快。哪還是取決
於你的key 的分佈如何。
真的遇到再跟我說10萬不是數字吧,你的base跟要比對的量
都是10萬等級的還不是數字嗎?
er...真的遇到的是破千萬的,十萬的一直都不當回事。
十萬跑 list 迭代很有感吧
你是寫C? java? C#? python? VBS?
好說也給個SAMPLE CODE 出來有感一下吧。
蠻猛的 怎麼現在連code review都要被翻桌了
這不是基本常識嗎...
沒人review 推一個叫做nbNumber的變數上去 你猜猜看是什麼
意思^^
openWheat() function huahaGift是啥^^
哦,連變數命名都出來呢。真的是笑死人。
想必你對你做的案子的英文的名詞都非常熟,還能中英對
照呢.
review最基本要寫到第二個人能看得懂 接著確保基本正確性
有時間可看有沒有更好的寫法能提出來 很多時候這個過程幫助
產品更好 也是讓自己能進步的方式 因為其他成員可能有更好
你沒想到的方法 教學相長也可以進步
牛逼數字 開麥客風 豪華禮物 你答對了嗎^^
review過的話這些垃圾就不會進去害人害己了
案子不趕,人力很多,高手很自信他的寫法更好。review!
很趕的話喬一下review看重點正確性就好了 除非無法忍受的東
西不然就別修 或是先註解之後再修也是一個方式
之前書上也有講過了 很多時候寫程式寫都很快 但看會很久 因
為寫太爛了 為了寫快寫一堆垃圾 幾週後出問題你回來看可能
連你這跟親爹都認不得 最後還是功德迴向到自己身上
看別人的正確性,就是自己沒事做,專做這一塊.
就是人力過剩.
要不然,大家都有自己的要寫,誰有這命去批改作業,還吃
力不見得討好的. 正如,你認為你的寫法比較好,
我認為我的沒問題,就有人說10萬就很有感,我是無感.
這時誰來裁決? 有一位全部人都認同的大神來裁決?
還是就隨他去? 哪reviewer的不爽,改成reviewer的,則
原作不爽. 不然再花時間寫一個測試, 來評比?
benchmarking 來一翻兩瞪眼, 時間太多?
不是週週要sprint? 這要不要加插進去sprint?
幫人家改作業沒必要。但是你是project owner不看的話都
不怕人家塞什麼垃圾進去嗎?
這麼怕就不要找這些人一起做囉。再說,我要是想做點什
你真的有本事找出來?
Who knows :)
真的能回廢話,who knows 有什麼好合作的?
code review確實花時間但利大於弊吧,除了正確性外,程式
碼品質好未來比較好維護,短空長多
但如果案子簡單以後也不負責維護,那為了搶快省略review感
覺也行
總是有很多東西是你講一下別人會覺得合理就改變的事情吧...
萬事都要有一個主宰來訂定要聽誰的? 我不認為多數時間就re
view個code分歧會到這麼大啦 真的不行也可以找leader來定奪
除非你真的認為你的code就是你的code 永遠不會有第二人去
做修改
不太懂內 code review有這麼洪水猛獸嗎? 我真的蠻意外的
沒啊,人力問題,管理問題而已。說白了就是錢的問題.
再說, 我也不知什麼叫"程式碼品質好", 有比較基礎?
找個opensource 的project 為例吧.
還是又 是所胃的leader 說了算這種管理方式?
不知兩位大神, 看我的opensource code 有沒有要加強的.
你回覆我的也是廢話:)反正你沒在擔心。
怪拐 你真的分不出好的程式碼跟壞的程式嗎?
算了 可能新手吧 那我無話可說了
我不知什麼叫好什麼叫壞,你給出來個定義。我是新手.
看一下我的PROJECT 吧,請你來評一評。
有一本書叫做 clean code可以去看一下 design pattern 也可
以了解一下 什麼情境用什麼pattern適合 還有基本的solid原
則
你還是評一下我的project吧,好讓我學習學習你這位大神
clean code 的作者,連是位軟體工程師這點都沒出處.
我看還是算了吧.
code review的重點在角色轉換和權責劃分,你不覺得寫code
和看code的觀點不太一樣嗎?你要說成本的話,你覺得請一
堆資深並信任他們都能做好自己的事,和請一堆一般加一個
資深主管做review,哪個比較省?另外code review也有一點
訓練的意義在
再者,code review可以讓主管提早發現不同員工負責的模組
的之間的問題並及早解決,而不是到串接那天才發現兩人牛
頭不對馬嘴或跨過界
不就是,這位天才資深,要弄清楚所有的需求?
65
首Po小弟就業大概十來年 雖然剛入職場時 敏捷開發就已經是很紅的議題 但至少我前幾份專案都還是很傳統的瀑布 個人感覺是近年越來越明顯5
敏捷只是工具 聽到花篇幅宣揚特色是敏捷的公司建議逃 就好比英文是工具 連高中生都知道這沒啥好吹的 敏捷認真要研究雖然要翻理論25
痛苦就不是敏捷 : 例如說 : 以前談好一整個版本的spec : 要談時程就是基於一整個版本再談 : 中間有什麼改動很正常X
以我自己覺得敏捷的特色 在於如何有效的生產及完成一個又一個的 sprint,SA,PM最好有技術經驗,團隊間成員 水準能力要差不多,會議就是拉有關係的開發進來就好。 我覺得跟客戶團隊的溝通有沒有及時的管道1
→ Lordaeron: AGILE的專家們,請問AGILE 在最開始前,要先寫一些底 07/27 19:10 → Lordaeron: 層的東西嗎? 要架環境嗎? 要的話,要算進sprint? 07/27 19:11 → Lordaeron: 會人人都有工作? 還是只有某幾位負責? 07/27 19:12 → Lordaeron: 再來,何時on production? 按國外大神的說法,沒提到呢 07/27 19:13 → Lordaeron: 若成員的程度差異,導致他的工作無法如期完成,會不會 07/27 19:134
敏捷是做出客戶真正想用的東西 在需求變動與不確定 (連客戶自己都不確定,想用什麼軟體) 以快速小迭代,每個 Sprint 交付最小增量給客戶 客戶親自使用並回饋之後,再次修正 Sprint Goal 開發團隊再次衝刺 Sprint Goal 微調之後
95
[討論] 寫三元判斷式code review被打槍小弟寫java的 以前常常寫三元判斷式 就比如說 String a; if(con) {18
Re: [討論] 寫三元判斷式code review被打槍三元不能用 算還好了 我還遇過 a=1; ... ...27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A 代表他能力不算差24
Re: [討論] 寫三元判斷式code review被打槍說到switch,想來問問你各位公司的code style是下面哪種 (1) switch Var1 { case a: xxx19
[請益] 台灣在寫android的人有多少?台灣在寫android的人有多少? 看到一篇文 "本人不幸在狗廠的安卓大組,幹了一年多了,說實話每天寫code如上墳。 以前是寫c++ infra的。自我感覺也是見過覆雜系統和覆雜code的。11
Re: [討論] 寫三元判斷式code review被打槍Code review 檢查這些會有點太花時間,應該有更重要的東西要看。 可以用一些 Gradle plugins 卡在 CI 比較省事: 1. Checkstyle 顧名思義檢查 style。 2. SpotBugs8
Re: [討論] 寫三元判斷式code review被打槍這種事情 不就和阿里巴巴一樣 一開始給大家一本手冊 哪些code 或是哪些style在本公司不要出現8
Re: [請益] 如何當軟體QA??之前寫的軟體測試幾個層級,提供參考。 最入門的狀況,Intern/工讀生通常只會碰到這 A. 依照Test Case進行測試。回報Issue,重現步驟 B. 有能力建置測試環境到可以部屬待測軟體。 測試的軟性觀念,這邊開始才真的進入測試的領域。6
Re: [討論] 怎樣算是一個合格的junior cpp programme先說 我不會寫C++ 但是關於軟體架構和Design Pattern我可以補充一下 軟體架構實際上在台灣多數職場裡的狀況 大概可以用一句話來形容5
Re: [討論] 寫三元判斷式code review被打槍review code 的時候, 對code style 有意見的人真很呵呵, 真的要對code style 有意見,麻煩就寫進code style checker, 如果在commit 之前的 code style checking 都過了, 就不要在這上面花時間,不然會沒完沒了。 因為有更多更重要的事要討論,