提笔想起进入字节快一年半了，这一年的成长是毋庸置疑的。在各个方面都有很大的提高，实际的收入也比曾经预想的要高很多。虽然花钱也增加了很多，但最终的存钱计划都很好的落地了。很庆幸自己当时被HR说服，选择了字节跳动。

公司的业务成长也非常快，无论是从app的使用人数上，还是app的数量上，今年都发展的很好。尤其是国外的tiktok，虽然印度封禁了我们，美国嚷嚷着要把封掉。但是随着公司的不断努力，tiktok站稳了脚跟。日活也了很大的突破。

毫无疑问，公司的未来肯定会成为全世界排名前几的公司。字节跳动还没有上市，到现在也没有任何上市的消息传出来，大家都很看好字节的发展，多多努力，多拿期权，等字节上市之日，也许就是一大波人财富自由的时刻。

公司整体的员工数量也增加了很多，我所在的部门，现在已经扩张近一倍了。到现在依然没有看到字节放缓招聘的脚步。

公司这一年多也慢慢涌现了更多的不错的app，例如懂车帝，番茄小说，幸福里基本都做到了行业的前几的地位。未来发展可期。

在字节的一年多中，所在的tiktok业务部门，随着tiktok业务的发展，我们的请求量也在日渐上升，大量的用户，也带给我们业务更高的要求。

对于每个做业务的同学，业务经验的程度决定了他未来的发展前途。新入职的校招生一般会从熟悉语言，字节内部系统，组内部分业务开始，慢慢的开始执行其中一部分的任务，后来会逐渐负责一个方向的项目。

在这些过程中，如果你要表现优异，你要学会如下的几点。

1. 最重要的是你最需要培养的就是自己的主人翁精神，这是非常重要的一点。你要学会自己owner一个项目的开始和结束，你不要依赖于他人。只有拥有了这个意识，你才算真正开始了你的职业征程。

2. 一个项目的生命周期，需要你去很好的掌控。一个项目的生命周期包括项目开始的背景，项目的技术方案设计，项目开发测试，项目的监控和稳定性，项目的文档建设。

a. 项目的背景，项目的背景决定了项目的技术设计，我们需要充分的了解其背后的逻辑，我们需要根据背景定位好自己的项目在整个体系的位置。

b. 项目的技术方案设计，项目的方案设计，不仅需要考虑到是否能够解决此次的问题，还要考虑更多，包括项目的可维护性，项目是否可以解决此类的通用问题，项目中收集或者传输的一些数据是否能够符合法律规定，

这些说句实在话，都需要大量的相关方面的经验，你只有见的多了，才能想到统一的解决方案，都需要你在工作中多和同事沟通，了解他们在做什么，这样才能慢慢积累业务经验。找到更好的解决方案。

c. 项目中的开发测试是我们开发人员的基本功，是我们每个开发人员都最熟悉的东西，但是我想说一些我的看法，开发我们也要注意很多东西，包括项目文档命名，方法变量命名，每一个命名都要符合当前业务场景，不要产生歧义，并和组内大多数同学保持相同的代码风格，减少这方面的沟通。

测试是项目开发过程中，比较耗时间的事情，我们经常调侃开发5分钟，调试2小时，我们要学会发觉高效的测试方案。尽量代码严谨，保证几次内能够调试完全。对于测试人员测试，如果需要我们开发人员帮助的，我们也应该在保证业务安全的同时，尽最大的可能的提高他们的工作效率，

多和测试人员沟通，获取他们的反馈和诉求。这些都需要我们付出努力不断沟通和学习。

d. 项目监控和稳定性，其实这也是属于项目的技术方案设计的一部分，但是因为确实很重要，就单独拿出来说一下，项目的监控是指业务中，一些关键数据的监控，我们需要保证项目上线后，可以实时的看到你的数据是否符合预期。

项目的设计选型中我们也要考虑底层的存储是否符合我们业务的要求，性能如何。还有我们上线业务，是否对下游会造成不稳定，如果出现业务错误率过高，你如何排查这些问题。你入职后，要学会熟悉自己的公司内部的常用打点，起码要知道成功率的打点和失败率，接口响应时间p99等基础的

打点，报警配置，大盘监控如何配置和查看。如何优化自己的大盘。

e. 项目的文档建设，一个项目的生命周期中，除了项目开发占比，一个大的项目，沟通成本也是非常之高，项目的文档建设，也是减少沟通的非常重要的一环。一个项目，应该必须具有项目的介绍文档，项目的整体设计文档，项目的常见问题自查文档，项目的整体规划（如果是长期发展）其他文档         （包含过程中沟通的一些文档）

3. 公司内部的常用内部工具，无论是解决问题，还是设计方案，只有我们了解更多的工具和基础组件，我们才能设计和维护好我们的项目。

4. 多记住别人对你的方案和系统提出的质疑，质疑声很难听，但确实实在在的对你未来的发展有很大的帮助。你要多思考这些质疑的问题，下次如何能够避免这种问题。

5. 多和领导，同事沟通，每隔一段时间，要和领导沟通一下，看看领导最近对你的看法以及有没有什么好的建议。

6. 每一次开会和okr制定都要对学会认真对待，每一次都是一次提升。不善于写文章的同学，也要多多努力。

7. 最后，我们要有解决难题的决心，项目中你吐槽的业务问题，也许都是你将要解决的难题。如果你都没有解决这些问题，很多时候，你是否能表现优异，也是看这些方面是否有突出表现（很遗憾，能力有限，在这些方面目前没有作出很大的贡献）。

每个做开发的同学，内心或多或少都有个技术大佬梦，我也是，非常希望自己能成为一名技术上的大佬，可以帮助同学解决难题。入职以来，技术方面虽然在逐渐的积累过程的成长没有我想象的那么大。总体说来有如下一些情况吧，我想也是工作了一阵必须熟悉的一些知识。

1. 业务中本就是微服务部署，服务直接通过rpc框架发起调用，我们业务都是建立在rpc框架之上，所以首先我们必须要了解rpc框架做了什么。那么他们都干了什么呢？闲言碎语忍不住自己稍微总结一下。rpc框架主要负责在多进程之间的信息传输，可以跨实例，也可以在同一台实例上进行调用。不同实 例之间方法调用， 需要数据在网络中传输，所以需要我们制定网络协议是tcp还是unix socket等，指定好网络传输协议，我们需要把这些二进制的bit流转化成我们可以识别的字符串，所以需要我们去编码和解码这些数据。如果需要压缩，可能还会有压缩算法等。这样需要交互的两端只需要将数据进行联通，真实业务场景肯定不再是两个实例间联通，有可能是多个集群直接相互联通，所以服务发起调用的时候需要知道被调用方的ip的，所以就有了注册中心，例如zk，etcd等，我们需要服务发现能力，需要依赖于注册中心去查找对应的实例，找到实例后，由于考虑负载均衡，我们需要根据一定的算法选择相应的实例。注册中心会有心跳机制，确保实例的正常。调用过程中不可避免的出现一些错误，网络问题或服务请求等方面的问题，这时候需要我们在框架中加入一些服务治理的能力，包括超时，重试，熔断，降级等功能。如上便是一个rpc框架大体的功能了。

2. 业务中为了解耦合，以及扛住突增的流量，我们通常会选择消息中间件，消息中间件，我这边了解过的有rocketmq和kakfa。两个都是广为流传的两个消息中间件。我们需要起码详细了解一个中间件的实现细节，我这边了解kafka稍微详细一些，大体上kafka分为三大部分，生产者和消费者，以及broker，注册中心，broker用户来暂时存储数据，用于数据流转的。申请kafka的时候，需要我们申请对应的partition的数量，以及大体流量预估。每一个信息的大小。服务端注册了kafka后，我们发送消息会有一个topic，topic的目的，就是供不同的业务场景使用，我们需要制定一个主题。当生产者将数据发送到broker上之后，消费者通过不断的pull消息，获取到broker上的数据。但是消息的量很大，不同的消费者同时消费一个broker的数据，吞吐量总是受限制，所以broker也是一个集群，供消费者按照配置的实例不断的获取。这时候就有了一个partition的概念，所以不同的消费者实例会消费不同的partition的数据，kafka相同partition的数据是有序的，但是不同partition是无序的。要考虑数据存储的安全，防止服务器宕机等问题下，数据的丢失，所以每个partition都会有副本，这个副本存在于不同的实例上。每次写入都会有同步副本的操作。细节大家可以再去了解

3. 业务中常用的cache，经常用redis作为缓存，或者持久化存储。redis主要支持5种数据类型，string，list, set, zset, hash，需要了解底层的数据存储结构。list常用数据结构压缩列表用编码方式，将一些string的数字转化成bit数组存储，zset常用的跳跃表等，以及redis常用来作为缓存，已经用来做分布式锁等情况。redis的分布式集群情况下，建议批量获取时多使用mget等方法，多个操作可以同时使用pipeline批量操作。redis的持久化RDB和AOF，可以用于多个集群之间的数据同步

4. mysql.. 今年接触不多，暂时不说了。。

先说这些吧。后续肯定还有会有更多的感悟，欢迎同学关注我，也可以评论一下，我会私信你我的微信号，有什么技术上的事情，可以相互学习，我也是个菜鸟..

最后贴一个我的内推帖子，部门招人力度还是很大的。欢迎找我投递。后端同学可以帮你review简历，如果你通过一面，我们还以语音交流一下面试经验。最后，欢迎大家评论。

投递日常实习和社招链接: https://job.toutiao.com/s/eUuvSp8
字节其他经验贴：https://www.nowcoder.com/discuss/609828?source_id=profile_create_nctrack&channel=-1