Access這套軟體就是你夢想中的軟體,可增減欄位+可修改欄位屬性(如正負價錢)+可修改欄位名稱....甚至可以寫程式來控制,但是你認為它還是不好上手! 所以對一個電腦生手來說,寫得太彈性就變成不好用了,也就不會去買它了!

延續 #1
就算是老手好了

像我寫的「SQL 動態欄位交叉定位表」
寫的很活，也算蠻複雜的
可是每次要改寫到另一個新表
就很懶得寫

※>> 寫得太彈性就變成不好用了

>>本來只可賣給一家公司
我猜您指的是如果將欄位等都寫死,只能賣一家

>>現在是可賣給20家公司
但如果寫活一點,就可以有機會賣給很多家, 但您忘了, 二種寫法的開發成本並不是相同的

>>假設本來一套賣1萬元，現在是一套賣2千元，如此一來創造雙贏的局面
如果您覺得真的很好賣,不妨向programmer保證一寫完就先付100份或一萬份的錢, 既然寫死的都能賣1萬,寫活的也沒必要賣2千啊,仍賣一萬有何不可呢? 如果您只是想出點子, 請programmer花心力去寫, 若真有收益才有機會雙贏, 那麼請問若到時賣得不好, 您給programmer什麼保障呢? 您覺得那是他讓負的風險,是嗎? 如果您這麼認為, 您可以繼續再等等看, 或許真的有與您志同道合的人願意拼拼看

那如果說你們常常寫到類似的軟體，是寫的很活的從中修改還是重頭寫起那一個比較好寫？

如果單純地只從您#4的問題,不去斷章取義地聯想
我的看法是
>>如果說你們常常寫到類似的軟體
我個人很少寫到類似的, 雖然接過7,8百個案子,但很少類似的, 因此平時只會寫更底層的副程式, 以便各專案共用

>>是寫的很活的從中修改還是重頭寫起那一個比較好寫？
這點的答案也不是那麼容易界定的, 我舉個簡單的例子好了, 如果客戶要您寫一支簡單的留言板, 只肯給您幾千元
那麼您要不要先寫一個可以經由設定就變成論壇, 討論板, 留言板,又能調整各個細部邏輯(留言者是否必需是會員, 能不能指定開放回應,要不要有驗證碼,..), 並且要能有多用戶的概念, 要不要多國語系, 要不要支援各式database,要不要能靈活地套用版型, ...

就算接到第一個留言板時寫了簡單版本,請問又再次接到時要不要從上個簡單版小改就好了呢? 要接幾個留言板才會促使您想要寫上述這麼"活"的呢? 如果下一個客戶仍只肯支付1,2千來擁有一個留言板時, 您肯不肯將這個這麼"活"的系統送給客戶呢?

以我的想法, 通常是一開始就決定寫package,才會寫得比較活, 因為打定主意要賣給不特定的人, 至於承接專案時,比較少會寫得太活(某種程度的靈活設定自然是有的), 就算真的會拿之前的案子來修改, 也不必因此少收一點錢,因為客戶的規格並不會因為您之前的案子而牽就您

不知道您所謂的：「可增減欄位+可修改欄位屬性+可修改欄位名稱」是指資料庫呢？還是指表單？

一般來講，一個應用程式是不太可能讓使用者在使用過程中隨意更改資料庫的結構。



若是您所謂的更改是指表單，例如有些零件的估價，如果是市售品，可能就只有一個「進貨單價」之類的欄位。

而加工件可能會有原材料、而原材料又有依重量或是依尺寸計算。

之後有可能有鉋床（為了除去黑皮）、銑床、鑽孔、熱處理、磨床、放電加工、線切割、治具磨床…等加工流程，

每種零件的加工程序（需要幾道加工）都會有所不同，而各種加工流程又有各種不同的計算方式。

所以這個估價程式如果沒辦法自由「可增減欄位+可修改欄位屬性+可修改欄位名稱」那就是寫得太爛了。



當然啦，我們寫程式的人，會在一定程度內將程式寫得活，但是不可能會去想寫一個適合各種業界都合用的『通吃』估價系統，

『通吃』不只是開發困難，且如果真的有這個市場且開發得出一個可全世界『通吃』的程式，一些軟體大廠早就搶著做了，不會輪到小咖來做的。

製造業的估價可不可以用
1.原物料(包含回收原物料造成的影響)
2.工資
3.費用
這3個項目全包？

阿源哥哥我覺得我想更改的是資料庫的結構。

全部應該由程式做的事
動到資料庫的結構做啥?

因為原先銅粉的回收有表達在Excel的表上和文字敘述上，程式設計師寫程式過程中從建產品資料和客戶資料一步一步確認，後來他卻說沒跟他講銅粉的影響，好像要修改很多地方很浪費時間，我是不知道問題的癥結在哪裡，因為站在消費者的立場花一樣的錢也是希望軟體早一點寫好。

如果有寫在規格裡,就提醒對方一下即可, 如果是他疏忽了,要改多少地方也是他需要概括承受的才是

是不是當初程式碼怎樣寫，就算當初沒把銅粉這加工過程所產生的東西可回收可以賣錢也能由消費者自行調整，避免這種情形發生？

阿源哥哥是不太能夠理解：「一個應用程式可以允許使用者任意更改資料庫結構」。

就個人粗淺的認知，您的需求就好像是一個購物商城的購物車一樣。

對於一個單一零件的估價就類似是一次的購物行為，所以主表單就是一些對於該零件的描述，

也就是能夠對應出讓人知道是對哪一個零件估價的綜合訊息。

而接下來的子表單就是類似該次的購物清單，就像是一台購物車可以包含各種類型、各種計價方式的商品一樣，

估價清單也是可以包含各種類型、各種計價方式的加工流程。

就像購物商城的程式不會將所販售的商品及計價方式『寫死』一樣，估價方式也不會是『寫死』的。

就像是您所提的『把銅粉這加工過程所產生的東西可回收可以賣錢』也只是想像成有一道程序（程序名稱是可自行設定的）

其計價方式是『負』的，這麼一來，在最後的類似購物總金額中自然會將這項回收金額扣回來了。

>>是不是當初程式碼怎樣寫，就算當初沒把銅粉這加工過程所產生的東西可回收可以賣錢也能由消費者自行調整，避免這種情形發生？
您的要求就不一定是合理的, 當初沒有講這規格, 人家當然就不一定要幫您寫進去

以我幾年前的案子為例, 客戶要做一個線上送贈品的活動,要求我給的機率是1/400, 也就是每400個人參加抽獎才可以一個人中獎;結果活動進行一段時間後,客戶反應"我東西送光了,怎麼還有人在得獎呢?"
我怎麼會知道他準備多少數量的獎品呢? 一天如果一百人,或十萬人參加,我根本無法預測,客戶沒有要我計算獎品數量的問題,我當然不會去做它, 至於中獎機率要不要能夠調整呢? 就看我的良心了,理論上客戶沒要求,我也没必要做, 如果我覺得這是順手就做得到的,自然會評估一下要不要順手做掉,但無論如何,只要客戶沒有提"要能夠調整中獎機率"我就覺得寫死也是ok的

至於您先前提到的態度"若下一次又要做,中獎率改成可以設定, 獎品數量可以設定,不是下次又接到時,會改得更快嗎?", 那就不一定了,事實我寫的幾百個案子裡,抽獎也就寫那麼一次, 我當然不會over design囉(純粹是成品考量)

"就像是您所提的『把銅粉這加工過程所產生的東西可回收可以賣錢』也只是想像成有一道程序（程序名稱是可自行設定的）

其計價方式是『負』的，這麼一來，在最後的類似購物總金額中自然會將這項回收金額扣回來了。"

銅粉的觀念我是一開始就有表現在Excel上和文字敘述上，就算沒注意到我也認為是負的不就解決了，為什麼還要改很多的感覺？
銅粉也有牽涉到產品的重量減少，但不是負的也就解決了嗎？