浅谈这半年的实习感想

public class 浅谈这半年的实习感想{

private final static String DIGEST = 写这篇文章，一是作为这半年实习的总结，二是分享自己想说的话。文中观点，小部分参考前人的经验之谈，大部分是自己的心得体会。说得对的，可以借鉴学习，说得错的，可以无视跳过。不局限于IT行业，其他行业也可从中参考部分观点。

public void 初级工程师的三个阶段(){

我给初级工程师划分了三个阶段：抄袭、模仿、创新。初级，是因为我自己的层次不足以评论高层次的事。工程师，是因为个人觉得水平算得上个入门级工程师。先从一个小故事说起，抛砖引玉：

三个程序员A、B、C，同时大学毕业，三人技术水平、经验等各方面差不多，进了同一个公司同一个部门，岗位也假设都一样吧。工作三年后，A的薪水翻了一倍，因为这三年里，项目经理安排给他的任务，他总是能很快从别的项目（自己的或者网上的）里找到模版，搬过来，修改下，在最短的时间里完成任务，工作效率算非常高。做事效率高，又听领导的话，说一不二，有需求就改，升职也是容易的事。再看B，B有个习惯，就是哪怕是查阅到了需要的代码，也要自己动手一个一个敲一遍，而不是copy、paste，这对工作效率来说就有点影响了。相似的功能模块，他把他封装起来，在此基础上不断改进完善，以便下次利用。对函数方法原理上稍有研究，在没有互联网查阅的条件下，以及没有旧的demo情况下，能凭记忆完成类似的较复杂的功能。最后看C，C每当遇到新的问题时，会把工作的任务丢一边，想办法把问题彻底搞懂，为什么会出现这种情况，怎么应付，怎么避免，甚至去把API文档查个明白，搞清楚原理的C就可以自己完成整个功能模块的code而不需要借助他人的东西。久而久之，在面对新的问题时，C能在最短时间内找到问题的突破口，设计出合适的函数或方法来解决。

对于刚开始起步的程序员，在遇到问题时，大部分人第一件事是百度。不懂就上网查，这是好事。然后将查阅所得的资料，复制粘贴下来，改改变量名，就变成自己的代码。是谓抄袭。纵观这件事本身，没有什么不对的地方，这也是一种学习的方式，效率也是很高的。但是，这类程序员，缺乏对问题本质的思考，以至于没网或者没旧demo的情况下，他便无法完成相应的代码。

其次，对于善于将别人的代码吸收消化变成自己的代码的程序员，他对问题本身有所研究，知道其中的亮点和瑕疵，哪里值得学习，自己为什么没想到，哪里可以优化，功能能否扩展。加上代码过手，有一定的熟练度，这类程序员往往在花一定时间的学习后，能做得比原作更好更完美。这就是模仿。如果对于赶进度的工作任务，喜欢模仿的程序员可能会因为误了工期而被上级批评，但是，熟练之后，下次遇到相似问题便能事倍功半。

知其然而不知其所以然，这是这一行的普遍现象，因为枯燥无味的API文档，密密麻麻的英文，一大堆看不懂的变量名，以及领导施压赶工，成了“精读”的绊脚石。结果就是选择了“涉猎”。善于精读的程序员，在算法上，往往比涉猎的程序员有更独到的见解，对问题考虑得也更加周全。站在巨人的肩上，你才能看得更远，官方的API文档就是巨人。深入底层地理解原理，你才能创造属于自己的style。而能在这一点上做好的，创新能力绝对是数一数二的，以至于前两者多年以后可能还是个coder，而创新的人已经升到了高职。

}

public void 写十小时代码不如做一小时思考(){

工作中，我们需要时不时地停下来，回顾总结一下前面的情况，反思自己的问题。把自己出现过的问题总结起来，想想为什么会出现，自己还有哪些不好的习惯需要改。把项目中觉得写得非常好有价值的code记录下来，发现其中的闪光点，在今后的代码中大放光彩。把自己做过的demo保存下来，有空时看看，哪里需要改进完善，当初为什么没想到。有兴趣的，还可以写写文章，记录自己的心得体会。磨刀不误砍柴工，整天机械式地敲代码只会让大脑退化。思考，才是保持大脑能力的最好办法。除此之外，利用空余时间，逛逛论坛和社区，学习别人的优秀项目，听听别人的经验之谈，也是对自身能力的巨大提升。别让代码锈了你的脑子。

}

public void 解法的多元化(){

有程序员抱怨自己做的事千篇一律，翻来覆去无非就那么几个功能需求，代码写来写去也大同小异，以至于技术没有提升。其实，即使是一件很小的事情，重复做也有其价值。同样的一部电影，看第一遍和看第十遍，一定会有不同的感悟。编程亦是如此。哪怕是十个项目里都用到了排序，你也可以用十种排序算法去分别实现，再比较十种算法的优劣。在算法上可以改进，在代码结构上可以改进，甚至考虑对性能的影响，也可以改进。我们每天都要吃饭，但是总要换着花样吃。同一个功能需求，学会尝试不同的实现方式，也就不会枯燥无味了，还能得到意想不到的收获。善于对同一个问题产生多种解法的人，很少会被问题卡住。同时他的代码也是趋于完美和最优解的。

}

public void 做一个有主见的程序员(){

程序员和项目经理的关系，就如同包身工和包工头，交给你任务，你做，他检查，客户看，哪里不对，提需求，你改。但是，程序员真的就是对项目经理唯命是从吗？假如这个项目中有不合理的需求，就好比叫你在水面上刷一层水泥让人在上面行走，尽管你想也许可以先在水面垫一层木板，把水泥刷木板上，等凝固了再去掉木板，但是对于客户，最后要走在这水泥上的人，谁也不敢保证这样做不会塌掉。如果你选择了妥协，这不仅是一种不负责任的态度，同时也是一个隐患，会增加后期客户要求返工的几率。那么你完全可以跟项目经理商量，先把水抽干，待水泥结实了再蓄水。或者再叫上客户，说明问题，能否搭一座桥在水面上方来取代水泥铺路。这也就降低了由于不合理需求导致变更而延长开发周期的可能。每一个程序员，在开发工程中，对需求应该认真思考，其合理性，可行性，危害性，复杂性等，并及时反馈给上级，甚至反馈给客户，避免无用功和浪费工时。没有主见的程序员，只是一台编程的机器，不能带来创造性的价值。

}

public void 宽度与深度(){

程序员在技术上有两个发展方向，宽度和深度。宽度，即知识面的广度，能力范围的覆盖面，做得好的，又叫全栈工程师。深度，单指某一个领域的钻研程度，其专业知识远超其他程序员，做得好的，我们称他为XXX领域的资深工程师。

当今IT行业发展迅速，新鲜事物不断诞生，我们当然不可能全部去学。单是编程语言，就不计其数。对于我们，该如何选择？首先，正视自己的知识面和能力范围，对于大部分人而言，在这个行业只能算个新人，论深度，没有个三五年的工作经验，是几乎不可能有资格谈及的。论宽度，走马观花地见一样学一样，更是不可能有所成就的。那么新人该如何发展？个人理解为，先学一技之长，再在对其深度方面发展的同时，兼顾宽度的发展。举个例子，一个会六种编程语言的程序员，这个会，就是说他的能力仅仅停留在基本的基础知识上，而没有深层次的认知，比如他可以用java做个基于socket的C/S，但是要求他做个带UI的多人聊天室就做不到了，他可以用html做一个静态网页，但是要求他做个个人博客网站就做不到了，那么去找工作，即使进到了岗位，也会很快因为能力不足以胜任业务需求而被淘汰。所以，应该先发展适当的深度，有一技之长，有你专攻的方向，你才能站稳脚，但是这并不代表你就可以不顾宽度，同样的两个前端工程师，其中一个sql很熟练，有大数据经验，那么优势就相当明显。然后，才是发展宽度，比如java工程师，刚开始只会java，后来服务器涉及到数据库，那么就得去学sql，然后涉及到web前端，又得去学html+css+js，哪天领导要求做移动应用开发，又要去学android/ios。所以，根据自己的业务需求来扩展自己能力的宽度，而不是盲目地今天听说php适合做服务器就去学php，明天谷歌推出新语言kotlin说要抗衡java就去学kotlin。到了后期，如果你的宽度达到了对五种以上编程语言的熟练运用，那么你就可以考虑好好钻研一下你的深度了，比如钻研一些重要的架构。

}

public void 如何判断程序员的能力(){

通常，人们用两种方法来评价一个程序员的能力：工作年龄和项目数量。对于工作年龄，是因为觉得工作得越久，学的知识越多，积累的经验也就越多，所以能力就越强。对于项目数量，是因为做了那么多项目，肯定也积累了丰富的经验，自然能力就越强。然而事实是，有的程序员，五年前什么水平，五年后也是什么水平，因为这五年里他做的事无非就是从喝一瓶雪碧到喝一瓶芬达，换汤不换药。那么如何判断一个程序员的能力强弱呢？实战，才是实力的最好的体现。一个优秀的程序员，不仅仅是在长年累月的工作中积累经验，从无数项目中储备知识，更是从中提升自己解决问题的能力，在新的任务下发后，能够在最短时间内着手并高质量地完成。而判断一个程序员的能力，就看他在面对新事物时的应变能力和解决能力。所以，不要被单纯的数字所迷惑，一个工作多年的程序员不一定能力就比刚毕业的实习生强。

}

public void 在自娱自乐中学习成长(){

对于真心喜欢这个行业的程序员，我希望你能把program当作自己的一项兴趣爱好，而不仅仅是你的job。“兴趣是最好的老师——爱因斯坦”，把编程开发当作兴趣的程序员，他会主动去寻找知识，去探索新的知识领域，去实践自己的专业能力，潜移默化中提升自己的水平。我个人的做法是，结合自己欠缺的技能，给自己定一个感兴趣的喜欢的project，难度适当超出自己现有水平。从原型设计，到架构层次，再到业务需求，逻辑处理，甚至性能优化，样式风格等，都认真思考并规划，制定一套完整的方案，然后开始着手。这不仅锻炼了自己architect的能力，还能让自己认识到不同业务不同岗位的任务，便于今后工作与同事之间分工合作，甚至对担任leader也是一种锻炼。至于你说做出来的东西没有实用价值或商用价值，没有就没有吧，你就当我是自娱自乐，反正我学到了东西。

}

public void 对自身的期望决定了能达到的高度(){

程序员，或者说coder，浮现在脑海里的第一印象是坐在电脑前敲键盘的码农。你愿意自己的职业生涯一直这样吗？coder，算是IT行业的起步阶段吧，往高职走是什么？designer？architect？PM？或者就在coder层发展，full stack engineer？senior engineer？

不管你选择了哪一种发展方向，你在你选择的路上又能走多远？这决定于你对自身的期望。先给自己的职业生涯定一些短期的小目标，努力一步一步实现，看得到的成就才能给人信心。然后再制定一些长远的目标，五年后你希望自己是个什么状况？十年后呢？二十年后呢？别等到多年后回过头来发现，自己忙忙碌碌多少年，站的高度还是一点没变。

}

public void 以匠心精神来对待工作(){

即使是同样阅历的程序员，开发出来的东西也会有天壤之别。做得好的，你读他的代码就像在欣赏一件作品，一件艺术品，而草草了事只为完成任务的，你读他的代码就像闻一坨屎一样，让人无法忍受。开发过程中，应该秉持一丝不苟的、严谨的态度，保持匠心精神，在细节地方精益求精。比如代码风格，排版，结构，命名，设计模式的选择，功能模块化，算法优化等，都是需要注重的地方。而对于不加思考仓促写出来的代码，不仅自己读起来费力，后期维护也会非常困难，害人害己。代码漂不漂亮，有时也是一名程序员技术水平的真实写照。

}

public void 工作环境与发展前途(){

工作环境通常分两类，产品型和技术型。前者又分外包型和工厂型。后者又分为研发型和服务型。

Type 外包型 = 由PM接项目，安排一群开发人员来完成。做好后交付客户，后期提供维护。大大小小项目都可能会遇到，没项目时非常悠闲，有项目时加班赶工非常累。

Type 工厂型 = 已经做好的项目，批量化生产产品，像商品一样由客户选择并购买。项目可能是外包型的项目的商品化，有可能是研发型的技术实例化。一旦开始批量化生产，开发人员基本失去了价值。

Type 研发型 = 平日专注于某个领域的技术研究，短期内很难看到价值。对于喜欢钻研的人来说还不错，否则枯燥无味看不到结果会让人抓狂甚至离职。并且及时性很关键，一旦别的公司先开发出该领域的技术，那么前功尽弃。

Type 服务型 = 客户主动找上门提出某个技术上的需求，architect提出解决方案，engineer实施完成并配置到客户。一般出现在有成熟管理能力和资深工程师以及架构师的公司。对开发人员技术要求较高。

选择适合自己的工作环境，避免盲目入职造成频繁换岗位。

而关于发展前途，主要参考在以下几个方面：

Case 领导者管理能力 = 一名优秀的leader就像一场战争的将军，手下将士再厉害，没人领导或者领导者能力不足，也是很难打胜仗的。

Case 开发人员整体水平 = 如果整体水平比自己高太多，工作压力会非常大，甚至被炒鱿鱼。如果比自己低太多，你觉得自己能提升多少？而如果整体水平跟自己差不多或略高，其中有个别技术大牛，那么再适合自己不过，既能保证自己日常工作能找到有共同语言的人交流，又能有努力发展的目标和动力。

Case 开发项目的主要价值 = 对于热门的话题，价值是很明显的，但是风险也是很高的，原因还是在于及时性，慢了就等于前功尽弃。而对于商业价值较低的开发团队，则根据开发人数，开发成本等几个方面去选择吧。

Case 饱和度 = 人员饱和度，裁员中还是扩招中；项目饱和度，闲的还是忙的；技术饱和度：处于研发阶段还是成果阶段。

}

public abstract class 编程之外的事{
public abstract void 身体状况():
public abstract void 素质修养():
public abstract void 职业素养():
public abstract void 人际交往():
public abstract void 认知能力():
public abstract void 经验阅历():
public abstract void 生存能力():

String explain = 以上七点，不是我要详细阐述的，而是自己需要认真反思的，所以不再赘述。

}

/**

* @Description谨以此文告诫刚满二十一岁的自己。同时勉励还在迷茫的朋友。人生已过去四分之一，接下来的路该怎么走。

*

* @Author曾宇

*

* @Date二零一七年七月六日

*/

}