Re: [請益] 有公司用這種開發方式嗎?
※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: 前在公司上過軟體外包管理的課程
: 有提到類似的事，提到的例子好像是花旗
: 我個人的心得是
: 一、系統架構要很強（SA），設計出來的東西不能到實作才發問題
: 二、規格要很明確，明確到每個函式都要定出來
永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
Boss, HW bug, OS bug 都會引起各種架構變化,
而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
每個函式都要定出來, 是用在程式模組之間的介面,
不是要SA把程式架構裡的每個函式都弄出來,
programmer越高段, 模組就可以越粗略, 自行發揮就好,
無法自行發揮的, 回去賣雞排啦
無法理解程式運作的人, 同時也等於無法debug的人,
能分工寫出來卻不能debug, 這算什麼分工
: 三、公司要有明確的程式設計風格，如
: 基本上， coding 是沒什麼大不了的
: 因為規格都詳細到函式，而且程式設計風格有明確規範
: 不同的人寫出來的差不大
: 但以台灣的現況：
: 一、台灣的公司不怎麼注重系統架構
: 真正的系統架構強者大概也不會受到重視，公司也不會想到要去培育
君不見園區各大公司裡面, 往往只有幾個人負責設計,
只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
只會更沒效率, 更多咖啡工程師抱怨賣肝
: 二、台灣的公司規格一改再改是理所當然，規格詳細到函式根本是自討苦吃
: 而且，台灣的公司規格稱不上是規格
: 頂多是需求的定義（譬如要做什麼，要有什麼功能），然後就開始實做
: 之後的系統設計、實做，都是 RD 的責任
改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.204.159.143
推
11/11 18:46, , 1F
11/11 18:46, 1F
→
11/11 20:46, , 2F
11/11 20:46, 2F
推
11/11 22:20, , 3F
11/11 22:20, 3F
推
11/11 22:43, , 4F
11/11 22:43, 4F
→
11/11 23:23, , 5F
11/11 23:23, 5F
推
11/11 23:28, , 6F
11/11 23:28, 6F
→
11/12 11:47, , 7F
11/12 11:47, 7F
討論串 (同標題文章)