职场求生攻略
2022-03-09 09:26:50
程序猿必须知道的职场知识
举报
猜你喜欢
大纲/内容
软件系统架构师，要有自己的经验积累和独到的眼光，要能够很好地认识问题、对问题建模、解决问题。
不要把自己的视野局限在技术层面，而是要把视野扩展到从看到问题，到最终解决问题这么一个全过程。
软件系统架构师也必须持续不断地更新自己的技术库，维持甚至扩张自己的技术领地。这样才能够让自己做出适合当下甚至未来发展的架构，可以进一步可以减少系统集成的风险。
修炼内功，厚积薄发
搭建骨架，稳步前进
服务业务，不忘初心
从业务来，到业务去
保持数据警醒度
思路
技术总结
发生冲突的一个很大的原因，是有直接的利益冲突。比如谈地盘、谈系统归属、谈责任等等。这些情况是经理等管理者的主要战场，我们程序员打好辅助就可以，一般不需要主动露面谈。如果遇到这些相关的讨论找上自己，可以先简单应付，但是真正到了讨论核心问题的时候，一定要记得把自己的经理拉进来。
自己说了不算的事情，不要随便做出承诺
有些冲突，程序员要主动退到一边
以共识为基础，把事情往前推进
做事情的方式方法可以妥协
目标必须坚持
每个人都有自己的偏好，比如说，有人喜欢用 Lambda，有人喜欢用 for 循环，有人喜欢这样去命名方法和变量，有人喜欢另外一种风格。从我个人的建议来说，谁负责写 code谁就有权利决定用自己喜欢的风格写代码。只要功能可以完成，代码足够鲁棒，那外人就没权利多加干涉。毕竟我们不是流水线上的工人，不可能生产出一样的代码。
代码方面的个人偏好
接口的设计其实非常考验一个人的能力。它比具体的实现代码更抽象，但是比架构设计更具体，是连接两者的桥梁。
从参数的角度说开去，接口就是这样一个越包容，越优秀的东西。如何能用最少的约束，把事情描述清楚，就是接口的一大目的。面临接口设计的争论时，大家可以就这个点展开，各抒己见。最终得出结论，也不是难事儿。
接口的设计
系统架构上的争论，则更是因人而异。因为做系统架构的过程，其实是每个人对一件事情理解和建模的过程。
如果在软件架构上有冲突，应该怎么处理呢？软件架构结果的冲突只是表象。根源是大家对问题的理解，对系统如何应对问题的方式理解不同。这时候，如果只是纠结于架构的不同，是无法得出一个结论的。所以，为了解决冲突，应该大家都回退一步，先从问题入手，让大家对问题的理解能够统一，对解决问题的方式能够统一。这样，即使架构上有所不同，也是容易解决的。
系统架构
功能现在就要
找到大家的共识
1. 代码偏好：findbugs 等业内标准。
2. 接口设计：接口设计应该包容。
3. 系统架构：大家对问题的理解要统一。
4.新功能：理解新需求，升级架构，以支持新功能。
什么是包容、什么是对问题的理解、什么又是新功能的本质，越来越没有绝对的正确。每个人，在自己不同的阶段，都会有不同的理解，更不用说在不同的人之间。
目标
原则
方式方法可以妥协，原则和目标必须坚持
如何应对沟通中的冲突
首先是可以互相切磋，提升彼此的认识。正所谓不打不相识，很多时候大家的认识都不够全面，通过冲突的方式，可以让彼此都拓展自己的认识。
其次，要说出来可以逼迫自己深入思考。想和别人刚，自己得先把自己的想法理清楚。很多时候，自己的想法是想当然的，当这种想当然和别人发生冲突的时候，就需要自己深入思考，或者找出自己的理由，或者放弃自己的成见，接受别人的观点。无论是哪种，对自己来说都是成长。
最后，有疑感就说出来，可以让彼此合作更默契。我们经常说一个团队有默契，其实默契就是这样磨合出来的。不磨合，只是表面的迎合，并不能让—个团队里的成员配合无间。
冲突的价值
程序员不要一味地逃避冲突。如果用妥协来避免冲突，这绝对不能很好地解决问题。当然，我不是说要做一个“杠精”，而是要在做事情的基础上，充分表达自己的观点和认识。
如果自己明知道别人的做法有问题，但是你选择不表达自己的看法，长久下来，只会让别人觉得你没想法。和自己有关的东西，更要在自己不认同的时候发声。如果你只是一味地委屈自己，成全别人，其实只会让人觉得你软弱。
根据我的观察，这种冲突，往往都能够让事情得到更好的结果。如果一味地为了避免冲突而保持缄默，其实长期来看，是无法融入到一个团体的。当然，如果一个团体里经常就相同的事情冲突来冲突去，那很可能说明大家就是无法磨合得很好。在这种情况下，如果你不打算离开这个团体，在面对冲突的时候干万别打退堂鼓。
总结
沟通什么时候应该妥协，什么时候应该坚持？
今天的工作效率高吗？有没有什么事情让自己觉得没技术含量？你是不是可以避免这些没技术含量的事情？是不是可以让这些没技术含量的事情自动起来？
如果非要衡量的话，可以用代码完成的功能这个维度来简单衡量。很多时候我们加班，并不是完成了更多的工作，而是用更长的时间，去完成自己本应该用作时间就可以完成的工作。这就是效率低。
分析是否当前效率低下
提高效率升级系统，开发自动化的工具
不要习惯低效率工作，要发挥自己的才能
任务太多
至于线上问题，这个基本上是不能逃避的。我们能做的，就是防患于未然。比如增强监控，要监控的不仅仅是自己的系统，还有自己依赖的系统和依赖自己的系统。又比如尽量避免在周五上线，因为如果周五上线出了问题，就要加班去搞等等。
至于优先级高的项目，在我看来，更多的是一个机会。这些项目无论是新业务新方向，还是系统升级更新，都是一个让自己刷新技能、扩展眼界的机会。这时候阶段性地付出一些时间，对自己的职业生涯来说，是挺值得的。
出现紧急情况
首先，员工留公司里肯定会做更多的工作。即使你不想做和工作相关的事情，只要在公司里呆着，也难免会不自觉地做一些工作。
其次，是方便彼此协作。即使你自己本身不加班，如果别人加班需要你协助的话，可以直接找到你人，你也不好意思面对面地拒绝别人。
最后，就是公司文化等原因，公司愿意营造出这么一个大家都在努力奋斗的氛围。
首先自然是学习新技术。一个选择是把自己白天没时间弄清楚的技术整明白。不要放过程序中任何一个错误日志，不要放过工作中任何一个没想通的事情。然后就是看看哪些技术可以用在我们自己的系统上，放心大胆地试试看。毕竟这不是被安排的任务，不需要背负产出的压力。
学习和探索新技术
每个组、每个系统，肯定都有大家一直在抱怨的小事情。这些事情不做也可以，但是做了会让自己组的效率更高。这时候，可以选择自己有兴趣且力所能及的点，把痛点修正掉。一个系统既然有人抱怨，还在一直用它，那就说明这个系统解决了实际的业务问题，是有价值的，是值得做好的。
技术升级无法解决架构的问题。对于遗留系统，很多时候需要考虑的不是升级技术，而是升级架构。
不要止步于抱怨
强制加班一般在干什么
强制加班
程序员加班的现状，是由不同的原因造成的。我们能做的就是不断反思、好好利用加班，让加班的时间尽量短，让加班的时间尽量对自己的发展更有好处。
如果是效率低，那就尝试提高效率。如果是有紧急任务，那就好好做、好好学。紧急的事情，是公司层面优先级更高的事情，更值得我们花时间做好。而对于现在被大家诟病的强制加班，也不能浪费了自己的时间。毕竟时间是自己的，一旦浪费了，损失的其实还是你自己。
加班逃不过，如何用正确姿势加班？
一部分原因是焦虑惯了，这份焦虑感，让自己持续要学东西，跟上技术的发展。一段时间没学习没成长的话，就会感觉心里不安。一直这样焦虑着，渐渐就养成了持续学习新技术、持续扩建自己技术领地的职业习惯。
另一部分原因是，自己在误打误撞中，也算是走出了一条适合自己的成长之路。
如何应对焦虑感
任何职业都有很多从业者\b，很少有人脱引而出
任何职业都需要努力，选择不能代替努力
前期职业？后期职业
新兴行业缺人不缺钱
如果微软距离倒闭永远只有 18 个月
软件公司的危机感必须传递给员工，对员工有更高的要求
程序猿必须有创新的精神、有斗志，不安于现状的人
软件行业确实不同
技术简单，产出明确，工作流程可以规范化
产出成果过程复杂，人才无法批量培养，需要经验积累和发挥自己的主观能动性
不同类的职业
持续学习技术
持续思考业务
学习更多的资源，积累自己的经验
程序猿应该怎么做
程序员来说，提高自己才只是标配，超速地提高自己才是高配。长期来看，程序员的职业生涯，没有保持水准这个选项。
你要学会锻炼自己的工作能力，做好技术与业务问题之间的桥梁，用好公司给你的资源，成就自己的成长。
程序员怎样才能越干越给力？
数据是软件系统的根本，抓住数据就能找到根本
在软件构造的虚拟世界中，数据是唯一的真实存在。尤其是那些以数据处理为目的的软件系统，更是这样。软件系统的目的就是把数据写入库。所以很多程序员戏称自己是专业的CRUD，从这个层面来说，CRUD 才是根本。
程序重要？数据更重要
对于很多偏数据的系统，数据架构设计比软件的架构更重要。数据的架构包括系统中有哪些实体、实体有哪些属性、属性分别是什么类型、实体与实体之间有什么关系、数据如何联动等等。当然也包括采用哪种数据库、数据库怎么分库分表等等。如果采用的是 NoSQL数据库，则要考虑数据的访问模式、数据的可靠性、数据的可用性等等。当然两种数据库都要考虑如何应对数据的增长问题。
这里我们再强调一点。程序写得烂，比如跑得慢一点，设计得不好等等，这些问题很多时候并不麻烦，大都是稍微花点时间就能够修复，也不会造成什么损失。我们写程序的时候，尤其需要注意的是生成入库数据和写入数据的代码。在对这些程序代码进行更改的时候，更是要谨慎谨慎再谨慎。如果破坏了数据或者写入了脏数据就麻烦了。这点一定要注意，敬畏数据。
软件系统可以升级，数据很难升级
我们可以把数据理解为新时代的土地，是一切的根基。有了数据，干什么都可以。没有数据，再好的种子，也没有发芽的空间。种子和土地，当然都重要，但是两者的分量不在一个级别上。数据够多，随便什么算法模型都能得出不错的结果。但如果没数据，能做到的事情就会很受限。可以说，数据起的是决定性的作用，是基础，是土地，算法和模型是地上开花。
数据是新时代的土地
数据的升级和迁移，比软件的升级风险要打的多，对于系统的数据设计，需要更注意
数据被删掉啦，回损失惨重，程序代码远远没有数据重要，长期来看，数据最重要
数据是新时代的信息，很难买到，自己积累更要费时费力
做系统，数据比软件更重要
任何问题，先找出数据，罗列清楚，再去做自己的分析。准确、经过整理的数据是自带力量的。
很多时候，仅仅是列出直接的数据还不够。为了更全面地理解问题，还需要注明数据的出处，甚至需要从多个数据源来交叉验证数据。数据是我们用来做判断的依据，对数据的态度要仔细认真，否则后面基于数据的讨论、结论和方案，可能都会是错的。注明出处是对数据负责。很多时候，罗列的数据可能并不全面。注明出处，方便你可以根据出处去对数据进行更详细的检查。而且不同的数据源，数据的可靠性也不一样。可以说数据源本身，就是数据的一种。
注重数据的出处，方便从数据源中获得更多的数据
如果有可能，交叉验证，从不同角度来获取相同意义的数据，进行对比和验证
与人沟通，最好有数据证明
数据是有分量的，对数据的辗转腾挪，都要费很大的劲。数据是有力量的，当你把数据整理好罗列出来的时候，甚至都不用说明自己的观点，就可以不言自明，让人无法反驳。数据是最难获取的，真正有价值的数据，钱是买不来的，只能靠自己积累。数据是软件系统的目的，和现实中业务相关的软件系统，无论业务逻辑玩的多花，最后都是要生成相应的数据，落盘为安。
在你眼里，数据到底是什么？
对于软件工程师来说，一个事情可以用一天的时间做完，也可以用一个星期的时间精心打磨。如何在时间有限的情况下安排自己的时间，让时间用在最值得做的事情上，就是排优先级需要考虑的内容。
给不同的工作安排优先级，不仅会让我们的工作效率更好，也可以让我们和同事之间达成良好的合作关系。
手忙脚乱或者工作不得法，往往是因为优先级没安排好，时间和精力有限导致事情等待，或者对事情的质量要求不一样
优先级的重要性
每个公司都有自己的发展计划，并给这些计划划定不同的权重，以指导协调公司內有限的资源。
工作发展计划
安全部门的要求就是最高的要求，是一切需求的“挡箭牌〞。当一个安全部门给的任务到了你手上，告诉经理你要放下手中的工作，立刻开始执行安全任务吧。这既是为了公司，也是为了自己。
安全计划
在日常工作中，我们有很多任务都是经理下达的。经理往往掌握着更多的信息，也更能判断一件事情的优先级。现在一般都是敏捷开发，经理会给每个 story 排优先级。在给任务排优先级的事情上，程序员可以提建议，也可以和经理讨论，但是一定要以经理的决定为准。
经理安排的临时的急事
需要别人配合的事情
优先做阻塞别人的事情
基于合作安排优先级
第一时间优先处理生产问题，找出解决办法
生产计划
基于工作性质安排优先级
先沟通，后做事
先外后内
随时沟通
如何安排优先级
给工作排优先级，不仅仅是一个提升工作效率的方法，也是提升自我和磨合团队的重要方式。
给事情排优先级，是一种把事情做好做对、做成的重要能力
它不仅需要你对事情有准确的认识和判断，还需要你有清晰思维，能够将事情分解，按照最优的顺序执行。给工作安排优先级的过程，也是锻炼自己能力的过程。
如何安排任务优先级？
邮件的目的：邮件不是用来的沟通，而是用来甩锅的
1、异步交流：邮件是一种异步交流的方式，双方有足够的时间准备邮件内容。
2、无法修改：邮件内容无法修改，这是邮件可靠的基石。
3、方便扩散：邮件有邮件组，可以很方便地把相关人员加进来，并且保留邮件历史记录。
邮件的特性
邮件的确认
邮件的证据
邮件的沟通和协作
邮件的防遗忘
邮件的通知
邮件的作用
化语言，为责任
化责任，为动力
邮件的魅力
1、定期查看邮件
2、仔细研究邮件的发送人，善于使用老板抄送
3、多检查一下邮件内容和标题
4、及时更新用户组，避免少发、漏发
5、发送会议纪要
邮件技巧
邮件是可以一来可以避免工作沟通带来的问题，二来也可以帮助自己梳理工作任务。
邮件对于沟通那么重要？
和人交流一般需要约好时间，到了时间不得不放下手头的工作。有时候也会有人主动过来，随便聊点东西。无论是哪种形式，其实都会打断程序员当前的工作。
1、工作的时候被打断，严重影响工作效率
2、交流不能帮助工作的直接完成
程序员其实只是交流中的“利益受损者〞，我们排斥的不是交流本身，而是厌烦交流中时间的“浪费〞。
3、程序猿在交流中只是利益受损者，从交流完成后才是程序猿开始工作
程序猿不喜欢交流的原因
在做事情的时候，优秀的交流能力是必须的。如果你能够展示自己在交流能力上的优势，组内外的同事也更愿意和你合作，经理也会优先考虑让你承担更多的责任，对自己的发展有很大的好处。
正视和各种类型人的交流，拒绝无效交流
如何爱上沟通
时刻保证自己获取信息的沟通，如果可以，交流的时候可以多主动思考，平时多交流多思考，就能抓住关键机会，抓住突破点
要创新，要整合资源。其实要想做到这一点，在一个公司里实现成长，就要时刻保持自己获取信息。如果能够重视平时的交流，交流的时候多主动思考，慢慢地，自己收获的关于公司和行业的信息也就越来越多，没准还就能够找到新的突破点，抓住新的机会。
输入
自己的想法，自己的工作成果，都应该积极主动地向外界输出。输出不一定是什么长篇大论，可以是简单的交流、发邮件、写文档、做工作成果演示等等。通过输出，我们才能慢慢赢得自己的声誉，树立自己的影响力。
输出
沟通的好处
交流不一定要是非常正视的形式。我们可以闲聊，趁着吃饭或者散步的时间，主动和组内同事，和自己的经理，和自己上下游的关键联系人交流自己的想法以及正在自己做的事情，然后也从对方那里获取相应的信息。
不要让自己做一个小透明，做的事情要让别人知道。同时，也知道别人在做什么，别人遇到了什么问题。别人的问题，就是你潜在的机会。
养成主动交流的习惯
其实人和人之间交流最重要的一点就是换位思考。站在对方的角度理解自己表述的内容，看看能否被正确地接纳和吸收。程序员是一种专业性很强的工种。很多专业技能相关的内容，可能会让非专业人士摸不着头脑。大到一个公司，一个部门，小到一个组，一个项目，都可能有很多专有名词，专用词汇，需要很强的背景知识。
简单来说，既要让对方听明白，也要让对方听到自己应该听的。交流不是应付差事，说完拉倒，也不要只顾自己说。
换位思考，注意受众
用数据说话，数据出处要清晰；推理条理要清晰，事情的来龙去脉要清晰。有时候写重要的邮件和文档，就像写论文一样。
交流是要带有足够的信息
这一条规则适用于所有场合。日常中普通的交流也是，如果带着明确的目的，那么就要先说出自己的结论和想法；如果是写邮件和文档，内容翔实的一个副作用是难免冗长。这时候应该注意，先把结论抛出来，再写细节。如果是 PPT 类的演讲，也是先抛出结论和成果，再去涉及详细的内容。
开会或者交流之前先说重点或者结论
交流小技巧
1、获取更多的信息
2、理解公司的业务
3、加深对行业的理解
4、发现新的机会
主动交流的输入好处
1、赢得自己的声誉
2、树立自己的影响力
3、赢得同事和经理的信任，承担更大的责任
交流中输出的好处
沟通为什么那么重要？
很多时候，只要我们勤勤恳恳，认真负责地做好老大交代的任务，就算是一个合格甚至优秀的员工了。但是程序员这份工作，如果只是做到这一点，最多算是合格。由于软件开发的特殊性，一个任务完成的界限是非常模糊的，而且会根据具体的情况而变化。那么这时候，就要求程序员发挥自己的主观能动性，才能把事情做成，能够交付，而不仅仅字面意义上的“完成工作〞。
现状
站在用户的角度，交付用户想要的东西。也就是说，不能止步于用户的需求。
发挥主观能动性，究其核心，我觉得就是一点：站在用户的角度，交付用户想要的东西。也就是说，不能止步于用户的需求。程序员作为冲在第一线的人，对细节的掌握是最多的。我们需要依靠这些细节，结合用户的需求，理解用户需求背后真正想要的东西，然后努力向这个目标发展。
交付思维
发挥主观能动性的一个代价，就是会用掉更多的时间。这方面一定要注意。比起功能的完美，在规定的时间内实现基本功能，才是优先级更高的事情。
假如你突然对一件事情有了想法，但是时间来不及，或者不确定是不是对用户有价值，那么可以及时和用户交流。如果用户觉得这个细节确实很重要，即使延期也值得做，那么大家可以商量新的时间线。如果用户觉得可有可无，或者可以放在后续迭代来做，那么就专心做好需求里描述好的功能
注意时间
如何发挥主观能动性
软件研发的复杂需求，导致没有标准可以参考，也可能很多事情导致在设计最初无法预料
做完不等于做好，能用不等于好用
现代技术快速迭代，导致需求和需要应对的问题也在随时变化，程序猿不能固守之前的设计
为什么要发挥主观能动性
为什么程序员，需要发挥主观能动性？
首先，程序员要对自己的基本能力负责，基本能力主要是技术能力和熟悉公司系统的能力。
工作中运用到的技术和预先学习的技术
自己的课余时间来学习其他技术
持续精进技术能力
熟悉公司的内部系统
对自己的基本能力负责
程序员这门职业的特殊性在于，工作本身的具体内容和难度，会随着被安排的工作内容的改变而改变。从对工作负责的角度来说，我们大部分人会付出比当时预想的更多的时间，才让自己能够按时完成工作。
尽自己的能力完成工作
发现自己无法完成时，要尽早的告诉经理
从管理者的角度来看，一个事情安排得不合理，就应该早发现，早计划，重新安排资源。毕竟大家的目的是把事情做完，而不是冒着事情可能做不完的风险去压榨一个人。
对安排的工作负责
解决问题时要在线
准时参加会议
对时间负责的背后，其实不止是为了保证工作时间。毕竟我们程序员都知道，坐在座位上并不代表就在工作，没在座位上也不代表没有在工作。这里想强调的一点是，程序员的工作不只是写代码，还有很大一部分是交流沟通，保证基本的工作时间，才能更多的和大家交流。
对工作时间负责
责任是一点点增加的，负责任的态度和习惯，也是从平时工作中的一件件事情中养成的。当你养成这样一种习惯之后，你会收获一个别人对你的金字评价：这个人，负责，靠谱。
程序员的职责范围仅仅只是被安排的任务吗？
职业素养
文化和价值观不是虚头巴佬的东西
如何选择适合自己的企业文化和价值观
企业文化和价值观
下降期的行业
风口期的行业
黄金发展期的行业
行业势头
基本工资最受法律保护
奖金
股票
期权
工资待遇
大厂
中厂
小厂
外包
公司规模
决定公司对人才的态度
决定公司内部管理和合作的风格
人才水平
如何选择一个公司
下属和领导，某种程度上来说是互相成就的，你们认可彼此的价值观和人格，也可以就一个问题互相讨论，甚至争论，他还会和你定期沟通，合理地安排资源和利益。
如果无法认同领导的价值观和人格，那迟早辞职或者走
跟着自己佩服的人、欣赏的人、认同的人工作
一个负责任的经理还或多或少有这几个品质：优秀、真诚、公平。在你眼里，一个比你优秀，对你真诚，处事也公平的经理毫无疑问会潜移默化地影响你。
认同彼此的价值观和人格
一对一会议
表扬做的好的事情
指出不好的地方，并进行沟通，提出修改方案
给出下一个发展的建议
定期和员工交流
发生主观能动性的前提
能够得到更好、更完整的结论
有能力引导讨论，指出讨论的方向。
可以互相争论和讨论
给手下的人新的机会
给手下的人发展时间
争取分配，和平分配
资源的利用和分配
管理者关系
是自己问题还是别人的问题
换工作之前与别人交谈，询问自己的问题（找出自己的原因，然后改变自己的心态，然后在跳槽）
换公司无法解决自身问题
心态
新行业、新方向
自己的兴趣方向
主动求变
公司文化
工作压力
发展方向
是否可持续发展
公司稳定性
不要让薪资成为跳槽的唯一原因
稳定+合理
薪资待遇
为什么想跳槽
公司不愿意聘用频繁跳槽的人
如果你觉得现在做的事情有价值，公司和行业也发展得不错，自己有成长，公司也愿意支持你的方向，给你资源发展，不要轻易被外界的 offer 诱惑。因为长期来看，只要公司在发展和成长，一个人在一个公司的积累和成长，大概率会给你带来稳定的长期收益。
从长期来看，一个公司的积累和成长是最宝贵的
内部转岗
为什么不应该跳槽
升职加薪是好事，但是自己的成长和长期稳定增长的收入才是金不换。换工作之前，更要平衡好自己的生活和发展，要想清楚哪个选择是短期利益下的诱惑，哪个才能带来长期利益下的发展。
跳槽
面试是和面试官合作，展示自己的优势和优秀之处。这样经过对比之后，面试官才能择优录用。
面试是什么？
解决的问题
自己的成长和能力
简历两页以内
精简的工作经历
经历倒序
突出重点，突出自己的优势
简历排版公正，给人一种大方的体验
写简历
针对公司，进行特定的准备
cs 基础
刷算法和数据结构
内推
应届生
为什么换工作
毕业一两年内
弄清自己的优势
突出工作成果
梳理自己的技术
建议内推
工作经历丰富
准备面试
不要勉强
注意反馈、交流通常，表达清晰
主动交流突出自己的优势
不推荐靠面经面试
面试准时到，不和面试官较劲
面试中需要注意什么
面试是公司择优录用的一个过程，因此从一开始，我们就要精心准备，从简历，面试准备，到面试发挥，每个步骤都需要用心。在这个过程中，最重要的，就是自己的积累和成长，毕竟面试靠的就是厚积薄发。
面试最重要的一点是，要真诚，绝大部分的公司对面试中的作假行为都是零容忍的。对于自己的经历，要坦诚地和公司描述清楚。即便之前工作的经历不好，但坦诚的态度也会让人相信你有改进的决心。
面试
结论：一个程序员，如果想长期从事这个行业，那么外包不值得做太多年。
难以获得完整地解决问题的能力
外包公司不注重人才的技术成长，涨薪受限
学习新的技术需要时间，外包公司项目很紧，基本上不愿意花时间让员工学技术
员工学习新技术，可能会造成人员的流失
外包公司没有探索的环境
可替代性强，可能无法完整参与一整个项目
外包的局限性
通过外包快速积攒经验
希望进入一个新的行业
为了眼前的生活
什么情况下可以考虑外包
程序员的工作就只是写程序；程序员只有转管理才有前途。
只要感到自己又成长，有收获，那么就值得的
同事和环境不同
和甲方的关系不同
外包公司的介入是在甲方完成了前期需求分析和设计之后。
外派一般会参与项目开发的大部分或者整个过程
做的事情不同
外包和外派的不同
外派做了甲方来不及的事情，或者低技术含量的事情
外派到底是做什么？
外派人员不享受甲方的福利待遇
工作于此，不属于此
独立承担任务是对人才的培养和锻炼，公司更愿意把这种机会留给正式员工，让正式员工在公司里有更多的积淀。
没有机会独立承担任务
不稳定，终止派遣合同的代价远远低于终止劳动合同的代价
外派人员实际从事的工作，大都是非核心的，得到的锻炼有限
发展受限，不会有甲方的培养机会
外派不足
外派成熟的大公司，多琢磨琢磨这些系统面对的问题，以及这些系统如何去解决这些问题，对于以后自己的发展是非常珍贵的经验。
增长见识
和外包比，可以完整的参与项目
优秀的人也总能赢得更多人的认可。在人才密集度高的公司工作，对建立高质量的人脉关系也是非常有帮助的。
证明自己的能力，赢得更多的机会
薪资比较高
外派的好处
无论是正式员工还是外派员工，只要你的工作能力够强，都可以赢得大家的认可，获得相应的回报。
外派公司也不值得长期呆
外派
管理岗：不要给管理套上太多虚无缥缈的光环，也不要对管理这份工作抱有太多不切实际的幻想。
转管理的不同：管理岗要通过手下实现更多的价值，来突出自己的价值
从 ic 视角转换到管理视角，发挥团队的最大战斗力
管理绩效，合理鼓励
对内
要组织协调各种资源，在有限的人和有限的预算内，把事情安排到内外各方都能接受甚至满意。
组织协调各种资源
要给出未来的人员计划和安排，计划未来一年可能需要的预算（包括人、机器、软件等），这些资源分别用来做什么。
计划和安排，争取资源
进行各种交流，做出承诺和决策
对外
理解公司的发展方向
培养人才、发展团队
获取客户，赢得认可
对未来
一线经理
工作内容是要跟人打交道，搞定人和人的关系，搞定关系背后的各种利益，
喜欢与人打交道
能够紧紧盯住公司和部门的发展方向，同时为自己的队伍制定适合公司和部门的发展方向。
经理一定是有干劲儿，打心底里要做事情的人。
会经营、有干劲、有眼光
各种千头万绪的事情都会涌来，各种信息都要消化吸收，各种决策都等着你做，对外有交付，对内要有交代。
能够承受压力
有远大的抱负
什么样的人适合做管理
管理的临界级别确实比个人刚高一两个级别
无论是转管理，临界级别在哪里，都有成长瓶颈
程序猿都有专攻的方向，比如业务，比如架构
无论是否转管理，越成长，越需要交流，获取信息，整合信息，提取信息
转不转管理？
转管理
做项目的变现的公司不是创业公司
小公司不一定是创业公司
创造新事物的公司才是创业公司
什么是创业公司
提前算好收支的帐
选择公司还是选择团队
认可创业人
亲兄弟明算帐
准备好强大的抗压能力
能够持续跟上公司的发展
考虑加入创业公司的事情
创业是hell难度，工作Normal难度
其实创业也是一种心态，如果普通工作中以创业的心态来做事情，可以获得更多的收获
即使创业失败啦，也是一种难得的收获
创业vs普通工作
创业公司
职场选择篇
1、在不同的公司的价值观下，每个人适应公司环境的时间不一样
一对一会议运用得当，可以解决很多问题。会议会提供一个私密的环境，让人敞开心扉地交流，拉近人和人之间的关系。在一对一会议时，生硬的上下级关系会变得温和，因为彼此之间，不再是纯粹的工作关系，更像是朋友在一块探讨事业与人生。
2、如果沟通不是搞笑吗，试一试一对一沟通
行情可以和同学朋友聊，没必要非自己跑一趟。
面试需要充分的准备，如果不是抱着我要换工作的决心，很难准备得很好。如果状态不好，那么面下来也可能拿不到自己应该达到的水平所对应的 offer。
面试之前表明自己的来意，否则会被拉黑
3、定期面试没必要
第一：选择比努力更重要
第二：如果不想被淘汰，必须不断成长
职场素养和选择篇总结
当前的工作做得好，只能说明自己能力对得上当前的级别。当前的工作越做越好，加薪的几率越大。
那就是先能做到下一级别的事情，才会升职到下一个级别。简单来说，你要先证明自己具备下个级别的能力，才能升职到下个级别。而不是去指望公司先给你升职，再自己努力达到下一个级别的要求。
升职的决定权掌握在公司和经理手里，那么公司和经理自然想让升职这件事情的主动权掌握在自己手里，而不是你手里。
大多数时候，很多公司对于那些无法证明自己能力的老员工，不会给他们升职，而是宁可招聘新的更高级别的员工。因为员工如果表现没有到下一个级别，给他们升职就会是一个错误的示范。会让更多的人觉得混着就应该得到升职。公司可不想让员工有这种念头。
先做到，再升职
稳定发挥意味着你能够在连续的几件事情上，都发挥出下一个级别的能力，达到下一个级别的水准。
级别越高，对稳定输出的要求也越高。这里稳定输出的内容，也可能不仅限于具体的某个工作。
稳定的输出工作成果，而不是时而不好时而好
建议你不要沉迷于只靠绝活。工作中用到的技术，你一定都要学会，就算是硬着头皮学，也得让自己能达到可以独立完成工作的程度。毕竟公司雇佣一个员工，是为了让员工完成工作，不是来技惊四座的。
技术上不仅要有绝活，还要全面掌握技术
资历老的同事通常有更多公司相关的经验积累，比如熟悉各种明坑案渠，各种系统怎么用，哪个同事对某个系统最精通等等。升职资历老的同事，一方面是对这种软能力和技能的认可，同时也是对资历的认可。
资历老的同事也认识很多人
资历是升职必须考虑的原因之一，也是对老员工的软能力和技术的一种认可
升职的逻辑
能够完成具体功能的代码，保证代码质量。
具备阅读代码的能力。
开始理解和掌握基本的设计模式。
不再闷头就开始写代码，而是开始在 class 和 package 层级，思考和实践高内聚、低耦合的代码。
建立自己学习技术的体系，培养学习技术的习惯。
写代码
接到需求，能够快读准确的给出可行性，难点，系统集成点，给出设计和工作量估计。可以将一个系统的设计划分为高内聚，低耦合的模块，并给出工作量估计。
补全自己计算机底层知识的短板。有一个自己是在做系统设计而不是瞎做系统设计的底气。
锻炼自己快速掌握一门技术的能力，包括技术的总体设计，优缺点，使用场景等。
熟练掌握这个系统，能够快速排错。
能主导搞定系统里的一个项目。带领低级别的同事做项目，自己能发挥主导作用。
稳稳的搞定一个系统，清楚了解系统的各个方面、各种功能和边界
逐渐掌握系统的全貌，设计新的功能时，可以通篇考虑。
可以对系统进行重构和升级，解决系统的技术债。
开始积淀起自己在相关领域的业务知识，理解领域中的难点，易出错的点和痛点。
可以顺畅地和上下游相关同事沟通交流，并开始培养自己的影响力。
了解系统所解决的问题领域，可以让系统发展更高的层面
程序猿的三个阶段
符合升职逻辑
和经理彼此不对的人
离职概率高的人
升职经理视角
程序员为什么升职？
人少总是小而美
人多就会有“江湖”
为什么我说一定会有职场政治？
随着公司的发展，内部外部环境的变化，公司改组是难免的。公司通过重新划分地盘，打破老的利益格局，重新规定各自的权利和责任。改组搞得对了，可以激发组织的活力，可以让做事情更顺畅自然。
我之前面对重组，只关心两件事，一是我的工作还有吗？二是我换老板了吗？最多再关心一下我老板换老板了没。现在我更愿意去理解这次改组的目的，想要解决的问题是什么。进而我能去理解，这次重组给自己所在的组带走了哪些老的负担，带来了哪些新的责任，又伴随着哪些新的机会。
改组？
一般公司里的那些职场政治
我觉得首先要做的，就是尊重职场政治。职场政治远不止我这里列出来的这些正能量的事情，也有很多算计，可能看上去并不那么让人舒服。但是，从屁股决定脑袋的角度来说，我们还是要尊重自己组织作出的各种决策，尽自己的力量去支持。你要知道，每一份工作背后的一系列利益逻辑都是各路老大搞定的。你不要动不动就想着，此处不留爷，自有留爷处。你这样想的话，到哪都没有你的工作。
尊重职场政治
一个公司，往大了说，大家是一个整体。往小了说，大家是一个个利益小团体。我们作为程序员，要懂得自己所在的组织的利益所在，不要做违背组织利益的事情。当然，这里也并不是鼓励大家去花太多的时间，思考职场政治。毕竟我们是干活的人，不是搞职场政治的人。大部分情况下，你只要配合经理做好自己的工作就好了。同时呢，我们还要能理解和自己合作的各个组，以及各个部门的利益所在。这样在大家合作的时候，能够泾渭分明。不要打破大家合作的约定和默契。
懂得组织的利益所在
面对职场政治，程序员应该做什么？
职场政治和我有什么关系？
因为程序员是一种既需要经济利益刺激，又需要荣誉感的工作。看着自己做的系统跑起来，服务千千万万的用户，这种感觉是程序员特别重要的一个追求。
这就是发挥一对一会议作用的时候了。在一对一会议上，我们可以把自己关心的各个点都和经理聊一聊。比如公司的发展方向、自己以后的发展路径如何与公司的发展路径切合、公司是否有资源安排跟大家做这种方向的转换，比如安排培训等等。对未来的方向清楚了，对变化的原因理解了，自然自己心里的疙瘩也就容易解开了。
程序员如何应对变化，重整旗鼓
首先，我们要意识到，没有完美的改变。我们程序员不能抓住新技术的缺陷，就将新东西一巴掌拍死
如果有一种完美的变化，那这种变化大概率会自然而然地发生，不会遇到太大的阻力。而需要自上而下推动的变化，都是会涉及利益再分配的。改变很少会是完美的，新的方案也很少能完胜老的方案。每一种变化的背后，都伴随着新的问题。
从责任上来说，作出决策的是老大们。我们程序员负责的是执行。我们改变不了我们老大已经做完的决定，但我们可以调整我们的心态，不要去抵触新技术，要看到新技术带来的新可能性。
1. 改变都是取舍的艺术
随着技术的发展，很多专业技能会被淘汰，甚至很多工种都会被淘汰。这时候，我们程序员一定要看清趋势，做好准备。
2. 看清趋势，做好准备
虽然决策是老大做出的，但是作为一个程序员，自然对事情也有自己的看法。如果你觉得老大搞的这个事情不靠谱，那么不妨退一步海阔天空，换个组或者换个部门。这也是一种积极应对。
当然，你可以觉得不靠谱，并且继续在现在的组工作。但是这时候就一定要积极地履行自己的责任，尽全力完成自己的工作。没准你做着做着，就觉得这件事情靠谱了。最危险的是自己觉得不靠谱，行动上也不积极，在老大看来就是尸位素餐，消极应对。这样即使你的判断是正确的，这件事情最后确实是不靠谱，搞不成。但是真的论起责任来，没准你就会因为工作态度有问题，变成背锅侠。所以说，程序员面对这种事情的时候，越是觉得不靠谱，越是要积极应对，努力工作，让自己的表现找不到瑕疵。要不然，就明哲保身，退到一边。
3. 或进或退，积极应对
程序员应该如何应对
从我们程序员的角度来说，有时候这种变化可以推着我们朝着更代表发展趋势的方向前进，有些时候不靠谱的变化又有可能让自己白费劲。所以我们还是回到利益这个点来看问题。老大作出决定，背负这个决定的责任。我们作为程序员，也要果断作出自己的决定，是全力以赴，还是明哲保身。
面对公司自上而下的技术更新，我该怎么办？
我们在日常的工作中，和同事的互相交流必不可少。一方面，我们要大胆主动地和同事多多沟通交流。另一方面我们也要意识到，沟通也是有技巧的，如果沟通不得要领，会降低沟通的效率、浪费大家的时间、甚至可能会引起别人的反感。
所谓的输出式沟通，就是把自己知识输出给别的同事。这里说的不是分享会这种集中式的输出，而是通过简单随意的沟通来进行的输出。这种沟通方式，非常考验技巧和方式。毕竟弄不好就会让人觉得你是在臭显摆。
尊重是被输出人的自我意愿
首先，同事并没有打断你工作的过程，而是在你已经暂停工作的时候，通过闲聊的方式分享了自己的经验。其次，同事把解决问题的主动权交给了你，你可以选择自己去试试看，也可以在自己搞不定的时候，选择去向这个同事请教。因为同事既然主动跟你说了这个话，自然表示他是愿意就这个事情提供帮助的。
不要打断解决问题的过程
是在帮助自己，而非显摆自己
输出式沟通
首先，大家是同事关系，不是师徒关系或者师生关系。所以从责任上来讲，我们周围的同事，是没有责任帮助我们，回答我们的问题的。当然，日常同事们会互帮互助。但是上面的道理是不变的。我们不能把别人的帮忙想成理所当然。不能认为这个事情我不会，那么你会你就应该教我，教到我会为止。这里是公司，不是学校。虽然大家一般都会友善地回答同事提出的问题，但是如果问的问题不对，不但很难得到想要的答案，还可能会慢慢地成为同事们拒绝帮助的对象。
没有人有义务帮助你，所以请尊重别人的时间和精力
问问题的本质，不是让别人帮你解决问题，而是要学会自己解决问题。如果问题解决了，自己还是一脸茫然，下次遇到类似或者相关的问题，还是不会，那么你就不是在问问题，你是在让别人帮你来做你自己的工作。
自己的能够解决问题就不要麻烦别人
探索式问题更受人欢迎
请教式沟通
首先要重点说一下的是，千万不要相同的问题问了一遍又一遍。这不叫问问题，这叫把别人当工具人使唤。如果问别人问题，别人也愿意回答，那就一次性问清楚问明白，然后自己好好总结，牢牢记住。一遍遍地问相同或相似的问题，是对别人的不尊重。
不要一遍遍地问相同或相似的问题，是对别人的不尊重。
然后是积极总结归纳。如果你向别人请教问题，收获了很多，那么不妨总结出一个文档发出来。这样一方面，归纳的过程能加深巩固你自己收获的知识，另一方面你整理出的文档可以帮助更多的人解决问题。这样做也能表达对帮你一把的同事的尊重。
请教后积极总结归纳，如果收获很多，可以书写总结文档
最后一点就是，如果你确实是个超级大萌新，什么都不懂，每天不得不到处请教同事各种问题，那么不妨和经理反映一下自己的实际情况，让经理指派人来帮你完成工作热身。毕竟大家都很忙，对于每天都要完成自己的工作的同事们，很难说能够挤出足够的时间来帮助你。
需要大量帮助时，向经理申请专门帮助自己的人
请教式沟通技巧
先准备好数据，做到言之有物
汇报工作时，先交代两个重点：成果和问题。工作成果是指那些已经落实了的成果，没落实的、没实际验证的不要想当然地乱说。问题是指现在遇到的感觉需要经理帮忙协调的，以及需要经理调动资源解决的事情。至于自己就能解决的问题，不需要说太多
汇报成果时，先汇报成果和问题
然后是申请资源。这时候，要整理清楚前因后果，你要想明白申请了资源能做到哪些事情、申请不到又会影响哪些事情、为什么资源不是要得更多或者更少。简言之，就是要证明这个资源用得值。
申请资源时，说清楚前因后果
最后是请求帮忙做决策。自己不能做决定的事情，就需要经理帮忙了。这种情况很多，比如遇到了新的情况，或者遇到需要对外部作出承诺的事情等等，所有自己吃不准的，不知道如何处理的，都可以找经理帮忙做决策。
当然，我们找经理做决策，不是去把包袱扔给经理，而是和经理一块协调解决问题。所以在找经理之前，我们也要整理好足够多的信息才行。
请求帮忙做决策。自己不能做决定的事情，要带着足够的信息来，不要只带着问题来。
向上沟通
沟通技巧：如何跟自己的同事请教问题？
多说、多沟通、多露面，加强沟通能力
会表现还包含和经理沟通顺畅，想经理所想，急经理所急，尽自己最大的努力来帮助经理。
多做分享，不管有没有人看
多画图也是一个锻炼自己表达能力的方式
体系化思考，总结的能力，形成自己的方法论。
要有自己落地的 action，有 case 支撑。
技术和业务两头抓
是要养成分享的习惯，锻炼自己做分享的能力。没有人听不重要，自己的能力得到锻炼了，随着自己的成长和做的事情越来越有料，以后不会缺少听众的。
简单来说，就是要能突出自己的成绩，要好好准备自己的晋升。这点也很重要，程序员不要抹不开面子。事情做都做了，好好拿出来说说，展示一下自己的成绩，没什么不可以的。升职是自己的事情，自己肯定要多操心。其实有时候，经理真的不一定能记住你一年到头做了哪些事情，所以，务必记得自己做出的成绩，而且要想办法如实突出自己的成绩。
技术人的总结
说话之前先思考再说话，要不然可能就失败的沟通
沟通总结
职场情商篇
一个人处在舒适区，就是可以轻松愉快地应对应自己的工作，闭着眼睛都能把工作完成。
学习区，就是工作有一点挑战，需要学点东西，但是也不需要费什么劲儿。
恐慌区，就是看啥啥不懂，干啥啥不会，满满的压力，完全无法进行工作。
平时我们谈论所处的工作状态的时候，都喜欢用舒适区、学习区、恐慌区这三个词来形容。
程序员这个职业不同。程序员所在的软件行业是一个高速发展的行业，如果要把技术当做安身立命的本事，那么程序员就必须要一直学习知识，才能保证自己不被淘汰。
急速发展的软件行业，尤其是互联网行业，是一个不进则退的行业。业务量和业务的复杂度都在增长，留给开发的时间则是越来越短。为了满足这一切，技术的更新换代，甚至技术方向的完全改变，都是不可避免的。
技术要么发展、要么淘汰
其实从利益的角度来讲，我们程序员也不应该呆在所谓的舒适区。一个客观事实是，软件行业的技术在飞速地发展，也就是说，程序员现有的技术知识存量，会一直贬值缩水。
学到手的技术会被一直贬值，不学习，就会跟着技术一直被贬职
为什么程序猿必须学习
程序员的生涯中，只有一直学习才是最舒适的状态。这里说的舒适当然不是指轻松随意，而是通过不断的学习，让自己可以轻松地应对工作，知道自己能够一直学得会、跟得上最新的技术。而自己的这种状态，可以带来发自内心的自信。这种技术自信，就是让自己舒适的根本。
在工作中寻找能提供正反馈的学习目标，工作中有相当一比例来学习
关注行业发展，随时了解行业动态，了解新技术的情况，但是不深入学习新技术
没事儿不找事儿，就是当遇到对你没太大帮助的技术，不去投入大把精力学它。只去简单了解这个技术的大概，细枝末节不去深究，只要知道它解决的问题是什么就可以了。
深入学习新技术时，搭建技术骨架，用新技术点缀自己的技术骨架
程序猿的舒适状态
核心架构设计：这些技术有哪些核心架构设计
功能模型：这个技术有哪些功能，功能的接口是什么。
状态模型：系统在运行时有哪些状态，状态之间的变化原因是什么。
数据模型：这个技术是怎么组织数据的，是怎么处理数据的。
线程模型：这个技术有哪些线程，分别是做什么的。
技术骨架的构成
学习观：程序员如何定义自己的技术舒适区？
软件工程师就是用技术把事情做成
需要做到只要面对 Java 的问题，你都不觉得难
熟练使用技术解决问题，深谙技术的各种坑
1. 熟练使用
知道 Java 和 Java 生态的长处与短处。看到一个需求，直觉判断出可行性，难点以及可能出问题的地方。
明晰技术的能力边界，准确判断技术能否以及如何满足某个具体的业务场景
2. 精准掌控
以JVM 为分割线，熟悉其上的类加载器、字节码、内存分配和内存模型这些 Java 生态的基石。这样做一方面是为了你能够进一步精准掌握 Java。另一方面，Java 作为一个设计优秀的语言，在设计自己的 DSL 的时候很多地方是值得参考的。
知道技术的底层实现和关键细节，如果让自己做，可以大致做出一个来。
3.知根知底
第一，吃透技术。你在工作中，用到的技术必须吃透
多和用户以及业务方交流，理解他们的需求，才能更好地施展技术。而不能本未倒置，自己想做成什么样，就做成什么样。业务方不理解，那是他们 low；用户不会用，那是他们笨。如果抱着这种态度，那么用再好的技术也做不成事情。
刚开始你和业务方以及用户交流的时候，会有鸡同鸭讲的感觉，但是请相信，随着交流的深入，观点的碰撞，作为程序员的我们，会更能够理解自己所做事情的价值，也更能够选择正确的技术和解决方案。
做技术一定要懂业务，也就是要理解我们要解决的问题。你一定要懂得，怎么用技术为业务创造价值，而不是给业务添乱。
技术的目的满足需求
技术的价值是支撑业务
技术要解决用户的问题，而不是证明技术多高明
第二，需求至上。技术对你来说只是满足业务和用户需求的手段
做程序员，技术观为何如此重要？
当我们换一个工作或者方向的时候，都是从小白开始，这时候的我们生产力很低，甚至为负。我们一定要意识到并且承认这一点，积极主动学习、补齐短板，至少做到合格。那么成为小稳，指日可待。
技术不扎实，不思进取
身为软件工程师，我们拿这份工资，就是要解决这些问题的，而不是去一味地抱怨。软件工程师就是要在现有的条件下，结合自己的技术，解决问题，把事情办成，让项目落地。当然，并不是所有问题都能靠软件工程师解决，但是能解决到什么程度，就很考验一个软件工程师的功力了。
先证明自己的价值，再提出各种要求和条件
技术洁癖，满眼问题
技术存在的目的就是解决问题，其他的都不重要
这个观点的意思其实很明确，就是当你在工作中使用一项技术，要用保守的态度，要以投入产出比做衡量，而不是根据自己对技术的偏好和冲动乱来。
有些技术不错的年轻人，就是因为做事情的态度有问题，才导致自己发展受限。
一个技术的出现和一个技术可以用在生产上，完全是两个概念。一个技术在成熟之前，在确定能给用户带来价值之前，不要目使用。不要沉浸在自己的技术世界里不可自拔。
新技术要好好学，吃透了，才能用得对，用得好。用之前问问自己，使用这个技术的代价是什么？价值是什么？事情值得做吗？我是为了解决实际的需求，还是为了满足自己那颗躁动的心？
学了新技术，内心很骚动，不用不爽
技术是会发展的，以前有的缺点，不代表未来一直都有。对技术不要有无谓的偏见，技术就是工具，就是用来解决问题的。一项技术能够在行业中流行，必定是有原因的。若是固步自封，早晚会被淘汰。
固步自封的遗老遗少，无视技术带来的创新
使用不必要的技术
软件工程师靠技术吃饭，但是世界并不是绕着技术转的。我们要对技术要有追求，但是要分清什么是自己的追求，什么是公司的追求。除了极少数脱离了低级趣味的公司之外，绝大多数公司雇佣软件工程师的目的，是为了创造价值。态度只能由内而外地改变。如果不是自己认识到问题，是不可能积极主动地改正的。不要让自己对技术错误的态度，成为职业生涯的绊脚石和阻力。
技术是手段而非目的，炫技很没必要，固步自封必被淘汰。技术的目的是解决问题，而非带来更多的问题。
程序员在技术的成长之路上，有哪些陷阱？
系统架构师就是构建一个系统世界，让业务可以在世界实现
理解要解决的问题
摸清解决问题能使用的各种资源
定义解决问题的模型
给出模型各个模块的详细设计
软件系统架构师的工作，有两个输入。一个输入是要解决的问题，这里说的问题，可能完成一个系统，可能是某一类相似的业务等，我们也可以把它认为是一个产品。另一个输人为了解决这个问题，所能使用的资源。这里说的资源，包括系统的工期、团队和公司的技术储备。以及人才储备、业界可以使用的技术、公司的基础设施等等。
随着对问题理解的深入，架构师会在脑子里慢慢形成自己对问题的理解。
问题本身要尽量客观地去认识，但是如何看待和定义一个问题，就不是一个客观的事情了。这会受到每个人的理念影响。其实对一个问题的定义，很大程度上就决定了如何解决一个问题。架构师看问题的理念不同，也直接影响了应对问题的不同方案。
架构师需要从实际问题出发，给出自己对问题的根本理解。所以，架构师和程序员相比，是一个更具有个性化的职业，也是一个更考验自己经验和技术功底的职业。而架构师最重要的能力之一呢，就是对问题的理解的深度。理解问题的这种能力，除了每个人的天赋之外，更多的是依靠你反复沟通、反复思考，以及在某个行业和领域的经验积累。
架构师解决问题的理念
架构师的输入
架构师工作的输出，其实有两部分。一部分是自己对问题的理解和定义，另一部分就是给出解决问题的框架模型，也就是软件架构。
对问题的定义，不是简单的文字性的描述。换句话说，定义可以是从系统架构角度给出的需求分析，或者说是对系统的建模。说起建模，你可能会觉得比较高深，不好理解。我们也可以称之为高层设计（high-level design)。
对问题的定义很重要。能够给出直指问题要害的定义，是非常考验一个架构师，尤其是偏产品类架构师的功力的。对于很多产品来说，架构师能够给出一个准确的定义，就已经成功了一小半，哪怕这时候一行代码都没有。
问题的定义
如果说给出问题的定义，更多的是依靠架构师对行业理解，那么给出解决问题的模型，就更多的是考验架构师的技术实力了。这时候架构师要给出的，是每个模块的详细设计。包括每个模块的接口定义、技术选型、关键实现的设计等等。
所以说，对问题的定义很重要。能够给出直指问题要害的定义，是非常考验一个架构师，尤其是偏产品类架构师的功力的。对于很多产品来说，架构师能够给出一个准确的定义，就已经成功了一小半，哪怕这时候一行代码都没有。
解决问题的模型
架构师的输出
系统架构师做什么
任何一个软件工程师，从写第一行代码的时候开始，就已经既是软件工程师，又是软件系统架构师了。因为我们在写代码之前，肯定要经历这么一个理解问题、分析和定义问题、构建系统的过程。知道自己要干什么，要怎么干，最后一步才是写代码。
首先你得重视自己写代码的能力，打好学习技术的基础。在这个阶段，程序员要能写得一手好代码，把基础的知识都学牢固，比如数据结构、网络、操作系统等等，建立起自己的技术领地。在写代码中，慢慢开始理解程序设计的技巧，比如设计模式、模块化、高内聚低耦合等等。
夯实技术实力
紧接着，就要更进一步，开始注重自己看问题、理解问题、分析问题的能力。简单来说，就是把重心向前挪，理解代码背后解决的问题，理解代码背后的设计理念，主动思考这些“虚头巴脑〞的问题。
同时，这个阶段程序员也要开始主动承担起，一些小模块的设计工作。系统架构师是一个需要非常多的实践积累的工作。每个人都有自己的成长方式，但是多做设计多思考，是普通人进阶软件系统架构师的不二法门。
注重架构师能力培养
软件系统架构师要有一个开放的心态，不能固守己见。优秀的系统架构，需要跟上发展，打破常规。
我们在实践系统架构的时候，也不要怕推翻自己之前的设计。你应该这么想：如果对于一件事情，我今天的认识和昨天是一样的，那就代表我这一天没有成长，如果我今天的认识和去年是一样的，那就代表我这一年没有成长。你想想，是不是这个道理？
保持开放的心态
如何成为架构师
来自实践和时间的积累
对行业产生自己的理解，形成自己的眼界
架构师的核心能力
如何从写代码的程序员，成长为软件系统架构师？
实际情况可能没有预料到，也可以会随时发生变化
系统集成意味着有交互，所有没有细节问题都会暴露在这些地方
系统集成是产出成果，需要得到别人认可
系统集成为什么那么难
内部子模块的架构不统一
和外部系统集成，越早确定细节越好，不要假设任何东西。任何在你看来很自然的东西，可能对方就是没有。你的系统如果对这些想当然的东西有强依赖，那么代价可能是惨重的。
对外部系统的假设不成立
外部系统的配置问题
用户输入数据问题
外部系统的传输数据问题
系统集成的常见的问题
架构要统一
不做假设，尽快做好外部依赖
在系统集成的边界，尽量记录好log
软件集成的应对方法
原因在于一方面，它需要给出最终的被大家认可的成果。另一方面，在现实条件中可能有各种各样，之前没有想到的问题这些问题，都会在系统集成的时候，一一暴露出来，成为系统集成路上的拦路虎，造成无法交付成果的情况。
这个过程，就是系统集成，是我们在为自己的想当然、对需求的理解偏差、经验的欠缺、能力的不足、视野的限制、不充足的前期调研、未预料到的意外来付出的代价。功力深厚的架构师，也是一个系统集成的大师。他可以在设计阶段，根据自己的经验，尽量减少问题，降低难度。所以，能够越少地付出这个代价，越能代表自身综合能力的提升，也是代表自身价值的提升。
为什么最容易出问题的是系统集成？
技术成长篇
职场求生指南
0 条评论
回复 删除
下一页
职业：暂无
作者其他创作：