Design schema carefully
The cost of changing/migrating old data is expensive, so it's important to try to make it right at first.
Give meaningful, easy-to-remember name
Use ID(instead of name) to reference other data.
Be schema-less
For example: in solr, only add explicit field if you need to search against it; for all other fields that we are sure we will never search, considering store all as one JSON or binary data field.
So it's easier to add/remove these fields.
Use public APIs as much as possible
-- For instance: when develop restful service: use apis from javax(HttpServletRequest) or javax.ws.rs.core if possible - not apis from com.sun.jersey or org.glassfish.jersey.
-- APIs from private apis is more likely to change.
Ensure You Can Wire On and Off Functions
Always Propose Different Solutions then Compare them
Use List and graph to compare pros and cons
Use Cases Analysis
How to implementation in high level
What's the effort
Don't over-engineer
Pull form upstream(master) branch frequently
- Always work on latest code
Build/Try simple workable code first
Solve Problem from Different Angles
What Could Possibly Go Wrong?
-- During coding, deployment
Soft Skills
How to find best solution
Always try/propose different approaches
Talk with others/team members
Don't get too defensive for your solution
- Be open minded
What important is to:
- find best/easiest/robust solution - good for you to maintain code later
- Learn new things, new ways to tackle problems
Don't (just) try to convince others to take your approach
It's easy that we propose different approaches for feature other developer is working on.
But more important is to compare whether the new approach is better or whether there is other better solution.
Different doesn't means better
This is especially more important for senior engineers, because if you give not-well-thought solution, others may be (forced) convinced to take your approach.
More important is to carefully compare these different approaches in detail
-- How to implement all (important/basic) functions in each approach
-- How to handle new requirements later
Communication
Communicate early and often
Let others know what you are doing and your progress
-- Avoid duplicate work
Be open-minded
Learn aggressively
The cost of changing/migrating old data is expensive, so it's important to try to make it right at first.
Give meaningful, easy-to-remember name
Use ID(instead of name) to reference other data.
Be schema-less
For example: in solr, only add explicit field if you need to search against it; for all other fields that we are sure we will never search, considering store all as one JSON or binary data field.
So it's easier to add/remove these fields.
Use public APIs as much as possible
-- For instance: when develop restful service: use apis from javax(HttpServletRequest) or javax.ws.rs.core if possible - not apis from com.sun.jersey or org.glassfish.jersey.
-- APIs from private apis is more likely to change.
Ensure You Can Wire On and Off Functions
Always Propose Different Solutions then Compare them
Use List and graph to compare pros and cons
Use Cases Analysis
How to implementation in high level
What's the effort
Don't over-engineer
Pull form upstream(master) branch frequently
- Always work on latest code
Build/Try simple workable code first
Solve Problem from Different Angles
What Could Possibly Go Wrong?
-- During coding, deployment
Soft Skills
How to find best solution
Always try/propose different approaches
Talk with others/team members
Don't get too defensive for your solution
- Be open minded
What important is to:
- find best/easiest/robust solution - good for you to maintain code later
- Learn new things, new ways to tackle problems
Don't (just) try to convince others to take your approach
It's easy that we propose different approaches for feature other developer is working on.
But more important is to compare whether the new approach is better or whether there is other better solution.
Different doesn't means better
This is especially more important for senior engineers, because if you give not-well-thought solution, others may be (forced) convinced to take your approach.
More important is to carefully compare these different approaches in detail
-- How to implement all (important/basic) functions in each approach
-- How to handle new requirements later
Communication
Communicate early and often
Let others know what you are doing and your progress
-- Avoid duplicate work
Be open-minded
Learn aggressively
