标签：notify 基本 class request 覆盖 编程 deb 代码 细节问题
作为项目后端工程师，本职的开发工作在6月7日前已经基本结束了。
小组本预计在6月7日发布Alpha版本，但6月7日当天小组一位同学在Git操作中出现了网络问题，前端代码有非常大一部分遭到了不可逆转的覆盖，因此当天发布的计划也就此破产。而在重新编写这部分前端代码后，前端又出现了各种各样千奇百怪的BUG。至今我们的项目仍在前端Debug中，且剩余了一些对于用户使用版来说不应该存在的瑕疵（比如需要控制台操作），这让我们深感惶恐。
编写后端代码的过程中，我发现技术模型和代码架构决定了代码实现的难易程度和可维护程度。一个好的技术模型可能比较难以理解，但理解之后实现起来则会越来越容易。例如本次项目的后端God模块中用到的synchronize、notifyAll的解决并发问题的方法以及前后端交互的request方法。在编写之前我花了大量的时间学习这两个方法的原理，但实际编写代码时发现一旦了解之后实现起来并不需要繁复和晦涩的代码操作。
而代码架构则保证了代码的可维护性。在编写前后端交互模块中，常常设计到功能和模块的合并、拓展以及接口的改变，而后端良好的代码架构则使God能够灵活地根据前端的需求进行局部的修改而不需要大规模重构。
6月份其实前端工作并不重，而在配合前端进行整体测试的过程中，我深刻体会到了前端工作的艰难。
前端代码量大，而且网页编写不能像后端一样容易地定位错误，所有的Bug都需要通过人工来寻找，大大增加了前端工程师们的工作量。我的前端工程师室友多次出现一下午五六小时花在寻找一个小错误上面的情况。
此期间我也适当参加了前端的一部分debug工作。我认为要解决或者说是预防以上的问题，一是需要前端工程师具有非常良好的代码习惯，包括命名风格，缩进风格和代码架构的设计，良好的习惯不仅能使代码查错的难度降低，本身也可以减少许多错误的发生，特别是在使用开源框架和html等注重“格式”的工具时；二是可以采用结对编程的方式，前端工作中的细节问题比后端更加难以发现，结对编程对效率有很大的提升。
在工作中我曾经解决困扰某位前端同学数小时的问题，而这个问题又是由代码习惯不好带来的，因此我对以上两点深有体会。
标签：notify 基本 class request 覆盖 编程 deb 代码 细节问题
原文地址：https://www.cnblogs.com/Ignoramus/p/9188813.html
