每次带新人做课程设计，被反复问到程序设计的方法有哪些的时候，都忍不住吐槽一句，这群孩子通病都是一模一样，捧着教材死背结构化、面向对象这些名词，压根没搞懂这些方法到底是用来解决什么麻烦的，纯粹为了学方法而去套用方法。
最开始写代码的时候，本人也是这个毛病，大一刚接触程序设计，傻乎乎把所有设计方法单独拆解背诵，做小型控制台学生管理系统时，硬套面向对象的写法，硬生生拆分出七八个冗余类，变量来回传递绕得脑袋发懵，明明用结构化程序设计，自上而下拆分功能模块就能十分钟搞定的小事，硬生生耗费一下午，最后写出来的代码冗余臃肿，还频繁出现逻辑bug，当时一度觉得是自己的编码能力不够，压根没怀疑过选的设计方法和项目本身不匹配。
那时候完全本末倒置了。
很长一段时间里，都偏执的认为，面向对象是所有项目里最优的解，反正行业里人人都推崇这种写法，所有程序设计任务，无脑用这个方式就不会出错。身边不少同行那会也都是这个想法，大家下意识贬低结构化设计，觉得这种老旧的方法早就该被淘汰，做开发谈结构化，甚至会被圈内人调侃跟不上行业节奏，拘泥于落后的编码模式。
直到后来接手一个老旧的嵌入式控制小程序，设备硬件内存极度有限，整体功能简单，无非就是数据采集、阈值判断、指令输出三个基础流程，试过用面向对象重构代码，光是初始化类的占用内存就直接超出设备承载上限，反复调试好几次都没办法解决，无奈之下只能换回结构化设计，按照顺序、选择、循环三大基础结构拆分整体流程，摒弃所有多余的封装与继承，精简一切无用代码，最后程序不仅流畅运行，内存占用直接缩减了六成，折腾好久才搞明白，各类设计方法从来没有高级低级之分，它们只是适配不同场景的编码工具。
还有原型设计法，算是新手最容易忽略的一个程序设计方式。
之前帮朋友做定制化表单小程序，客户给出的需求模糊且反复变动，前期敲定的功能板块，隔天就会被全盘推翻重新调整，一开始按常规流程先完整规划整体架构，耗费两三天写完基础框架，结果需求一改，大半代码直接作废，白白浪费大量时间和精力，那段时间差点直接摆烂放弃这个小单子。
后面换了原型设计的思路，不再一开始就追求代码完整性，先搭建极简可运行的雏形版本，只保留表单录入、数据存储这类核心基础功能，交付给客户直观验证效果，再根据对方的反馈一点点迭代增补附属功能，不用整体重构，只做局部修改，整个项目的开发效率直接翻倍，也终于摆脱了被多变需求牵着走的窘境。
关掉编辑器，盯着桌面上散落的几份新旧项目源码，指尖无意识摩挲键盘边缘，脑子里还回放着新人死记知识点的模样。比起耗费大把时间熟记所有程序设计方法，读懂当下项目的真实限制与核心需求，才是写代码最容易被忽视的地方。