姬長信(Redy)

大龄程序员技术管理路上的悲喜总结


本文仅仅是对自己作为一个普通大龄开发者的一些技术与管理的总结。不喜勿喷。谢谢!

生在中国这片热土,我们做程序开发的人要面临很多的挑战。只要生命不息,挑战就永远不会停止。

比如最近疯传的 35 岁程序员送外卖。这明显点出了在中国搞开发,要面临的其中之一挑战:年龄。

在整个 IT 领域,大多数的开发者都属于普通人。只有极少数部分人能站在技术的尖端引领技术的前进与走向。那么,普通的开发者,又很容易被新人替换。新人更经济实惠,压力小。而老开发人员技术的天花板无法打破的情况下。要面临跟着一群小朋友一起起早贪黑的工作模式。甚至于会出现自己一把年纪,上面的领导比自己还小好多岁的窘境。

肯定有人会说我们这群老人矫情。但是,又有几人能做到内心毫无波澜呢?

本篇博文主要是针对我们这群普通的开发者处境所写。请允许我在这里贩卖焦虑。

一、系统架构

作为技术这条路线,最终都会偏架构方向。即使做技术经理或总监。都必须对系统架构要有一定的知识储备,以备对团队的架构搭建与变更做出准确的判断。

这里并不是说我们去设计一些千万级别以上 PV 的系统架构。做为普通的开发者,要接触上亿的系统平台相对来说机会并不是很多。即使接触了,也仅仅只是这个平台里面的一个小螺丝。要能主导这个架构的设计,还稍显稚嫩。我再次说明一下,这里仅仅只对普通的开发者。不指那些尖端的高技术人才。

在我的理念当中,千万级别及以下 PV 的构架,通常用不到微服务。所以,不要用微服务来坑自己。加重架构的复杂度。

在这个体系里面有以下技术/服务/文档可能是我们要涉及的:

像我这样普通的大龄开发者,经历过的大大小小项目也挺多的。要真的能达到千万级别 PV 的挺少的。通常要面临的挑战如下:

二、网站劫持

网站劫持这是一个比较笼统的叫法。实际有如下几种劫持:

而注入型劫持,又分以下几种:

DNS 劫持:
在工作中,经常会有用户跟我们的客服同事反馈 App 打不开或报错。这其中有一部分就是 DNS 被劫持所致。劫持之后 App 请求接口拿不到数据或拿不到指定的数据,肯定会报错。影响用户正常的访问。

URL 跳转型劫持与注入型劫持都可以通过 HTTPS 方式解决。而 DNS 劫持就比较特殊了。

关于 DNS 劫持解决的办法是通过直接访问受信任的 DNS 来解决。因为,这种 DNS 的劫持通常是运营商 Local DNS 缓存问题造成的。比如,攻击者污染了根 DNS 服务器。导致运营商同步造成了数据的污染。自然访问就会出现问题。

所幸,我们可以采用类似阿里云这种平台提供的 HTTPDNS 服务。来解决 DNS 劫持的问题。
HTTPDNS 的功能特性:

  • 防劫持:绕过运营商Local DNS,避免域名劫持,让每一次访问都畅通无阻。

  • 精准调度:基于访问的来源IP,获得最精准的解析结果,让客户端就近接入业务节点。

  • 0ms解析延迟:通过热点域名预解析、缓存DNS解析结果、解析结果懒更新策略等方式实现0解析延迟。

  • 快速生效:避免Local DNS不遵循权威TTL,解析结果长时间无法更新的问题。

  • 降低解析失败率:有效降低无线场景下解析失败的比率。

  • 稳定可靠:99.9%的可用性,确保域名解析服务稳定可靠。

三、系统安全

系统安全真的真的特别重要。作为一名开发老兵,心中始终要有一根弦:代码千万行,安全第一条。

常见安全防范:

四、代码规范

即使你是外包或建站类型的项目开发,代码规范能帮助你减少项目交叉维护带来的痛苦。
不管是后端 PHP、Java、Go,还是 Web 前端,还是 Android/iOS 客户端。必须有一套代码规范。

其实代码规范这个东西是一种约定俗成的规定。并不是一层不变的教条。也要因地制宜的形式进行使用。不能生搬硬套。小团队只要大体上没有问题即可。大团队可能就需要专门 Review 代码的机制,以及代码提交的辅助性插件来进行代码规范的验证。

五、工作汇报

如果你是老板可能就不需要进行工作向上汇报。否则,不管是哪个阶层,工作汇报必须是工作中重要的一环。而每个层次的员工汇报工作的方式又有不同的侧重点。

这里指的是工作汇报,而不是项目进度汇报。

(1)非核心开发员工

此类员工工作汇报应该有如下几点:

(2)核心开发员工

此类员工作为核心输出。与非核心开发员工还是有区别的:

核心员工重点工作是编写核心业务代码。并且指导并协助非核心开发员工遇到的各种难题。必要的时候,还需要对这此处于最底层梯队的员工进行技术培训。让他们快速成长,慢慢成长为核心员工。
其次,核心员工不但能发现问题,还能解决问题。当需要部门管理者作决策时,是带着A/B决策方案去。

(3)主管级别员工

这一类员工实则是与核心开发员工差不多。在核心开发员工上面进行一层工作的协调分配的工作。

六、职责清晰

这一点是针对开发转技术管理路线的人而言。要让每个开发准确知道自己所负责的事情。说穿了就是职责与责任。
如果职责不清晰,对一些事不关已高高挂起心态的人来说,会导致事情变得难以推进。只有明确职责之后,在事情没有办好的时候,就知道是谁的责任。

七、绩效考核

这个与第六点相呼应。唯一的难点是要能及时且准确对责任做出评估,该扣绩效扣绩效。这奖励的就奖励。绝不能拖泥带水、瞻前顾后。特别是拒绝过分护短的情况发生。

八、上下关系

很多刚从开发转管理的人会有一个毛病。觉得要以技术实力去让人服从。这明显是不合适的。技术能力固然很重要,但不能本末倒置。天下技术千千万。要以这种思维去做技术管理。那我相信,这世界上没有几人能坐得稳。

所以,技术这东西得多去关注理论的东西即要。这样才关键时刻能做出正确的选择。

有些人还觉得要跟下面的人打成一片才能让别人服从自己的工作安排。我并不这样认为。工作中率先不服从或意见最多的反而是那些平常你极力去讨好的人。我们在做管理的时候,只需要秉承公平公正公开的原则,去对待每一个人和工作即可。

那些不愿意服从的人,不管是交好的或关系远的,都应该及时进行制止和批评。如果依然如此,那是他个人问题,不是我们管理的问题。除非我们的工作安排确实出现了严重的不公平不合理的情况。

以上都是自己瞎逼逼的一些总结。

管理这份活儿,它并不容易干。但好在能在此间修休汲取一些实战经验来检验自己的不足。也是有幸之事儿了。