总结20条编程经验,有用,留着

1. 估算解决问题所需要的时间。不要怕,承认吧!我曾见过一些程序员为了解决一个特殊问题而坐在显示器前面8小时。为自己定一个时间限制吧,1小时、30分钟或甚至15分钟。如果在这期间你不能解决问题,那就去寻求帮助,或到网上找答案,而不是尝试去做“超级堆码员”。

2. 编程语言是一种语言,只是一种语言。随着时光推移,只要你理解了一种语言的原理,你会发现各种语言之间的相似之处 。你所选择的语言,你应该觉得“舒服”,并且能够写出有效(而且简洁)的代码。最重要的,让语言去适应项目,反之亦然。

3. 不要过于注重程序的“设计模式”。 有时候,写一个简单的算法,要比引入某种模式更容易。在多数情况下,程序代码应是简单易懂,甚至清洁工也能看懂。

4. 经常备份代码。在我年轻时,我就有过因硬盘故障而丢了大量代码的经历,这经历很恐怖的。只要你一次没有备份,就应当像有着严格的期限,客户明天就需要。此时就该源码/版本控制软件大显身手了。

5. 承认自己并不是最顶尖的程序员 – 知不足。我常想,我对编程了解已足够多,但是总有其他人比你优秀。正所谓,“一山总比一山高”。所以,向他们看齐吧!

6. 学习再学习。正如第5点所说,我经常会在手里拿一本计算机或编程相关的杂志或书(不信,可以问我的朋友)。诚然,总有很多你不知道的技术,你可以从中学习以保持不落后。如果你有一种灵巧的方式来获取你需要的新技术,那你每天都应该坚持学习。

7. 永恒的变化。你对待技术/编程知识,就应像你对待股票一样:多样化。不要在某一特定技术上自我感觉良好。如果那种技术或语言已经没有足够支持,那你还不如现在就开始更新你的简历,并启动培训新计划。我能保持前行的主要原则是什么呢?至少了解两到三种语言,所以,如果某种语言过时了,你在学习新技术的时候还可以依靠另一种语言。

8. 提携新人。协助并且培养初级/入门的开发人员学习优秀的编程方法和技巧。也许你还不知道,在帮助他们向更高一层前进时,你自己也在向更高一层提升,你会更加自信。

9. 简化算法。代码如恶魔,在你完成编码后,应回头并且优化它。从长远来看,这里或那里一些的改进,会让后来的支持人员更加轻松。

10. 编写文档。无论是Web服务的API,还是一个简单的类,你尽量编写相应文档。我曾经引以为豪的代码注释,因过度注释而有人指责。给三行代码加一行注释,只需要你几秒时间。如果那是一个比较难以理解的技术,千万别担心过多注释。如果你能很好做好自己的工作,大多数架构师、后备程序员、支持组都会感激你。

11. 测试、测试再测试。我是一名黑盒测试粉丝。当你完成编码后,你“被认可”的时候就开始了。如果你们公司有QA部门,如果你的代码中有错误,那你得到的评论,会比项目经理还多。如果你不彻底测试自己的代码,那恐怕你开发的就不只是代码,可能还会声名狼藉。

12. 庆祝每一次成功。我见过很多程序员在解决编程技术难题后,会和同伴握手、击掌或甚至手舞足蹈。每个人在生命中都会碰到“顿悟”。如果一个程序员高兴地跑来叫你去看他的非凡代码,也许你已经看过这样的代码100遍了,但你也应该为了这个家伙而庆祝第101次。

13. 经常检查代码。 在公司,你的代码要经常检查(包括自查和其他同事检查)。不要把别人的检查,看成是对代码风格的苛求。应该把它们看作是有建设性的批评。对个人来说,经常检查你的代码并且自问,“我怎样才能写得更好呢?” 这会让你加速你的成长,让你成为一个更优秀的程序员。

14. 回顾你的代码。在看到自己以前的代码时,通常会有两种方式:“难以至信,这代码是我写的”和“难以至信,这代码是我写的”。第一种往往是厌恶的语气,并在想如何改进它。你也许会惊叹,旧代码也能复活成为一种更好的程序,甚至是一个完整的产品。第二种通常带着惊奇和成就感。开发人员应该一到两个自己完成的项目成果,能让众人不禁而立并注目而观的项目。同样,基于你优越的编程能力,你可以把过去的程序或项目拿出来,把它们更新为更加优秀的产品或想法。

15. 幽默是不可缺的。在我20年的开发生涯中,我还没有碰到哪位程序员是没有幽默感的。实际上,干我们这行,幽默是一项必备品。

16. 谨防那些无所不知的程序员,不愿分享的程序员,还有经验不足的程序员。当你遇到这几种程序员时,你自己要谦虚。无所不知的程序员,更想当一个英雄而不是团队成员;保守的程序员则是在编写着他们独享的代码;而经验不足的程序员则会每十分钟就来问你一下,当代码完成后,代码已经是你的,而不是他们。

17. 任何项目都不会那么简单。朋友、家人和同事曾请求我仓促做一些事情,仓促做一个程序或者网站。对于这样的事,应该从双方做计划,才能做出令两方都会满意的东西。如果某人起初只是需要一个使用Microsoft Access的、只有有3个页面的网站,但来就很可能变成一个有15个页面的网站,并使用SQL Server,有一个论坛,还有一个定制的CMS(内容管理系统)。

18. 任何时候不要想当然。假如你承接一个简单的项目,你可能会认为某个部分可以轻松完成。千万别这样想!除非你有一个类、组件、或者一段已经写好的代码,并且在现有的项目已经测试通过。不要认为这将是很容易的。

19. 没有已经完成的软件。曾经有一位程序员告诉我,没有软件是已经完成的,它只是“暂时完成了”。这是明智的忠告。如果客户还在使用你写的程序,并经受了时间的考验。如果有机会,你仍在更新它,这并不是什么坏事,这让你不断地前行。

20. 耐心是一种美德。当客户、朋友或家庭成员用电脑的时候,他们也许会受挫,进而想砸电脑,或气冲冲地离开。我一直在告诉他们,“是你掌控电脑,不是电脑掌控你。”对于用作编程的电脑,你要有一定的耐心。一旦程序员知道问题所在后,他们就会站在电脑的角度看问题,并且说“哦,这就是为什么它是这样做。”

程序员如何积累编程技术或编程经验?

工作中总是被问到程序员如何积累编程技术或编程经验?首先我认为编程是一门实践性的很强的艺术,所以貌似唯有实践才能积累。然而把它当作一个个人软件过程(PSP)的问题,总感觉是有一些规律、规则或建议可以解答。思索良久,结合自己的工作经历,尝试给出一个自己对这个问题的解答。

经验是什么?

    程序写多了,总会发现有一些东西是不怎么变的,就是说你写一万遍也是这么个写法,而这就是所谓的经验。当然这些不变的东西有大有小,如果我们能给它分一下类,并取个好听的名字,然后在后续的编程实践中得以运用,那么这个过程就是所谓的积累。
    经验分类
    我们将小一些的不变的东西叫习惯用法(idiom),大一些的叫模式(pattern),再大一些叫框架(framework),再大一些就是技术栈(technology stack)了。
Idiom(习惯用法)
    习惯用法更多的停留在语言层面上,与语言特性密切相关,通常是一些API的经典用法。如文件拷贝的经典写法、网络状态的判断、临时文件的创建及删除等。
    一般我们会将这个经典的写法整理到笔记本中,方便查阅。对于使用Eclipse的用户,可以将这些抽取成代码片段,分类保存起来,方便应用。
Pattern(模式)
    模式更多的描述一类问题的解决方案,比较抽象适用于任何语言。如经典的23种设计模式、并发编程模式等。对于模式要理解解决的问题域及实现方式,所以就要求在编程实践中有意的训练,然后从实践中积累自己的编程模式。
    例如关于网络并发编程模式主要有:Reactor模式和Proactor模式。在Linux中使用epoll,当IO可读写的时候通知你,你再去同步读写,这就是所谓Reactor模式。而windows下的iocp或者Linux下的ZeroMQ则是数据发送完了或者接收完了再通知你,这就是所谓Proactor模式。其实说白了就是,Reactor给你的是读写权,Proactor给你的是数据。
Framework(框架)
    Framework就是对Pattern的实现,目的是简化应用编程和重用代码。如Struts、Spring、Mina、Netty等框架。对于框架的积累,一般在编程中多以快速原型发布,持续演进方式推进,最终形成稳定的框架实现。
Technology Stack(技术栈)
    积累自己的技术栈是架构师必备素养之一。这就要求我们在编程实践中要以架构师的视角看问题,运用技术,积累技术。
    我觉得如果能做好上面的这几个方面,从小到大,反复迭代的实践,编程技术或编程经验的积累又有何难呢?

C++编程经验分享

1.不要在构造函数中做初始化操作
要求类(尤其是对外接口类)提供Init()函数,在该函数中进行相关初始化操作,初始化失败能够返回错误码。
可以规避问题:
构造函数中难以返回错误码,外部调用者无从判断初始化结果。
当该类作为全局变量使用时,构造函数调用发生在main()函数执行之前,出现问题难以追踪。

2.所有函数返回值都要判断

可以规避问题:
及时发现错误环节,终止处理流程,避免后续发生难以预料的错误。

3.关于函数返回值:
除了逻辑判断函数外,函数返回值都为整型,且该返回值只能用来表示函数执行情况(是否正确执行及错误码)。禁止采用bool类型作为返回值来表示函数执行情况。
避免void作为返回类型
返回值不能用来传递结果,结果数据可以采用引用类型的出参来实现。
返回值为整数时,其代表的含义统一规范为:小于0时表示执行错误;等于0时表示执行正确。

4.函数调用与错误日志
任何函数调用失败,必须记录日志。
避免无效的日志:日志中需要明确记录错误码(返回值)。除此之外,日志中还需要记录尽量多的上下文信息,包括全部的入参信息,具有相关性的成员变量信息、全局变量信息等。

5.尽量不使用全局变量。考虑采用成员变量或者main()中的局部变量代替。
如果采用全局变量,需要给出合适的解释。
可以规避问题:
各种奇葩问题

6.全局变量注意事项(如果一定要使用)
如果只在一个CPP文件中使用,那么请使用静态(static)全局变量。例如static int a = 0;
如果需要跨CPP使用,那么请使用较长且有区分度的名字来命名全局变量。例如。int _g_model_section_object;(解决linux上全局符号表识别错误问题)
确定该全局变量类的构造函数中没有进行复杂的初始化工作、是否依赖其他类。
清楚:c++标准没有规定不同编译单元(cpp文件)中的全局对象的构造顺序,只规定了同一编译单元中的全局对象按照其定义的顺序构造并倒序析构。
清楚:全局变量初始化发生在main函数执行前,且没有办法捕获到全局对象初始化抛出的异常。

7.使用数组前要先判空。
未判空的情况下,使用下标0或者front()或者back()函数访问数组元素都是危险的。

8.函数入参检查与出参复归
防御性编程:函数开始位置应对所有入参合法性、有效性进行检测;
函数开始位置应该对所有出参进行清理和复归工作;

9.字符串拷贝函数
字符串相关操作导致了太多问题。注意解决长度越界问题。

10.结构体与构造函数
结构体中如果使用了char[]数组,必须在构造函数中给char[]数组赋初值。
例如:

  1. struct Test
  2. {
  3. Test( )
  4. {
  5. *name=0;
  6. };
  7. char name[32];
  8. };
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1

慎用memset给结构体初始化,因为结构中可能有非连续变量类型,如string等。
错误示例:

  1. struct Test
  2. {
  3. char name[32];
  4. std::string name2;
  5. };
  6. Test test;
  7. memset( &test, 0, sizeof( Test ) );
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1

11.函数入参
复杂对象(如vector)应采用引用方式作为入参,而不是值传递。
对于“引用入参”应该采用const修饰符。尤其注意字符串入参应采用const char 类型,而不要采用char 

12.”%s”与字符串
注意printf等函数中”%s”与字符串的对应关系,规避输出崩溃问题。代码review时,应着重检查该类问题。

13.使用stdint.h定义的变量类型
建议采用stdint.h中定义的数据类型如int32_t、int64_t、uint32_t、uint64_t等,避免不同平台数据长度问题。

14.命名规则
源码文件名、动态库名、执行程序名采用小写字母+下划线的组合方式。规避操作系统对大小写字母敏感导致的各类问题。

15.减少重复代码,优化结构设计
败絮其中,难以金玉在外。要努力避免流水账代码、机械地拷贝、粘贴、无设计的堆砌。相似代码、相似功能尽量抽取出来,封装为一个内部公共函数。

16.动态库中的结构体要定义在命名空间中
动态库中所定义的结构体,要定义在专有的命名空间中。规避问题:避免动态库与可执行程序之间结构体重名导致的各种问题。

17.switch-case语句中必须要有default语句,且default语句中应打印相关日志信息。

18.多线程
非线程安全的C函数。如struct tm *localtime(const time_t *timep);还有strtok、asctime、ctime、gmtime等等,使用时需要特别注意。
多线程共享的资源,使用前要先上线程锁。STL模板库是非线程安全的,例如多线程共享同一个vector,那么有关vector的任何操作前都需要使用锁保护,即使调用的仅仅是size()函数。
关于线程的退出。不要试图从外部强制杀掉某个线程,这样做存在极大的内存泄漏风险。

19.配置文件采用INI格式
除非INI格式不能满足配置要求,否则应一律采用INI格式。

20.函数提前结束,做好资源释放工作
若在某个程序分支中提前退出函数,请不要忘记释放内存、数据库句柄、文件句柄等资源,否则会导致内存泄漏,资源耗尽。
举例:

  1. int Test( int a )
  2. {
  3. char * b = new char[100];
  4. //
  5. if ( a > 1000 )
  6. {
  7. delete b;//在这种情况下,切记不要忘记释放b
  8. return 1;
  9. }
  10. //其他操作
  11. }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

21.消缺与维护
克服侥幸心理,问题只要出现一次就肯定会出现第二次第三次….;
不要放过小问题,小问题可能迁出大问题;
不应通过“试”来解决问题,应寻找问题的根本原因;
修复BUG需谨慎,全盘考虑,避免引入新BUG。

22.代码注释问题

形式要统一(固定格式的注释风格,别一会//一会/**/以及其他的)

简单明了(多用无用的注释不要写)

注释先于代码创建或者边写代码边注释

注释位置就近原则一般写在上方或右方

其他特殊注释①典型算法必须有注释

②代码不明晰或不可移植处必须有注释

③代码修改处加上修改标识的注释

④循环和逻辑分支组成中添加注释(提示开始和结束位置)

⑤防止问题重复出现,对错误修复和解决方法的代码进行注释