嵌入式Linux（79）
十个最值得阅读学习的C开源项目代码
来源：开源中国&&&时间：&10:24:55&&&阅读数：3062
[导读]&开源世界有许多优秀的开源项目，我选取其中十个最优秀的、最轻量级的C语言的项目，希望可以为C语言开发人员提供参考。
&&&&&&&开源世界有许多优秀的开源项目，我选取其中十个最优秀的、最轻量级的C语言的项目，希望可以为C语言开发人员提供参考。
1.&Webbench
&&&&&&&Webbench是一个在linux下使用的非常简单的网站压测工具。它使用fork()模拟多个客户端同时访问我们设定的URL，测试网站在压力下工作的性能，最多可以模拟3万个并发连接去测试网站的负载能力。Webbench使用C语言编写,&代码实在太简洁，源码加起来不到600行。
下载链接：
2.&Tinyhttpd
&&&&&&&tinyhttpd是一个超轻量型Http&Server，使用C语言开发，全部代码只有502行(包括注释)，附带一个简单的Client，可以通过阅读这段代码理解一个&Http&Server&的本质。
下载链接：
&&&&&&&cJSON是C语言中的一个JSON编解码器，非常轻量级，C文件只有500多行，速度也非常理想。
&&&&&&&cJSON也存在几个弱点，虽然功能不是非常强大，但cJSON的小身板和速度是最值得赞赏的。其代码被非常好地维护着，结构也简单易懂，可以作为一个非常好的C语言项目进行学习。
项目主页:&
4.&CMockery
&&&&&&&cmockery是google发布的用于C单元测试的一个轻量级的框架。它很小巧，对其他开源包没有依赖，对被测试代码侵入性小。cmockery的源代码行数不到3K，你阅读一下will_return和mock的源代码就一目了然了。
&&&&&&&主要特点：
&&&&&&&免费且开源，google提供技术支持；
&&&&&&&轻量级的框架，使测试更加快速简单；
&&&&&&&避免使用复杂的编译器特性，对老版本的编译器来讲，兼容性好；
&&&&&&&并不强制要求待测代码必须依赖C99标准，这一特性对许多嵌入式系统的开发很有用
下载链接：
&&&&&&&libev是一个开源的事件驱动库，基于epoll，kqueue等OS提供的基础设施。其以高效出名，它可以将IO事件，定时器，和信号统一起来，统一放在事件处理这一套框架下处理。基于Reactor模式，效率较高，并且代码精简（4.15版本8000多行），是学习事件驱动编程的很好的资源。
下载链接：
6.&Memcached
&&&&&&&Memcached&是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态数据库驱动网站的速度。Memcached&基于一个存储键/值对的&hashmap。Memcached-1.4.7的代码量还是可以接受的，只有10K行左右。
下载地址：
&&&&&&&Lua很棒，Lua是巴西人发明的，这些都令我不爽，但是还不至于脸红，最多眼红。
&&&&&&&让我脸红的是Lua的源代码，百分之一百的ANSI&C，一点都不掺杂。在任何支持ANSI&C编译器的平台上都可以轻松编译通过。我试过，真是一点废话都没有。Lua的代码数量足够小，5.1.4仅仅1.5W行，去掉空白行和注释估计能到1W行。
下载地址：
&&&&&&&SQLite是一个开源的嵌入式关系数据库，实现自包容、零配置、支持事务的SQL数据库引擎。&其特点是高度便携、使用方便、结构紧凑、高效、可靠。足够小，大致3万行C代码，250K。
下载地址：
9.&UNIX&V6
&&&&&&&UNIX&V6&的内核源代码包括设备驱动程序在内&约有1&万行，这个数量的源代码，初学者是能够充分理解的。有一种说法是一个人所能理解的代码量上限为1&万行，UNIX&V6的内核源代码从数量上看正好在这个范围之内。看到这里，大家是不是也有“如果只有1万行的话没准儿我也能学会”的想法呢？
&&&&&&&另一方面，最近的操作系统，例如Linux&最新版的内核源代码据说超过了1000&万行。就算不是初学者，想完全理解全部代码基本上也是不可能的。
下载地址：
10.&NETBSD
&&&&&&&NetBSD是一个免费的，具有高度移植性的&UNIX-like&操作系统，是现行可移植平台最多的操作系统，可以在许多平台上执行，从&64bit&alpha&服务器到手持设备和嵌入式设备。NetBSD计划的口号是：&Of&course&it&runs&NetBSD&。它设计简洁，代码规范，拥有众多先进特性，使得它在业界和学术界广受好评。由于简洁的设计和先进的特征，使得它在生产和研究方面，都有卓越的表现，而且它也有受使用者支持的完整的源代码。许多程序都可以很容易地通过NetBSD&Packages&Collection获得。
下载地址：
原文出自：http://my.oschina.net/zhoukuo/blog/335788
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：204710次
积分：2842
积分：2842
排名：第9690名
原创：63篇
转载：146篇
评论：24条
(1)(1)(2)(2)(1)(2)(1)(3)(1)(4)(5)(1)(1)(1)(28)(7)(2)(1)(12)(19)(2)(4)(4)(2)(8)(35)(61)> 黄亿华的博客详情
摘要: 今天刚好看到同事写一段代码，跟同事聊到一个代码风格的问题，讨论了一会，也没得出什么结果。回来想了想，之所以大家观点不一样，其实是一开始代码追求的目的就不一样。
关于代码质量的一些思考
今天刚好看到同事写一段代码，跟同事聊到一个代码风格的问题，讨论了一会，也没得出什么结果。回来想了想，之所以大家观点不一样，其实是一开始代码追求的目的就不一样。
## 1. 可读性
我是一直认为代码的可读性是最重要的目标。太多的书都讲到一个观点：“代码是写给人阅读的，只不过刚好能被计算机执行”。
大部分做自己产品的团队，一个项目的维护时间可能是开发时间的5倍以上，而维护的常见内容都是一些小功能以及已有bug的修复。可读性带来的好处就是，非常容易弄清一段功能逻辑，从而定位问题。遇到团队人员变动，新人也能很快的熟悉。我在公司换过很多组，也接手过很多的项目（大多数的可读性并不好），就这一点来说，真是切肤之痛。
什么样的代码，算是可读性好？我跟别人提过一个标准：“你写的代码，过了几个月、半年、一年，跟你说道一个功能，即使你不记得这个功能怎么做，你也能说清楚这个功能写在哪个地方”。这个标准我自己认为还是很有效的。
那用什么方法可以增加可读性呢？合理的拆分和抽象会增加可读性。另外，我其实一直崇尚“用最常用的方法写程序，直到它发展到你已经理解困难的时候，再去重构”。
## 2. 代码美学与合理性
经历过跟很多人的合作，我发现，很多非常优秀的开发者，会从直觉上把一个代码片段“是否优美”作为第一考虑的目标。他们会追求一些高级编程技巧的合理运用，或者开发一些公共组件，来达到行数足够少，或是表达足够清晰的目标。这个好像教材里也不曾提到的，我把它叫做“合理的代码美学”。
对于Java代码来说，有人就喜欢把一些常见功能，用自定义注解，然后用AOP来完成注解的解释。例如，一个功能需要随时可以打开或关闭，我可以通过一个注解来完成它而不是在业务处理中写一些if-else-check。
@NewFeatureEnabled
public void doSomething(){
实际上，完成一个“优美的”小功能，也就是用自己心中认为最好的方法去完成一件事，这样的满足感，也是让人持续编程的动力。严格的说，这样的代码有没有给代码质量带来提升呢？肯定有。第一很多时候这样的代码会经过更多的考虑，必然有更高的质量；第二很多更好的开发技巧，都是来自这些“不一样”的追求。
但是我认为，软件开发与艺术最大的不同是，它是一个多人合作劳动，一个人觉得合理的，其他人未必会感同身受，甚至会恰恰相反。这样的代码是蛋糕上华丽的三层奶油，有时会给人眼前一亮的感觉，但是也可能会让人找不到蛋糕本身。所以我的建议是：“如果你要用一个新技巧，最好积极宣传，和团队达成共识”。
比如这个`@NewFeatureEnabled`的功能，我会想：“如果别人接手这个项目，他是不是知道NewFeatureEnabled是什么意思？即使知道，他怎么知道这个功能的开关，是由其他地方一个AOP来完成的呢？”但是如果大家都接受这个方式，知道AOP是在哪里配置，如何工作的，那么也就是一个还不错的尝试了。
## 3. 可复用性
追求复用性是开发者的一个本能。大家都希望少写代码，最好要用的时候，一切都准备好了。我见过太多的代码为了复用而设计，但是基本上所有以复用为第一目标的代码，都没有什么好质量。不是说可复用性不重要，而是它容易让人走上歪路。
比较好的复用方式，应该是零件式的复用，每一块都有各自的规范和存在，但是这样的复用是一个严肃的过程，往往也达不到最大化的“代码复用”。为了复用的抽象，常见的就是把一段公用的代码块独立出来成为函数或者类，而这部分的逻辑甚至都是无法独立存在，也单独无法被人理解的。这种拼接式的复用，类似于为了表示一只猫和一只狗，把猫的身体和狗的身体复用成一块，然后写一堆判断代码来告诉别人什么时候这个身体是猫，什么时候这个身体是狗，最后再跟各自的脑袋组合起来。当然了，没有人知道这个“既是猫又是狗的身体”是什么。如果你想知道猫长什么样，估计得先给它做个缝合手术才行。
如果一个项目以这样的思路开发久了，你会发现代码逻辑散落在各处，各种业务场景互相交织，任何改动都会牵一发动全身。
如果要为可读性排个名的话，我认为大概是：
毫无头绪的抽象&只为复用的抽象&不做抽象&简单的抽象&局部优美的代码&整体优美的代码&清晰的层次结构并抽象&整体优美并且被大家接受的代码
最后一个层级，这样的代码实际上已经是更高的生产力了，就像Spring之于满地new对象就是个进步。可能代码进化到最后，真的就是跟自然语言那么简单，到时候我们就需要研究怎么在代码里写诗了！
人打赏支持
开源马克杯
领取时间：
开源马克杯是开源中国定制的“高大上”Coders 喝水利器！
领取条件：购买或拥有开源马克杯的OSCer可领取
开源项目作者
领取时间：
作为一个开源项目作者，是时候站出来拯救世界了！
领取条件：开源项目被开源中国收录的开发者可领取
参与源创会
领取时间：
“”在线下联结了各位 OSCer，推广开源项目和理念，很荣幸有你的参与~
领取条件：参与过开源中国“源创会”的 OSCer 可以领取
码字总数 114152
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥
& 开源中国(OSChina.NET) |
开源中国社区(OSChina.net)是工信部
指定的官方社区值得学习的C语言开源项目
C++标准库，包括了STL容器，算法和函数等。
C++通用框架和库
异步事件循环
音频，声音，音乐，数字化音乐库
生物信息，基因组学和生物技术
压缩和归档库
并发执行和多线程
数据库，SQL服务器，ODBC驱动程序和工具
调试库， 内存和资源泄露检测，单元测试
图形用户界面
动力学仿真引擎
Web应用框架
XML就是个垃圾，xml的解析很烦人，对于计算机它也是个灾难。这种糟糕的东西完全没有存在的理由了。-Linus
一些有用的库或者工具，但是不适合上面的分类，或者还没有分类。
用于创建开发环境的软件
C/C++编译器列表
在线编译器
在线C/C++编译器列表
C/C++调试器列表
集成开发环境（IDE）
C/C++集成开发环境列表
静态代码分析
提高质量，减少瑕疵的代码分析工具列表
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。看到的一些关于程序员的告诫以及指点，和大家分享一下_疯狂源代码吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：12,246贴子：
看到的一些关于程序员的告诫以及指点，和大家分享一下
程序员的“潜规则”
实际上，程序员都是倾向于生活在规则下的人。创建规则可以让我们过得更好，因为这样做可以提前决定一些事情，而不是要在匆忙中做出所有的决定。
我今天早上应该去健身房吗？
我的规则告诉我说我要在周三前往健身房，今天是周三，因此我要去健身房，就这么办了！
这周，当我正在思考那些对我施加有影响的规则时，我想到了去制定一系列软件开发者都应该遵守的规则，我认为这可能是一个好主意。
现在，我承认，这里面的大多数规则比那些“指导方针”要求的要多，它们是：1: 技术是你获取解决方案的方法，而不是解决方案本身
我们可以得意忘形地使用最新的JavaScript框架-嗯哼，Angular-IoC 容器，编程语言，甚至操作系统。但作为一个程序员，所有这些东西并不是问题真正的解决方案，相反，它们只是帮助我们解决问题的简单工具。
在面对那些我们喜欢或是当前非常流行的特殊技术时，我们必须非常小心，而不是变得过于疯狂。以免步入这样一个险境：仅仅因为我们手里拿了一把闪闪发亮的锤子，就把所有的问题都看作钉子。2: 对代码而言，“聪明”是“清晰”的敌人
在写代码的时候，我们应努力保持书写的代码清晰易懂。
可以明确（Clear）表明自身意图的代码，永远要比那些晦涩的代码更有价值-无论那些晦涩的代码被构建得多么聪明（Clever）。
虽然情况并不总是这样，但一般来说，“聪明”是“清晰”的敌人。
一种经常出现的情况是，当我们写出一段“聪明”的代码时，这段代码并不是特别的“清晰”。
这条规则非常重要，尤其是当我们思考我们要做一些特别“聪明”的事情时。
有时候我们写出了“聪明”的代码，它们同时也是清晰的，但是其他情况也会时有发生。
如果你对写出简洁的代码感兴趣，我高度推荐你用下面这本书上描写的规则来检验：Robert C. Martin的《干净的编码者：专业程序员的行为守则》（The Clean Coder: A Code of Conduct for Professional Programmers）3: 只在逼不得已的情况下才写代码
这条可能会有些争议，毕竟，作为程序员，我们的工作不就是写代码吗？
嗯。。。这个看你怎么说了。
写代码的确是我们工作的一部分，但是，我们要尽可能努力的去用最少的代码来解决问题。
所谓“最少的代码”并不是说我们只能用一个字母的变量名或者其它方式来压缩我们的代码。“最少的代码”指的是我们应该只写为了实现功能而必不可少的代码。
我们常常添加一些“酷”的功能，来让代码“健壮”和“灵活”，让代码能够处理“所有”可能的使用情况。我们企图猜测那些可能会被用到的功能。总之，我们常常花费时间去解决一些头脑中臆想出来的可能的情况。
我们这么做，是错的。
不能否认，这些多余的代码能会带来些好处。然而，这些代码同样的会有很多危害。我们写得代码越多，就越有可能引入错误；我们写得代码越多，将来的维护工作就越繁杂。
好的软件工程师只写绝对需要的代码。
伟大的软件工程师会把没用的代码统统都删掉。4: 注释是魔鬼
我并不是很热衷于写注释。当我跟Bob Martin在一起时，他说：
“你写的每个注释，都代表着你表达能力的欠缺“
这并不是说一点注释也不写，但通常我们可以通过一种更好的方式——命名来避免。
注释仅在命名不能有效表示变量或方法的意图时才真正需要。此时的注释表达了不能用代码表达的真实意图。
例如，注释能够告诉你在代码中某些奇怪的操作顺序并不是错误的，它是由于底层系统的某一bug而有意为之的。
但通常，注释不仅没有必要，有时它们还会&撒谎&.
注释没有随着代码更新的倾向，而这是很危险的，因为它们会将你带入歧途。
你会查检每条注释和与之对应的代码，确保代码是在做注释说的事么？如果是的话，写注释还有什么用？如果不是，你怎么相信注释说的是对的？
真他妈麻烦，所以最好还是尽量别写注释了。
OK，喷子们，在下面的评论区里留下你们的“口水”吧，但我会无视你们的。5: 永远要在你开始写代码前考虑好它是做什么的
这一条看上去显而易见，然而事实并非如此。
想想你有多少次并没有完全想好就坐下来写代码，而这段代码确实实现了你要做的功能？比之我乐于承认这个思路的正确性，我行动了更多次，这是一条我需要经常去品读的规则。练习测试驱动开发（Test Driven Development，TDD）在这里会有所帮助，因为你在写出代码前，必须逐字的了解它们会做些什么，但是这依然无法阻止你去做错的事情。因此，在构建一个特性或功能前，保证自己百分之百地理解需求，也是很重要的。6: 在交付之前，测试你的代码别把你的代码直接扔给QA，然后指望着所有人来浪费时间为你服务。事实上，你自己认真的运行一下测试案例，是完成代码之前必不可少的一步。这并不是说一定让你自己找到代码中所有的问题，但是你至少得把那些愚蠢得令人尴尬的错误找出来吧？很多软件工程师都觉得测试代码是QA的工作。这个想法绝对是大错特错。保证代码的质量，是每个人的工作！7: 每天学点新东西如果你每天都不学新知识，你就在退步，因为我可以保证你会忘记一些东西。每天学一些新东西，并不会花去你太多的时间。试着花15分钟去读一本书每天的小进步，随着时间的推移会积少成多，并在很大程度上重塑你的未来。如果你想在未来获取回报，你现在就需要开始投资了。此外，今天的技术变化非常之快，如果你不能做到不断提高已有技能并学会新的技能，你会很快掉队。8: 写代码是件快乐的事诚然，你最开始进入这个行业可能只是因为它待遇优厚。我是说，为了良好的待遇找工作没有任何错误，但是医生或律师可能会是更好的选择。你之所以成为了一名软件开发人员，是因为你爱写代码。因此，不要忘记你在做你所热爱的事情。写代码有很多乐趣，我希望我能写更多的代码。我这几天经常忙于写代码并试图让它占据我更多的时间，这也是我为什么如此清晰地记得它有多么的有趣。也许你已经忘记了写代码的乐趣，也许是时候你应该再次记起写代码是多么的有趣了-通过开始一个边角的项目，或是仅仅改变你的心态，意识到你开始写了代码，并为之付出。（但愿如此）9: 你无法完全了解它无论你学了多少知识，都会有大量你所不知道的东西。认识这一点非常重要，因为你可以驾驭你的那些想要去学会所有东西的发狂的想法。没能获取所有问题的答案，这挺好的。在自己不理解某事时寻求帮助或说出来，这也挺好的。在很多情况下，你可以相当接近地了解到你想知道的事情-相信我，我一直在这样做我的观点是，不要总想着学会一切-如果这是个不可能完成的任务。相反，你应该重点学习那些你需要去知道的东西，并且提升那些可以让自己学习速度加快的能力。10: 最佳实践要因地制宜测试驱动开发是你最拿手的编程方式么?我们应该一直采用结对编程?不使用IOC容器你就不好编了?这些问题的答案是“看情况吧”具体情况具体分析.人们会将所谓的“最佳实践”强推给你，并且他们经常说这些很实用——你应该经常这样做或那样做——但这是不对的。当我写代码时我会遵循很多”最佳实践“，但有时我也会背离它们。原则是永恒的，最佳实践是变通的.11: 力求精简所有问题都可以进行分解.最佳的解决方案往往是最简单的.但简单并不容易.简化事情需要付出努力。本文目的在于简化复杂的软件开发和人生.相信我，这并不容易.傻瓜为问题提出复杂的解决方案.简化解决方案需要更多的精力和耐心，但这没有错。花点时间。多点努力。力求精简.你遵守什么规则？上面是我遵守的规则，那你呢？
一次新的奇迹玩法？你想成为霸服大魔王吗？
有种读起来像翻译后的英语的感觉！当然，是写的很棒那种……
这就是人家外国人写的，然后翻译过来的
还有很多片这样的文章，马上找个时间再发几篇
面试取胜的8个技巧
IT职位现在相当热门。和软件开发人员在今年将有大量的就业机会。可是，面试成了招聘过程中的拦路虎，成为了很多程序员的噩梦。下面教你8个技巧，希望能有助于你成功取胜编程面试。　　1.知道如何写算法　　如果你申请的是的工作，那么显然你需要知道如何编码。写代码脚本其实与写算法来解决软件问题略有不同。用人单位可能会提出这样的问题，“写一个算法，可以从链表中找到某个元素，并将此元素挪到列表末尾。”所以，你必须知道如何写算法。　　只需具备一点点的数据结构知识以及知道如何实现不同类型的算法，那么写算法对你而言应该不难。你可以在网上找到很多这方面的资源。只要你能够顺利地写出如何数组排序，那么就可以去面试了。 　　2.不用工具写代码　　大多非常习惯于借助工具——模拟器、、框架等——它们能使得我们的编程任务变得更容易。更喜欢IntelliJ和Eclipse，不喜欢使用插件。而人员不需要任何IDE，他们使用文本编程。IDE无疑是强大的，但是当你去面试时，用人单位可能会要求你在不用任何工具的情况下写代码。如果你平时能够在没有任何框架和工具的情况下练习练习，那么在面试时绝对可以轻轻松松地写出代码。 　　3.有经验　　编程经验能为你的简历添加价值。相较于一些白纸，用人单位更青睐于一些具备了相关经验的求职人员。如果你没有任何经验，那也不必发愁。通过构建，然后发布到应用商店;将开放到GitHub上;促进现有的开源项目等等，都是能为你增加经验值的方法。
4.将自己的思考过程说出来　　提问之后，请将你的思考过程响亮地说出来。不管你怎么别扭，怎么不习惯，也要试着用这种方式来思考问题。无论你想什么，说出来。这能为你的表现加分。 　
5.不要争执，责怪和找借口　　有的面试人员习惯用争论来证明自己的观点。你如果确实不知道问题的答案，那么只需要简单地说明一下。争论是没有意义的。如果你不知道提出的具体问题，那么不要责怪面试官提出的方式不对，也不可归咎于大学教授没有教到那一部分。这些想法很要不得，请为自己的行为负责。 　　6.不要放弃　　会有目的地提出一些很难的问题，以此来测试你应对困境的能力。如果面试官给出的是你闻所未闻最困难的问题，那么也不可轻言放弃。如果你能尽力尝试，那么用人单位会更加尊重你。没有哪家公司会希望自己的员工总是抱怨问题很难，即便确实是特别难以攻克的问题!所以，不要放弃，试着尽力去回答。 　　7.测试代码　　没有代码是完美的。假装你的代码存在着一些错误，在告诉你已经完成代码之前，要先测试一下。作为一个，测试每一行代码你写的代码很重要。 　　8.反馈　　当你构建产品时，也应该与客户和最终用户构建联系。所以，可以问问对你代码的意见。有些人可能会认为这无关紧要，但是，你的这种征求反馈的做法在面试官眼里则非常重要。这能显示你的学习兴趣和理解代码的能力。
如何做一名容易被识别的优秀 　
关于我们这个行业，“是什么品质使得优秀的区别于其他程序员?”是最难回答的问题之一。在这里和大家分享一下我认为团队中每个人都需要具备的基本技能和特质。 　　1.适应性和灵活性很多开发团队都在喊我们需要灵活的开发人员——尤其是在软件开发初期这类人才更为重要。如果你平时是搞UI编程的，那么我们希望你能深入到数据持久层。我们甚至可能还会要求你去做一些测试。你可能是作为一个而聘用的，但我们希望下一个应用程序你能用.NET写……擅长多任务和成为某个领域的专家一样重要。在当时可能会让你想抓狂，但是挨过这段日子之后，你的简历绝对会让你的下一个雇主心动不已。　　2.热情也许你上大学学习这个专业，只是因为你听说这行业能赚钱。几年之后，当你发现回报并没有你想象得那么丰厚的时候，可能就会开始沮丧，提不起干劲来。伟大的会真心实意地爱着编程——可以不喜欢现在正在搞的代码——但总的来说，你应该成为一个享受于构建一些东西来解决问题的人。当有时间空下来可以喝杯咖啡的时候，你会去逛逛类似于JavaLobby的网站，寻找提高自己的途径。你会对最新的举措，市面上刚出来的Web框架感兴趣，津津乐道。　　3.用科学武装头脑的实干家《The Pragmatic Programmer》是软件行业中最重要的书籍之一。它不仅不局限于某一种特定的编程语言，而且还为我们提供了一系列的指南，是一部非常经典的著作。在团队工作时我们需要考虑到自己的行为所带来的后果，拒绝“破窗理论”。对工作保持一贯的高标准——测试、编码和文档等等——然后渐渐带动整个的团队，蔚然成风。保持新鲜感的最好办法是用科学的思维武装头脑。任何问题都可以被分解，所有语言都有着一系列相似的特征。之所以有些人能做到这一点，而其他人却不能的主要原因是在于，你是否保持对自己的质疑：这个代码片段还能不能写得更好?是不是可以用一种更有条理的方式呈现这些信息?我可以郑重地告诉你，这些答案几乎总是肯定的，所以踏踏实实地解决这些“自我质疑”吧!　　4.良好的组织安排能力　　一个优秀的会把事情安排得井井有条，甚至每天下班前都会列出明天的任务。这样如果需要做别的事情的话，至少可以参考这个清单，看看放到什么时候做合适，或者会不会对其他任务造成影响。ps，这里推荐一个蛮有用的工具——Mylyn，一个基于任务的Eclipse插件。在处理代码和文档方面也需要良好的组织安排能力。如果我们能够有组织地进行封装、设计、命名类和变量，不但有助于团队成员的理解，还能让你几个月后的再次查看，不至于像是在阅读他人的代码。　　5.通情达理，平易近人　　我们大多数在团队环境中工作的，所以我们必须要具备人际交往的能力。所有被尊重的伟大个个都平易近人。你需要腾出时间为他人提供帮助，不管是有问题的代码，还是项目经理想了解一下你的预估。除此以外，你还应该尽量做到表达清晰——以免交流之后，对方反而对问题更加困惑了。通情达理也很重要。不管你在企业中是什么职位，或多或少总要涉及到协商和谈判。或许当你知道自己是正确的时候没法心平气和地做到这一点，但是你最好还是找到双方都可以接受的方案，千万不要太过于强硬。　　6.把握机会　　不要寄希望于别人会来告诉你需要做哪些正确的事情。也许你就快要发布了，却还必须转到最新的框架版本。如果你是热衷于自己的工作，那么你应该保持与时俱进。如果你擅于变通，那么你可能愿意牺牲午餐时间，或者在家中的空闲时间，来研究研究原型看看是否奏效。每一个机会都有它的成本，但是在你决定要不要使用之前先好好盘算盘算是否值得，千万不要盲目。把握机会也适用于你的职业生涯。这个新的创业公司是否值得加入?也许你对目前的工作感到满意，但是你还是应该挑战自己。每个成功人士的故事背后都有着共同的主题——抓住值得的机会，在那些错误的机会上学习，吃一堑长一智。　　7.引以为豪　　请为你的工作感到自豪。这是来自于很多专业人士的谆谆教诲——那些我们眼中的伟人，总是认为自己的行业是最重要的，坚信我们的世界需要伟大的。　　这是很难做到的，如果你不喜欢编程的话，但它依然是有可能的。如果你不喜欢自己的工作，那么为什么不想想办法解决呢?如果你觉得每天的日常工作就是编写繁琐的代码，那么也许加入一个开源项目会点燃你激情的火花?你会发现那些对自己职业感到自豪的开发人员让你望尘莫及，无论是他们的代码质量，还是他们在解决艰巨任务中所享受到的快感。　　
这些文章怎么样？千万别沉了啊！虽然我还没毕业，但我觉得对不管对毕业的已踏入工作的还是没毕业的都很有作用的啊！
贴吧热议榜
使用签名档&&
保存至快速回贴