什么是有独立开发能力的程序员？

这个是仁者见仁智者见智的事情，作为行业老人和经常讲这个话题的可以抛出一下个人看法。

一个人可以独立搞定中小规模项目的就是了。

这个搞定是要从需求概述，需求分析，原型设计，效果图，前后端数据库开发，部署上线全过程的能力，

注意强调的是这个快速搞定的能力，中间不是必须自己搞定，可以看自己的情况借助外力，但是如果没有外力自己也能沟通独立抗住整个的全部。

最早之前我都是一个人搞定，后来逐步交给下边的来处理了， *** 作和熟悉这个过程很重要，但不必追求事必躬亲，但是要有这个能力就足够了[赞]

独立开发能力，我的理解是从零开始，零架构零框架，除了winAPI外，不依赖任何第三方库，能够搭建一个比较大系统。少点依赖框架，你会发现你比别人更利害。全栈虽然比较难，需要比较长时间的磨练，但仍然可以做到。搞通几种之后，大体上都会差不多，就是语法格式上的区别。

事实证明，人的精力是有限的，不可能样样精通。就拿我来说，我非常喜欢折腾技术，嵌入式，单片机，JAVA，Linux，C语言，shell，Python，js，go，rust，前端框架angular，react，vue也能写个小Demo，Vim和emacs也是用得飞起。这时候做做小工具小网站还是够的。有些简单的想法能够快速做个Demo出来，但是再深入就感觉比较吃力了。

最好还是专注。像linus一生只用c语言，但是人家两周就能写出git。这种才是真牛逼。

当我们在聊技术能力的时候，我们到底在聊什么？

有的人认为：技术实力就是指算法和数据结构很厉害

有的人认为：研究过Linux内核源码和看懂《深入浅出MFC》的才是技术牛逼的人

有的人认为：会写C++的才是真正的技术高手，因为C++的对象初始化有N种写法

有的人认为：技术高手必须对业务很熟悉

有的人认为：贡献了开源项目代码的才是技术牛人

有的人认为：只有架构师才是技术大牛

相信一千个人眼中有一千个哈姆雷特，一千个程序员心中有一千个技术大牛！

对于程序员来说，技术范围包括服务器、android、iOS、前端，出色的完成每一个项目，稳定好自己的工作，不好高骛远，是作为一个优秀的员工当下所必须具备的，判断程序员技术实力的一个总的原则就是指解决问题的能力！

综上所述，我们对各种技术实力的理解大致以下几点：

1、技术实力就是指算法和数据结构很厉害

2、研究过Linux内核源码和看懂《深入浅出MFC》的才是技术牛逼的人

3、会写C++的才是真正的技术高手，因为C++的对象初始化有N种写法

4、架构师才是技术大牛

那作为一个程序员，一定是思维条理性、逻辑性，对新技术感兴趣，耐得住寂寞。同时具备独立开发能力的程序员，大体总结出了以下几点：

1、独立解决问题的能力

大多数程序员都是以“码农”自嘲，在工作中就根据需求复制粘贴代码，代码出现逻辑问题就抛给别人解决。那些能独立快速解决代码问题且稀缺的程序员，就会显得弥足珍贵。因此，培养独立自主快速解决问题的能力，能使自己成为团队中不可或缺的部分。

2、源码阅读能力

会用代码是一个方面，认识代码又是另一个方面。能阅读源码是独立解决问题的先决条件，只有熟知源码，才能很快的发现问题。另外，熟练的阅读源码能让自己做到举一反三，使自己编写的代码更加优化简洁，提高工作效率。

3、架构能力

架构能力是未来成长储备的进阶方向之一。随着年龄的增长，纯粹的技术能力已不适合自身的长远发展，也不适应公司组织架构的优化，面对更年轻、学习能力更强的程序员，做纯技术的你已不具备比他们优异的核心竞争力。因此，你需要储备一些技术大方向的知识，也就是这里说的架构能力。做一名架构师，搭建技术框架，除了需要同时掌握以上两种技能，还要学习更多的架构知识，例如，高并发、高可用、高性能、分布式、微服务等。

4、管理能力

管理能力是未来成长的另一个方向。当技术达到了一定的层面，技术已不足以支撑起你的核心竞争力的时候，这时的你可以考虑到管理层继续磨砺自己，带好团队也是体现自己价值的重要途径。当然，在此之前，你必须要储备相关的管理技能，例如，计划、组织、领导、控制能力，只有掌握这些要素才能在管理过程中高效的发挥其职能。

感谢邀请！

具有独立开发的能力的程序员顾名思义就是相当于全栈，像以前的老项目很多都是这样，后端程序员又当爹又当妈，既要自己写前端页面样式，又要编写后台核心代码。

但是个人经验来说，具有独立开发能力的程序员也分两种：

第一种就是都独立负责系统的某个模块或者某个功能的设计和开发；

第二种就牛逼了，相当于全栈，从需求分析，原型设计，数据库设计，到编码阶段，测试，部署，上线一条龙都会的。这种的一般都是具备3~5年以上经验的程序员。

一般来说，小公司需要的都是第二种，大公司则偏向于第一种。希望我的回答能够帮助到你，有什么不同意见欢迎下方评论留言。

两个意思：

一个是小企业，请一个人，做一个小系统，一个人能全部搞定，既懂美工，又懂架构，最后开发实现并上线；

一个是小团队，按功能分配工作，各自完成自己的工作，不能等待别人来指导才能往下走，这样的话就不具备独立开发能力了；

说白了，就是对技术的一种要求，能遇到问题自己想办法解决，而不是需要领导来帮助。

程序员挺多，但不是每一个人都能遇到问题自己就能解决掉，而要求独立，说的就是能自己解决问题的程序员。

反正不管那么多，努力学好技术才是真。

对于大多数运维程序员来说，时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。今天我们就通过案例分析来了解一下，运维程序员如何快速处理线上问题。

任何一旦掉进坑里，明智的做法一定是：跳坑_>填坑_>避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：

跳坑

‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到低。

线上服务的可用性决定着服务者的客户利益，影响着公司的收益。一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。为此，遇到生产故障后的一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到低。

填坑

‘填坑’——找到问题原因，根本上解决问题。

在恢复线上服务，尽大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。

避坑

‘避坑’——举一反三，消灭隐患。

找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点那些流程/规范/制度需要优化这类问题是否在其他系统或者团队中也存在通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。

线上故障处理的思路

依据线上故障处理的目标及目标的优先级，线上排障的一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。因此，可以将线上故障处理的步骤分为：

故障发现

故障定位

故障排除

故障回溯

其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。

上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。这个思路类似于 *** 作系统的fork/join设计思想，目的在于提高效率。

在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到低且可控。北京北大青鸟建议可以等到线上服务’撑’过去之后，我们再慢慢定位故障原因，根本上解决问题。

对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。

而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。

一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。

反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。

所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。

一、自动化运维的概念

随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工 *** 作为出发点的诉求被广泛研究和应用。

所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统724小时高效稳定运行 。这是所有业务系统运维的终极目标。

按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：

（1）依靠纯手工，重复地进行软件的部署与运维；

（2）通过编写脚本，方便地进行软件的部署与运维；

（3）借助第三方工具，高效地进行软件的部署与运维；

二、自动化运维需要解决的问题

自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。

三、自动化运维的常用工具

自动化运维常用的工具包括以下几种：

1、Ansible

ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

ansible具有如下一些特性：

(1)模块化：调用特定的模块，完成特殊的任务。

(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。

(3)支持自定义模块，可使用任何编程语言写模块。

(4)基于python语言实现。

(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。

(6)安全，基于OpenSSH

(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。

(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。

(9)较强大的多层解决方案role。

2、Chef

Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。

Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。

Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。

Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。

Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。

Knife 用于与ChefNodes进行交互。

Test Kitchen 用于验证Chef代码

Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。

Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。

Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。

Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。

3、Puppet

puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。

客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；

Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；

Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；

Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；

Puppet服务端再把客户端的执行结果写入日志。

4、Saltstack

SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。

在saltstack架构中服务器端叫Master，客户端叫Minion。

在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。

saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。

saltstack提供如下一些功能：

（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。

（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）

（3）云管理(cloud)：用于管理云主机

（4）事件驱动：被动执行，当达到某个值会自动触发

这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：

作为web程序员，一定会接触到Linux，所以常见的Linux的命令还是要掌握的；我就说说平时我常用的命令。

环境发布

程序包上传到服务器上之后，除了执行中间件停服务的命令之外，还有更暴力的方式：

ps-ef|grepjava/或者端口号，找打对应的进程号

kill-9进程号，其中-9就有点儿暴力了

copy拷贝文件/路径，把程序包拷贝到合适的目录下面

rm-rxxxx，把日志文件清除一下

nohupjava-jar

xxxjar

--serverport=8080&，启动一下服务

查看日志

服务有问题，最直接有效的方式就是查看日志了。

cd返回根目录；cdxxx进入目录；cd返回上级目录

tail-f：查看文件的最后几行，文件内容不断追加，就能不断地看到追加的内容

view：查看文件，如果要编辑的话，就是vi，记得强制退出esc-:q!

不过我还是比较喜欢把日志下载到本地看

其他常用命令

从一台机器跳到另外一台机器：ssh用户名@ip:port

查看服务器配置（配置给的低了，去找管硬件的人开撕）：

cat/proc/cpuinfo|grepprocessor|wc-l

cat/proc/meminfo

查看服务器的CPU、内存使用情况：top

查看硬盘剩余空间：df

能想起来的就这么多了，很多安装和配置的工作，在我们单位用不上，有专门的人负责。

希望我的回答，能够帮助到你！

您好，IDEA 的代码出现问题，可能涉及的原因非常多，比如语法错误、编译错误、运行时错误等等。对于无法重现的问题，估计常常就是出现了一些暂时性的情况，重启 IDE 或清除缓存等 *** 作可以解决问题。但是如果这种问题经常出现，而且没有明显的原因，我们需要对可能的因素进行排查。
可以尝试以下解决方法：
1 尝试重启 IDEA 进行代码检查和编译。
2 检查代码中是否存在语法错误、内存泄漏等问题。
3 检查代码是否与其他类或包中的代码产生冲突或不兼容。
4 检查本地环境是否出现了问题，如电脑 CPU 或内存的负荷等，也可能会影响 IDE 的运行。
5 更新 IDEA 到最新的版本。
如果这些方法不起作用，您还可以尝试在 IDEA 中使用 debug 模式，更好地跟踪应用程序在运行时发生了什么问题，并及时解决它们。

---