除了js，能换一种完备的语言吗？

发布于
2018-12-05

如题详述：

最近，一直在开发react项目，给我最大感受就是bug，以及复杂性。只要测试人员想测试，产品经理想到处点点，bug总是会有的，感觉就是改不完的，这也让我开始怀疑js这门语言。

对于问题，我想的当然是最完美解决方案，可是在js语言里，我感觉做不到，无论是页面交互逻辑、数据逻辑、业务场景逻辑、react运行原理以及公共组件封装的完备性，这里面的复杂性我永远考虑不全，所以对于问题我也只能是暂时解决了、当下解决了，因为，冷不丁什么场景、什么逻辑考虑不到而有了bug。

每天在这样的场景下修改bug，让我如临深渊，如履薄冰，也不想这样无休止的bug下去。

对于前端开发，的确有了很大的进步，前后端分离、单页应用、数据逻辑处理转移到前端，或页面交互、或用户体验，随着而来的就是前端开发的复杂性。同样一个项目，配备着同样数量的前后端开发人员，可总感觉前端有改不完的bug，而后端就很闲，我不知道是身为前端的我们太弱，还是后端人员太强。

鉴于此，我开始怀疑js这门语言，对于一门弱类型语言，本来就存在着很多不确定性、不太好理解的内部换算规律，至于这种规律，可能是我懂得太少，亦或是js套路太深了，反正我就是这样轻而易举的掉入坑中了。

至于个人开发，自己又是个相对追求完美的人，对于问题都希望尽我能用最完美解决方案。一开始就是从无到有的选择了前端，如果可能，我愿意换一种语言，能吻合我性格的一种语言。

不知大家有什么看法，亦或是好的建议？

javascript

阅读 4.6k

9 个回答

Untitled

归根结底是你的能力不够、对这个语言不熟悉，而不是这个语言本身，bug是不可避免的，如何在设计阶段通过合理的设计和约定来避免bug，以及出现bug后怎么高效定位、解决bug，并从中吸取教训，是一个程序员应该具备的最基本的素养，如果你根本就不了解语言的特点，不知道怎么提高运行效率，实现前没有好好设计模型，随心所欲瞎逼写一通；今天定义了一个数据类型，明天又按另一种类型写；今天这个函数是这个作用，明天就变那个作用了；全局变量满地跑，变量名abcd排着用，自带混淆，那你换什么语言写都是一堆bug。动态语言还好，你还能运行起来，静态语言你连编译都编译不出来，到时候你还得发个问题问：除了C++，能换一种能编译出来的语言吗？

另外推荐你在熟悉了语言特性之后再迁移到typescript，包含静态类型检查，但不是说就不会有bug。

不知道你有没有看到，我把底下的回复贴上来

会有这样的想法说明你的能力不足，需要多看别人的或者框架的代码，学习别人的思路，学习框架的设计思路。
有bug可以接受，但低级bug多了（单个页面中两三个低级bug就可以毁掉用户体验），欠缺考虑的地方多了就会让人觉得你们太过马虎。要达到各方面尽可能周全的考虑，可以通过抽象和模块化实现，各种框架就是帮程序员干这种事的。此外，确定单点/单个模块无明显bug后再将其整合进其父模块。
不妨在实现前通过画程序框图/结构图/数据流图/状态机，然后根据此设计实现。实现时一定要写注释，不要求每一句都要注释，之前每个函数，每个模块都要有注释标明其作用，复杂的模块最好还要标明其思路，单句可读性差的骚操作也要注释。
你排斥的不是js和bug，是这份工作。

回答你的评论：直接搜索即可。这些东西是软件工程里的概念，小工程可有可无，大工程一般还是要借助这些东西，当然如果你小工程都做得很头疼了也可以用这些东西帮助你开发。

举个开发方法的例子（实际有前人总结的若干软件开发模型）：

分析需求

对于你们来说，需求应该已经由分析人员分析好了，你们应该能直接拿到列好的需求要点，例如主界面有哪些功能模块/分区，用户主要使用移动端还是PC端等。如果这部分工作没有独立出来，那你们应该自己单独做这个分析，而且需求列完是需要甲方确认的，避免由于误解引起不必要的麻烦。

UI和交互设计

这部分可以被单独独立出来，但大部分情况下似乎都由前端工程师包办。你们如果没有单独的设计部门，而整个站点又较为复杂，需要先将大致可能的页面先列出来，然后还需要将这些页面的大致样式设计出来（可以在纸上大致画出来）。千万不要想到要加一个页面就新建a.html，b.html，denglu.html，zhuce.html，好歹也是login.html。当然开发到一半觉得要加页面也是很常有的事情，但先想好怎么划分了再动手会比你先一股脑把几个页面写在一起里，然后再从一坨代码中把他们分离出来好得多。

划分模块和子功能

在UI大致设计好后，按功能模块，复杂的功能可以再细分成子功能，如果涉及复杂数据的处理，需要为处理数据的功能也划分模块，并约定好接口。UI操作和数据操作、请求尽可能分开。举个例子，假设有一个功能是点击一个按钮就收集一些数据然后向后端发送一个请求，然后根据响应结果（假设服务器响应结果有3种：成功，无效表单，暂不可用）向用户反馈情况。如果UI操作和数据操作不分开，这个功能的代码看起来可能会像这样：

$('#someButton').on('click', function() {
  let name = $('#name').value()
  let user = $('#user').value()
  // Some other data
  if(!user) {
    alert('User must be specified!')
    return
  }
  // Some other checks before sending the request
  $.ajax({
    url: '/',
    method: 'POST',
    data: {
      name,
      user,
      ...
    },
    success: data => {
      if(data.status != 'success' || !(data.msg)) {
        // Exception handling
      }
      $('someDiv').html(data.msg)
    },
    error: (xhr, errMsg, err) => {
      switch(xhr.response) {
        case 'INVALID_FORM':  // ...
        case 'TEMPORARY_UNAVAILABLE':  // ...
        default: {
          switch(xhr.status) {
            case 400:  // ...
            case 500:  // ...
            // Exception handling
          }
        }
      }
    }
  })
})

而分离的话看起来就会像这样

const API_URL = {
  someFeature: '/'
}

async function someAPIFunction(name, user, /* ... */) {
  let res
  try {
    res = await post(API_URL.someFeature, { name, user, /* ... */ })
  } catch(err) {
    throw new Error(err)
  }
  switch(await res.text()) {
    case 'SUCCESS': return
    // Some other cases
  }
}

$('#someButton').on('click', async function() {
  let name = $('#name').value()
  let user = $('#user').value()
  // Some other data
  if(!user) {
    alert('User must be specified!')
    return
  }
  // Some other checks before sending the request
  try {
    await someAPIFunction(name, user)
  } catch(err) {
    // Some exception handling
  }
})

看起来可读性高了不少，UI和调用后端API的部分也完全分离了，方便定位bug和维护。

实现模块

按照先前的设计实现各个模块，单独测试每个模块，保证每个模块在整合之前已经是正确实现的，避免单个模块存在的错误在整合后被放大。在实现的时候如果发现先前的设计不够合理，可以修改先前的设计。

反馈、修改

请用户/测试人员试用产品原型，根据反馈情况完善功能。

上述几个过程有时候可以并行进行。

像结构图、数据流图和框图这些东西，百度图片搜一下就有了：链接1，链接2，链接3

eason_li

853116

发布于
2018-12-05

更新于
2018-12-05

1、之所以你觉得后端bug少是因为后端的业务逻辑只体现在数据，只要数据结果对就可以，但是前端页面各种数据显示、交互本身就有很多不确定性，所以对于一些经验不丰富的人来说，bug多是肯定的，本身和js没有关系
2、如果只是语言本身的语法结构，有很多的替代品，比如coffee，typescript，个人比较建议用typescript

pfan

5661310

发布于
2018-12-05

没有不存在bug的代码~

牛书书

10.1k82035

发布于
2018-12-05

去做产品经理把难题留给程序员

安于现状i

8791410

发布于
2018-12-05

没有bug你就失业了

XYShaoKang

3.3k1415

发布于
2018-12-05

所谓完美从来都是一种错觉,说得好听点是追求完美,不好听就是不懂取舍.

做任何事情都需要去平衡成本和收益的,我们都只能做出最经济的选择,而很难做到完美.

比如bug这个问题,假如这个世界上的程序,能够开发到没有bug的完美程度,那么也就不需要那么多程序员了.一个没有bug的程序,除非没人用.上帝老人家编写的这个世界尚且有bug何况我们一个程序员.

我觉得程序员的核心能力就是解决问题的能力,

像你说的别人随便就能找出一个bug来,那何不自己先把bug找出来呢.自己先把单元测试写了,别等别人来找茬.

你说复杂度考虑不全,这个是正常,没人天生就会所有事情,重要的是学呀,吃一堑长一智,把你能考虑到的考虑了,当后面出现没考虑到的,在解决就是了,在下次就会记得这次教训,而考虑的更全面的一些的,成长是需要一个过程的嘛.

程序的本质就是一个解决问题的工具,关键还是得看谁在用而已.

布列瑟农的星空

1.4k21127

发布于
2018-12-06

js的确有很多的缺陷，如果你觉得是语言的问题的话可以使用ts，强对象类型，增加了很多约束，开发起来的确会避免很多低级bug；但是这归根结底还是你自身的能力问题。
后端bug少是因为后端负责的逻辑少，而且很多东西框架都给他们提供好了；而前端要考虑用户操作/业务逻辑/数据格式很多方面，工作量大不少，当然容易出bug；并不是说前端能力弱或者语言本身不行；
我觉得你首先在写代码的时候就应该多考虑各种情况，然后跟后端对接的时候约束好无数据时返回的格式，自己写的时候多测试，在测试之前起码得把各流程给跑通。
还有一个就是开发规范，如果bug特别多，我感觉开发流程和规范上可能有问题。