偶然在網路上看到的影片：用動畫展示氣泡排序法（Bubble Sort）跟快速排序法（Quicksort）的運作原理，並比較兩者的效率（進行比較的次數）。整支影片看起來還滿可愛的。
Visualization of Quick sort
7月 23, 2010
9月 06, 2008
【轉貼】明星程設師的十大特質
@
| 標籤:
轉貼
Every company is a tech company these days. From software startups to hedge funds to pharmaceutical giants to big media, they're all increasingly in the business of software. Quality code has become not only a necessity, but a competitive differentiator. And as companies compete around software, the people who can make it happen - software engineers - are becoming increasingly important. But how do you spot the 'cream of the crop' programmers? In this post we outline the top ten traits of a rockstar developer.
We've written here before about the future of software development, in which a few smart developers can leverage libraries and web services to build large-scale systems of unprecedented complexity. It only takes a couple of smart engineers to create quality software of immense value, and below is a list of the top ten qualities you should look for when hiring a developer:
1. Loves To Code
Programming is a labor of love. Like any occupation, truly great things are achieved only with passion. It is a common misconception that writing code is mechanical and purely scientific. In truth, the best software engineers are craftsman, bringing energy, ingenuity, and creativity to every line of code. Great engineers know when a small piece of code is shaping up perfectly and when the pieces of a large system start to fit together like a puzzle. Engineers who love to code derive pleasure from building software in much the same way a composer might feel ecstatic about finishing a symphony. It is that feeling of excitement and accomplishment that makes rockstar engineers love to code.
2. Gets Things Done
There are plenty of technical people out there who talk about software instead writing it. One of the most important traits of a great software engineer is that they actually code. They actually get things done. Smart people know that the best way to solve problems is go straight at them. Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand? The recent methodologies for building software, called Agile practices, focus on just that. The idea is to break complex projects into short iterations, each of which focuses on a small set of incremental features. Because each iteration takes just a few weeks to code, the features are manageable and simple. Teams that follow agile practices never create infrastructure for its own sake, instead they are focused on addressing a simple set of requirements. The secret is that when this approach is applied iteratively, a rich, complex piece of software arises naturally.
3. Continuously Refactors Code
Coding is very much like sculpting. Just like an artist is constantly perfecting his masterpiece, an engineer continuously reshapes his code to meet requirements in the best possible way. The discipline of reshaping code is known as refactoring and was formally described by Martin Fowler in his seminal book. The original idea behind refactoring was to improve code without changing what it does, moving pieces of the software around to ensure that the system is free of rot and also does what it is supposed to do based on current requirements. Continuous refactoring allows developers to solve another well-known problem - black box legacy code that no one wants to touch. For decades engineering culture dictated that you should not change the things that work. The issue, though, is that over time you become a slave to the old code, which grows unstable and incompatible. Refactoring changes that, because instead of the code owning you, you own the code. Refactoring establishes ongoing dialogue between the engineer and the code and leads to ownership, certainty, confidence, and stability in the system.
4. Uses Design Patterns
Ever since the so called Gang of Four published their famous Design Patterns book, world-class engineers have been talking about patterns. Patterns are ubiquitous in our world - both in nature and all human endeavors; software engineering is no exception. Patterns are recurrent scenarios and mechanisms that live across languages and systems. A good engineer always recognizes and leverages patterns, but is not driven by them. Instead of trying to fit the system into a set of patterns, the engineer recognizes opportunities in which to apply patterns. Applying a pattern ensures correctness since it leverages existing know-how: a method for solving a particular engineering problem that has worked before.
5. Writes Tests
Long gone are the days when engineers thought of testing as beneath them. After all, how can you be certain that your code is actually working if you never test it? An agile practice called Unit Testing has recently gained popularity because it focuses on writing tests to mirror the code. As the system grows, the body of tests grows with it, providing proof that the code actually works. Experienced engineers know and understand the value of tests, because their goal is to create a working system. Good engineers will always write a test once a bug has been exposed to make sure it does not come back again. But a good engineer also knows not to waste time writing trivial or greenundant tests, instead focusing on testing the essential parts of each component.
6. Leverages Existing Code
Reinventing the wheel has always been one of the biggest problems in the software industry. From inventing new languages to rewriting libraries, the strange drive to ignore and greeno what is already there and already works has been the cause of a lot of software failures. A rockstar engineer will focus on three essential kinds of reuse. First of all, the reuse of internal infrastructure, the code that he and his peers have written. Secondly, the use of third party libraries, for example, in Java, the libraries that are part of JDK or popular libraries provided by the Apache Foundation. And finally, a good engineer would look to leverage web-scale web service, like the ones offegreen by Amazon. Correct leveraging of existing infrastructure allows rockstar engineers to focus on what is most essential - the application itself.
7. Focuses on Usability
Good engineers always focus on the users. Whether the user is a business or an individual, whether the engineer works for a consumer software company or an investment bank, the focus is on working, usable software. How will users interact with the system? Does it provide a simple, intuitive, and smooth experience? The notion that because a software engineer is a techie, he or she thus can not relate to how other people interact with the system is deeply flawed. Good engineers work hard to make the system simple and usable. They think about customers all the time and do not try to invent convoluted stuff that can only be understood and appreciated by geeks.
8. Writes Maintainable Code
The other secret of good engineers is that it takes the same amount of time to write good code as it does to write bad code. A disciplined engineer thinks about the maintainability and evolution of the code from its first line. There is never any reason to write ugly code, a method that spawns multiple pages, or code with cryptic variable names. Rockstars write code which follows naming conventions, code which is compact, simple and not overly clever. Each line of code serves its purpose and resides in the right place. The bits that are difficult to understand are commented, but otherwise naming conventions are clear. Expressive names for methods and variables can make the code self-explanatory.
9. Can Code in Any Language
A good engineer might have a favorite programming language but is never religious about it. There are many great programming languages these days and to say that you only can code in one of them is to demonstrate a lack of versatility. In Java, C#, or C++ you can write any modern software. You can code the back end of any web site in PHP, in Perl, or in Ruby. At the end of the day, the language does not matter as much as the libraries that come with it. A good engineer knows that and is willing and able to learn new languages, new libraries and new ways of building systems.
10. Knows Basic Computer Science
The last, but certainly not the least trait of a great engineer is a solid foundation. A good engineer might not have a degree in computer science but must know the basics - data structures and algorithms. How can you build large scale software without knowing what a hashtable is? Or the difference between a linked list and an array? These are the basics that everyone should know. And the algorithms are just as important - from binary search to different sorts to graph traversals, a rockstar engineer must know and internalize the basics. These foundations are necessary to make the right design decisions when building any modern piece of software.
Conclusion
There are many traits that distinguish great software engineers. Among the ones we discussed, passion is certainly very important. Knowing the basics like code reuse, design patterns, fundamental data structures, and algorithms is necessary, while agile practices of refactoring and unit testing help engineers iteratively evolve complex software. Most importantly, rockstar engineers believe in simplicity and common sense. It is these beliefs that help them succeed in building the seemingly impossible, complex software systems that are necessary in today's world.
Let us know what other traits you think a rockstar software engineer should have, in the comments below.
We've written here before about the future of software development, in which a few smart developers can leverage libraries and web services to build large-scale systems of unprecedented complexity. It only takes a couple of smart engineers to create quality software of immense value, and below is a list of the top ten qualities you should look for when hiring a developer:
1. Loves To Code
Programming is a labor of love. Like any occupation, truly great things are achieved only with passion. It is a common misconception that writing code is mechanical and purely scientific. In truth, the best software engineers are craftsman, bringing energy, ingenuity, and creativity to every line of code. Great engineers know when a small piece of code is shaping up perfectly and when the pieces of a large system start to fit together like a puzzle. Engineers who love to code derive pleasure from building software in much the same way a composer might feel ecstatic about finishing a symphony. It is that feeling of excitement and accomplishment that makes rockstar engineers love to code.
2. Gets Things Done
There are plenty of technical people out there who talk about software instead writing it. One of the most important traits of a great software engineer is that they actually code. They actually get things done. Smart people know that the best way to solve problems is go straight at them. Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand? The recent methodologies for building software, called Agile practices, focus on just that. The idea is to break complex projects into short iterations, each of which focuses on a small set of incremental features. Because each iteration takes just a few weeks to code, the features are manageable and simple. Teams that follow agile practices never create infrastructure for its own sake, instead they are focused on addressing a simple set of requirements. The secret is that when this approach is applied iteratively, a rich, complex piece of software arises naturally.
3. Continuously Refactors Code
Coding is very much like sculpting. Just like an artist is constantly perfecting his masterpiece, an engineer continuously reshapes his code to meet requirements in the best possible way. The discipline of reshaping code is known as refactoring and was formally described by Martin Fowler in his seminal book. The original idea behind refactoring was to improve code without changing what it does, moving pieces of the software around to ensure that the system is free of rot and also does what it is supposed to do based on current requirements. Continuous refactoring allows developers to solve another well-known problem - black box legacy code that no one wants to touch. For decades engineering culture dictated that you should not change the things that work. The issue, though, is that over time you become a slave to the old code, which grows unstable and incompatible. Refactoring changes that, because instead of the code owning you, you own the code. Refactoring establishes ongoing dialogue between the engineer and the code and leads to ownership, certainty, confidence, and stability in the system.
4. Uses Design Patterns
Ever since the so called Gang of Four published their famous Design Patterns book, world-class engineers have been talking about patterns. Patterns are ubiquitous in our world - both in nature and all human endeavors; software engineering is no exception. Patterns are recurrent scenarios and mechanisms that live across languages and systems. A good engineer always recognizes and leverages patterns, but is not driven by them. Instead of trying to fit the system into a set of patterns, the engineer recognizes opportunities in which to apply patterns. Applying a pattern ensures correctness since it leverages existing know-how: a method for solving a particular engineering problem that has worked before.
5. Writes Tests
Long gone are the days when engineers thought of testing as beneath them. After all, how can you be certain that your code is actually working if you never test it? An agile practice called Unit Testing has recently gained popularity because it focuses on writing tests to mirror the code. As the system grows, the body of tests grows with it, providing proof that the code actually works. Experienced engineers know and understand the value of tests, because their goal is to create a working system. Good engineers will always write a test once a bug has been exposed to make sure it does not come back again. But a good engineer also knows not to waste time writing trivial or greenundant tests, instead focusing on testing the essential parts of each component.
6. Leverages Existing Code
Reinventing the wheel has always been one of the biggest problems in the software industry. From inventing new languages to rewriting libraries, the strange drive to ignore and greeno what is already there and already works has been the cause of a lot of software failures. A rockstar engineer will focus on three essential kinds of reuse. First of all, the reuse of internal infrastructure, the code that he and his peers have written. Secondly, the use of third party libraries, for example, in Java, the libraries that are part of JDK or popular libraries provided by the Apache Foundation. And finally, a good engineer would look to leverage web-scale web service, like the ones offegreen by Amazon. Correct leveraging of existing infrastructure allows rockstar engineers to focus on what is most essential - the application itself.
7. Focuses on Usability
Good engineers always focus on the users. Whether the user is a business or an individual, whether the engineer works for a consumer software company or an investment bank, the focus is on working, usable software. How will users interact with the system? Does it provide a simple, intuitive, and smooth experience? The notion that because a software engineer is a techie, he or she thus can not relate to how other people interact with the system is deeply flawed. Good engineers work hard to make the system simple and usable. They think about customers all the time and do not try to invent convoluted stuff that can only be understood and appreciated by geeks.
8. Writes Maintainable Code
The other secret of good engineers is that it takes the same amount of time to write good code as it does to write bad code. A disciplined engineer thinks about the maintainability and evolution of the code from its first line. There is never any reason to write ugly code, a method that spawns multiple pages, or code with cryptic variable names. Rockstars write code which follows naming conventions, code which is compact, simple and not overly clever. Each line of code serves its purpose and resides in the right place. The bits that are difficult to understand are commented, but otherwise naming conventions are clear. Expressive names for methods and variables can make the code self-explanatory.
9. Can Code in Any Language
A good engineer might have a favorite programming language but is never religious about it. There are many great programming languages these days and to say that you only can code in one of them is to demonstrate a lack of versatility. In Java, C#, or C++ you can write any modern software. You can code the back end of any web site in PHP, in Perl, or in Ruby. At the end of the day, the language does not matter as much as the libraries that come with it. A good engineer knows that and is willing and able to learn new languages, new libraries and new ways of building systems.
10. Knows Basic Computer Science
The last, but certainly not the least trait of a great engineer is a solid foundation. A good engineer might not have a degree in computer science but must know the basics - data structures and algorithms. How can you build large scale software without knowing what a hashtable is? Or the difference between a linked list and an array? These are the basics that everyone should know. And the algorithms are just as important - from binary search to different sorts to graph traversals, a rockstar engineer must know and internalize the basics. These foundations are necessary to make the right design decisions when building any modern piece of software.
Conclusion
There are many traits that distinguish great software engineers. Among the ones we discussed, passion is certainly very important. Knowing the basics like code reuse, design patterns, fundamental data structures, and algorithms is necessary, while agile practices of refactoring and unit testing help engineers iteratively evolve complex software. Most importantly, rockstar engineers believe in simplicity and common sense. It is these beliefs that help them succeed in building the seemingly impossible, complex software systems that are necessary in today's world.
Let us know what other traits you think a rockstar software engineer should have, in the comments below.
作者：Alex Iskold
出處：Top 10 Traits of a Rockstar Software Engineer
8月 18, 2008
【轉貼】遊戲程設之路
@
| 標籤:
轉貼
這篇就當做是自我介紹之一，順便也說明一下我自學程式語言的過程，好讓想自學的人，能夠參考看看。
在國一的某一天，我哥弄了一套 Visual Basic 6.0 回來，他說他想學，但是過不了多久，他在經過幾次的失敗之後就放棄了，於是被我撿來學，一開始，什麼都不懂，在上網找了 VB 研究小站之類的網站來參考，終於寫出自己的第一個程式，一個簡單的比大小程式，那種正常運作的感動我到現在還記得，從此就走上了這條不歸路。
國中的三年，上課時我都在睡覺，放學回到家就開始寫程式，寫到一兩點才睡覺，在這段時間，我常常忘記我到底吃飯了沒。到了國三，開始轉戰 C++，VB 相對於 C++，比較簡單，因此剛進入 C++ 會有些挫折，但是久了，也就習慣了 C++。
在這段期間，我不停的想一些有的沒有的小東西來做，其中有小遊戲，有小程式，很多東西，雖然都在做到一半時，想到其它有的沒有的東西去做而終止，但是在每一個小題目當中都會學到一點點東西，就靠著網路買的書還有網路查資料以及問問題。
其中，有一個構想我重寫了三次，第一次用 VB，第二、三次用 C++，因為，每當我停下來，過一陣子再回去想完成它，卻發現，這樣的架構，實在笨到不行，一些做法，也讓我自己覺得我當時為什麼會那麼做，而對於不好的架構而言，就像一條到處是洞的船，這邊有個洞補這裡，那邊有個洞補那裡，這些洞是補不完的，與其不停的補洞，不如重造一條，而每次重寫，雖然是一樣的東西，但是時間用得更短，程式碼也更精簡，架構也更完整，麼說，這樣就是有在進步。
根據我的經驗，我整理出一開始自學程式語言的幾個要點。
一、越早學越好
我的同學們聽到程式語言，都一直說多難多難，完全看不懂之類的，這是理所當然的事，就和英文一樣，當你沒學過英文，要你去看英文的文章，看不懂是正常的，而我們的英文在國中開始教，學到今天高三也有六年了，如果說，程式語言從國一開始學，學六年還學不到什麼東西，那我也不知道該說什麼，因此，越早學越好，學越久，經驗越豐富。
二、耐心與熱情
耐心與熱情是必要的，很多時候，一個程式，裡面只有一個符號打錯，卻會造成莫明奇妙的錯誤，這時，請用你的耐心和熱情去找到這個錯誤，而當你找到這個錯誤並且修正後，以遊戲來看，你的經驗值就增加了，這就是升級的動力來源，一點一滴的經驗累積。
三、買正確的書
學程式語言書是必要的，而書有分兩種，一種是工具書，一種是學習書，工具書第一次到手先大略的看一遍，有個印相記得哪些東西在哪裡，然後就丟在電腦旁邊，而當需要資料參考時，就依照印相去找出工具書來翻閱，至於學習書，是按照進度一步一步前進，而同樣的，在學完之後一樣也是放電腦旁邊，當有疑問時可以拿出來解惑，當然，如果買到爛書，可能會有不好的後果，所以買之前，可以上網問一下網友，哪些書是必買，那些不能買。
四、善用網路資源
自從有了 Google 之後，很多東西都可以輕鬆的找到，舉個例子，cout 在 c++ 裡面到底是什麼，只要在 Google打 "Cout c++"，就有一大堆的資料可以參考，因此，搜尋資料的能力，要好好陪養，思考應該用什麼關鍵字去搜尋，這是必須練習的，除了搜尋，發問也是一個很好的管道，然而，很多人常常都把發問當成順位第一的解決方法，這是錯誤的學習方法，因為，很多問題，已經被提出來討論過很多次了，因此，在 Google 或是討論版裡面都可以找到答案，比起問已經被討論多次的問題，搜尋所花的時間只有一點點，而發問卻要等別人回答，因此，請養成一個良好的習慣，先搜尋，真的很難找到答案，再發問，為什麼會有這種想法？原因很簡單，就是當我回答一些人的問題時，都是從 Google 找到資料的...，所以我想，即然我能在 Google 找到資料丟給他，為什麼不讓他自己去找呢？
五、基本的英文能力
學程式語言，基本的英文能力是必要的，因為很多經典的書都只有英文版，而技術文件也通常都是英文的，例如 MSDN 就是用英文寫的，如果你連這個函數大概在幹麻的都看不懂，這樣在學習上會是很大的障礙。
六、基本的數學能力
除了英文能力，數學對於程式語言也是很重要的，或許，你會覺得，我數學爛到暴一樣也可以寫好程式，事實的確是這樣沒錯，但是，就是有那麼可能 1% 不到的地方，需要一些數學底子，就拿 45 度視角的地圖引擎來說，如果你不會斜向座標系與直角座標互換，那麼，你滑鼠目前指的地圖座標，就沒有辦法判斷，其它方法是有，但是都沒有數學公式直接轉換來得快速，因此，基本的數學能力也是必須的。
七、演算法和資料結構
當程式語言學習到一定程度時，演算法和資料結構是一定要學的，如果演算法和資料結構不學，在寫遊戲時，總是會用一些很暴力的笨方法去解決問題，對於注重流暢度的遊戲程式來說，這不是件什麼好事，而且當地圖需要最短路徑時，也需要演算法才能完成。
除了程式語言一般的學習，當要用程式來寫遊戲，需要再另外學些東西，然而，如果以分工的角度來看，可以挑著學：
一、視窗程式設計
可以挑一套自己喜歡的視窗程式設計方法去學，目前有很多種選擇，MFC、Win32SDK、BCB....，等等，在設計地圖編輯器等等之類的編輯器是一定要學的。
二、Winsock
當你的遊戲不是一個人玩時，Winsock 就派上用場了，當然，DirectX 的連線方式也是另一個選擇，不過我個人比較喜歡 Winsock。
三、DirectX
DirectX 幾乎是在 Windows 下寫遊戲必學，Direct Draw 和 Direct 3D 兩個是最重要的，一個負責 2D 一個負責 3D，然而，現在 2D 大多都已經由 3D 模擬，因此，我是認為可以直接學 Direct 3D 就好，而要處理到音效、影片，就輪到 Direct Sound 和 Direct Show 上場了。
四、人工智慧
其實我一直覺得人工智慧這個名字取得不好，因為遊戲裡的"智慧"，大多都只是照一定規則的行為而以，這個部份，也是專門的領域。
五、古典物理
古典物理！？有沒有搞錯？是的，沒有搞錯，目前的遊戲很多都有很好的物理模擬，可以從物理模擬中，讓玩家感受的更真實的虛擬世界，如果物理沒有一點底子，就算是寫好的引擎可以使用，很多東西沒搞懂可能也不知道該怎麼用。
六、已經寫好的套件
事實上，很多東西因為太常用，都已經有人寫成引擎供人使用，就拿魔獸世界來說，他們就用到了 Lua 來當腳本的直譯器，重新開發一個直譯器的時間就整個省下來了，而且這些套件大多都經過很多人使用過，並且更新，因此穩定性和效能來講，常常會比自己寫的來的好(不過呢，人總是犯賤，有時不知道為什麼就比較喜歡自己寫)，因此，上面這些東西有時不一定要學，可以直接使用別人的套件，底層的東西就可以不用學了。
以上，是我自己小小的一點看法，如果覺得有問題請提出來指正，我有想到更多的話，會再補上來的。
在國一的某一天，我哥弄了一套 Visual Basic 6.0 回來，他說他想學，但是過不了多久，他在經過幾次的失敗之後就放棄了，於是被我撿來學，一開始，什麼都不懂，在上網找了 VB 研究小站之類的網站來參考，終於寫出自己的第一個程式，一個簡單的比大小程式，那種正常運作的感動我到現在還記得，從此就走上了這條不歸路。
國中的三年，上課時我都在睡覺，放學回到家就開始寫程式，寫到一兩點才睡覺，在這段時間，我常常忘記我到底吃飯了沒。到了國三，開始轉戰 C++，VB 相對於 C++，比較簡單，因此剛進入 C++ 會有些挫折，但是久了，也就習慣了 C++。
在這段期間，我不停的想一些有的沒有的小東西來做，其中有小遊戲，有小程式，很多東西，雖然都在做到一半時，想到其它有的沒有的東西去做而終止，但是在每一個小題目當中都會學到一點點東西，就靠著網路買的書還有網路查資料以及問問題。
其中，有一個構想我重寫了三次，第一次用 VB，第二、三次用 C++，因為，每當我停下來，過一陣子再回去想完成它，卻發現，這樣的架構，實在笨到不行，一些做法，也讓我自己覺得我當時為什麼會那麼做，而對於不好的架構而言，就像一條到處是洞的船，這邊有個洞補這裡，那邊有個洞補那裡，這些洞是補不完的，與其不停的補洞，不如重造一條，而每次重寫，雖然是一樣的東西，但是時間用得更短，程式碼也更精簡，架構也更完整，麼說，這樣就是有在進步。
根據我的經驗，我整理出一開始自學程式語言的幾個要點。
一、越早學越好
我的同學們聽到程式語言，都一直說多難多難，完全看不懂之類的，這是理所當然的事，就和英文一樣，當你沒學過英文，要你去看英文的文章，看不懂是正常的，而我們的英文在國中開始教，學到今天高三也有六年了，如果說，程式語言從國一開始學，學六年還學不到什麼東西，那我也不知道該說什麼，因此，越早學越好，學越久，經驗越豐富。
二、耐心與熱情
耐心與熱情是必要的，很多時候，一個程式，裡面只有一個符號打錯，卻會造成莫明奇妙的錯誤，這時，請用你的耐心和熱情去找到這個錯誤，而當你找到這個錯誤並且修正後，以遊戲來看，你的經驗值就增加了，這就是升級的動力來源，一點一滴的經驗累積。
三、買正確的書
學程式語言書是必要的，而書有分兩種，一種是工具書，一種是學習書，工具書第一次到手先大略的看一遍，有個印相記得哪些東西在哪裡，然後就丟在電腦旁邊，而當需要資料參考時，就依照印相去找出工具書來翻閱，至於學習書，是按照進度一步一步前進，而同樣的，在學完之後一樣也是放電腦旁邊，當有疑問時可以拿出來解惑，當然，如果買到爛書，可能會有不好的後果，所以買之前，可以上網問一下網友，哪些書是必買，那些不能買。
四、善用網路資源
自從有了 Google 之後，很多東西都可以輕鬆的找到，舉個例子，cout 在 c++ 裡面到底是什麼，只要在 Google打 "Cout c++"，就有一大堆的資料可以參考，因此，搜尋資料的能力，要好好陪養，思考應該用什麼關鍵字去搜尋，這是必須練習的，除了搜尋，發問也是一個很好的管道，然而，很多人常常都把發問當成順位第一的解決方法，這是錯誤的學習方法，因為，很多問題，已經被提出來討論過很多次了，因此，在 Google 或是討論版裡面都可以找到答案，比起問已經被討論多次的問題，搜尋所花的時間只有一點點，而發問卻要等別人回答，因此，請養成一個良好的習慣，先搜尋，真的很難找到答案，再發問，為什麼會有這種想法？原因很簡單，就是當我回答一些人的問題時，都是從 Google 找到資料的...，所以我想，即然我能在 Google 找到資料丟給他，為什麼不讓他自己去找呢？
五、基本的英文能力
學程式語言，基本的英文能力是必要的，因為很多經典的書都只有英文版，而技術文件也通常都是英文的，例如 MSDN 就是用英文寫的，如果你連這個函數大概在幹麻的都看不懂，這樣在學習上會是很大的障礙。
六、基本的數學能力
除了英文能力，數學對於程式語言也是很重要的，或許，你會覺得，我數學爛到暴一樣也可以寫好程式，事實的確是這樣沒錯，但是，就是有那麼可能 1% 不到的地方，需要一些數學底子，就拿 45 度視角的地圖引擎來說，如果你不會斜向座標系與直角座標互換，那麼，你滑鼠目前指的地圖座標，就沒有辦法判斷，其它方法是有，但是都沒有數學公式直接轉換來得快速，因此，基本的數學能力也是必須的。
七、演算法和資料結構
當程式語言學習到一定程度時，演算法和資料結構是一定要學的，如果演算法和資料結構不學，在寫遊戲時，總是會用一些很暴力的笨方法去解決問題，對於注重流暢度的遊戲程式來說，這不是件什麼好事，而且當地圖需要最短路徑時，也需要演算法才能完成。
除了程式語言一般的學習，當要用程式來寫遊戲，需要再另外學些東西，然而，如果以分工的角度來看，可以挑著學：
一、視窗程式設計
可以挑一套自己喜歡的視窗程式設計方法去學，目前有很多種選擇，MFC、Win32SDK、BCB....，等等，在設計地圖編輯器等等之類的編輯器是一定要學的。
二、Winsock
當你的遊戲不是一個人玩時，Winsock 就派上用場了，當然，DirectX 的連線方式也是另一個選擇，不過我個人比較喜歡 Winsock。
三、DirectX
DirectX 幾乎是在 Windows 下寫遊戲必學，Direct Draw 和 Direct 3D 兩個是最重要的，一個負責 2D 一個負責 3D，然而，現在 2D 大多都已經由 3D 模擬，因此，我是認為可以直接學 Direct 3D 就好，而要處理到音效、影片，就輪到 Direct Sound 和 Direct Show 上場了。
四、人工智慧
其實我一直覺得人工智慧這個名字取得不好，因為遊戲裡的"智慧"，大多都只是照一定規則的行為而以，這個部份，也是專門的領域。
五、古典物理
古典物理！？有沒有搞錯？是的，沒有搞錯，目前的遊戲很多都有很好的物理模擬，可以從物理模擬中，讓玩家感受的更真實的虛擬世界，如果物理沒有一點底子，就算是寫好的引擎可以使用，很多東西沒搞懂可能也不知道該怎麼用。
六、已經寫好的套件
事實上，很多東西因為太常用，都已經有人寫成引擎供人使用，就拿魔獸世界來說，他們就用到了 Lua 來當腳本的直譯器，重新開發一個直譯器的時間就整個省下來了，而且這些套件大多都經過很多人使用過，並且更新，因此穩定性和效能來講，常常會比自己寫的來的好(不過呢，人總是犯賤，有時不知道為什麼就比較喜歡自己寫)，因此，上面這些東西有時不一定要學，可以直接使用別人的套件，底層的東西就可以不用學了。
以上，是我自己小小的一點看法，如果覺得有問題請提出來指正，我有想到更多的話，會再補上來的。
作者：StubbornLin (Victor)
出處：批踢踢實業坊(ptt.cc)
GameDesign 精華區 - [程式] 遊戲程設之路
8月 11, 2008
【轉貼】資工系KTV必點歌曲
@
| 標籤:
轉貼
6月 01, 2008
【轉貼】程設師遇到BUG的回應
@
| 標籤:
轉貼
程式為什麼不會動？程式設計師告訴你為什麼！
20. "That's weird..."
這很奇怪喔。
19. "It's never done that before."
以前從來不會這樣啊！
18. "It worked yesterday."
昨天明明會動的啊！
17. "How is that possible?"
怎麼可能！？
16. "It must be a hardware problem."
這一定是硬體的問題。
15. "What did you type in wrong to get it to crash?"
你到底是打了什麼才讓程式當掉的？
14. "There is something funky in your data."
一定是你的資料有問題。
13. "I haven't touched that module in weeks!"
我已經好幾個禮拜沒碰那一段程式了。
12. "You must have the wrong version."
你一定是用到舊版了。
11. "It's just some unlucky coincidence."
一定是巧合！為什麼這種壞運氣只讓你碰上。
10. "I can't test everything!"
我不可能什麼功能都測試到吧，有 bug 是正常的！
9. "THIS can't be the source of THAT."
這個不可能是那個的原始碼！
8. "It works, but it hasn't been tested."
這程式應該是會動的，只是我寫好後還沒做測試。
7. "Somebody must have changed my code."
可惡！一定有人改了我的程式。
6. "Did you check for a virus on your system?"
你有檢查過你的電腦有沒有病毒嗎？
5. "Even though it doesn't work, how does it feel?"
儘管這功能還不能動啦，你覺得他如何？
4. "You can't use that version on your system."
在你的系統不能用那一個版本的程式啦！
3. "Why do you want to do it that way?"
你幹嘛要那樣操作，都是你的問題。
2. "Where were you when the program blew up?"
程式發生問題時你在哪裡？
1. "It works on my machine."
在我的機器明明就可以動啊！
20. "That's weird..."
這很奇怪喔。
19. "It's never done that before."
以前從來不會這樣啊！
18. "It worked yesterday."
昨天明明會動的啊！
17. "How is that possible?"
怎麼可能！？
16. "It must be a hardware problem."
這一定是硬體的問題。
15. "What did you type in wrong to get it to crash?"
你到底是打了什麼才讓程式當掉的？
14. "There is something funky in your data."
一定是你的資料有問題。
13. "I haven't touched that module in weeks!"
我已經好幾個禮拜沒碰那一段程式了。
12. "You must have the wrong version."
你一定是用到舊版了。
11. "It's just some unlucky coincidence."
一定是巧合！為什麼這種壞運氣只讓你碰上。
10. "I can't test everything!"
我不可能什麼功能都測試到吧，有 bug 是正常的！
9. "THIS can't be the source of THAT."
這個不可能是那個的原始碼！
8. "It works, but it hasn't been tested."
這程式應該是會動的，只是我寫好後還沒做測試。
7. "Somebody must have changed my code."
可惡！一定有人改了我的程式。
6. "Did you check for a virus on your system?"
你有檢查過你的電腦有沒有病毒嗎？
5. "Even though it doesn't work, how does it feel?"
儘管這功能還不能動啦，你覺得他如何？
4. "You can't use that version on your system."
在你的系統不能用那一個版本的程式啦！
3. "Why do you want to do it that way?"
你幹嘛要那樣操作，都是你的問題。
2. "Where were you when the program blew up?"
程式發生問題時你在哪裡？
1. "It works on my machine."
在我的機器明明就可以動啊！
原文：Top 20 replies by Programmers to Testers when their programs don't work
中譯：程式為什麼不會動？程式設計師告訴你為什麼！
5月 23, 2008
【轉貼】勤勉之人、輕量之人
@
| 標籤:
轉貼
這是 Ruby 之父兼日本 Ruby 協會會長(日本 Ruby の会)高橋征義 2007 年來台的演講，談到程式開發人員的兩種分類：勤勉之人(使用 Cobol、C/C++、Java)、輕量之人(使用 Perl、Python、Ruby)。
高橋通篇使用英文演講。影片雜音很多，不過搭配投影片，內容應不難理解。影片中也可以見識到傳說中的高橋流(高橋メソッド)簡報，其簡單大方的風格真有特色。
高橋メソッド in 中文
Diligent people, Lightweight people
簡報本身還滿幽默的。連涼宮春日(涼宮 ハルヒ)都可以搬出來講，真是服了他了。
高橋通篇使用英文演講。影片雜音很多，不過搭配投影片，內容應不難理解。影片中也可以見識到傳說中的高橋流(高橋メソッド)簡報，其簡單大方的風格真有特色。
高橋メソッド in 中文
Diligent people, Lightweight people
簡報本身還滿幽默的。連涼宮春日(涼宮 ハルヒ)都可以搬出來講，真是服了他了。
5月 10, 2008
【轉貼】程式高手的八大奧秘
@
| 標籤:
轉貼
不知不觉做软件已经做了十年，有成功的喜悦，也有失败的痛苦，但总不敢称自己是高手，因为和我心目中真正的高手们比起来，还差的太远。世界上并没有成为高手的快捷方式，但一些基本原则是可以遵循的。
1、扎实的基础
数据结构、离散数学、编译原理，这些是所有计算机科学的基础，如果不掌握它们，很难写出高水平的程序。程序人人都会写，但当你发现写到一定程度很难再提高的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，即使你再精通OOP，遇到一些基本算法的时候可能也会束手无策。因此多读一些计算机基础理论方面的书籍是非常有必要的。
2、丰富的想像力
不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想像力是建立在丰富的知识的基础上，除计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。开阔的思维对程序员来说很重要。
3、最简单的是最好的
这也许是所有科学都遵循的一条准则，复杂的质能转换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。
4、不钻牛角尖
当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。
5、对答案的渴求
人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。
6、多与别人交流
三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。
7、良好的编程风格
注意养成良好的习惯，代码的缩进编排，变量的命名规则要始终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程序的一个重要组成部分，它可以使你的代码更容易理解，而如果代码已经清楚地表达了你的思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。
8、韧性和毅力
这也许是“高手”和一般程序员最大的区别。高手们并不是天才，他们是在无数个日日夜夜中磨炼出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个10000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条。
这些是我这几年程序员生涯的一点体会，希望能够给大家有所帮助。
1、扎实的基础
数据结构、离散数学、编译原理，这些是所有计算机科学的基础，如果不掌握它们，很难写出高水平的程序。程序人人都会写，但当你发现写到一定程度很难再提高的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，即使你再精通OOP，遇到一些基本算法的时候可能也会束手无策。因此多读一些计算机基础理论方面的书籍是非常有必要的。
2、丰富的想像力
不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想像力是建立在丰富的知识的基础上，除计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。开阔的思维对程序员来说很重要。
3、最简单的是最好的
这也许是所有科学都遵循的一条准则，复杂的质能转换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。
4、不钻牛角尖
当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。
5、对答案的渴求
人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。
6、多与别人交流
三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。
7、良好的编程风格
注意养成良好的习惯，代码的缩进编排，变量的命名规则要始终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程序的一个重要组成部分，它可以使你的代码更容易理解，而如果代码已经清楚地表达了你的思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。
8、韧性和毅力
这也许是“高手”和一般程序员最大的区别。高手们并不是天才，他们是在无数个日日夜夜中磨炼出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个10000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条。
这些是我这几年程序员生涯的一点体会，希望能够给大家有所帮助。
作者：金蝶中间件公司 CTO 袁红岗
出處：高手谈做程序员的基本原则
訂閱：
文章 (Atom)
