1.软件工程师特质:外在简单；用技术高效解决问题；持续改善，追求极致；热衷创新，热爱分享；好奇务实，讲究逻辑。
2.信念是“代码改变世界”，这种信念源于对成就感的需求。
3.一线城市和次一线城市的机会巨大（北京＞上海＞深圳＞杭州＞成都＞广州＞南京＞厦门）。
4.国内处于特殊（流量驱动）发展阶段，将会逐渐从劳动密集型走向知识密集型，另外再加上很多公司的组织管理能力不足，导致996严重。
5.软件工程师的四大台阶:新手（执行力）、进阶（设计能力）、高手（融会贯通能力、沉淀方法论）、行业大神（开创新领域）。
6.35岁不是年龄的坎儿，而是能力的坎儿。淘汰的原因是没有达到资深工程师水平（高手阶段）。避免被淘汰的实质是要成为所在公司或团队的主要贡献者。
7.如果是创始人或合伙人，那就必须具备:带来稳定资源、吸引人才、带来可观（经济收益或社会收益）收益,带动团队自驱制定方向和实施计划，解决问题并推动创新落地，感知技术变化，技术潮流，并规划好团队未来发展，抓得住重点，简化问题，标准化问题，进而实现规模化和平台化。
8.如果是企业中层，那就必须具备探路能力、提出更简单高效的新创意，解决难题的能力，能够不断发现不足并弥补不足，从而提高标准。
9.如果是行家（专家），那就必须具备降低时间、金钱、人力、物力成本的能力，找到最佳路线和通过最佳实践抵达目的地，从而提升效率，能够发现重要问题，提前解决问题，避免意外发生。
10.行业变化瞬息万变，不进则退，持续学习是刚性要求。
11.数学和英语就是最实用的工具。
12.企业业务能够适应未来发展，发展动作是否迅速（即面向未来），企业文化是以技术为主导（即技术驱动型），这样的企业才是软件工程师们成长和发展的优质平台。
13.伟大的成就从认识自己开始：找到特长，扬长避短。明确兴趣，乐此不疲。总结方法（学习时间管理、做计划、统筹、总结过错），探明事物因果。务实勤奋，斗志昂扬。
14.规范编码，按标准做事，可以提升团队协作效率。
15.只敲优质代码：可读（命名清楚、布局清晰、注释明确‘功能和怎么用’）；可扩展（面对新需求，主干代码不会被改动）；可重用（可以被复用）。
16.别把编程原则当教条，始终明确编程的目的是高效地解决问题而不是为了满足哪项原则。
17.测试比编写代码难：单元测试（用白盒测试）、功能测试（用黑盒测试）、集成测试、非功能测试（性能、可用性、可靠性）、回归测试（意味着自动化测试）。高效测试还是要靠代码来做，拥有全面思考能力，才能做出好测试。
18.自己的程序自己参与测试，不要把用户当做你的测试工程师，否则会影响用户体验感。边界环境更容易暴露缺陷。测试时，如果接口的功能稳定，其具体实现就没必要关注。主干核心模块，必须进行性能测试。
19.对Bug和问题以及对应的测试程序都要构建一个提交代码库，保证以后的回归测试能够自动运行这个测试。
20.新人入职从执行任务开始，执行任务从改Bug开始。
21.用侦探思维定位Bug：模拟Bug场景、二分法定位、调试工具定位、极限测试定位、小黄鸭定位（把小黄鸭当做听众，一行行地向他解释代码，从而理清代码逻辑，最后定位问题）。
22.修复Bug要小心谨慎:看整体（明确修改Bug不会影响其他支线）、改细节（优化结构，让代码更易于理解）、review之前review（提交之前找人review，看看方案是否完善，是否有更好的建议）。
23.接受大工作量任务，先做任务分解，每完成一个子任务就提交一次，方便他人及时并快速发现问题，从而及时修正，避免大返工。
24.写出优质代码的前提是心里明白什么样的代码是优质代码，读代码是个不错的途径，多读这些代码:大神作品里反复被使用的代码、长时间没被淘汰的代码、特别容易调试的代码。
25.快速提升最简单的方法:读懂牛人的代码，感受它的清晰明确、易用、自带说明、高效、通用、可扩展、风格。
26.杰夫.阿特伍德（Jeff Atwood）说“代码告诉你怎么做，文档会告诉你为什么”。因此，了解思想方法，原理和思路，经验和方法，读书和文档较好。了解具体细节，读代码较好。
27.学习牛人的方法，比照抄答案有用。在高手帮你review中学习。和高手共事，一起解决难题。
28.和优秀的人一起工作，潜移默化中都是成长。
29.搭伴学习，亦师亦友。互为磨刀石，互为回音壁。
30.避免需求分析中的X-Y问题。要明确根本需求是什么，不要被层层嵌套的错误需求迷惑，直接参与客户沟通，了解客户初衷。
31.不做模糊不清的需求。明确详细边界。确定不可预期事物的备用方案。
32.原型设计的重点是实现最难的部分，先做最难的部分，既能提早发现问题，也能节省开发时间。在原型设计阶段解决了系统中那些最难的问题，到后期整个项目的推进就会十分顺利。
33.原型设计的关键是接口设计。做接口设计时，要多考量每个阶段可能会调用哪些接口、每个接口需要哪些字段、怎样定义数据等，只有充分想清楚这些问题，才能避免不确定因素对项目整体的影响。
34.架构设计基本思想是：分而治之，思路清晰。划分模块要遵循“高内聚，低耦合”原则，有利于理清思路让设计变得清晰，也利于团队分工，各司其职。做好层层分解后，第三方读者也会很容易看清楚每个部分做什么。
35.架构设计需要关注的重要问题有：考虑系统异常情况（普通异常，宕机、断网、断电等）、系统极限（负载十倍，超高并发等）情况。
36.业务方不应该仅仅把技术方视为需求解决方，应该让技术方参与问题解决前期过程，充分调动技术方的主观能动性。业务方不应该直接将需求丢给技术方，而应该告诉技术方真正想解决的核心问题是什么。如今，项目开发过程中遇到的所有问题都不是单纯的技术问题，需要业务方和技术方团结协作，最终从根本上解决问题。
37.技术是第一生产力，有放大作用，能够把结果规模化、高效化地放大。前台团队相当于数字1，中后台团队相当于数字0，0要紧紧围绕1去建设并创造价值，解决前台的需求和痛点，辅助或优先于前台预见可能发生的问题，为前台团队提供有价值的服务。
38.打牢基础（基础知识和基本技能），以不变应万变，无招胜有招。
39.系统学习少不了构建脉络清晰的知识结构网，更要知道某个知识的来龙去脉和前世今生，知其然，更知其所以然。学习不是要找到答案，而是为了找到方法，就像数学里的公式一样，能够高效的解决复杂问题，方法即公式，公式的由来即知识的来龙去脉。
40.学习的方式很多，最有效的学习方式是主动学习（讨论、实践、教授给他人），而不是被动学习（听讲、阅读、视听、演示）。
41.软件工程师要有前瞻能力（要有足够的知识广度（读论文、业界大公司的资料等可以让你获得足够多信息的途径），做跨行业的交流（多与投资者、创业者等见多识广的人群交流））和权衡利弊（明确目标知主次，学会预测先预防）的能力。
42.要想成为技术大神，就需要主动寻找行业技术难题并攻克之，灵活地变通解决问题的方法和途径。
43.技术选型六要素：该技术是否解决了一个足够大的问题而值得投入时间、该技术的解决问题方式是否有足够的想象空间、是否有大公司撑腰、是否有很好的技术社区、是否有颠覆性应用（如java语言的颠覆性应用就有Spring）、是否拥有十年以上的饱满成长期。
44.软件工程师要有责任心和职业修养，代码不仅仅要解决实际问题，还要其可持续发展性，实现其从易读可维护到艺术感的飞跃。
45.代码评审可以让代码从解决问题到写得漂亮的层面进行转变，应该关注这几个方面：代码设计，代码实现的功能，代码复杂性，是否通过各项测试，命名是否明确，注释是否清晰有效，风格是否规范，相应文档是否完善。
46.代码评审不是为了找Bug，严格区分代码评审与测试两个阶段的工作内容和工作重点，工作内容与工作阶段严格匹配，工作效率将会大幅提升。
47.常规管理者的工作有三：一是在专业上给下属指导，二是对任务进行拆解，组织团队完成目标，三是日常组织与管理工作。在软件行业，对于管理者在技术上的要求较高，如果没有足够精通的技术和专业素养，很难服众。
48.作为软件工程师的管理者，要学会放手让团队成员进行项目主干开发，明确自己的工作内容是给团队知道方向，指出该做的和不该做的，坚持的和可舍弃的，并让团队成员理解你规划的原因。
49.作为软件工程师的管理者，要具备足够的说服能力，工程师本身就是理性的，逻辑和道理更容易促进他们对你工作的理解。同时，管理者需要明确地告知下属：为什么做，为什么不做，有哪些方法，好的方法是什么，好在哪里。错在何处，为什么错，改进方法有哪些，好的补救方法是什么。简言之，讲清楚道理，给出足够的证据。
50.软件工程师解决问题6步法：定义问题，明晰问题，分析利弊（明确限制条件和有利条件），拆解问题，设计方案，落实解决。
51.科学的员工激励机制能够让团队处于高效的工作水平，其直接原因是满足了员工对成就感的需求。
52.作为一个软件工程团队的管理者，有责任和义务做好人才布局，管理者会识人辨人，知道每个员工的擅长和不足，能够为每一个员工提供合适的赛道，促进员工成长与发展。科学合理的人才布局能够为整个团队积累人才资源，提升团队战斗力。
53.放眼未来，长远布局。聪明的管理者知道那些事情可以长期投入，后期可以产生规模效应。明智的管理者也不会受限于眼前的短期目标而忽视或暂停长期目标的推进。短期目标只能护及当前，长期目标才能保障未来，管理者要协调好两者在某些特定时间节点的矛盾。
54.平衡需求之间的轻重缓急，面对紧急需求，要尽可能考虑技术手段以外的解决方案，是否可以人工解决，而不动用技术团队去研发相应的技术。节省技术团队的精力，将其用在刀刃上。
55.在重要事情和紧急事情之间的平衡之处最能考验一个管理者的能力和格局。
56.团队内部如果足够公开透明，每个人的周报，代码，工作进度，设计文档等都能公开可见，就会促进内部监督，提高协作效率。
57.合作共赢，团队之间找到共同利益点，相互协作，共同解决问题，实现1+1大于2的效益。
--------------------参考：丁丛丛,靳冉.《这就是软件工程师 用代码改变世界的人》。
标签：一张,工程师,管理者,代码,纸条,技术,测试,团队 来源： https://blog.csdn.net/xlt_jbwkj/article/details/114922402
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。