Friday, June 21, 2013
Sunday, June 2, 2013
Here are some best practices that I have learnt so far. If you find something to be inappropriate / inaccurate, please comment below so that I may update this post as necessary. Again, these are evolving thoughts and may change as I learn something new. I have put these things on GitHub too.
- Always make sure that you name the variables appropriately.
- Follow a general pattern. It should be clear what a function does and returns. stick to the standards.
- Experiment as much as possible before you use some thing in production.
- Open source almost everything as much as possible.
- Composability - Always keep this in your mind.
- Never change a function signature that some one else has written without discussing with your team first. This is the most stupidest thing to do.
- Write kick ass test cases. This will drag you in the beginning, but trust me, this will hold your back in the long run.
- Write as much extensive documentation as possible.
- Build a CI server. Have it test your code each time you commit your code. That way, everyone will immediately know if something is broken.
- Always stick to the standards and general patterns as much as possible. By that way, any new member in the team can figure things on himself without much help from the others.
- If the logic / idea behind the code is not obvious, either write a crystal clear documentation or rewrite the code so it is obvious.
- Remove redundant pieces of code, UI or anything.
- Never update a production server. If there are any compelling reasons to update your server, have an identical staging server, update/ upgrade it, run your kick-ass test cases and if everything seems to be right, then you may continue updating your production server.
- Prefer Git unless you have any oher strong reason to use somthing else.
- Keep your runnables on root of your repo.
- Have to main branches - prod (for production) and dev (development) branches.
- And other branches as required - hotfix-* and feature-*
- You NEVER commit directly on prod.
- If there are any severe bugs in prod, then you may checkout hotfix-* from prod, fix the issue and merge it back into prod.
- The only activity on prod branch is to pull from a stable dev or a hotfix-*.
- If you want to add a new feature, then you should checkout feature-* from dev, Implement the feature and merge it back to dev.
- The activities on dev should only pulling from feature-* and pulling from prod which has a hotfix-* merge.
- Avoid usage of GUI tools. GUIs are great for code review. But always use git command line for committing and stuff.
- Try to user --no-ff to preserve branching history.
- We almost always write our new code at the end of the file. This will lead to merge conflict if all of us work on same part of file. Instead, try to write new codes other than the end of file. some where it is more appropriate. This will prevent merge conflict to an extent.
- It is always a good idea to have release notes with a diff of codes. Great for reviews.
- Merge vs. Rebase: Use merge when you want to preserve the branching tree. Using merge will result in a additional merge commit. Use rebase if you dont need preserve the branching tree and avoid the additional merge commit.
- Get out as soon as possible.
- Build a very minimal viable product and go out as soon as possible. You never know what users want. This will give an opportunity to learn and build more.
- After all, this is the part which users will be seeing.
- DO NOT make the user remember anything.
- Everything should be intuitive.
- Users should accomplish their tasks with as much lesser efforts as possible.
- Keep the interface as much simple as possible.
- Everything should be obvious.
- Make Fewer HTTP Requests
- Use a Content Delivery Network
- Add an Expires Header
- Gzip Components
- Put Stylesheets at the Top
- Put Scripts at the Bottom
- Avoid CSS Expressions
- Reduce DNS Lookups
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
- Make AJAX Cacheable
- If you want to succeed as bad as you want to breath, you will.
- If you use any open source projects, give an attribution to them.
- Contribute to their repo or donate something, no matter how small it is. It is these small things that move an open source projects forward.
- Open source your code as much as possible.
- If you are a startup, hire some freshers who are passionate about technology, and guide and mentor them. Turn them into some valuable stuff that a society could use. And make sure he will do the same thing to some other fresher when he is settled.
- Blog about problems you have faced and the approach that you took to solve it. It might help some one else.