※ 本文為 cuteman0725 轉寄自 ptt.cc 更新時間: 2012-09-23 16:26:33
看板 Soft_Job
作者 標題 Re: [請益] 程式寫太慢..
時間 Sat Sep 22 02:04:40 2012
你要學會如何解決問題，而不是氣餒。
首先...
沒有人是什麼都會的
------------------
當你的主管拿了一份"作業"，說要讓你"練習"時，我相信他多少有心理準備，
知道你不會兩三下就交出來。因此，遇到問題解不開，絕對不是什麼罪該萬死的錯。
罪該萬死的是自己不會卻沒有去想法子，死線到了兩手一攤說我不會。
程式設計師的工作，大多數的時候都在想辦法解決自己不知道答案的問題。所以...
不懂，很正常！
以後只會碰到更多不會處理的問題，但是你還是要去解決，因為這就是你的工作。
沒有問題是不能解決的
--------------------
說實際一點的話好了，你既然是新人，那麼你所遇到的問題，通常都是可以處理的。
如果真的那麼難的話，你也不會在這裡發文問這種問題了。
不會很正常，問題又一定有解法，那麼還有什麼好擔心的 ?
解決"不會解決問題"的問題
------------------------
既然問題是有解的，那麼就只剩下找解法。怎麼做 ?
這個問題不好回答，因為我不清楚作業內容是什麼，不瞭解你的程度，也不知道你
卡在什麼環節上，更不曉得你做過了什麼樣的努力。但就我自己本身或看過的人的經驗
來說，通常都是這幾種狀況。
卡在什麼環節上，更不曉得你做過了什麼樣的努力。但就我自己本身或看過的人的經驗
來說，通常都是這幾種狀況。
1. 根本不知道問題在哪
這種現象很容易出現在第一次接觸的問題上，連自己為什麼不會都講不出
個所以然來。這個時候，你就需要仔細的去思考，是什麼地方不懂。
是不知道整個程式運作流程 ？不知道用什麼的技術 ？API 看不懂不會用 ？
程式寫出來有錯不知道原因 ？
如果現在有30秒的時間讓你問一個問題，你能夠馬上完整地描述你的困境，而非
單純把問題丟出去要答案嘛 ?
不行的話，開始著手釐清。
2. 不肯(敢)提問
怕被別人認為自己程度差，怕煩到同事前輩。明明答案只需要開口就有了，卻
不願意去問。大部份的程式設計師工作的時候，都身處於一個開發團隊裡。身為
團隊的一員，幫助同儕解決問題，本來就是應該的，更何況是幫助新人 ？而且我
認為會去做程式設計工作的人，大部份都樂意於幫忙解決程式上的問題。
團隊的一員，幫助同儕解決問題，本來就是應該的，更何況是幫助新人 ？而且我
認為會去做程式設計工作的人，大部份都樂意於幫忙解決程式上的問題。
溝通、合作是程式設計師的工作之一，因此不要怕和同事提問，他們可能都正預
期著你會問問題，如果不肯提問而造成工作無法達到目標，真的就是因小失大，
而未來你也該抱著如此的心態去幫助同事。
期著你會問問題，如果不肯提問而造成工作無法達到目標，真的就是因小失大，
而未來你也該抱著如此的心態去幫助同事。
如果沒有同事，或是同事真的沒辦法幫你解決問題 ？
網路上多的是程式的討論區，到處都有高手等著你發問，豈有藉口說沒人能問 ？
3. 不會找資料
3. 不會找資料
上面剛剛也說過了，問題通常早就被人問過，被人解決過了，可是在 Google 找
半天卻找不到解答，很多時候都是找的方式有問題。例如：Google 收尋時關鍵字
只打中文、只看中文網頁、不看技術文件... 云云，這些都是有問題的。拿英文
不好當藉口是不能讓問題消失的，資料來源範圍當然是越大越好。
半天卻找不到解答，很多時候都是找的方式有問題。例如：Google 收尋時關鍵字
只打中文、只看中文網頁、不看技術文件... 云云，這些都是有問題的。拿英文
不好當藉口是不能讓問題消失的，資料來源範圍當然是越大越好。
程式上的問題通常關鍵字以錯誤訊息、API來當作條件會是一個好的開始。找到
的資料太發散時，就多加一些和你問題有關的關鍵字。如果還是找不到，技術文
件通常會是一個很好的資料來源。如果完全沒有東西，那你可能是關鍵字範圍太
細，試著用英文描述問題的關鍵字，Google 會幫你多找出不少內容。
的資料太發散時，就多加一些和你問題有關的關鍵字。如果還是找不到，技術文
件通常會是一個很好的資料來源。如果完全沒有東西，那你可能是關鍵字範圍太
細，試著用英文描述問題的關鍵字，Google 會幫你多找出不少內容。
4. 你累了嘛？
寫程式是很燒腦力的事，為了解決問題而長時間不休息，只會讓效率更差。甚至
過度加班、熬夜使身體得不到休息，結果隔天精神更差。壓力很容易造成這種
惡性循環，你必需要學會處理這些壓力，並適度的讓你的身心休息。上洗手間、
喝水，找事離開座位幾分鐘走一走，腦袋休息一下。有時候在來回的路上你就會
靈光一閃。
喝水，找事離開座位幾分鐘走一走，腦袋休息一下。有時候在來回的路上你就會
靈光一閃。
如何提問
--------
雖然我說的好像大家都等著你發問，非常的美好。但現實生活上，你的同事都有自己
的工作要負責，就算你隔著螢幕問著住在世界另一端的大大，他也有自己的現實生活要忙
，因此有些準備工作你必需要先做好。
的工作要負責，就算你隔著螢幕問著住在世界另一端的大大，他也有自己的現實生活要忙
，因此有些準備工作你必需要先做好。
1. 想清楚你要問什麼問題
如果要問什麼都不清楚的話，要如何期待別人給出滿意的回答 ？花時間想辦法
弄清楚想問的東西，把範圍縮小，絕對不要拋出一個無邊無際的問題。
如果想問的是程式的問題，較好的方式是想辦法弄出一個可以重現問題的範例，
這個作法叫做 SSCCE (Short, Self Contained, Correct (Compilable),
Example, http://sscce.org/ )。為什麼要這樣做 ？一方面是讓回答的人可以
Short, Self Contained, Correct Example
Describes the short, self contained,
correct example. A useful technique for debugging. ...
Describes the short, self contained,
correct example. A useful technique for debugging. ...
摸索出問題癥結所在。
2. 提問前先嘗試解決
千萬不要因為問了就有答案而拼命提問，很少有人會喜歡回答一個去 google
就有一堆資料的問題。程式有 bug 找不到問題 ？試著一行一行的把程式解釋
給自己聽( http://en.wikipedia.org/wiki/Rubber_duck_debugging )。答案
Rubber duck debugging - Wikipedia, the free encyclopedia
![[圖]]()
Rubber duck debugging,[1], rubber ducking,[2] and the rubber duckie test[3] are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all t ...
![[圖]](http://i2.disp.cc/s/upload.wikimedia.org/wikipedia_commons_thumb_d_d5_Rubber_duck_assisting_with_debugging.jpg_220px-Rubber_duck_assisting_with_debugging.jpg)
3, 尊重對方的時間
雖然幫助同事是應該，但不要忘了公司裡的每個人都有自己的事要忙。整理好你
的問題，一次問完，不要每十分鐘就跑去打斷對方工作。如果不確定對方是否有
空幫你，那麼就問是否有適合的時間能和他請教。
的問題，一次問完，不要每十分鐘就跑去打斷對方工作。如果不確定對方是否有
空幫你，那麼就問是否有適合的時間能和他請教。
要講的話還有很多可以講，有空時可以讀讀這篇，雖然有點舊了，但仍然是很好的一篇文
章。
提問的智慧（How To Ask Questions The Smart Way）
http://www.chweng.idv.tw/smart-questions.php
--
We who cut mere stones must always be envisioning cathedrals.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.35.186.241
推 :推這篇，不光是寫程式，很多方面都是這樣1F 09/22 02:41
推 :強力推，受用不盡2F 09/22 03:50
推 :推3F 09/22 04:15
推 :不只是寫程式的要看! 團隊合作的都該看4F 09/22 06:11
推 :這篇寫得真好！光是知道問題在哪都要練很久5F 09/22 09:11
→ :推SSCCE 我也是無中生有自己習得這個方法XD6F 09/22 09:20
推 :這一定要推一下7F 09/22 09:22
推 :推這篇~8F 09/22 10:07
推 :有看有推9F 09/22 11:06
推 :請教問題要請吃飯.10F 09/22 11:11
→ :推一個 熱心教學11F 09/22 11:46
推 :大推這篇！12F 09/22 12:06
推 :大推!!寫得真好!!13F 09/22 12:43
推 :好用心~推~~~14F 09/22 13:09
推 :推～15F 09/22 13:22
推 :推~~16F 09/22 18:26
推 :推這篇17F 09/22 19:12
推 :推這篇18F 09/22 19:43
推 :大推.. 你累了嗎~~19F 09/22 22:49
--
作者 awert 的最新發文:
- 你要學會如何解決問題，而不是氣餒。 首先... 沒有人是什麼都會的 ------------------ 當你的主管拿了一份"作業"，說要讓你"練習"時，我相信 …19F 17推
- 用推文有點慢.. 我的想法是這樣子的，這個idiom並沒有問題。 但是，實際寫code時遇到要處理null問題時， 我不會鑽牛角尖考慮哪一種處理null的方式比較漂亮/有效率， 而是要先看為什麼要處理 …1F
- 理論上是第二種，差別單純在於 a如果是null時，不會有NullPointerException 但我覺得微調這個沒有太大意義就是了..1F
(￣︶￣)ｂ abc1231qa 說讚！
回列表(←)
分享