我先做一下自我介绍，我是19年毕业的本科应届生，目前就职于豚厂，主要从事java开发的工作。

写在前面

最近，不少的应届生问我怎么找工作，说现在找工作太难了，我也知道受疫情的影响，目前很多公司的招聘都延迟甚至取消了招聘计划，对于应届毕业生来说，这无疑是一个漫长的冬季，大厂本身不好进，疫情期间对于应试者的要求更加严格，小厂有过之而无不及，甚至直接把应届生置之门外，这些情况在应试者的角度来说是不可改变的，但是我想说寒冬固然萧瑟，让你感觉到寒冷，但是越是寒冷，就要动起来跺跺脚，能量需要自己去创造，机会更需要自己去把握！

我的大学

相信我的大学生活跟绝大多数的大学生一样，大一虚度了光阴，大二找不到方向和定位。我大一喜欢玩游戏，上课时间都在想下课了回宿舍我要怎么打装备、怎么强化。大一读完，我跟我爸妈说：“爸，妈，我想去当兵，读大学没用，啥也学不到”。

大二上学期我想把成绩提上去，期末基本每科成绩都是80，90分以上，但是还是觉得自己学的东西很虚，可以说还是啥也不会，太概念化。大二下可以说是我思想发生转变的一个时期，班主任的编程小组要招人，我就去尝试了面试一下，面试内容很简单，手写一个冒泡排序，我当时愣住了，脑子里飘过一行字“冒泡排序是啥东西？”。看到和我一起去的同学们和编程小组的学姐学哥们侃侃而谈，我在旁边插不上一句话，因为他们说的我不懂。那一天我受到了雷劈一样的打击，大学不是我没学到东西，而是我在浪费时间，学到的东西没有沉淀，我一直在虚度光阴。我要改变。我跟自己说，从那以后我在csdn开了自己的博客，激励自己记录自己的学习生活。我也是从那个时候，慢慢的变成了一个技术宅。

大三大四我开始了一边学习一边面试，学校的课程只有专业课成绩可以，其他的都是考试前临时抱佛脚，我把大部分的时间用在了看书、自学、找工作中，我的舍友也是如此，大学我最最怀念最最难忘的也是那段时光，有痛，有泪，有欢笑，我和舍友们朝九晚五的学习，大三我经历了春招失利，面试了腾讯和蘑菇街两家企业，腾讯是我面试的第一家企业，也是我第一次面试，那种羞涩，那种敬畏感和不知所措的感觉至今难忘，最终败于二面，蘑菇街在hr面后失之交臂，春招结束。我相信，现在很多的同学跟我一样，一次次碰壁，一次次失败，你觉的自己已经走到了绝境，但是我想说的是，别气馁，别放弃，你的坚持你的努力会给你带来应得的回报，只是时间未到，这个世界没有绝境。经历了三个月时间，迎来秋招，我志在必得，拿到了多家企业的offer，最终选择了豚厂，从农村小伙，变成了程里人，我来到了北京，来到了我小时候梦想的城市。

PS：面试首先要认真对待自己的简历，一份好的简历是你面试成功的敲门砖。面试运气是一部分，但是也要注意面试技巧，面试官问到的问题就那么几个，面试的时候你要把主动权掌握到自己的手里，把自己的知识整理起来，形成闭环，一发而动全身，我的经历希望现在正在找工作的学弟学妹们看到，你坚持努力，好的工作机会会向你招手的。

初入职场

忘了说我在大学学习的是C/C++,来公司以后转了JAVA，一直以来都听别人说只要学会了C语言，学习其他的语言很简单，但是我想说那是你没有经历转语言的痛苦，语言只是处理问题的思维和代码逻辑相通，但是语法、数据结构、语言特性上都是有区别的，举个例子，最简单的C语言的printf，JAVA是System.out.println()，我刚学java的时候就总是突然冒出一点C的写法，那时候自己哭笑不得。

实习期间我看完了300多课时的《java从入门到精通》的课程，看完了《java编程思想这本书》，熟读了《设计模式》，我觉的我已经精通java了，少年轻狂，在一次次项目的历练中，我才发现，一个优秀的程序员并不是你语言功底有多厉害，更重要的是你对待工作的态度。一段好的代码不是你使用的技术有多么高级，更重要的是你所写代码可读性、可用性。

我刚刚接需求的时候，我只是为了完成需求而去写代码，我只要完成了产品要求的功能我就心满意足甚至还有点成就感。

心路

这天，我的需求要发布了，导师diff代码，给我提出很多建议，“这里加下注释，这里日志没必要，这里为什么要用for循环，是不是可以这样...还有这里....这里”，按照导师的要求匆匆改完代码，很顺利，我配合QA同学，把代码上线了，上线观察了几分钟，观察了监控和服务器日志，功能没问题，心里想产品提的需求对于我来说太简单的，lerder给我三天的时间，我只用了两天，我心想自己有点厉害，估计现在来阵风，我能飘起来。心里对自己更加佩服了。

年少轻狂，是还没有接受社会的毒打，在功能上线以后顺利运行了几个小时之后，突然跳出几个邮件，“空指针系统异常”的邮件，我心想，肯定不是我的代码，仔细一看异常的系统是我刚刚发布的系统，心里一惊，看了眼错误那行代码，异常的那一行是我写的代码！，我慌了，完了完了，我的代码出问题了，赶紧去定位问题，最终定位到问题是因为我们的系统调下游系统的查询服务挂了，写代码的时候只想着调下游服务查询数据，只觉得代码走到这里查询是一定会查询到数据的，没有考虑到下游服务如果出现异常，我们的系统是否可用的问题，因为少了一行判断，造成了线上空指针的问题，NULL指针是一个常见但是很低级的问题。我心里很惭愧。

上面就是我刚做需求时候内心的真实写照，代码只是为了实现需求写的，我们都知道，实现功能很容易，但是如何写出让大家赞美的代码很难。

下面总结一下我的开发经验与个我一样的职场新人共勉：

1、第一步当然是了解需求，了解一个需求不是你看了一遍需求文档就行了，最重要的就是要沟通，重要的事情说三遍，沟通！沟通！沟通！一定要清楚的了解到需求背景，需求要实现什么，怎么去实现，如果需求没有弄明白，需求设计和开发都是白扯。在设计开发阶段沟通也是很重要的。在开发过程中遇到不清楚的也要及时提出来。避免隐患和错误的产生。

2、需求清楚了之后，就是需求设计的阶段了，我的经验是，功能迭代，我会把旧版流程或成流程图，对比新的功能上差距，这样做便于快速了解代码，快速找到当前功能的缺陷和优化点，更有利于你对新功能的设计和实现，设计时，想好要怎么实现，采用什么框架，涉及到哪些风险点、哪里会出现异常、接口的吞吐量和异常处理，在这里我要提一点，迭代不能局限了开发者的思想，要敢于去改变老代码，迭代只会让代码越来越多，越来越复杂。对于新手，我觉得我们一定要有敢于去重构的精神。

3、前期的设计完成之后就是写代码了，我说几个我认为重要的点：

写代码一定要加注释，加注释，加注释！举个栗子：比如你用pair<A,B>这种这种数据结构很容易让人对于其中的A,B的含义混淆，使用的时候一定要加注释并且命名含义要明确，以免其他人使用的时候混淆。下面这段代码一层调用勉强知道Pair的含义，如果调用层加深后面想真正知道这个Pair就要扣代码,一定要注释清楚。Pair换成UserInfo含义就很清楚了。代码不是自己能看懂就够了！

public class Pair<K, V> {
    private K k;

    private V v;

    public static <K, V> Pair of(K k, V v){
        Pair<K, V> pair = new Pair<>();
        pair.setK(k);
        pair.setV(v);
        return pair;
    }

    public K getK() {
        return k;
    }

    public void setK(K k) {
        this.k = k;
    }

    public V getV() {
        return v;
    }

    public void setV(V v) {
        this.v = v;
    }

    @Override
    public String toString() {
        return "Pair{" +
                "k=" + k +
                ", v=" + v +
                '}';
    }

    public static void main(String[] args) {
        String userMaek = "A";
        String userStatus = "open";
        Pair<String, String> statusPair = getUserInfo(userMaek, userStatus);

    }

    /**
     * 获取用户状态
     * @param userMark 用户打标
     * @param userStatus 用户状态
     * @return
     */
    public static Pair<String, String> getUserInfo(String userMark, String userStatus){
        return Pair.of(userMark, userStatus);
    }
}

/**
 * 用户信息
 */
class UserInfo{
    String userMaek;
    String userStatusp;
}

注意日志的处理，好的日志在定位问题的时候能发挥高效的作用。日志并不是越多越好，过多无用的日志会占用服务器资源，造成浪费。
异常处理，异常处理是一种艺术，什么样的异常应该捕获，什么样的异常可以抛出，这个需要开发者仔细衡量，千万不要把异常栈打出来，这样错误日志过多，不仅耗费资源，而且不美观，在线上报警收到邮件的时候会吓到你！
函数功能单一，实现功能解耦，一个方法的代码不能过长，建议不要超过30行，方法冗长不易解读和维护。

希望别人在看到你的代码不要跟你说这句话！