→ cha122977:金手指接關XD 04/14 00:29
推 TWTRubiks:感謝大大的解釋，蠻多說到我的心坎的!!尤其是一點一點只 04/14 12:21
→ TWTRubiks:出那邊(bug,新舊程式) 04/14 12:21
→ qrtt1:誰沒有菜過xd 04/14 12:53
※ 引述《TWTRubiks (阿哲)》之銘言：
: 目前我是電機系 - 大二(科大)的學生，二年級時開始對寫程式有了一點興趣，
: 大二上時先跑去修了大三的JAVA，然後二下就先找教授做專題了，由於是第一次做專題，
: 教授要求的，我們一組(2個人)就做(我們都是第一次做專題)，然後我做到今天，大約做
: 了1個多月而已，發現了一個蠻嚴重的問題.....
: 因為我們都是老師要求甚麼，我們就做甚麼.....到今天發現，這些東西程式根本串不起來
: ，也就是說，再做專題之前，我應該先把整個『架構』想好在下去做的，不然一堆程式碼
: 都是GOOGLE然後COPY再改一改而已(總覺得這樣沒什麼效率)
: P.S 做的時候是用第一次才接觸的 C#
: 所以，我看我下禮拜和組員討論時打算說，「我們是不是該砍掉重練了....」
: 我猜到時候和教授說一定要被罵了.....
: 結論: 我想請問版上高手幾個問題
: 1. 做一個企畫 or 軟體 or 專題 是不是該心裡有個稿，也就是說我哪裡要怎麼做之
: 類的!?
: 2. 還有哪些是要成為一個程式設計師必備的呢?! 肝?! 創意?!
: 如有違反版規~ 會自D
: 謝謝大家~
現在不是討論一個程式設計師該有的能力的時候。
現在讓你做專題，時間至少有一、二個學期，都會有一定的進度
就用你們目前有的能力「土炮」出任何做得出來的東西
知道那個「理想」中的境界對要面對的問題暫時沒有助益。
即使現在匆匆看了 design pattern、refactoring
testing driven development、continuous integration、...
... OOAD
都無法產生立即的效益，唯一的可能就是你是天才
可以短時間內吸收它們，並用在適當的地方。
你要面對的「架構」是什麼，先不要想成高階的 SD SA 的東西
如其他版友說的，要先知道「組出來是什麼東西」才能組得出來。
換個方向想，使用者如何使用你的東西？
他如何與你的「成品」互動？
每一個「互動」轉化到你的系統，該替使用者做些什麼？
最終，使用者應該獲得什麼回饋。
每一個步驟都明確了（使用者做什麼 vs 系統該回饋什麼）
你的東西就有明確的組成方式。
至於那個「理想的境界」只有幾個情況用得到：
*. bug 太多改不完
不知正規的手法，那就用新鮮的肝搞定
*. 要加新功能，怎麼容入舊的 code
不知正規的手法，那就 copy & paste 與新鮮的肝搞定
*. 功能全被翻掉了，但有些 code 想留下來重用
不知正規的手法，那就剪下貼上到新的 class 與新鮮的肝搞定
*. 覺得程式亂無章法，越來越改不動了
不知正規的手法，那至少減少每一個 class 與 method 的行數
切得稍為細一點，短一點。讓它亂得不要太誇張，
至少得整理到新鮮的肝能負荷的程度
*. 覺得找 bug 找到眼睛發麻，開始出現疊影
除了 stdout, stderr 輸出 debug message
別忘了學習 debugger 的用法，
二分搜尋法的概念很好用，
bug 的發生 （假定為單一 thread）
一定在某個狀態變更之前與之後，
不會寫 unit testing 至少要會用 debugger 配合二分搜尋法
好讓新鮮的肝能獲得多一點的休息
組不出來實在是不太可能，問題除了對目標掌握程度之外
就是對 library 或 api 用法的理解或誤解之別。
沒有好方法用時，就用笨方法，多花點時間還是能做出來的。
另外，專題才剛開始，最頭大之處在大家各別寫完後
組起來不會動！？這時刻很囧的
建議有 2 點：
1. 一開始先別理花悄的功能，先專注在流程上的整合
畫面可以是醜的，功能可以是陽春的，但一定要做到能動！
還沒實作到的部分，先寫個「假的」讓流程可以跑完
2. 孩子的教育不能等，剛開始入門有機會就摸摸版本控制系統吧
現實世界有金手指讓你無限接關不是很棒嗎！？
其他的...
等你程式會動了，主要目標都完成了。
心有餘力再來思考提昇品質吧（看看 clean code 還蠻輕鬆的）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.43.121.88