1、一些简单的方法可以让你的代码看起来更明了，如函数或者方法，尽量的写的小一些，如果太冗长，尝试抽出一块写成一个函数；
2、如果业务逻辑比较复杂，判断选项较多，可以把判断抽出来，归结出不同条件，再用switch case写，如果还不够明了，把case们
写成函数方法就更好了，过于复杂的嵌套IF会把维护人员弄傻；
3、动态文件和静态文件要分开，写在一起很方便，后期安全问题会让人不知所措（例如专题可以做分离）；
4、写代码要顾及出错后的调试，合理使用异常处理；
5、尽量的复用，在代码开发初期能按照流程写就好了，但后期或者前期规划可注意复用；
6、如果不是故意搞破坏或者实在没办法，切勿把大段大段的代码写到模板里，能让人疯掉。
7、基本问题,命名尽量不要用缩写，英文或拼音的尽量写的人看懂，"1,1_1,1_1_1"还有一些模糊的命名会持续在项目的每一个阶段浪费
时间，最后杀死这个项目。
8、基本问题,缩进尽量有统一规则，注释有时间的话尽量加上。
系统问题和前期问题(个人看法)：
1、注意系统即便写的很好也可能废掉；
2、前期设计要占一大部分时间，然后是开发，之后是测试（技术测试和业务验收），如果业务逻辑等有变化，需要修改，包括技术思维
变化自己要修改，所以没有结束，甚至没有无线接近，直到软件生命周期结束。
3、能省力气开发的尽量要节省力气（节约成本），比如
a、尽量让自己代码易读、简洁、可复用；
b、尽量砍掉可预计不必要的功能；
c、如果去做规划，如果增加时间可以有效重新整理（重构）程序项目，可做（没思路当然啥都不干最好）;
d、关于捷径，如果有开源和网上可查代码利用尽量利用，之后就是C选项。
4、即便写好一个系统，后期运营维护让系统有效执行要耗掉剩余的90%精力（接2）；
关于沟通：
即便不理解不同意也要给不同的意见留一部分空间；
推荐工具：xmind,百度脑图等工具