服务器不可用
服务器应用程序不可用
您试图在此 Web 服务器上访问的 Web 应用程序当前不可用。请点击 Web 浏览器中的“刷新”按钮重试您的请求。
管理员注意事项:
详述此特定请求失败原因的错误消息可在 Web 服务器的系统事件日志中找到。请检查此日志项以查明导致该错误发生的原因。程序猿，怎样才能写好程序？_网易科技
程序猿，怎样才能写好程序？
用微信扫码二维码
分享至好友和朋友圈
本文作者余晟，来自其微信公众号“余晟以为”，原文题目为《“把程序写好”这回事》刚领证的著名程序员狗叔（@Googollee），前几周提出了很好玩的问题：“把程序写好的知识，是从哪里学来的呢？”。我和狗叔回忆，我们好像都没有正经上过什么“把程序写好”的培训班，也没有《九阴真经》之类的宝典。但是我们又都看到，很多程序员写的程序是不合格的，大量基础规范都没有遵循（更可怕的是这样的程序很可能还在服务我们每天的生活）。那么，优秀的程序员，是从哪里学到把程序写好的知识的呢？这个问题我想了很久，有几点结论可以分享给大家。首先，必须要正视“写代码”这回事有很多人虽然做着程序员的工作，其实内心是看不起写程序的。对他们来说，写代码只是不得不经历的初级阶段，等到职业生涯发展了，就可以脱离这种单调无聊的工作了。但是，这种想法是错的，有这种想法只能说明对计算机和程序的认知还相当肤浅。写代码绝不是简单无聊的劳动，程序员首先必须了解计算机的运行原理，然后需要把现实问题建模，并在计算机的世界里精确地还原出问题的解决方案。既然代码要交给功能强大的计算机去严格执行，程序员要担负的责任就相当大，因为代码的任何一点差异，都有可能影响程序最终的运行结果——因为程序的细小缺陷导致航天任务失败的例子已经有好几次了。反过来说，程序员能掌握的权力相当大，成为“合格程序员”的门槛也相当高，虽然这种门槛并不为许多人所知。前段时间有很多人叫嚷“我万事俱备，只差一个写代码的”，恰恰是因为他们把写程序看成简单机械的劳动，但以自己的聪明才智又学不会这种“简单机械”的劳动。这种矛盾，恰恰说明写程序是有门槛、有要求的。所以，要想成为称职的程序员，必须正视写代码。其次，必须读过一些基本的书籍学校里通常会安排编程语言的课程，但不会教“怎样把程序写好”的课程。许多人对计算机的理解还停留在“科学与理论”的角度，只要程序能“对”，能输出正确结果就可以；却不知道如今与计算机相关的大量工作，其重心已经转移到实践和工程意识的方面了。这种错误的理解，导致很多程序员在工作之后相当长的时间里，学习的内容还局限于钻研理论和算法，一直忽略了“把程序写好”的补习。其实市面上已经有一些教人“把程序写好”的书籍，认真读完这些书，认真落实其中的规范，至少能保证把程序写“合格”，不会有明显的缺陷，为将来把程序写好奠定坚实的基础。从我和身边朋友的经验出发，我觉得《代码大全》、《重构》、《编程珠玑》、《程序员修炼之道》这几本书都是很不错的，如果能耐心读完并认真思考，写程序的水平会有相当的保证。要保持好奇心，多借鉴其它项目的内部实现我们时常开玩笑说，现在很多程序员的工作，就是从网上下载一些开源项目，然后改改参数。其实这并非玩笑，而是很多程序员工作的真实写照。充其量，他们还要做一些穿针引线的工作，把这些项目粘合组装起来。这看起来确实是简单机械的劳动，也不会给人多少提升。但事实并非如此。很多好的程序员就在这个过程中学会了把代码越写越好。因为他们保持了好奇心，去探究这些开源项目的内部实现，把应用的过程当成了学习的途径。在使用一个现成方案之前，先想想如果自己去解决要怎么办，再看看其他人的现成代码，确保自己懂得了这些代码蕴含的思维。甚至比较相类似的几个开源项目的源代码，分析其优劣，在自己的工作中注重借鉴其长处，避免其短处。久而久之，写程序的水平自然会有大的提升。在写程序时，要懂得在工程与理论之间求得平衡在谈到写程序时，经常有人引用奥卡姆剃刀原则，说“如无必要，勿增实体”；也有人引用爱因斯坦的话，“要足够简单，但不应该过于简单”。由此证明，好的程序应当是足够简单而且非常优雅的。在大方向上，我认同这种说法。但在具体的问题上，它未必正确。因为编程是与工程密切相关的工作，与工程密切相关就意味着大量的权衡、取舍。无论奥卡姆剃刀原则还是爱因斯坦的话，原本的主题都是针对理论的，所以两者并不能严格划等号。在实践中我见到过很多过份迷恋简单、美感的程序员，我称之为“玩套路”——他们太在意程序的形式美感，为了刻意追求那种严谨整齐的感觉而忽略了现实，也不懂得针对现实做出取舍，最终把自己套了进去。结果，用户明明需要的一亩菜地，他们交付的却是一份盆景，还振振有辞地指责用户不懂技术。这样的人，往往既当不好程序员，也成不了软件开发工程师。坦然接受其他人对自己代码的批评Code Review是提高代码质量的有效手段，这一点大家公认。但是在很多场合，Code Review很难推行起来，原因之一就是程序员内心难以接受其他人对自己代码的批评。这种现象倒也情有可原，因为写程序这回事，大家多少认为是有绝对标准，可以分出高下的。对大多数人来说，潜意识里也确实很难区分“对我的工作的批评”和“对我的批评”。所以面对其他人对自己代码的批评，除非是来自上级，否则多少有些面子上挂不住，天然有争辩的冲动。我自己就遇到过好几次这样的情况，本来讨论理论和方案一切正常，只要涉及到“看某人的代码”，气氛就随之大变。我们需要明白，不经历挑战和批评，人是很难提高的。其他人的批评，只要不是恶意的，总是能提供不一样的视角，帮助我们更深入或者更全面的认识问题，这是很好的成长机会。相比起来，“丢面子”更多只是一闪而过的，甚至根本只是自己觉得很丢脸，其他人完全不在意的。为了怕“丢面子”而排斥其他人的批评，实在是得不偿失。另一方面，团队领导也应当营造平等合理的协作气氛，倡导“对事不对人”的价值观。这样，才能让更多的成员坦然接受对自己代码的批评。程序员需要有对荣誉感的追求归根到底，“荣誉感”是驱动个人不断追求更高境界的源动力。对没有荣誉感的程序员来说，“把程序写好”充其量是不得已背上的负担；而对于具有荣誉感的程序员来说，“把程序写好”是需要不断追求的目标。在我看来，程序员的荣誉感主要体现在两个重要的方面。第一是对质量的追求，好的程序员一定会对自己交付的程序的质量负责，力求做到没有缺陷，所以不会依赖Code Review来发现代码的缺陷，也不会依赖测试来发现功能的缺陷…… 甚至要向上游扩展了解问题的起因和目的，向下游扩展了解程序运行的状态和行为——这已经是“全栈工程师”的雏形了。
第二是对“用技术更好解决问题”的不断思索和追求。程序与现实不完全相同，所以很多时候并不受现实的严格限制，程序能不能突破这些限制，如何突破这些限制，靠的就是程序员的荣誉感。现实中很多时候确实“鱼与熊掌不可兼得”，但是在程序的世界里，在某些情况下，鱼与熊掌是可能兼得的。现实中“菜刀用来杀人”似乎是无解的，但在程序的世界里，有些菜刀就可以做到不能用来杀人。普通人或许囿于现实生活经验无法想想“鱼与熊掌兼得”、“菜刀不能杀人”，但想把程序写好的程序员，一定不能就此止步。最后我想说的是，程序员应当属于德鲁克说的“知识工作者”。对于知识工作者，我们就不能像对待机器和工人那样去严格约束工作的过程，只能要求结果，或者说“找到合适的人，提供合适的环境，期待美好的事情发生”，这也是很多程序员享受的方式。但是，如果程序员不在乎自我驱动和追求，把写程序当作不需要任何想象力和创造力简单重复劳动，那么“血汗工厂”的工作方式可能更能保证生产效率。
本文来源：网易科技报道
责任编辑：王朦_NT2210
用微信扫码二维码
分享至好友和朋友圈
加载更多新闻
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
阅读下一篇
用微信扫描二维码
分享至好友和朋友圈首先声明，我不是高手也不是老手。下面的内容如有错误或是不合理的，请各位看到的一定要告诉我！^_^!今天本来在看书《windows 核心编程》，看来一会儿发现做了这2，3年的开发，也写了几万行的code，应该总结一下比较好。记得2年前看过一个林斌在清华大学讲如何写好程序的视频，现在想起来有点体会，写一下，以免忘记。对于我们这样的以程序开发为生的人来说，我们的职责就是让我们的程序能工作的好点，再好的。这有点类似于服务行业“我们要让我们的服务是一流的”。所以我们每天写它个一两百行代码是正常的事情，说简单也简单，说难也难。行内有句话：对于相同功能的程序，100程序员有100种写法。那么有什么差别呢？我想无非是想的多想的少而已。这句话如何理解呢？我是这样理解的：考察一个程序的优劣性有很多个方面，第一，可用性，即在正常的输入情况下不能错，这是最基本的，你要是去银行存1w，它把你处理成1k，你不得把银行拆啦$_$！第二，在第一的基础上增加有效性，同样一段程序你的要跑10分钟，而别人的只用1分钟，那么你的程序不可能是好的程序，而这点正是好的程序的开始，关于这点涉及到的知识与方法可能跟人比较相关，所以我认为程序员之间差就差在这点上。那么我们怎么去考察这点呢？我个人认为需要从下面几点来看：一是解决方案的选用，这点涉及到你对业务的理解。二是这个方案是否最优，这点涉及到你对操作系统的理解，对数据结构的理解，对语言的理解。不要重复的造轮子，除非你自信造的比现有的要好！三是实现的难度和时间，这点是不可少的，如果你的方案太难实现或是需要太多的时间实现，我估计你的boss是不会答应的。第三点是可维护性，好程序是易于维护，毕竟对于一段程序，你写的也好，他写的也好，我们都只是过客，匆匆的来，匆匆的走，唯一能做的是让别人工作更轻松一点，自己也能轻松点，现在的程序在编译时都可以用混淆器来混淆代码了，所以我们不需要你把code写的让人看不懂#_#。对于这点，跟程序员的代码风格有关，也和细心有关。说了这么多理论性的东西后，你会说那么如何才能写出好的程序呢？我想这是没有唯一答案的，唯一的只是好程序不是写出来的，而是改出来的。这个世界上没有完美的程序，即使是google的也是一样，否则就不需要人维护了。我个人的观点是，一个程序在你发布出去之前，不能少于3遍的修改，第一遍实现了可用性后，扔掉；第二遍，从有效性的角度去考虑问题；第三遍，才是维护性的内容，你的风格，变量命名，采用模块的方式，错误的处理等。所以，我的观点是：操作系统提供了，就不要自己写，如果有更好的API就选择更好的API。使用合理的数据结构，就像你考虑使用数组和链表时的那样。尽可能的使用数学的方法去完成工作，这个我想看过几篇文档的人都知道。尽可能的使用模块化，不要以为这个只是OOP的专利哦。合理的使用空间来换取时间。不要钻牛角尖，也不要依赖心理，优化需要先考虑整体，在考虑局部，最后考虑编译器。所有的结论都通过数据来证明，不要自以为是。让你的程序看起来和别人的差不多（风格问题）。程序员是勤快的，懒的只是他的工作，多让电脑干重复的活，你所要作的是让它更好的工作。对于变量：能不全局就不要用全局的，能不静态就不要用静态的，能不新声明就不要新声明。对于值参数：考虑类型，考虑边界，考虑初始值，考虑内存分布。对于指针参数：考虑类型，考虑空，考虑输入输出，考虑是否会被修改，考虑与值类型的区别，考虑是否可以用引用或是句柄代替。对于函数：考虑参数个数，考虑返回值，考虑调用那些库函数和API，考虑作用范围，考虑是否递归，考虑命名，考虑错误处理，考虑被调用的次数，考虑效率，考虑并发的可能，考虑资源的分配与释放。对于类：考虑设计模式，考虑通用性，考虑成员函数接口最小化，考虑资源的分配与释放，考虑被继承的可能性，考虑多实例，考虑扩展的可能，考虑并发的可能，考虑抽象的意义，考虑独立性。对于模块：考虑维护性，考虑复用性，考虑多进程共享，考虑是否动态载入，考虑平台移植。以上这些就是我自己对写程序的感想，一人之见！^_^!
阅读(...) 评论()