InnoDB error : Total number of locks exceeds the lock table size

InnoDB error : Total number of locks exceeds the lock table size

mysql> show engine innodb status\G

Solution: increase the innodb_buffer_pool_size

Reference:
http://www.pythian.com/news/22699/innodb-error-total-number-of-locks-exceeds-the-lock-table-size/

被迫才是進步的原動力

昨天看到神人 vgod 寫了一篇 過早最佳化是萬惡的根源，這篇文章是不錯。但是，對於「職業」那邊實在有太多奇怪的假設。

想了一下，決定還是在 FB 寫了一下我的看法，然後再轉貼到這裡來。

===

簡單回一下好了。關於職業的部分。我本來也是覺得就如同跟 @vgod 一樣所說，在裡面可以全新鍛鍊和學習各種知識和技能。

我在大學裡面，就是抱著這樣的心態，學習各種知識。我在大學裡面最認真修的課，不是數學（唯一感興趣的是線性代數、離散數學、代數） ，而是….去修資科系基礎理論的課，什麼作業系統、計算機結構、演算法、資料結構、數位電路、etc…大概能修的我都修了。數學系最 重視的微積分、高等微積分，我沒有很喜歡。而且，我大概下課的時間都泡在系上的機房，弄網路、伺服器、寫寫簡單的網站。

而最後我也是抱著這樣的心態，選擇了第一份工作。因為我覺得大學的環境才能讓「自己有選擇想練什麼武功的自由」。 我希望一直這樣持續下去。

然而，接下來的事情。你們知道了，我被打臉了。狠狠的打了一巴掌。

那一天，我才發現我關在學校自己練的等級，跟職業的人是差上那麼多。這才是讓我選擇馬上離開那個環境的主因。

很多人以為「自己有選擇想練什麼武功的自由」，才能讓自己的 power 開到最大。我對這件事情有截然不同的感受。為什麼職業的環境會成長很快。因為上班領錢，才有限時被交出成果的壓力。而且那個壓力能造成的動力是遠比自己下定決心要練什麼技能的動力還要可怕的。上班，你會被迫限時學到跟這個領域所有「基礎」的工具。一個月「基礎的程度」，可能直接贏掉自己自由學「半年」以上的程度。

而且特別是，如果你的同事和老闆，都是佼佼者的話….。到現在我還是相當感謝曾經共事過的 @gugod, @ihower, @gslin, @hlb, @嬸嬸 XD

我學到的就是。如果你想把什麼東西學好，稍微深呼吸一下（當然就是自學一點皮毛，希望不要進去之後死太慘），就跳下去…。 害怕溺水的恐懼會被讓你瞬間就學會游泳。（如果你跳下去就死拜託不要怪我…orz）

如果你曾經看過我半年前寫過的為什麼我想創業 一文。 你就會知道，我在這四年裡面「被迫」學會了多少事。

職業工程師，並不是只有用 PHP 寫了一千個論壇和購物程式那麼無聊。老實說，寫到第二個第三個，你就會知道 Framework 的重要性。

當然，如果你之後玩到神兵級 Framework 如「Ruby on Rails」。那麼你還會更會知道，這世界不是只有 CRUD。（Ruby on Rails 本身 的架構採用了大量 Patterns of Enterprise Application Architecture 這本書裡面的實作，裡面也大量用了 Design Pattern 的技巧）。

不只如此，你還會從周遭的 ecosystem 的 plugin 中學到各種各式各樣的 pratical、theoretical 的佼佼實作。

當這些東西看多了以後你就更進一步的發現，語言根本不是重點，掌握這些「企業級理論」（註）的核心精隨，才是重點。

而當進一步又將 Ruby on Rails 玩的十分純熟之後。就會馬上意識到，用什麼語言寫，把 code 寫得多快已經完全不是重點了。

• 如果專案控管能力不佳，需求一直在改變，那麼就算你的「架構理論」玩的再漂亮都是一樣的，結不了案就是結不了案。
• 如果團隊協調能力不佳，那麼不管公司投再多人進來，累死的就是那幾個人而已。
• 如果時間成本能力不佳，不是會造成公司大虧損賠本，甚至會專案進行到一半就被迫終止。

很多人以為我網站寫的很快，是因為 Framework 的關係。真的不是這麼簡單…，那是我身上擁有所有的技巧綜合出來的結果。

如果我沒有領錢「被迫」進行我很多「不喜歡」的事，我不會學到這一些東西。如果我沒有「被迫」去處在那一些環境，我能學到的東西就限於「我在學校時一開始能望過去的眼界」，而不是環繞在我周遭各個神人的眼界。

而這也是為什麼我會寫出那兩篇文章的初衷。我不是出來走這麼一遭，不會發現我當初那樣的假設，完全不堪一擊。

而再舉一個例子，曾經很多人一直對我，開口閉口就是 Ruby on Rails 值得學習，感到很不解。事實上，我也是從這個 Framework 的進化裡面， 才學到人不能把眼界只侷限在某一個端點。我個人的能力，很大的原因是跟隨這個 Framework 一起成長的。如果我當初不是碰這個 Framework 起來，我恐怕真的沒有這個能力成長的這麼迅速。因為台灣沒有太多「大型」Scale （PV 千萬以上） 的網站，可以逼迫一個工程師直接從最基礎的 Turtorial 中，自學到那麼多 optimze techniques、best practices（更何況這種等級公司的入場卷，也不是你說想要應徵就能應徵上)。

從這個 Framework ecosystem 裡面產生出來的 plugin 也是世界上各式各地的程式設計師貢獻出來的，這裡面融合了他們公司現在「最好」的 pratices，有些甚至是 future architecture。如果我在一間悶頭自幹工具的公司上班，我是沒有機會見識到這一切的。

我不認為自己一開始有多好的眼界，能有辦法看到多棒的未來，並且照著我所看到的事堅定的往前走。甚至，直到現在，我現在還是不認為自己還是具備這個能力。但我唯一知道的是，我不能把自己鎖在自己的眼界裡。

我想說的話，就只有這樣而已。

[註] ：Deisgn Pattern、Agile、Testing、Scaling、Performace Tuning …

Reference:

http://blog.xdite.net/posts/2012/10/28/force-to-improve-yourself

程式技術這條路 - 北冥神功還是吸星大法

沒看過豬走路，也該吃過豬肉，沒走過那些年，也應該聽過九把刀，沒讀過武俠小說，也肯定聽過金庸這號人物，學習程式設計某種程度就像在練武功，天下武功，無堅不摧，唯快不破， 任何問題，只要功力夠強，都能夠找到解決之道，然而再強之人都有他不熟悉的領域，而唯一能確保自己立於不敗之地的方法便是快，快速摸索，快速理解，快速學習，快速解決問題。

然而快只是千錘百鍊，無盡鍛鍊後的結果，變快的過程卻是條漫漫長路，是功力的累積，更是建構基礎與觀念的浩大工程，但這條長路有人走正道，有人走偏鋒，前者就如同修鍊北冥神功，後者猶如吸星大法，在金庸的武俠小說裏，兩者均是上乘內功，表面相同，運作的方式卻大相逕庭，北冥神功厲害之處在於其將對手內力吸納匯至自身體內，轉化融合成一道北冥真氣之後化為已用，吸星大法同樣會吸納內力，不同之處在於這些內力匯入體內之後只會被保留下來而不會進一步轉化，由於各派武功內力特質屬性天差地遠，運使化功大法者，可能因為體內同時存在各種不同的內力相互排斥遭到反噬而身受其害。



程式功力欲臻化境，無論走那一條路就是練，練就要時間，但是走偏鋒者偏偏就不信， 拜 Google 大神有之，上論壇要答案有之，更不要臉者，無視自身一幅猥瑣，直接點江湖中的某某大師坐檯吃吃豆腐順便要答案， 大師即便佛心來著不與之計較，奉上武功秘笈套譜猶嫌不足，挑明給個頁數找到答案直接抄抄了事。招數有了卻不練，儘想著直接拿來套招，內力匯入體內卻不轉化，終致走火入魔 ~

走正道者，往往從基本功打起，瞭解最基礎的程式設計原理、語法與資料結構，遍歷類別、函式庫摸索物件功能設計背後的原理， 經年累月續積內力終致神功大成，往後再遇到任何新的技術即能快速消化並換化作為己用。

在這個海量資訊的時代，技術本身早已不值錢，辛辛苦苦寫的程式碼根本不值一曬，任何成功的軟體與服務都沒有辦法被複製，因為關鍵不在技術本身，燃燒的熱情是唯一重要的事，如果沒有這樣一顆心，為什麼還要在這一行浪費人生？

好吧，隨便寫寫就隨便看看吧 XD

本網站已經不再更新了，請移駕至康廷數位（http://www.kangting.tw），不便之處還請見諒。

回應
# re: 技術這條路 - 北冥神功還是吸星大法
當然是全部內化，而成已用啊。
2011/11/28 下午 11:48 | 小賤健 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
你畫的圖 北冥神功 練成一團肥肉 :步入中老年 ....

吸星大法 是六塊腹肌 :年輕人 .....
2011/11/28 下午 11:49 | JT_taipei 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
我比較喜歡嫁衣神功! 分享才有得!

2011/11/29 上午 12:19 | Jason 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
to 小賤健：不過北冥神功有旦書，對手的內力不能太強，不然還沒吸到自己先掛了，所以按步就班真的很重要　　：D

to JT_taipei ：所以厲害的程式人都是坐到一層肥肉嗎XD

to Jason：古龍的比較沒在練，不過分享幾乎是所有程式人都很喜歡作的事對吧，哈

2011/11/29 上午 08:15 | 呂高旭 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
個人是比較喜歡 六脈神劍 跟 降龍18掌
看清楚 ,是18掌,不是18招喔
2011/11/30 上午 12:44 | 貼地飛行 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
帥哦，北冥神功是程式人必修內功，至於 六脈神劍 與 降龍18掌 小弟我一直認為就是外功囉，等書的範例喬一段落，改天來寫一篇好了XD

2011/11/30 下午 01:36 | 呂高旭 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
那天才可以練好北冥神功呢.....

2011/11/30 下午 03:26 | 打雜妹 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
北冥神功其實是一種態度， 六脈神劍 與 降龍18掌 才需要鍛鍊 XD

2011/11/30 下午 09:02 | 呂高旭 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
請問一下，我比較喜歡

燃燒自己的小宇宙（聖鬥士 星矢）.....算是那一派系？ :-P

這句話，大推～～「更不要臉者，無視自身一幅猥瑣，直接點江湖中的某某大師坐檯吃吃豆腐順便要答案， 大師即便佛心來著不與之計較，奉上武功秘笈套譜猶嫌不足，挑明給個頁數找到答案直接抄抄了事。」

2011/12/2 下午 03:59 | MIS2000 Lab. (ASP.NET 專題實務) 回覆
# re: 技術這條路 - 北冥神功還是吸星大法
感謝 MIS2000 Lab ~~

「燃燒吧，我的小宇宙」是熱情吧，這句話也是我目前的心情寫照，這種熱血的心情是程式設計師立足的根本了，我想

現在每天都超熱血，準備等待 2012 年後出關，迎接令人振奮的軟體新世紀XD

Reference:
http://www.dotblogs.com.tw/kangting/archive/2011/11/28/59874.aspx

The Tao Of Programming

Translated by Geoffrey James
Transcribed by Duke Hillard
Transmitted by Anupam Trivedi, Sajitha Tampi, and Meghshyam Jagannath
Re-html-ized and edited by Kragen Sittler
Updated html layout and styles by Douglas Richardson

---

Table of Contents

1. The Silent Void
2. The Ancient Masters
3. Design
4. Coding
5. Maintenance
6. Management
7. Corporate Wisdom
8. Hardware and Software
9. Epilogue

---

Book 1 - The Silent Void

Thus spake the master programmer:
“When you have learned to snatch the error code from the trap frame, it will be time for you to leave.”

1.1

Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming.
If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is great, then the application is great. The user is pleased and there exists harmony in the world.
The Tao of Programming flows far away and returns on the wind of morning.

1.2

The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.

1.3

In the beginning was the Tao. The Tao gave birth to Space and Time. Therefore Space and Time are Yin and Yang of programming.
Programmers that do not comprehend the Tao are always running out of time and space for their programs. Programmers that comprehend the Tao always have enough time and space to accomplish their goals.
How could it be otherwise?

1.4

The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it.
If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear.
Going forward is a way to retreat.
Great talent shows itself late in life.
Even a perfect program still has bugs.

---

Book 2 - The Ancient Masters

Thus spake the master programmer:
“After three days without programming, life becomes meaningless.”

2.1

The programmers of old were mysterious and profound. We cannot fathom their thoughts, so all we do is describe their appearance.
Aware, like a fox crossing the water. Alert, like a general on the battlefield. Kind, like a hostess greeting her guests. Simple, like uncarved blocks of wood. Opaque, like black pools in darkened caves.
Who can tell the secrets of their hearts and minds?
The answer exists only in Tao.

2.2

Grand Master Turing once dreamed that he was a machine. When he awoke he exclaimed:

“I don't know whether I am Turing dreaming that I am a machine, or a machine dreaming that I am Turing!”

2.3

A programmer from a very large computer company went to a software conference and then returned to report to his manager, saying: “What sort of programmers work for other companies? They behaved badly and were unconcerned with appearances. There hair was long and unkempt and their clothes were wrinkled and old. They crashed our hospitality suite and they made rude noises during my presentation.”
The manager said: “I should have never sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conventions?
“They are alive within the Tao.”

2.4

A novice asked the Master: “Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?”
The Master replies: “That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.”

---

Book 3 - Design

Thus spake the master programmer:
“When the program is being tested, it is too late to make design changes.”

3.1

There once was a man who went to a computer trade show. Each day as he entered, the man told the guard at the door:

“I am a great thief, renowned for my feats of shoplifting. Be forewarned, for this trade show shall not escape unplundered.”

This speech disturbed the guard greatly, because there were millions of dollars of computer equipment inside, so he watched the man carefully. But the man merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes, but nothing was to be found.
On the next day of the trade show, the man returned and chided the guard saying: “I escaped with a vast booty yesterday, but today will be even better.” So the guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his curiosity no longer. “Sir Thief,” he said, “I am so perplexed, I cannot live in peace. Please enlighten me. What is it that you are stealing?”
The man smiled. “I am stealing ideas,” he said.

3.2

There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, “What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.”

3.3

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: “Which is easier to design: an accounting package or an operating system?”
“An operating system,” replied the programmer.
The warlord uttered an exclamation of disbelief. “Surely an accounting package is trivial next to the complexity of an operating system,” he said.
“Not so,” said the programmer, “when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.”
The warlord of Wu nodded and smiled. “That is all good and well, but which is easier to debug?”
The programmer made no reply.

3.4

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?”
“It will take one year,” said the master promptly.
“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”
The master programmer frowned. “In that case, it will take two years.”
“And what if I assign a hundred programmers to it?”
The master programmer shrugged. “Then the design will never be completed,” he said.

---

Book 4 - Coding

Thus spake the master programmer:
“A well-written program is its own heaven; a poorly-written program is its own hell.”

4.1

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.

4.2

A novice asked the master: “I have a program that sometime runs and sometimes aborts. I have followed the rules of programming, yet I am totally baffled. What is the reason for this?”
The master replied: “You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.
“The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment.”
“But how will I know when I have received enlightenment?” asked the novice.
“Your program will then run correctly,” replied the master.

4.3

A master was explaining the nature of Tao of to one of his novices. “The Tao is embodied in all software - regardless of how insignificant,” said the master.
“Is the Tao in a hand-held calculator?” asked the novice.
“It is,” came the reply.
“Is the Tao in a video game?” continued the novice.
“It is even in a video game,” said the master.
“And is the Tao in the DOS for a personal computer?”
The master coughed and shifted his position slightly. “The lesson is over for today,” he said.

4.4

Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without an error message, and the program ran like a gentle wind.
“Excellent!” the Prince exclaimed, “Your technique is faultless!”
“Technique?” said the programmer turning from his terminal, “What I follow is Tao - beyond all techniques! When I first began to program I would see before me the whole problem in one mass. After three years I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off.”
Prince Wang said, “Would that all of my programmers were as wise!”

---

Book 5 - Maintenance

Thus spake the master programmer:
“Though a program be but three lines long, someday it will have to be maintained.”

5.1

A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
Software rots if not used.
These are great mysteries.

5.2

A manager asked a programmer how long it would take him to finish the program on which he was working. “It will be finished tomorrow,” the programmer promptly replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long will it take?”
The programmer thought for a moment. “I have some features that I wish to add. This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be satisfied if you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.

5.3

A novice programmer was once assigned to code a simple financial package.
The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
When the master asked about this, the novice became indignant. “Don't be so impatient,” he said, “I'll put in the financial stuff eventually.”

5.4

Does a good farmer neglect a crop he has planted?
Does a good teacher overlook even the most humble student?
Does a good father allow a single child to starve?
Does a good programmer refuse to maintain his code?

---

Book 6 - Management

Thus spake the master programmer:
“Let the programmers be many and the managers few - then all will be productive.”

6.1

When managers hold endless meetings, the programmers write games. When accountants talk of quarterly profits, the development budget is about to be cut. When senior scientists talk blue sky, the clouds are about to roll in.
Truly, this is not the Tao of Programming.
When managers make commitments, game programs are ignored. When accountants make long-range plans, harmony and order are about to be restored. When senior scientists address the problems at hand, the problems will soon be solved.
Truly, this is the Tao of Programming.

6.2

Why are programmers non-productive?
Because their time is wasted in meetings.
Why are programmers rebellious?
Because the management interferes too much.
Why are the programmers resigning one by one?
Because they are burnt out.
Having worked for poor management, they no longer value their jobs.

6.3

A manager was about to be fired, but a programmer who worked for him invented a new program that became popular and sold well. As a result, the manager retained his job.
The manager tried to give the programmer a bonus, but the programmer refused it, saying, “I wrote the program because I thought it was an interesting concept, and thus I expect no reward.”
The manager upon hearing this remarked, “This programmer, though he holds a position of small esteem, understands well the proper duty of an employee. Let us promote him to the exalted position of management consultant!”
But when told this, the programmer once more refused, saying, “I exist so that I can program. If I were promoted, I would do nothing but waste everyone's time. Can I go now? I have a program that I'm working on."

6.4

A manager went to his programmers and told them: “As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon.” At this, all of them became angry and several resigned on the spot.
So the manager said: “All right, in that case you may set your own working hours, as long as you finish your projects on schedule.” The programmers, now satisfied, began to come in at noon and work to the wee hours of the morning.

---

Book 7 - Corporate Wisdom

Thus spake the master programmer:
“You can demonstrate a program for a corporate executive, but you can't make him computer literate.”

7.1

A novice asked the master: “In the east there is a great tree-structure that men call `Corporate Headquarters'. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying `Go, Hence!' or `Go, Hither!' and nobody knows what is meant. Every year new names are put onto the branches, but all to no avail. How can such an unnatural entity be?"
The master replied: “You perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness?”

7.2

In the east there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its mark upon the beach. Then the bird mounts on the wind and, with the blue sky at its back, returns home.
The novice programmer stares in wonder at the bird, for he understands it not. The average programmer dreads the coming of the bird, for he fears its message. The master programmer continues to work at his terminal, for he does not know that the bird has come and gone.

7.3

The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master's office while the master waited in silence.
“This is an integrated, distributed, general-purpose workstation,” began the magician, “ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state of the art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?”
The master raised his eyebrows slightly. “It is indeed amazing,” he said.
“Corporate Headquarters has commanded,” continued the magician, “that everyone use this workstation as a platform for new programs. Do you agree to this?”
“Certainly,” replied the master, “I will have it transported to the data center immediately!” And the magician returned to his tower, well pleased.
Several days later, a novice wandered into the office of the master programmer and said, “I cannot find the listing for my new program. Do you know where it might be?”
“Yes,” replied the master, “the listings are stacked on the platform in the data center.”

7.4

The master programmer moves from program to program without fear. No change in management can harm him. He will not be fired, even if the project is cancelled. Why is this? He is filled with Tao.

---

Book 8 - Hardware and Software

Thus spake the master programmer:
“Without the wind, the grass does not move. Without software, hardware is useless.”

8.1

A novice asked the master: “I perceive that one computer company is much larger than all others. It towers above its competition like a giant among dwarfs. Any one of its divisions could comprise an entire business. Why is this so?”
The master replied, “Why do you ask such foolish questions? That company is large because it is large. If it only made hardware, nobody would buy it. If it only made software, nobody would use it. If it only maintained systems, people would treat it like a servant. But because it combines all of these things, people think it one of the gods! By not seeking to strive, it conquers without effort.”

8.2

A master programmer passed a novice programmer one day. The master noted the novice's preoccupation with a hand-held computer game. “Excuse me,” he said, “may I examine it?”
The novice bolted to attention and handed the device to the master. “I see that the device claims to have three levels of play: Easy, Medium, and Hard,” said the master. “Yet every such device has another level of play, where the device seeks not to conquer the human, nor to be conquered by the human.”
“Pray, great master,” implored the novice, “how does one find this mysterious setting?”
The master dropped the device to the ground and crushed it underfoot. And suddenly the novice was enlightened.

8.3

There was once a programmer who worked upon microprocessors. “Look at how well off I am here,” he said to a mainframe programmer who came to visit, “I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self- consistent and easy-to-use. Why do you not quit your present job and join me here?”
The mainframe programmer then began to describe his system to his friend, saying “The mainframe sits like an ancient sage meditating in the midst of the data center. Its disk drives lie end-to-end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am.”
The microcomputer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.

8.4

Hardware met Software on the road to Changtse. Software said: “You are Yin and I am Yang. If we travel together we will become famous and earn vast sums of money.” And so the set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rags and hobbled along propped on a thorny stick. Firmware said to them: “The Tao lies beyond Yin and Yang. It is silent and still as a pool of water. It does not seek fame, therefore nobody knows its presence. It does not seek fortune, for it is complete within itself. It exists beyond space and time.”
Software and Hardware, ashamed, returned to their homes.

---

Book 9 - Epilogue

Thus spake the master programmer:
“It is time for you to leave.”

---

Reference:
http://huffman.sourceforge.net/tao/tao-of-programming.html

程式設計之道

THE DAO OF PROGRAMMING Geoffrey James
程式設計之道 冼鏡光
微電腦時代96,97
第一部 寂靜虛無篇
大師如是說:"學會從程式抓蟲子之後, 就可以畢業了
1.1 節
.寂靜虛無中有奧秘, 不動不靜, 乃程式之源, 吾無以名之, 故稱之為程式設計之道.
.若道至大, 則作業系統至大; 若作業系統至大, 編譯程式亦然; 若編譯程式至大,
則應用程式亦復如是, 是故使用人大悅, 世有和諧存焉.
1.2 節
.程式設計之道無遠弗屆, 雖晨曦微風而返.
.道生機器語言, 機器語言生組譯程式.
.組譯程式生編譯程式, 於是萬餘語言存焉.
.各語言有其目的, 均表達軟體之陰陽; 其在道中亦各得其所.
.但若能避免, 就不要用COBOL 寫程式.
1.3 節
.太初有道, 道生時空, 故時空乃程式設計之陰陽.
.程式員不悟道則時空永不敷使用, 悟道者恒有充份時空完成目標.
1.4 節
.上智程式員聞道而行之, 中智程式員聞道而求之, 下智程式員聞道而笑之.
.若無笑聲則無道矣.
.至高之聲難以聽聞.
.前進就是後退之路; 大智總是晚成; 每一個完美的程式仍有BUG.
.道在所有知識之外.
第二部 古之大師篇
大師如是說:"三日不寫程式則生命無趣.
2.1 節
.古程式員神秘而深奧, 無以度量其思維, 僅能描述其表象.
.像狐狸涉水般地小心; 像戰場老兵般地警覺; 像未經琢磨的木頭般地璞拙;
像洞中深潭地不透明.
.誰能指出他們心靈中的秘密?
.答案全在道中.
2.2 節
.大師Turing曾經夢到他是一部電腦, 醒後道:
. "不知是我Turing作夢變成機器, 還是一部機器作夢變成我我Turing."
.一家大電腦公司的程式員參加軟體會議後, 向他的經理報告說:"你知道其他電腦
公司有什麼程式員嗎? 他們不修邊幅, 頭髮長而邋遢, 衣服既舊且皺, 他們破壞
了氣氛, 而且我簡報時老是製造噪音."
.經理說:"我根本就不應該派你參加會議, 這些程式員超然物外, 他們把生命看成無稽,
意外的結合. 他們往來而無藩籬, 為他們的程式而活, 為什們他們一定要受社會積習
的約束?
.他們生活在道中."
2.3 節
.生手問大師:"有一個程式員從不設計, 測試程式, 寫作文獻, 但了解他的人都認為
他是世間最好的程式員. 為什麼?"
.大師曰:"這個程式員已充份悟道, 他超越了設計的需要; 系統垮了不會生氣,
而無條件接受這個世界. 他超越了文獻的需要, 他不再計較是否有人看他的程式.
他也超越了測試的需要, 他的每一個程式都圓滿無缺, 清澈, 優雅, 目的自明.
.是的, 他已悟道, 登堂入室.
第三部 設計篇
大師說:"到測試程式時再回頭修改設計就太遲了."
3.1 節
.曾經有人在參觀電腦展每天進門時都向警衛說:"我是的妙賊, 偷東西的技巧已臻化境,
先告訴你, 我絕不會放過這次展覽."
.這段話刺激到警衛, 因為展覽場有好幾百萬元價值的儀器, 所以老是盯這他,
不過卻只看到這個人一個攤位接著一個攤位看, 哼著小曲而已.
.這個人出門的時侯, 警衛把他帶到一旁搜身, 但卻找不到什麼.
.第二天這個人又來了, 而且教訓警衛說:"昨天我收獲不錯, 不過今天會更佳."
所以警衛就更加注意他了, 但是仍然沒有結果.
.最後一天警衛終於忍不住好奇心, 問那個人:"賊大師, 我給您弄得寢食難安,
您是否以教我, 究竟偷了些什麼?"
.這個人笑笑, 說:"我偷的是概念."
3.2 節
.從前有一位大師專寫沒有結構化的程式, 一個生手模仿他, 也開始寫沒有結構化的
程式. 當這位生手要求大師評量進展時, 大師卻批評他寫作沒有結構化的程式.
.大師說:"對大師適用的不一定適合生手, 在能超越結構化之前, 必須先悟道."
3.3 節
.某長官問程式員:"設計會計系統與作業系統, 那一個比較簡單?"
.程式員說:"作業系統."
.長官發出不相信的驚呼:"很顯然的, 會計系統不如作業系統複雜",他說.
." 不!"程式員回答,"在設計會計系統時, 程式員是各種不同主意的人之間的橋樑,
這些主意不外乎: 系統要如何作業? 報表型式如何? 要如何迎合稅法?...等等.
反過來, 作業系統卻不受外界表象的限制; 在設計作業系統時, 程式員尋求人與機器
間最純的和諧, 這就是為什麼作業系統容易設計."
.長官點頭微笑稱是:"但是那一個容易偵錯?"
.程式員沒有回答.
3.4 節
.經理去見大師, 並且告訴他一套新應用程式文件的需求規格, 問道:"如果我給你五
個程式員, 要多久才能設計好這個系統?"
.大師很快回答:"一年."
." 但是我們需要馬上用這個系統! 如果我給你十個程式員, 那要多久?"經理說.
.大師皺眉說:"這要兩年."
." 如果我給你一百個程式員呢?"
.大師聳聳肩:"這個系統根本作不出來了."
第四部 寫作篇
大師如是說:"寫作良好的程式本身自成天堂, 寫得差的程式本身就是地獄.
4.1 節
.程式要輕靈, 副程式像一串珍珠. 程式的精神與意圖應始終如一, 不多不少;
沒有多餘的迴圈, 也沒有額外的變數, 既不缺少結構, 也不過份笨重.
.程式應該追隨" 最低驚訝定律",這是什麼?
.簡單得很, 使用人對程式的反應是驚訝的機會要愈低愈好.
.程式不管再複雜, 應該以一個整體來作用; 他應該用內部邏輯, 而不是外在的表
象來指導作業.
.如果程式不滿足這些要求, 就會雜亂而易生混淆, 唯一的補救就是重新寫過.
4.2 節
.生手問大師:"我有一個程式, 有時侯作得很好, 有時侯卻不行; 我一直遵行程式設
計的規律, 但是卻把我弄得很困擾, 其理安在?"
.大師答曰:"因為不悟道才會如此, 只有笨蛋才會期望他的同儕有合理的行為,
而你卻對人類生產的機器有所期望?!計算機只模擬了決定論, 只有道才十全十美.
.程式設計的準則還是暫時性的, 只有道才會進入永恒. 所以, 你在開竅前要先思索道."
." 但我要如何才能知道已經開竅了呢?"生手問.
.大師回答:"從此以後, 你的程式都能正確執行."
4.3 節
.大師對弟子說:"不論軟體之為大為小, 道在所有軟體中."
." 桌上型計算機有道嗎?"弟子問.
." 有!"大師答.
." 電動玩具程式中有道嗎?"弟子續問.
." 也有!"大師說.
." 那個人電腦的DOS 中有道嗎?"
.大師咳一下, 輕輕挪動了位置,"下課",他說.
4.4 節
.皇太子的程式員正在寫作軟體, 指尖在鍵盤上飛舞, 程式順暢無誤的編譯完成,
執行起來像陣微風輕拂而完美的結束.
." 了不起!", 太子嘆曰:"你的技巧無懈可擊."
." 技巧?"程式員從終端機上轉過頭說,"我所信從的是道, 道超越任何技巧!
我開始學寫程式時, 在我眼前所見是混成一片的程式; 三年後, 不再見到這一大片
程式了
, 我學會使用副程式; 現在, 眼前一片空靈, 什麼都沒有了, 所有東西都進入無
型式的一片靜寂; 所有感覺都不必作用.
.我的精神可以依直覺而不必依任何計劃行事, 換言之, 我的程式自己寫作自己.
當然, 有時會有困難的問題; 我看著他們到來, 我降低自已的速度, 靜靜的看,
改一列程式之後困難就會煙消雲散; 我再重新靜靜坐著欣賞工作的歡樂. 我閉上雙眼
一會兒, 然後關機."
.皇太子說:"我的所有程式員都那麼聰明睿智嗎?"
第五部 維護篇
大師如是說:"雖然程式只有三列, 但總有一天需要維護."
5.1 節
.常用的門不必上油.
.急流不會淤塞.
.聲音與思想不能在真空中傳遞.
.不用的軟體會生鏽.
.這就是至大的奧秘.
5.2 節
.經理問程式員究竟要多久才能把手上的程式寫完."明天",程式員很快的回答.
.經理說:"我想你不太踏實; 真的要多久?"
.程式員想了一會兒:"我希望在程式中加上一些東西, 這至少要兩週."程式員終於說
." 時間還是短了一些",經理堅持說:"如果你能簡單的告訴我什麼時後能寫完我才會滿意."
.程式員同意這一點.
.幾年後經理退休了, 在歡送餐會上發現那個程式員伏在終端機上睡著了, 因為他
寫程式寫了整夜.
5.3 節
.一個生手被分派去寫一個單純的財務軟體.
.這個生手狂熱地工做了幾天, 但是當大師看他的成品時, 卻發現這個程式中包
含一個螢光幕編修程式, 一組一般性的繪圖程式, 一個人工智慧界面, 但卻沒有什麼
與財務方面有關.
.大師就問他, 這個生手卻變得很激動:"不要那麼沒耐心,"他說,"我最終會把財務
部份加上去."
5.4 節
.好農夫會忽視他種的穀子嗎?
.好老師會忽略他最差的學生嗎?
.好父親會容許他的孩子挨餓嗎?
.好程式員會拒絕維護自己的程式嗎?
第六部 管理篇
大師如是說:"程式員要多, 經理要少, 生產力就會增加."
6.1 節
.經理有開不完的會的話, 程式員就會寫電玩; 主計部門想到利潤, 發展經費
就會被刪減; 高級科學家談到藍藍青天, 那麼青天一定會有浮雲飛過.
.當然, 這不是程式設計之道.
.當經理許下承諾, 程式員就不理會電玩; 當主計部門有長程規劃, 就會回復
和諧與秩序; 當高級科學家處理手上的問題, 問題很快就會解決.
.這才是程式設計之道.
6.2 節
.為什麼程式員沒有生產力? 因為他們的時間都花在開會上頭.
.為什麼程式員難以駕御? 因為管理階層干預太多.
.為什麼程式員一個接一個辭職? 因為他們精力耗光了.
.在不良管理下工作, 程式員不會覺得他的工作有價值.
6.3 節
.某個經理快被炒魷魚了, 但是他底下的一個程式員寫了一個叫好又叫座的程式;
當然, 這位經理因而保住了飯碗.
.經理打算給這位程式員一點獎勵, 但他拒絕接受, 並且說:"因為我覺得這是個有
趣的概念, 才會寫這個程式, 所以我不希望有獎勵."
.經理聽了之後說:"這個程式員雖然職位不高, 但卻充份了解做為一個職員的責任,
讓我們把他升成崇高的管理顧問吧!"
.在告訴程式員時, 他再度拒絕, 說:"我之存在是因為可以寫程式, 如果升了我,
那除了浪費每一個人的時間外而成不了事. 我可以走了嗎? 我還得寫程式."
6.4 節
.經理告訴程式員們說:"下面是你們的工作時間: 早上九點來上班, 下午五點鐘下班."
所有程式員都很生氣, 有幾個馬上辭職.
.於是經理說:"好吧! 這樣好了, 只要能夠如期完工, 工作時間由你們自定."程式員現
在滿意了, 每天中午開始工作, 直到第二天早上.
第七部 公司智慧篇
大師如是說:"你可以對主管示範一個程式, 但無法讓他通曉電腦."
7.1 節
.生手問大師:"遙遠東方有一個叫" 公司總部" 的偉大樹狀結構, 上面滿滿地標上了
些副總裁, 會計長等的圖案. 它發出大量的備忘錄, 每張上面都寫了" 收文!"
" 發文!"沒有人知道是什麼意義. 每年都會把新的名字加到新的分 枝上, 但似乎全
都徒勞無功. 為什麼這樣一個不自然的組織還能繼續存在?"
.大師回答說:"你已經體認到這個龐大的結構, 而被它不合理的目的困擾.
不過你能不從它無休止的迴旋而得到樂趣嗎? 能夠不欣賞深藏在枝葉底端毫無困難
的程式設計嗎? 為什麼要被他的無用而困擾呢."
7.2 節
.東方海上有大魚曰鯤, 鯤能變成雙翼遮天的大鵬. 當大鵬飛越陸地時帶來一道公司
總部的訊息, 這道訊息正好掉在一群程式員中央, 然後大鵬折起雙翼乘風而歸.
.生手程式員瞪眼望著大鵬, 因為他們不認得; 中智程式員憂大鵬的來臨, 因為他們
害怕它帶來的訊息; 只有大師才能繼續坐在終端機前工作, 因為他不知大鵬的來去
7.3 節
.象牙塔的魔術師帶著他的最新發明去見大師, 他推了一個大黑盒子走進大師的辦公室,
大師正在靜靜的等著.
." 這是一套整合性, 分散式, 一般用途的工作站",魔術師如是說,"還有一套專屬的
作業系統, 第六代語言, 多項最先進的使用人界面, 再加上人體工學的設計;
這花了我的助手們好幾百人年才造出來的, 不是很了不起嗎?"
.大師抬了下眼珠子,"的確了不起."大師說.
.魔術師繼續說:"公司總部已經下令每個人都要用這台工作站做發展新軟體的基石,
您同意嗎?"
." 當然."大師答道:"我馬上會把它放到資訊中心去."於是魔術師高高興興的回到
象牙塔去.
.幾天後, 一個生手在大師的辦公室裡團團轉, 說:"我找不到新程式的報表,
您知道會在那兒嗎?"
." 當然",大師答道,"報表就堆在資訊中心裡頭的基石上!"

7.4 節
.大師可以毫無憂慮的從這個程式轉入另一個程式, 管理上的改變傷不到他;
縱使計劃中止了, 也不會被炒魷魚. 為什麼? 因為他充滿了道.
第八部 硬體與軟體篇
大師如是說:"沒有風, 草不會動, 沒有軟體, 硬體就是廢物."
8.1 節
.生手問大師:"我知道一家電腦公司比其他的大得多, 高高在上就像巨人之比侏儒;
它的任一部都可以單獨成為一個企業. 為什麼會這樣?"
.大師回答:"你為什麼問這個笨問題? 這家公司就是因為它大才會這麼大. 如果它只
知道硬體, 沒有人會買它; 如果只生產軟體, 沒有人會用它; 如果只維護系統,
人家會把它看成修理員; 但是因為他把所有的合在一起, 人們就把它當神一樣看待了
. 它根本無需競爭, 因為贏來不費吹灰之力."
8.2 節
.大師有一天經過一個生手旁邊, 發現生手迷上一台手掌型的電玩,"對不起",大師說,
"我可以看看它嗎?"
.生手停下來, 並且把這台機器交給大師. 大師說:"我看到這台機器玩起來有三個層次:
初級, 中級, 高級; 不過這種機器通常都有另一個層次的說法, 使機器贏不了人類,
而人類也勝不了機器."
." 啊! 大師",生手說:"這個奇妙的開關在那裡?"
.大師把機器摔到地上, 用腳把它踏爛.
.突然地, 生手開竅了.
8.3 節
.從前有一位微電腦的程式員對一位來拜訪他的大型電腦程式員說:"你看,
在我這兒多好! 我有我自己的作業系統與案儲存設備, 我不必與任何人共用任
何電腦資源;軟體本身自給自足, 而且容易使用. 為什麼你不辭掉目前的工作
來加入我們?"
.於是大型電腦的程式員就對他的朋友解釋:"大型電腦就像古之聖哲般的穩穩座落i
在資訊中心中央, 磁碟一個接一個蔚為奇觀, 軟體像鑽石般地有多種面目, 像
古森林般的濃密茂盛. 各個程式像一片急流般地湧入系統, 而這就是我在那兒工
作的樂趣 ."
.聽了這段話之後, 微電腦程式員靜默無聲; 但是這兩個人卻結為好友, 至死不渝.
8.4 節
.Hardware與Software走在路上, Software說:"你是陰我是陽, 如果我們能一條心,
一定會成大名賺大錢."所以,他們就聯合在一起而想征服世界.
.走了一段路之後, 碰到Firmware, 穿得破破爛爛, 拿著根柺杖, 並且對他們說:
"道在陰陽之外, 寂靜不動如古井之不生波瀾; 道不求名, 故無人知曉其存在;
道不逐利, 因它圓滿無缺. 道超乎時空之外."
.Hardware和Software聽了之後倍感慚愧而打道回家.
第九部 尾聲
大師如是說:"這是下課的時候了!"

Reference:
http://mis.ndhu.edu.tw/docu/The_DAO_of_programming.htm

程式語言與人生

程式語言與人生
Posted by pest MAY4
人生就像學程式語言…

一開始要學說話 (Hello World!)，

再來要學算數；

慢慢的，開始對邏輯產生概念 (if …. else )，

你發現人生有些重複的事可以用更聰明的方法做 ( for …. )，

但有時候沒有叫停，也只能忍著苦做下去 ( while … )。

你學會讀書寫字，讀別人的思想，寫自己的感言 ( File I/O )，

你發現世界的知識無窮無盡，善用別人的知識才能夠跑得更遠 ( library )；

可是你也會遇到挫折，並且學會面對它們 ( exception & error handling ) 。

知識藏在神秘的角落，發掘其中的奧妙你才能夠出人頭地 ( database )。

但是世界比你想像的更大，能和遠方的人溝通更能創造機會 ( network )，

你會遇到和你截然不同的人，說著不一樣的話，如果你懂得溝通，他們也能成為你的後盾 ( protocol )。

年輕時衝動的你，也會開始瞭解到做事有方法比衝勁重要 ( algorithm )，

那些偉大的成就，其實也是建立在耐心的反覆檢查之上 ( debug )。

孩子，

其實你不是在學一種程式語言，

你學的，是人生。

Reference:
http://pesty.yichi.org/blog/2007/05/04/programming_language_and_life/

程式、設計與程式設計 - 流程圖 flowchart

程式、設計與程式設計 - 流程圖 flowchart

從大學一年級開始，我就常常被同學抓去問程式。不過，我從來不直接寫好程式給人家抄，都是要看到寫好的程式碼才會幫忙指出邏輯上的錯誤。（或是看到 註解，卻發現動作似乎不是那麼回事的程式碼。）拜此「只教你釣魚卻不給你魚」的邏輯之賜，漸漸的，來要作業的人少了，留下了真正想學東西的人。
最近跟同學吃飯的時候，聊到他們來問我程式的「感想」- 雖然被我冷嘲熱諷，但還是覺得有學到東西。尤其是最近程式越寫越大，聽到我說的一段話，覺得感觸良多：

「程式設計」為什麼叫做程式「設計」，就是因為重點在「設計」。否則它就會叫「程式撰寫」之類的東西了。
寫 程式如果不先設計，很容易花很多時間卻只寫出一個爛程式。你也許會認為，不設計可以節省時間，但是那是錯的。不先設計只會讓你寫到一半的時候不知道該怎麼 辦，然後花更多時間思考。卻又因為沒經過完整的設計，最後寫出一個不怎麼樣的（爛）程式。看著這個爛程式，你當然會想再花時間把它改好，卻因為沒有設計不 知該如何下手。但是這是你「已經」花了很多時間寫出來的程式，捨不得把它丟掉。於是花下比之前還多的時間下去除錯、增刪功能，最後還是做出一個不怎麼樣的 爛程式。然後你覺得它還是不夠好，可是又更捨不得把它丟掉（因為你已經為它付出太多了！），於是花下更多時間修改，然後更捨不得，然後修改，然後更捨不 得... 可是總歸要變成個爛程式，因為缺乏設計。死馬當活馬醫不是不行，但是可能會比直接換匹馬來的麻煩。就算真的醫好了，遇上你們這些實習醫生，這匹馬也不會變 的活跳跳，大概還是個半死不活的樣子，絕對不會比經過適當調教的健康馬跑的好。
所以，如果你們給我一個程式，我看了以後叫你重寫， 意思不是叫你直接去重寫，而是我覺得你必須重新設計你的邏輯，然後重寫。寫程式之前要先設計，是天經地義的道理。為什麼程式設計一開始要教流程圖？為什麼 計概一開始要教流程圖？為什麼組語一開始要教流程圖？都只是為了教你一套設計程式的方法。我不是說一定要畫什麼鬼流程圖，因為我自己也不畫那個東西，但是 至少要先設計過才開始寫程式。

後來，有位同學告訴我他的心得...

你知道第一次我來問你程式的時候，也是一直被罵「上課沒專心聽」、「去看課本第 xx 頁」之類的。也許當時我問的只是一些「for 迴圈怎麼用」或「switch ... case 的語法是什麼」的問題，上課老師一定教過、課本上也一定有。但是當時我只覺得「如果我上課都聽的懂、課本都看的懂，幹麻還來問你？」
後 來有一個比較大的作業，也是寫到一半拿來問你。當時你看了一眼程式碼以後，指著螢幕問我「這幾行程式碼在幹什麼？」的時候，我整個人傻掉，因為真的回答不 出來。當時你只說了「連你都不知道在作什麼的碼，寫它幹麻？」後來，你一點一點的改我的程式，一點一點告訴我哪裡可能該怎麼寫，一點一點把東西加進去，寫 出來的東西，我只覺得「這根本不是我寫的！」。
最後終於全部寫完、可以正確跑出結果，但是我還是霧煞煞。這個時候你又做了另一件讓 我吐血的事 - 把視窗整個關掉，跟我說「好啦！我已經告訴你該怎麼寫了，回去以後自己重寫一次。」當時我整個人抓狂，那是我花了三天才寫出來的東西，你看了兩個小時、改 了一堆東西以後叫我重寫？
後來我回去以後當然沒重寫，又抓著原來那塊半死不活的程式屍體改來改去，花了一個晚上，寫出了一個勉強可以跑，但是很多功能做不到的爛程式。當時的感覺，就真的是捨不得把它丟掉重寫一個。

突然之間，我終於知道為什麼新手容易寫出爛程式，除了技術功力以外，最根本的問題就是他們懶的作設計。許多老師在一開始給的都只是小程式 （Hello World!），幾乎一看就可以知道該怎麼寫，或是只要照著黑板抄就會跑，不需要什麼設計。很多時候，連為什麼要這樣寫都不知道。但是，隨著課程的深入， 依樣畫葫蘆已經不能作出作業。可是因為之前沒有設計解法的能力，所以想破頭也不知道該怎麼把答案弄出來。
後來繼續聊下去，發現大家都不知道該怎樣作設計才好。我是覺得，雖然有許多文章要你別再畫流程圖了，但是那是寫給已經畫過幾百張流程圖的老手看的，新手還是得從流程圖開始。所以，畫流程圖的時候...

1. 不要超過一張 A4 紙（即使有那些「至下頁」的小圓點，你還是不會知道自己在畫些什麼的！相信我。）
2. 不要過度詳細（如果一個方塊對一行程式碼，直接去寫就好了，別浪費時間畫圖。）
3. 從 大問題開始畫起（例如，直接畫「程式開始 -> 擷取聲音 -> 傅立葉轉換 -> RLE 編碼 -> 赫夫曼編碼 -> 存檔 -> 結束」，別把 FFT、RLE、Huffman Encoding 到底怎麼做畫進同一張圖內。）
4. 解決小問題（慢慢開始畫出怎樣開音效卡、怎樣收麥克風、讀進來的串流應該放在哪裡...）
5. 照著畫出來的東西用手算一遍，看看有沒有邏輯錯誤。
6. 把鍵盤拉過來開始打程式。

所以... 新手們...... 看看這篇文章，然後回去畫流程圖吧！！！

Reference:
http://palatis.blogspot.ca/2005/10/blog-post_30.html