星期日, 十一月 25, 2007
架构 Architecture
1.最高层次系统的分解
2.系统中不易改变的决定
架构是一种主观的东西,是专家级项目人员对系统设计的一些可共享的理解。它包括一些决定,开发者们希望这些决定能及时早作出,因为在开发者看来它们是难以改变的。
架构的主观性也来源于此,如果你发现某些决定并不像你想象的那么难以改变,那么它就不再与架构相关。
星期日, 八月 12, 2007
Working Professional @ SAP
What makes effective writing?
Get to the point
Almost write if you talk
Always reread what you have written
4S rules:
Simple
Short
Specific
Sympathetic
Planning tool matrix
Import but not urgent
We should always focus on the import but not urgent.
Core Time : You should always reserve part of time as Core Time , which means during this time , you should focus on what’s really needed, during this time , you should not be disturbed by Emails , phone call, meetings , something like that.
Common Time Waster:
Inability to say “No”
Inability to delegate
Inability to prioritize
Lack of planning
Always think about goal before doing it, it will make you more effective when doing it.
Communication Skills: Open close principle.
The art of the explaining:
Say your purpose first
Logic order
Close with action plan
Keep it simple and short
Listening Skills:
SLANT: Sit, Lean, Ask, Nod, Think
Body Language is important during talking.
The Art of Project Mangement - Why Leadership is based on trust
Building and losing trust
* Trust is built through effective commitments.
- Do what you say and say what you mean.
- Admit when you're wrong.
- Enlist the opinions and ideas of others in decisions that impact them.
- We can trust people we do not like or do not wish to spend time with.
* Through inconsistent behavior on matters of importance.
Two kinds of power : Granted Power and Earned Power
* Use the granting of authority and trust to enable people to do a great work.
* Granted power comes from the organizational hierarchy. Earned power comes only from people's responses to your actions. Earned power is more useful than granted power, although both are necessary.
- Persuasion is stronger than dicdation
- When things go out of control , granted power can be the fastest way to achieve order.
- Be clear , be direct
Trust others
* Use delegation to build trust on your team and to ensure your team against adversity.
Respond to problems in a way that will maintain people's trust. Support them during crises so that they bring issues to you instead of hiding them.
- delegation : trusting others to make decisions.
Trust in yourself
* Trust in yourself is the core of leadership.
* Self-discovery is the way to learn who you are and to develop healthy self-reliance.
星期三, 五月 09, 2007
How to access private fields through reflect?
A a = new A("Hello Vincent");
Field field = a.getClass().getDeclaredField("a");
field.setAccessible(true);
System.out.println(field.get(a).toString());
星期二, 五月 01, 2007
Design Patterns - Null Object Pattern
Design Patterns - Visitor Pattern
星期一, 四月 30, 2007
Design Patterns - Memento Pattern
Design Patterns - Prototype Pattern
星期三, 四月 25, 2007
Design Patterns - Composite Pattern
星期一, 四月 09, 2007
Design Patterns - Decorator Pattern
Design Patterns - Facade Pattern
Design Patterns - Adapter Pattern
Design Patterns - Singleton Pattern
sample code :
public class Singleton {
private static Singleton uniqueInstance;
private Singleton() {
}
public Singleton getInstance() {
if(uniqueInstance == null) {
uniqueInstance = new Singleton();
}
return uniqueInstance;
}
}
Deal with multi thread :
public class Singleton {
private static Singleton uniqueInstance;
private Singleton() {
}
public synchronized Singleton getInstance() {
if(uniqueInstance == null) {
uniqueInstance = new Singleton();
}
return uniqueInstance;
}
}
Double checked Singlton method :
package com.oreilly.designpattern.singleton;
public class DoubleCheckSingleton {
private volatile static DoubleCheckSingleton uniqueInstance;
private DoubleCheckSingleton() {
}
public DoubleCheckSingleton getInstance() {
if (uniqueInstance == null) {
synchronized (DoubleCheckSingleton.class) {
if (uniqueInstance == null) {
uniqueInstance = new DoubleCheckSingleton();
}
}
}
return uniqueInstance;
}
}
星期六, 二月 10, 2007
Code Complete - fixing a defect
* Understand the program , not just the problem
- that means the code related to the problem , not a few lines , but a few hundreds
* Confirm the defect diagnosis
* Relax
- This is very important , in many circumstance you will work under pressure
* Save the original source code
- using version control tool
* Fix the problem , not the symptom
* Make one change at a time
* Check your fix
* Add a unit test that express the defect
* Look for similar defects