1) All customisation have to be deployable and repeatable, such as using WSPs and features to deploy solution to SharePoint environment. NEVER do manual deployments or fixes, such as create a custom list, modify config file, update SharePoint site. As all these can be done in SharePoint API and scripted in most cases.
2) Implement automate deployment process to reduce possible human error, such as site creation and site configuration. This can be done by PowerShell, batch file, wsp or custom application. Example write a bespoke console application to export site hierarchy and contents, when deploy solution the bespoke application should reuse to create whole SharePoint site.
3) Make sure all SharePoint Services Objects were disposed correctly to avoid memory leak. Reference site http://msdn.microsoft.com/en-us/library/aa973248(v=office.12).aspx. And the tool to check objects were disposed correctly, http://archive.msdn.microsoft.com/SPDisposeCheck.
4) Do not try to customise any SharePoint site definition or template, all design and customization should be done by feature stapling or web provisioning event. Any customisation on SharePoint component is bad and not promised to compatible in future SharePoint release.
5) Custom coding should be done in Sandbox solution and this is because:
a. Better resource monitoring and controlling.
b. Compatible with Office 365.
c. Isolated, better security for farm.
http://msdn.microsoft.com/en-us/magazine/ee335711.aspx
6) Minified JS and CSS files, also consolidate them into two files to improve SharePoint rendering performance.
7) Using Model-View-Presenter (MVP), Model-View-Controller (MVC) or similar layer separation pattern to speed up development process. Using mocking framework to perform unit testing on SharePoint object. E.g TypeMock or Nmock. In my opinion the unit test should cover basic function tests with looses code, this will prevent chances to break test classes when code refactoring.
8) Make sure source and destination server are in same version and packages when using the SharePoint's content export/import. Such as same language pack, service pack, hotfixes.
9) Test, test and test before check-in into source control. Developer has full responsibility when check-in codes, he/she must fully tested their code and check-in with meaning comments.
10) Try to use the out-of-box features as much as possible, unless you have very strong reason not to do so otherwise developer should avoid using any custom database, codes or third parties components.
