我们在编写代码的时候，如果发现某个处理过程已经在别处写好了，想拿过来用，就会有所考量。不能复制过来，因为修改起来费时费力；也不能轻易建立依赖，因为修改可能会产生意外影响。是的，重复会增加冗余，但是复用会增加依赖。
为此，聪明的人们想到很多办法，指出了“软件设计原则”，还有人提到了“代码坏味”，代码质量被重视起来了。扩展性，高性能，稳定性，可维护性，都是人们追求的目标。丑陋的设计和肮脏的代码，是不可容忍的。人们当然知道“适用”才是最好的，当然不想“过度设计”，当然知道“模式”只是前人总结的一些可选经验。然而，某些代码我们就是不能容忍。
后来，我们从这个层面跳出来了，看到了代码要解决的问题，看到了“方案”和“需求”，看到了软件怎样被人使用，看到了代码在工程中的作用。于是，我们学会了如何根据问题的结构来组织代码，根据业务的发展来促进代码的演进，学会了推动别人来使用软件，为生态做出贡献。然而，这并没有什么卵用。我们仍然会遇到新状况，仍然有不能用已有经验去解决的问题，我们可能会遇到沟通问题，遇到协作问题，遇到工程问题。
这不是一个人的事情，我们不得不让大家都知道哪里出问题了，才有可能解决它。我们发现了人的重要性，我们必须营造良好的“氛围”，优秀的人们才会被吸引过来。我们不得不主动沟通，统一方向，不得不扩大影响力，促成某件事情落地执行。
我们总有事情要做，没有通用的解决方案，没有“银弹”。很多事情与代码无关，与编程也无关，工程师们到底应该做什么呢？有人会说，快速写出可用的代码去实现业务目标就够了。我承认这是应该做的，但是还有价值更大的事情。
这件事情就是，“想办法”。有的人总是没想法，而有的人总是会想办法。这些，经验、原则、模式、方案、工程、文化，不都是别人想出来的吗？关键不在于做什么，而在于谁去做它，不同的人会想出不同的办法。
所以，我认为软件工程师并不仅仅是写代码的人。而是发现问题，并思考如何解决的人。能发现多大价值的问题并解决它，工程师就能创造多大的价值。这里提到的问题，并不局限于业务功能，也不局限于代码本身，不局限于软件工程，更不局限于团队文化。它们都是问题，都需要想办法。我们想到的办法如果可以用代码解决，就实现它，如果不能，那就用别的办法解决它。
我觉得，到了这一步，才能从容的面对丑陋的代码，面对混乱的项目工程，面对水土不服的文化。为什么？因为这些问题，本来就应该是工程师们，想办法去解决的呀。
发现问题，让我们想个办法，然后解决它。
陈皓：我给大约40多家公司做过相应的技术咨询和解决过很多技术问题，绝大多数公司都是因为性能和稳定性的问题来找我的，我给这些公司解决问题的时候，基本都是这样的Pattern：一开始，发现都是一些技术知识点的问题；然后，马上进入到系统架构方面方面的问题；当再解决架构问题的时候，我发现，已经是软件工程的问题；而软件工程问题的后面，又是公司管理上的问题；而公司管理的问题，结果又到了人的问题上；而人的问题，又到了公司文化的问题……
我能做的是，观察这个公司的业务形态、和相关的思维方式，以及现有的资源和相应的技术实力，帮助他们从技术到管理上缓解或改善现有的问题。
网友评论