Re: [心得] 敏捷課程觀察心得

看板Soft_Job作者 (CHA)時間6年前 (2018/04/07 03:46), 6年前編輯推噓2(2027)
留言29則, 10人參與, 6年前最新討論串10/11 (看更多)
※ 引述《YAYA6655 (YAYA)》之銘言: : 以我20年的經驗來說,什麼敏捷,設計模式,很多都是脫褲子放屁。 : 更早期還有什麼OO方法論,部分人神鬼上身,什麼東西都要OO一下,連寫個九九乘法 : 表都要開一個 class ninenine。 我學OO大概6年,還真的沒用過OO的方式寫99乘法表 唯一寫過的一次是在main裡面直接幹,然後拆幾個function出來而已 然後我就想啊,如果叫我現在用OO的寫法寫99乘法表,那會長成什麼樣子? 然後就有了以下這個東西 https://gist.github.com/chartsai/9f32d6430a825f9296b376b60758192f https://imgur.com/a/NF5Cl 接受自訂大小(ex: 不想印9x9,改印12 x 12) 可以指定分幾段(ex: 1~3 一段, 4~6 一段, 7~9一段…預設是超過六組就分兩段) https://imgur.com/a/HTwh3 可以只打印特定行(ex: 3 x 1, 3 x 2 ....) https://imgur.com/a/cj0BO 可以給打印格式(ex: %d x %d = %4d, %d * %d -> %2d) https://imgur.com/a/o6rye 純實作含空行大概花40行,為了方便多寫了一個不用給格式的helper function花15行 demo用的main function花了20行XD 用的是我現在的主要語言Kotlin,可讀性待鄉民認證(?) 我覺得要增加功能或者是後續維護都不是大問題 要做Unit Test也算簡單 目前沒有做防呆,但應該不是大問題,輸入值驗一下就好了 不知道鄉民們怎麼看?是殺雞焉用牛刀呢?還是比直接幹來的好呢? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 104.132.45.94 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1523043988.A.36F.html ※ 編輯: cha122977 (104.132.45.94), 04/07/2018 03:49:05

04/07 09:43, 6年前 , 1F
把一件簡單的事情搞得這麼複雜 XD
04/07 09:43, 1F

04/07 09:58, 6年前 , 2F
(a).可以加個客戶需求分析,系統分析,單元測試,效能測試
04/07 09:58, 2F

04/07 09:58, 6年前 , 3F
,說明文件,功能上還可以產生圖片,excel,網頁..
04/07 09:58, 3F

04/07 09:58, 6年前 , 4F
(b).直接告訢我做完了與結果就行了,超過3句話的討論都
04/07 09:58, 4F

04/07 09:59, 6年前 , 5F
可以省了,因為這種題目沒有預期會有困難的地方,就需要
04/07 09:59, 5F

04/07 09:59, 6年前 , 6F
時花時間下去而己.
04/07 09:59, 6F

04/07 10:00, 6年前 , 7F
課堂上,外包,或是拿project來練功,(a)常見; 自行開發
04/07 10:00, 7F

04/07 10:00, 6年前 , 8F
產品(b)划算, 不知道有沒有離題?
04/07 10:00, 8F

04/07 11:22, 6年前 , 9F

04/07 11:23, 6年前 , 10F
simple design這有順序的四要點,是很好的遵循原則
04/07 11:23, 10F

04/07 13:56, 6年前 , 11F
練功的話都沒差的 想做就做 但真正要練的 其實是在看到實
04/07 13:56, 11F

04/07 13:57, 6年前 , 12F
際生活裡的真實需求時 那才是真槍實彈
04/07 13:57, 12F

04/07 13:59, 6年前 , 13F
像這個練習題就可以模擬 如果我需求只是要1到9 給小朋友看
04/07 13:59, 13F

04/07 13:59, 6年前 , 14F
你這樣當然是過度設計 但如果是要弄成大軟體裡的模組 這樣
04/07 13:59, 14F

04/07 13:59, 6年前 , 15F
也還行
04/07 13:59, 15F

04/07 14:53, 6年前 , 16F
有沒有過度,是要看未來有沒有擴充修改的需求阿
04/07 14:53, 16F

04/07 14:53, 6年前 , 17F
交個學校作業這樣寫就太搞剛了
04/07 14:53, 17F

04/07 14:53, 6年前 , 18F
但是如果這個功能未來有要擴充,寫的好一點就會有幫助
04/07 14:53, 18F

04/07 14:54, 6年前 , 19F
比方說,如果以後這個功能要加上16進位的15*15乘法表呢
04/07 14:54, 19F

04/07 14:55, 6年前 , 20F
核心部份想必都差不多,但是細節就會有點不一樣
04/07 14:55, 20F

04/07 20:54, 6年前 , 21F
真實產品等到需要擴充再重構, 一開始就想太遠未必好
04/07 20:54, 21F

04/07 20:55, 6年前 , 22F
應該說出現需求時才會預期未來還有更多延伸需求
04/07 20:55, 22F

04/08 02:30, 6年前 , 23F
看過一本大師們的閒聊,兩個風格不同的大師共同開發軟體
04/08 02:30, 23F

04/08 02:31, 6年前 , 24F
一個就考慮更遠的需求,一個著眼於現在,這樣也能一起合作XD
04/08 02:31, 24F

04/08 14:25, 6年前 , 25F
都知道可擴充行好了當然這樣寫啊
04/08 14:25, 25F

04/08 15:51, 6年前 , 26F
就是需求拉 我倒覺得重構比較重要
04/08 15:51, 26F

04/08 15:52, 6年前 , 27F
如何把一開始很簡單的code改成需求很多的code
04/08 15:52, 27F

04/08 15:53, 6年前 , 28F
一般大概就是疊床架屋 搞到程式亂七八糟
04/08 15:53, 28F

04/09 21:25, 6年前 , 29F
同意有需求再改就好 但要一開始就寫的好改我覺得不容易
04/09 21:25, 29F
文章代碼(AID): #1QnywKDl (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1QnywKDl (Soft_Job)