高级程序员到底长什么样子？( 三 ) _程序员

困难的事交给他们很放心，因为他们擅长的不是某种技术，而是解决问题的能力。他们总能解决那些之前从未遇到过的新问题，哪怕它们很困难。

那么，怎么做有助于我们成为高级程序员呢？
1、关注技术之余还要关注业务为什么把它放第一点，因为我觉得这点最重要，是其它项的基础，也最容易做到，但是很多程序员不愿意去做。
一定要搞清楚业务目标，不搞清楚不开工。相信我，只要是一位合格的 leader，一定会不厌其烦地和你说清楚的。
然后要习惯基于业务目标去分析可能会面临的技术挑战。比如，多少流量，涉及哪些用户角色和功能，复杂度有多大等等。
再带着下面的“不可能三角”去寻找合适的技术框架、解决方案。尽可能地寻求最优的平衡，而不是走极端。

文章插图

如果拿捏不准，可以将多个方案各自的优缺点罗列出来，向 leader 寻求建议。
2、“设计”代码而不是“写”代码一般人可能拿到需求，就开始写代码了，写着写着由于页面功能越来越多，感觉代码越来越复杂，自己都会觉得难以维护了。
虽说要做好设计离不开大量的实战经验的积累，但还是有些方法可以让塑造这个能力的过程更快一些。比如：

首先就是前面提到的第一点，多关注业务。不了解业务，你啥都设计不出来，或者把马设计成了驴……
如果某个功能的开发/修改，以“天”为工时单位，一定要先画图。具体画什么图，可以参考我之前写的文章：软件开发中会用到的图。
搞明白每个设计模式的特点和适用场景，注意，不需要把代码怎么写背下来。只要你每次写代码之前扫一眼设计模式的列表，看看有没有适用的。如果有的话，再去“依样画葫芦”按照设计模式去实现，经过时间的积累，慢慢地，你真正掌握的设计模式就越来越多了。这有助于锻炼你的设计能力。

3、“接”需求之前会先“砍”需求要做这点还得依赖于第一点，否则，你提出的“砍”需求建议大多是不会被采纳的。
很多人在听需求讲解的时候，思考的是，这个功能能不能实现、怎么实现、难不难。大多数的提问也是基于这个思路展开的。
可能也会提出“砍”需求的问题，但是理由大多是这个实现起来太麻烦了，这个没法实现之类。
其实只要你时刻保持着“做这个需求的目的是什么”这个问题去思考，“砍”需求会变成一件更容易成功，而且自然而然的事情。
4、解决一类问题而不是一个问题很多人觉得，每天看到 bug 清完就万事大吉了，哪怕同一个问题在生产环境出现多次，最多也就说一句“不会吧，怎么又出问题了” 。
这种对待问题的方式只会让你越来越忙，因为你的解决问题效率与投入的时间多少是成同比变化的。
我们要习惯于解决掉一个 bug 之后，想一下能否通过什么方式找到现有代码中的同类问题，并把它们处理掉。
甚至是考虑有没有什么办法能够一劳永逸地避免此类问题再次发生，比如封装一个 SDK 或者写一个组件，尽可能用一种低侵入的通用方式将问题扼杀在摇篮里。不但让自己轻松了，也造福了大家。
5、遵循 KISS 原则，写尽可能简单的代码KISS 原则：保持简单，愚蠢（Keep it simple, stupid）。
不单单是程序员，任何化繁为简的能力才是一个人功力深厚的体现，没有之一。
越简单，越接近本质。就好比，有的人要用长篇大论才能讲明白一件事，而有的人只要做一个形象的比喻你就懂了。
这个“简单”指的是整体的简单，而不是通过局部的复杂让另一个局部简单。比如，为了上层的使用更加傻瓜化，底层封装的代码错综复杂、晦涩难懂，这并不是真正的“简单” 。
如果你自认为已经是一个中级或者高级程序员了，那么你回头去看看自己还是初级程序员那会写的代码，就会很容易发现一些显得冗余的代码。
第二点提到的——“设计代码而不是写代码”对做好这点有很大的帮助。
6、选择忍受某些问题在人工智能还不能代替我们 coding 之前，我们永远要亲自面对无穷无尽的、这样那样的问题。
然而，任何事物都有两面性的，一个方案在解决一个老问题的同时，总会带来新的问题。所以，我们一定要意识到，忍受某些问题是必然的。