程序员应该写出怎样的代码
虽说老板和产品经理都不会太关心代码质量，所求无非是美观可用效率高等等，但作为一个略有追求的程序员在严酷的需求排期和反复推翻修改的生存环境之下，面对前人挖下的坑和自己几个月前寥寥草草写出的 adhoc 代码，总会望洋兴叹一番，痛定思痛想要写出一些拯救苍生（几个月后的自己）的传世代码。
然鹅面对一堆静态动态模板混杂、数个参数可变返回数据可变的异步嵌套接口加上鬼都不认识的 model/view 继承堆积起来意大利面条一般的代码，更别说还有不知哪里引用的全局样式给兴高采烈调完所有组件的你温柔一刀。怎么办？
首先从简单的样式部分着手，CSS Module 或 styled component 完美解决了局部样式的问题，SSR 解决了前后端模板的一致性。这些都是社区提供的通用方案，剩下的基本就是如何组织 model 以及接口了，即前后端数据同步问题。
我们知道 Python 和 JavaScript 都是动态语言，而动态语言最臭名昭著的就是“动态一时爽，重构火葬场”，基本一个数据倒上那么三四次手之后就变得亲妈不认了。类型是一定要加的，我们用 TypeScript！
具体的好处前面已经提到过了，这里想说明的是类型定义不仅保证了代码逻辑的正确性，也给予阅读时良好的体验，有了类型以后相当一部分关于变量的说明都可以挪到 type 和 interface 上，代码更容易实现“自解释”。其实 ES Module 很大程度上已经完善了代码的引用逻辑，但相比之下类型定义具有更强的约束（字段级别）和更灵活的配置（interface 鸭子类型），所以都 0202 年了，还不上 TypeScript 真的都没法说自己是工程化的前端项目。
但 TypeScript 只是解决了前端的代码一致性，JavaScript 总还是要在 web 这个容器内运行的，目前边缘计算还不够成熟，以服务器为数据源和计算存储中心的 C/S 架构仍是未来一段时间的主流，所以接口相对于前端的重要性是不言而喻的（插一句，往后想想，与设备的连接接口以后会不会成为前端的新方向呢？这就成了边缘计算）。而对于 HTTP 请求而言，RESTful 是曾经统治一时的事实标准，非常 CRUD，但也非常不灵活。
我们需要的是一种组织更加灵活、分层结构、高度复用、最好实现“自文档”的接口，这就是 GraphQL。虽然它也存在嵌套查询时会拖慢数据库，参数传递不清晰等毛病，但瑕不掩瑜，它确实是目前前端对于结构化数据查询最好的方式，更为出众的是它支持自定义返回字段，不多不少刚刚好是前端想要的那些，这简直太香了。
如果不考虑性能和异步并发，这些已经足以一个前端掌控 95% 的开发任务了，但往往那 5% 的事儿占据了 95% 的开发时间，后面会写写对于 Web Assembly 和 Reactive Programming 的理解，长远来看，当前围绕 html 进行的框架或者语言升级将告一段落，往后会转入多语言及范式涌入 web 开发领域碰撞并融合，浏览器正式成为继 iOS 和 Android 之后的第三大移动操作平台，更为可贵的是 web 的普适性使它几乎没有什么前置使用成本。
