论架构师的重要性

想要设计开发一款软件系统，随便招聘几个有两年经验的程序员就能开发出来，这样成本比较低。然而要明白性价比这个词，你选择以低成本开发软件系统，那么就要接受它简陋的代价。

1.修改现有系统的某功能，使其能够智能化提示或自动化辅助。卧槽，这个难度有点大，这个系统本就是拼凑起来的，哪里搞得了这些玩意，再说现有的程序员也没有这个能力，招人吧。经过反复博弈和折磨，最后实现了目标，但是也损伤了信任。

2.功能加多了，问题自然而然就多了。这个功能怎么又出问题了，赶紧修复，然后告诉人事计入绩效考核。

3.使用一段时间，页面数据加载越来越慢。怎么那么慢要等半天，太耽误事儿了，赶紧优化，然后告诉人事计入绩效考核。

4.现在系统注册的用户越来越多，需要扩容。赶紧扩容，要是用户跑了，责任全是你们技术来背。

5.由于用户增多，对系统的稳定性越来越高，直接读写关系数据库已经不现实。赶紧进行负载均衡部署、启动消息队列技术、启动缓存数据库。

6.软件系统安全性要求提升，要记录用户的“增删改查”操作，并对异常数据进行消息预警，快去设计日志系统和消息系统。

7.某日系统被网络攻击，要死啊，赶紧处理。扯淡吧，就那仨瓜俩枣的投入，既要又要还要，bye-bye，另请高明吧。

8.招聘新人牛人，牛人一看现有的系统，给出唯一方案，推倒重建，要不然俺也搞不了。此刻你低声下气的将原班人马请回来，出钱出力，问题也只是稍微改善一点，无法解决根除。

9.此刻软件系统陷入死循环，像滚雪球一样，越滚越大。新需求越来越多，且无法增加上，问题越来越多，且无法解决。

10.此时你也陷入了崩溃的边缘，即便愿意花钱招聘大牛，时间也来不及了，即便时间来得及，推倒重建的代价和风险也会把你逼疯。最后的答案是你疯掉，然后不停的联想“千里之行始于足下”的大道理，自己当初为什么如此草率，此刻你也彻底了解软件系统的设计研发原理。

11.也许你会痛定思痛，推倒重建，或许你会挂掉。以下假若你想凤凰涅槃重生的场景。

12.编程技术是每时每刻变化的，不是固定的。随着技术本身的升级，即便软件系统没有增加功能，软件系统依然要升级，程序员的技术能力也要升级，对于不想升级自身技能的，只好让其毕业了。

13.某功能背后的技术实现，不仅需要程序员的能力强，而且还需要不停的测试打磨，最终测出最佳的使用场景和性能，所以千万别认为像换汽车轮胎那样傻瓜。

14.既然要满足“行万里”的目标，就要做匹配目标的设计，而不是随便招几个程序员先搞出来。软件系统的设计研发难就难在抽象上，许多人根本就不具备抽象能力，那就更加不用提归类、汇总、粒度、统计、算法、结构化、流程化、层次化等。

15.在公司里，管理最好的部门一定是财务部，因为前有会计准则指导和约束，中有财务软件帮助，后有审计监督，所以不论任何公司的财务部都是管理最好的部门，且财务部门也最能理解软件设计研发人员，因为软件系统的设计研发难度100倍于它。

16.如果你的老板想一套是一套，不要犹豫赶紧离开当前公司，因为那会把你累死。我只是增加这么小的一个需求，能有多难，在我的薪资后边增加一个零，也只是随手画上而已。软件系统之所以问题越来越多、越来越大，根源就在此，不懂得未雨绸缪的老板本质就是个草包。如上述遭遇的死循环，如果老板懂得未雨绸缪，在问题出现前就重新设计研发新系统了，而不是一味的在简陋的系统上增增减减。

17.想要一次性建成理想中的软件系统，绝对在扯淡，肯定是分阶段、循序渐进按照实际需求设计研发。即便真有满足建设理想系统的实力、环境等一切条件，也不可行，因为设计研发需要时间，任何人都无法预测未来。

18.软件系统设计就是建模，把需求规制于模型里，最终模型的完整度就决定了一切。研发完成上线后就如模型里的布局功能一样，至于到时候是否能满足实际需要，此刻便已决定。需要组建什么样的研发团队，投入的成本、周期等资源，会遇到何种风险和危机，如何规避它们。后期的运维和演进路线。后续版本的模型应该在何时设计、何时研发。

19.人是最不可控的，尤其是脑袋上缺毛的程序员，因此，即便你千辛万苦、穷尽心神设计出来需求模型，也未必能研发的出来。研发过程其实就是对需求模型进行验证，你可能发现需求模型最后会千疮百孔、面目全非，好在你最初说的圆不是圆，产出物才是你理想中的真爱。这就是需求模型的价值，设计人员与研发人员需要反反复复的修改确认每一个细节和数字，甚至是标点符号。这就完了吗？不，这才刚刚开始。

20.要知道软件系统的设计研发成本非常高、风险特别大，一方面是编程技术本身，另一方面是程序员的技能。很多时候，程序员常常会把自身能力不足的责任推到编程语言上，99%的老板会信以为真，最后尽瞎折腾了。还有许多程序员只具备做系统V1.0版本的能力，当你准备V2.0时才会发现被骗了。因此，想要降低成本和风险，你必须有一位技术大拿坐镇核心，许多人感觉上是技术总监，实际上是架构师，除非技术总监参与编码设计，但大多数时候，技术总监已经不参与具体的编程了，他要负责除研发之外的许多事情，如对老板负责、对公司负责、对软件团队负责、对运维管理负责等。

21.除非是天才一类的人，否则没个十年八年对技术的设计研发阅历，想贴上架构师的身份标签，水分含量不要太多啊。真正的架构师有能力根据公司的实际需求构思出最合理的技术方案（成本低、周期短、问题少、稳定性强、伸缩性强、团队能力强等），而且还具备未雨绸缪的能力，现在知道为什么说没个十年八年的时间了吧，因为他需要成长历练，精通并掌握各项技术技能。不然怎么可能构思出最合理的技术方案，像那些水货一样，会使用某个框架、能带人开发项目就敢自称架构师。

22.要把某一项编程技术练熟，然后融会贯通，不经历实战是不可能的，技术指南中说如此如此，那是因为它是技术指南，实际如何只有亲自操作一番才行。实操过就行了吗？不完全行，因为技术是会升级和淘汰的，所以不要说掌握千百项技术技能，几十项技能就已经是绝大多数人的上限了。然而聪明的人会将实操过的技术技能管理于自己的知识网络中，落实于自己的框架平台里，该更新时升级，该抛弃时淘汰。试想一下，倘若你的软件系统基于这么一套框架平台进行设计、研发、管理，是不是就安心的多了。

23.在进行信息化建设时，如上所述，完成了设计与研发就完了吗，是的，不过在上述过程中我并没有说另一个概念：数据，而它也是绝大多数管理者在经历过设计研发阶段后常常忽视的，实际却是都在围绕它转。我常常提醒到软件系统的设计、研发、使用和管理者们，数据的独立性、安全性和完整性才是检验软件系统的标准，你想想自己是否把一些本该存储于数据库中的数据写在了程序代码中。信息化建设的核心是数字化，软件程序只是帮助我们更好的收集、编辑和查看数据，而数据的变化和状态应该被记录到数据库的数据表中。

24.需求建模、系统研发、数据存储，没有结束呢，不要着急。软件系统是给人使用的，所以需要把它部署到硬件服务器上，并且还要根据需要扩容，最好是自动化作业完成。当遇到问题时能主动防御，并向技术人员发出预警。是的，这些都需要构思其中，一定要记住：软件系统是科学计算，不兼容“临时抱佛脚”的思想行为，以及侥幸或运气类的玄学骚操作。

25.将上述内容提到的文字融合在一起，脑袋应该会比较充实，那要是在此基础上乘以10呢。有道是“只有背后很努力，才会看上去毫不费力”，如果你只理解了上述内容，是做不出你理想中的软件系统。

26.写到这里，读到这里，你还会轻视某些程序员吗？也不会很轻浮的随心所欲了吧！不要说软件系统，现实中许多心怡的商品都是反复设计打磨出来的，所以要有耐心、更要学会尊重，尊重他人，也是在尊重自己。这算是我首次站在非计算机技术出身人士的角度写文章，感觉很有意思。

 

 

其他信息

最近AI界消停了不少，正好也写点近段时间的个人见解，说实话，我不看好aiAgent（AI智能体），除非AI幻觉下降到忽略不计，以及API调用成本大众可接受，否则这家伙会成为吞金兽，用不起。然而鉴于芯片成本、研发成本、电力成本等居高不下，想要制定出大众可接受、又可盈利的价格，实在是不现实。