待补充··············
逐步转型,还在积累经验。
Poor Home/Blog
先前有担任过项目经理,业务需求比较明确,倾向于兼技术经理,偏业务需求挖掘算是第一次做。可能也没有纯粹的项目经理,业务和技术应该都是需要具备的其中几项辅助技能。
提到技术岗,我觉得技术有个特性是只有行业顶尖的人负责造轮子,各行业上大多的技术岗真的蛮心酸。一个技术宅同事常吐槽说,很多时候并不是技术能力比不上主流,而是你处在的行业需求跟不上主流,许多传统行业信息化公司天花板略微一跳就触顶了,研发预算也不高,需要的技术人员水平自然也就降低,学多了用不上就只能频繁换地找些挑战,但是人到三十几岁就是个坎,要么就重复使用的用烂了么的技能,慢慢磨时间,要么就努力提升自己管理水平和业务沟通的水平,努力去带好团队。
健全制度的公司决定所有员工的工资,确定一个合适的晋升渠道,初创或者是传统的公司决定部门主管的薪资,主管决定你的薪资,但是不负责你的未来。
一、先梳理几个关键节点。
前半段过去学习,负责其中一个专题,初步踏入数字政府一网统管的这个领域,当时除了觉得跨市出差比较辛苦,但是知识学习是非常快乐的。
收尾到末端,不知什么风起,开始
二、再谈谈对大脑项目总负责的项目集成管理的经验
三、在谈下当下对央国企的感悟
价值观不明确。数字政府建设是最终是解决什么问题。为客户、
工作是工作
政治是政治,站位很重要
情怀最为
管理上冲突。
首先要明确一点,正确评估自己的能力水平和性格特点,走技术专家路线还是走管理路线。技术专家也是有好几个方向的,一般还是与实际业务结合 偏应用路线解决方案,使自己的技术形成一个闭环。通过不断的学习使得解决方案构建升级。
因为打算走技术专家路线,整理几个前端比较常规的岗位和进阶方向,技术专家我觉得正常是其中几个自由组合吧。。
①Node服务端工程师:
所需掌握技能:
1、安全性角度考虑:如果我们想要一个公共组件库,那么把组件放到我们私有库中,只有内网可以访问,这样可以避免组件中业务的泄露;
2、模块复用性角度考虑:多个项目之间有重复的共有模块,当需要修改模块,通过简单的统一的配置就可以实现;提炼后的组件有专门的地址可以用来查看,方便使用,在后期项目的引用中也能节约开发成本
3、npm包下载速度角度考虑:使用内部的地址,能够在开发下载node包的同时,将关联的依赖包缓存到verdaccio服务器中,下载速度更快;
4、项目开发中的路劲角度考虑:在项目开发中书写代码更整洁简练,不需书写更长的相对路径;
5、公司技术沉淀角度考虑:知识的沉淀,在公司业务相关的应用上尤佳;
6、版本角度的考虑:相当于一个容器,统一管理需要的包,保持版本的唯一;
7、开发效率角度考虑:使私有公共业务或组件模块能以共有包一样的管理组织方式,保持一致性,提高开发效率,下载的时候,可以让公共包走公共仓库,私有包走私有仓库;
基于Linux version 3.10.0-1062.9.1.el7.x86_64
前端近五年了, 按照一万小时定律,我现在应该也不平凡了,但是到超凡,那也还没有。 笼统点的自我感觉就是基本点都通了,应用类的技能都能用上,像是读完了高中。天文地理生物化学都知道些脉络,但是再细致一些,就需要更系统地进阶性学习。
前端架构师的职责 促进前端工程化、服务化,持续提升研发效率,保障线上产品质量; 作为前端架构师, 首先要解决的问题就是让日益膨胀的代码可控,
基本职能为:
**地球的一度是 6378km*3.1416*2/360=111.3km,
3 度带是从中央向两边各 1.5 度,就是 167km,加上横轴加常数 500km,最大为 667km;
6 度带是从中央向两边各 3 度,就是 334km,加上横轴加常数 500km,最大为 834km