想学技术的新手们请进

经常会看到这样的朋友，或者刚毕业，或者工作了没多久。

往往会在那里抱怨，这家公司很烂，我学不到东西。好多技术他们都不用，公司里的那些家伙，水平又很次。用的框架又很垃圾，等等等等。

问题在于，你们有没有想过，学了技术来是干什么用的呢？
难道不是提高自己完成项目的能力吗？

似乎不见得，有人只是想要“把那些伟大的单词，加入自己的简历”。比如说ORM，这家公司既不用Hibernate，又不用iBatis，也不用支持EJB的某个知名产品。这将来的简历，怎么拿的出手呀？

在我看来，要想真正的提高自己，那么就应该着眼于完成项目的能力。
给你的任务，能不能完成？
类似的任务，相近的任务，你是不是能够找到方法，提高效率，改进质量？
人家的垃圾代码，你能不能够更快的看懂、理解并使用？
就算是帮人家擦屁股，也要想办法，擦得有技术含量一点！

光知道在那里抱怨，最应该学的东西却没有学到。
真正遇到了有挑战性的项目，你能搞定吗？

那些能够让你飞快进步的挑战，你有能力承受得了那种压力吗？
如果领导从来没有见你轻松搞定一个普通的项目，他凭什么相信你，能够承担更大的责任？

仔细想想吧。

我喜欢问别人一个问题  “你觉得从维护性的项目中能获得什么收获？”

对我自己来讲，新开发项目和维护项目大致是一半一半。最开始维护别人的项目可以学到很多东西，到后面维护很多项目的时候，会发现很多垃圾的地方，或者新功能很难满足，通过总结，就可以在新项目的开发中提早避免这些问题。

我觉得一个开发人员必须体会下维护的痛苦，自己开发新项目的时候才能尽可能的为他人着想，提高代码的质量。

我还是那句话，学技术不是拿来玩或者炫耀的，是为了完成项目。

同意楼主一个看法，无论是software engineer,developer还是programmer任务都只有一个：solve problems.

不过绝大部分的朋友都没弄一个清晰的概念，就是做software engineer还是做programmer。大多的讨论都是围绕"code"，但是coding只是implementation的一个环节，而implementation又是整个SDLC的一个部分（不是说其不重要，但是确实花的时间最少的一个环节）。真正头痛的是在plan, architecture/HLD,和design，自然投入的时间也多。当然，有的朋友只喜欢implement也很正常，但是每次看到“求代码”，“这是我写的**程序的代码”等等，没有requirement怎么知道那些代码拿来干什么的，很难考究写得好还是不好。给他们提出建议，能否上个需求或者代码的目的，答复就不说了，永远是reactive。我见过太多的朋友，问题一来就到处找相关的solution就直接写code，没有经过分析和设计等。还有，通过提高代码的质量去提高项目的质量，这是没错的。但是代码只是语言，一个向computer表达实现你的solution的工具。关键有效的还是应该针对requirement去改善项目的architecture/design，从而得到更好的方式去改善代码。按照这个思维，提高代码质量的考虑应该是放在a/d之后的。总之还是SDLC这个approach了。

India的IT发展快的一个主要原因，是因为SDLC在他们的软件业发展应用起来了。借楼主的帖子问一句：SDLC的概念什么时候才能进入中国软件开发/教育/市场的主流？

PS：我在想，能否在国内办一个consulting和software engieering的培训机构，灌输SDLC这个concept，望有志之事共同商讨。

Wayne

观点非常同意，文风很难接受。

能不能少一点“英文缩写混杂”的段落？

从“这个技术有意思/吸引人”到职业的过程。
有激情和创造力的人因为高调走这个过程尤其漫长，倒是比较平庸的人因为低调很容易完成这个过程。

我承认我刚工作那会就是这样……不过现在觉得其实怎么把一个用烂框架写的程序写好了才是本事……

敢进来发言的看来都不像是新手(除了我),不知道不什么要用这个主题:"想学技术的新手们请进",应该更像是:"为什么要学技术"或"学技术的目的在于__________________?",看你们讨论的也许并不是新手才应该看得吧?

ls你都3颗了，还说自己是新手……我可是彻彻底底的新手，很多时候只能跟着大大门走，没有自己的思想

其实做软件的要提高的是自身的综合素质(分析问题、解决问题的能力以及沟通表达能力)，而不仅仅为了技术而技术。
最值得开发人员自豪的应该是在某种困难的条件下，完成了某种艰巨的任务而得到客户、公司的认可与信赖！而不应该是自己学会了某种语言、某种工具与知道某种名词。