發表文章
3000元投資全世界
買基金，先看進場時機。
投資前，一定要做功課
每股盈餘?本益比?停損停利
股票遇到暴跌怎麼辦?
是否跌破年線?如果跌破年線，通常意味著要等待很久才能回升。
標的物必須有的救
相對高點(七千點以上)及低點(五千點以下)
美國利率越調越高後，原本從國外來的熱錢紛紛離開亞洲，回到歐美市場。
調整的頻率有多快? 調整的幅度有多高?
投資不能單戀一支花
資產配置
幣別、股債比率、地區產業發展
絕對報酬，穩健成長
資產負債表、損益表
零存整付、定存定額
每月14000，6%，5年100萬
累積理財知識
1.政治風險
2.信用風險
3.匯率風險
4.流動性風險 小型股不易套現
5.利率風險 利率下跌、債?賺錢；利率賺錢、債?賠錢
投資標的、地區、投資風險、理財目標、時間
共同基金特色
1.金額可大可小
2.可分散標的、市場、時間投資、降低風險
3.專業館哩，提高收益
4.手續簡便，買賣容易，流動性佳
5.省時省力，合法節稅
基金先天陷阱
陷阱一:行情跌，基金經理人最多只能賣出30%
陷阱二:小心投資標的少、交易量低的基金
陷阱三:規模太小的基金，不牢靠
當基金的規模小到一定程度時，會因為它的固定費用而影響績效
台灣基金規模十億以上，海外基金規模四、五千萬
陷阱四:基金也有時間；壽命的限制
投資共同基金前務必要了解
1.基金規模大或小
2.基金投資標的的多或少
3.基金交易量的多或寡
4.基金有無時間、壽命限制
5.不強求基金經理人必賺錢
你適合投資哪一種債?基金?
1.想穩穩賺點兒利息:購買貨幣型基金
2.想賺更高利息、願意冒一點風險:購買歐債、亞洲新興債或全球債
3.不怕風險高:購買新興國家債?基金
4.希望股債都賺:購買複合式債?基金
5.購買債?型基金必考量四因子:利息、信用、匯率、政治風險
每月五千，投資報酬率8%
15年=>173萬
25年=>475.5萬
35年=>1146.9萬
每月五千，三十年，總投資金額180萬
5%=>416.1萬
8%=>745.2萬
10%=>1130.2萬
定期定額投資守則
1.量力而為
2.選擇在上升趨勢的市場，或絕對報酬曲線往上的基金
3.避免波動太大的地區或績效不穩的基金
4.善用暫停扣款、部份贖回，及適時轉換，自動停利
5.持之以恆
A Share，先收手續費
B Share，後收手續費
基金投資十大教戰守則
1.過度依賴過去績效
2.進場時機永遠不對
3.對基金淨值的高低價欠缺敏感度
4.投資人買賣基金欠缺停損概念
5.妥善分析基金波動幅度
6.過度聽信理財人員的建議
7.小心手續費及匯率風險
8.妥善資產配置是理財第一原則
9.時點要分散，標的也要分散
10.留意小道消息
本益比 股價/盈餘
基金買進、轉換、賣出的決策原則
1.基金績效不穩定
2.表現比大盤差
3.和同儕比較短中長績效經常吊車尾
4.基金公司或經理人有重大改變
5.當盤市走向不明，可分批調節降低風險
6.當大盤轉向時
7.當價格來到目標停利/停損點
8.當價格來到目標獲利/損失率
黃金交叉 股市短日線平均值穿過長天線平均值，並且在長天線之上
死亡交叉 股市長天線平均值穿過短日線平均值，並且在短日線之上
從利率高低選擇投資工具
1.利率由高往下:投資債?基金
2.利率到達谷底:投資股票基金，賣出債?基金
3.利率由下往上:投資貨幣基金
從國民生產毛額看景氣
GDP
=Government(政府建設)
+Export(出口)
-Import(進口)
+Inventory(存貨)
+Consumption(消費)
+Investment(投資)
從景氣燈號看景氣
紅燈------景氣過熱---38分以上
黃紅燈---景氣微熱---32~37分
綠燈------景氣穩定---23~31分
黃藍燈---景氣欠佳---18~22分
藍燈------景氣衰退---17分以下
從政府動作看景氣
財政政策
貨幣政策
貨幣供給水平(M1:活期性存款、活期儲蓄存款，M2=M1再加上定期存款)
景氣循環鐘
12.景氣頂端
1.物價上漲
2.利率開始上揚
緊縮貨幣政策
債?價格下跌
3.股價下挫
4.公司獲利下降
5.房地產價格下滑，議價空間加大
6.景氣股底
7.利率下降
寬鬆貨幣政策
8.債?價格上揚
9.公司獲利回升
10.股價回升
11.房地產價格上揚
12.景氣頂端
財經資訊
台灣經濟新報www.tej.com.w
Bloomberg
經建會www.cept.gov.tw
經濟日報 工商時報
CRB指數又稱CRB期貨價格指數，由二十一種不同商品組成
選基金指標
基金風險度
變動標準差 指的是震盪幅度
貝他值 指的是基金與大盤貼近的幅度
阿爾發值 經理人超越大盤績效的能力
夏普值 經理人冒每一單位風險所得出的超額利潤
分散投資
中報酬，低風險
穩健報酬，長期投資
八個步驟
1.選擇幣別
2.選擇投資工具
3.從風險較低的基金類開始
4.海外債?
5.選擇自己熟悉的市場
6.找出核心投資並訂下比例
7.決定操作策略
買進，並長期持有
8.利用負相關的基金做投資組合的基本原料
社會新鮮人，首重練功力
時間及複利
避免快速消費陷阱
專注本業
三十歲擁有一百萬
理財與財務規劃
人生各階段財務需求
短中長期規劃
2008年4月20日 星期日
[Book][書摘]35歲前要有錢
35歲前要有錢
30、100、100的魔術數字
30歲前存30萬，養成儲蓄習慣
35歲前存到100萬，複利8%
40歲前存到200萬，複利8%
退休時千萬
25歲開始定額投資，60歲就能獲得一筆可觀的退休金(假設每年報酬率6%)
10000/月 報酬率6% 十年 176萬
15000/月 報酬率6% 十年 250萬
15000/月 報酬率6% 二十五年 1046萬
15000/月 報酬率6% 三十五年 2481萬
量入為出、開源節流、不要浪費
一生能賺多少錢?
30歲~60歲 年收100 =>30X100=3000
平均壽命 男:76 女:80
理財不能等，要理財年輕時就要開始
信用卡
延遲付費、本月消費、下月還清
免息分期是一顆包著負債的糖衣
記帳
先理債再理財
不要為理財而負債
1.理財之前要先有足夠的儲蓄
2.理財的態要很好
每月開支紀錄表
報酬率背後意義代表風險
把本金拉高，讓報酬率不要負擔太重
高儲蓄、低投資報酬率、專注本業
賺的錢存一半以上
有錢人想的跟你不一樣
定期檢查財務狀況、吸收最新的理財資訊
理財的兩大禁忌 :貪婪與恐懼
資產配置
一般人會操作到的區間，通常是你認為的最高點要減百分之十，最低點要加百分之十。
七二法則
72/預期報酬率=本金翻一倍的時間
聽不懂的商品不要碰
資訊來源、判讀能力
收入三等份
1.固定重大支出 如:房子、車子、保險
2.基本開銷 食、衣、住、行、育、樂
3.存款
再窮也要存錢
積少成多
節約支出
要理財必須每月存三分之ㄧ以上
越早存錢投資越早享受果實
比定存高就是贏，穩紮穩打
永久儲蓄的習慣是理財的基本
多賺!少花!
不要花費太多買無謂的產品，能延遲消費就延遲消費，要存錢就不要浪費
高配息股票
中鋼、台塑
股東持股比例在50%以上的公司
保險
壽險、意外險、醫療險、防癌險
負債的元兇 過度消費、衝動消費
購物清單
去除拿鐵因子
不要太早買車
二手車
買車就是負債
理財最怕就是負債
養車費用攤提表
二手屋
總價低一點的
小孩教育費花的多不如花的有頭腦
不要帶太多錢、金融卡、信用卡
不要為贈品辦卡
資產負債表
負債比 負債佔收入的比例有多少
先還高利率的短期負債，在還低利率的長期負債
降低消費慾望
花錢前停看聽，貨比三家
延遲消費
要花在有用的地方上
預算控制
先窮後富
[Book][書摘]槓桿閱讀術
槓桿閱讀術
尋找問題解決之道，不多讀不重要的地方，重點掌握
先讀目錄、後記，判斷是否對自己有所幫助
有用的地方做筆記
在書本上標號、劃線、紀錄、折頁
抽出書中精華
收入百分之十購買書籍
只有自己掏腰包，才會意識到想要回本
一星期一本書
同樣的主題讀上五本書，就可以看出自己獨樹一格的原理原則
沒有時間讀書只是藉口
書中集結別人幾十年的經驗和智慧
除非改變了交往的人與所讀的書，
否則五年後的你與現在完全一樣。
-------查理斯 瓊斯(Charlie Jones)
人生最有害的詞彙是明天，用這詞彙最多的是窮人、不成功的人
、不健康的人。他們常說明天開始減肥和運動、明天開始讀懂。
我從未看過明天。
在我身上只有今天。
今天是勝利者的辭彙，
明天是失敗者的辭彙。
-------羅勃特 清崎(Robert Kiyosaki)
儘可能的丟棄沒有必要的書籍
加強自我的課題，研究相關產業、學習會計知識...等
沒有必要忍受去閱讀難懂的書籍
經驗類型
選擇和切身有關的題目
時間管理...
依主題、趨勢、直覺選書
類別集中法
哪本書都寫到相同內容，你就可以判斷那是所有認為的重點
彩色浴
設定每天幾點到幾點，變成習慣
一大早，早睡早起
與其選出全部的一百項來讀，而沒有學到一項，還不如只選出
重要的一項來實踐，才能有所回報。
一本書裡重點只佔百分之二十
捨棄完美主義
80/20法則
粗體字
不好的書馬上丟棄
事前準備好十本還沒讀的書
掃讀
槓桿效益筆記本
按照題目做分類
1.重點紀錄
2.後續工作 實際體驗
主題類
經營
行銷
創業
資訊科技
訓練、人才管理
財務知識
不動產、股票投資
退休
目標管理
自我管理
人脈
閱讀、學習
實用英語
健康
時間管理
溝通
心理學
參考資料
引用文句
多讀幾次筆記，作為個人資產
讀過的書不要再讀第二遍，經典除外
利用書架來整理書籍
IP20書架www.ip20.co.jp
反覆閱讀，實踐
隨身攜帶筆記
用電腦製作列印
[Book]Pragmatic Programmer
http://www.amazon.com/Pragmatic-Programmer-The/dp/B000SEGEKI/ref=dp_kinw_strp_1
1. Care About Your Craft
Why spend your life developing software unless you care about doing it well?
2. Think! About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.
3. Provide Options, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
4. Don't Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
5. Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it.
6. Remember the Big Picture
Don't get so engrossed in the details that you forget to check what's happening around you.
7. Make Quality a Requirements Issue
Involve your users in determining the project's real quality requirements.
8. Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
9. Critically Analyze What You Read and Hear
Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
10. It's Both What You Say and the Way You Say It
There's no point in having great ideas if you don't communicate them effectively.
11. DRY–Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
12. Make It Easy to Reuse
If it's easy to reuse, people will. Create an environment that supports reuse.
13. Eliminate Effects Between Unrelated Things
Design components that are self-contained. independent, and have a single, well-defined purpose.
14. There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.
15. Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.
16. Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
17. Program Close to the Problem Domain
Design and code in your user's language.
18. Estimate to Avoid Surprises
Estimate before you start. You'll spot potential problems up front.
19. Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.
20. Keep Knowledge in Plain Text
Plain text won't become obsolete. It helps leverage your work and simplifies debugging and testing.
21. Use the Power of Command Shells
Use the shell when graphical user interfaces don't cut it.
22. Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
23. Always Use Source Code Control
Source code control is a time machine for your work—you can go back.
24. Fix the Problem, Not the Blame
It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.
25. Don't Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
26. "select" Isn't Broken.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
27. Don't Assume It—Prove It
Prove your assumptions in the actual environment-- with real data and boundary conditions.
28. Learn a Text Manipulation Language.
You spend a large part of each day working with text. Why not have the computer do some of it for you?
29. Write Code That Writes Code
Code generators increase your productivity and help avoid duplication.
30. You Can't Write Perfect Software
Software can't be perfect. Protect your code and users from the inevitable errors.
31. Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.
32. Crash Early
A dead program normally does a lot less damage than a crippled one.
33. Use Assertions to Prevent the Impossible
Assertions validate your assumptions. Use them to protect your code from an uncertain world.
34. Use Exceptions for Exceptional Problems
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
35. Finish What You Start
Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
36. Minimize Coupling Between Modules
Avoid coupling by writing "shy" code and applying the Law of Demeter.
37. Configure, Don't Integrate
Implement technology choices for an application as configuration options, not through integration or engineering.
38. Put Abstractions in Code, Details in Metadata
Program for the general case, and put the specifics outside the compiled code base.
39. Analyze Workflow to Improve Concurrency
Exploit concurrency in your user's workflow.
40. Design Using Services
Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.
41. Always Design for Concurrency
Allow for concurrency, and you'll design cleaner interfaces with fewer assumptions.
42. Separate Views from Models
Gain flexibility at low cost by designing your application in terms of models and views.
43. Use Blackboards to Coordinate Workflow
Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
44. Don't Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan.
45. Estimate the Order of Your Algorithms
Get a feel for how long things are likely to take before you write code.
46. Test Your Estimates
Mathematical analysis of algorithms doesn't tell you everything. Try timing your code in its target environment.
47. Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
48. Design to Test
Start thinking about testing before you write a line of code.
49. Test Your Software, or Your Users Will
Test ruthlessly. Don't make your users find bugs for you.
50. Don't Use Wizard Code You Don't Understand
Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
51. Don't Gather Requirements–Dig for Them
Requirements rarely lie on the surface. They're buried deep beneath layers of assumptions, misconceptions, and politics.
52. Workwith a User to Think Like a User
It's the best way to gain insight into how the system will really be used.
53. Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
54. Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.
55. Don't Think Outside the Box–Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"
56. Start When You're Ready.
You've been building experience all your life. Don't ignore niggling doubts.
57. Some Things Are Better Done than Described
Don't fall into the specification spiral—at some point you need to start coding.
58. Don't Be a Slave to Formal Methods.
Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
59. Costly Tools Don't Produce Better Designs
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
60. Organize Teams Around Functionality
Don't separate designers from coders, testers from data modelers. Build teams the way you build code.
61. Don't Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.
62. Test Early. Test Often. Test Automatically
Tests that run with every build are much more effective than test plans that sit on a shelf.
63. Coding Ain't Done 'Til All the Tests Run
'Nuff said.
64. Use Saboteurs to Test Your Testing
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
65. Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn't enough.
66. Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
67. English is Just a Programming Language
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
68. Build Documentation In, Don't Bolt It On
Documentation created separately from code is less likely to be correct and up to date.
69. Gently Exceed Your Users' Expectations
Come to understand your users' expectations, then deliver just that little bit more.
70. Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.
1. Care About Your Craft
Why spend your life developing software unless you care about doing it well?
2. Think! About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.
3. Provide Options, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
4. Don't Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
5. Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it.
6. Remember the Big Picture
Don't get so engrossed in the details that you forget to check what's happening around you.
7. Make Quality a Requirements Issue
Involve your users in determining the project's real quality requirements.
8. Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
9. Critically Analyze What You Read and Hear
Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
10. It's Both What You Say and the Way You Say It
There's no point in having great ideas if you don't communicate them effectively.
11. DRY–Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
12. Make It Easy to Reuse
If it's easy to reuse, people will. Create an environment that supports reuse.
13. Eliminate Effects Between Unrelated Things
Design components that are self-contained. independent, and have a single, well-defined purpose.
14. There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.
15. Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.
16. Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
17. Program Close to the Problem Domain
Design and code in your user's language.
18. Estimate to Avoid Surprises
Estimate before you start. You'll spot potential problems up front.
19. Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.
20. Keep Knowledge in Plain Text
Plain text won't become obsolete. It helps leverage your work and simplifies debugging and testing.
21. Use the Power of Command Shells
Use the shell when graphical user interfaces don't cut it.
22. Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
23. Always Use Source Code Control
Source code control is a time machine for your work—you can go back.
24. Fix the Problem, Not the Blame
It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.
25. Don't Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
26. "select" Isn't Broken.
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
27. Don't Assume It—Prove It
Prove your assumptions in the actual environment-- with real data and boundary conditions.
28. Learn a Text Manipulation Language.
You spend a large part of each day working with text. Why not have the computer do some of it for you?
29. Write Code That Writes Code
Code generators increase your productivity and help avoid duplication.
30. You Can't Write Perfect Software
Software can't be perfect. Protect your code and users from the inevitable errors.
31. Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.
32. Crash Early
A dead program normally does a lot less damage than a crippled one.
33. Use Assertions to Prevent the Impossible
Assertions validate your assumptions. Use them to protect your code from an uncertain world.
34. Use Exceptions for Exceptional Problems
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
35. Finish What You Start
Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
36. Minimize Coupling Between Modules
Avoid coupling by writing "shy" code and applying the Law of Demeter.
37. Configure, Don't Integrate
Implement technology choices for an application as configuration options, not through integration or engineering.
38. Put Abstractions in Code, Details in Metadata
Program for the general case, and put the specifics outside the compiled code base.
39. Analyze Workflow to Improve Concurrency
Exploit concurrency in your user's workflow.
40. Design Using Services
Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.
41. Always Design for Concurrency
Allow for concurrency, and you'll design cleaner interfaces with fewer assumptions.
42. Separate Views from Models
Gain flexibility at low cost by designing your application in terms of models and views.
43. Use Blackboards to Coordinate Workflow
Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
44. Don't Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan.
45. Estimate the Order of Your Algorithms
Get a feel for how long things are likely to take before you write code.
46. Test Your Estimates
Mathematical analysis of algorithms doesn't tell you everything. Try timing your code in its target environment.
47. Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
48. Design to Test
Start thinking about testing before you write a line of code.
49. Test Your Software, or Your Users Will
Test ruthlessly. Don't make your users find bugs for you.
50. Don't Use Wizard Code You Don't Understand
Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
51. Don't Gather Requirements–Dig for Them
Requirements rarely lie on the surface. They're buried deep beneath layers of assumptions, misconceptions, and politics.
52. Workwith a User to Think Like a User
It's the best way to gain insight into how the system will really be used.
53. Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
54. Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.
55. Don't Think Outside the Box–Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"
56. Start When You're Ready.
You've been building experience all your life. Don't ignore niggling doubts.
57. Some Things Are Better Done than Described
Don't fall into the specification spiral—at some point you need to start coding.
58. Don't Be a Slave to Formal Methods.
Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
59. Costly Tools Don't Produce Better Designs
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
60. Organize Teams Around Functionality
Don't separate designers from coders, testers from data modelers. Build teams the way you build code.
61. Don't Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.
62. Test Early. Test Often. Test Automatically
Tests that run with every build are much more effective than test plans that sit on a shelf.
63. Coding Ain't Done 'Til All the Tests Run
'Nuff said.
64. Use Saboteurs to Test Your Testing
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
65. Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn't enough.
66. Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
67. English is Just a Programming Language
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
68. Build Documentation In, Don't Bolt It On
Documentation created separately from code is less likely to be correct and up to date.
69. Gently Exceed Your Users' Expectations
Come to understand your users' expectations, then deliver just that little bit more.
70. Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.
訂閱：
文章 (Atom)