但小程序却不一样，虽然2016年小程序就有了一个小的测试应用产品，但是成熟期是在2018年底，各大企业和用户使用频率较高的爆发期是在2019年。有人说，小程序的到来取代了移动网站，真的是这样吗？他们各自的优缺点又是什么样的呢？
一、产品属性的区别
1移动网站：移动网站是一个独立的互联网产品，它拥有独立的域名和服务器，企业可以根据自身需求自由调整和优化；
2小程序：小程序是依托在第三方平台的互联网产品，它所有的程序开发和制作都是基于第三方平台的接口来完成。
二、受众群体的区别
1移动网站：移动网站的受众群体是所有移动端浏览器的使用客户，他没有地域、年龄、性别等限止条件，只要企业能够做好移动网站的搜索引擎排名，那么用户无论通过什么手机、什么浏览器搜索对应的相关词都能找到这个网站。
2小程序：通过不同平台制作的小程序所面向的受众群体是有不一样的，微信小程序的使用者是微信用户，支付宝小程序的使用者是支付宝用户，今日头条小程序的使用者是今日头条用户，这些用户基于平台来进行特定需求的访问。
无论是移动网站还是小程序他们都有自身的优势和特点，并没有说谁取代了谁，所以，企业可以根据自身需求进行选择，当然也可以两者都做。
软件开发中需要注意的细节
软件开发中需要注意的细节
1.系统流程梳理
对于软件开发来说，每一个开发者不应该仅仅拿到的是一些文档，而是应该大家坐在一起，由熟悉该软件业务的管理者或者其他人来进行一次严谨的描述，并进行讨论，加以完善和改进，让参与编码的开发者在这个过程中不仅能够熟悉自己要做的那些功能的细节，还能对这个系统有一个大致的了解和熟悉，只有这样，在开发中才会避免一些不必要的问题发生，而且还能发现一些隐藏的问题，要知道修改问题是需要花费很多时间和精力的，比如编码和业务是有冲突的，本人有遇到过，代码不能完全跟着业务走，业务也在适当的时候在满足正常场景下根据编码风格做适当的调整。最终达到一种整体和谐的一种美感。在编码的前期要让每一个参与项目的人能够清晰的知道我要做的是什么，最终的目标是什么样的，我要关注的重点有些，还有哪些疑虑我需要讨论或者解决的。准备工作做好后，对每一个团队成员项目的进度是非常清晰的。
2.技术框架的选择
一般选择技术架构有几个衡量的点：
第一点：效率。
第二点：成本。
第三点：稳定性。
3.编码
在软件产品的编码中需要注意的一些宏观问题：
第一点：代码风格。
一个年轻的团队很容易遇到这个问题，一个软件开发完了，回头去看里面的代码，编码风格很不统一，有5个开发者就有5种代码风格！怎么样避免这种情况，只能在编码之前进行代码编码风格宣讲和讨论，把规则制定下来，大家按这种风格进行代码编写，还有一点要做的就是代码检视，不要因为忙而忽略这个，一周花一个下午来看看别人的代码，不仅能看到一些问题，而且还能看到自己的一些问题，当开发一段时间过去以后，代码不断的调整，最终的源码看上去就是一个人完成的一样！所以开工之前把这方面工作做好，事半功倍，后面还有很长的软件维护工作要做，如果整体代码一团糟，我想没人愿意去维护这么糟糕的代码。这样的项目本人也遇到过，深有体会。
第二点：注释。
比风格统一的更难的可能就是注释了，我想你不会这么认为，我也想自己这种认识是错的，因为写注释这种活总比编码要容易得多吧，不是这样的，很多人应该都看过国内一些开源的程序员写的开源软件吧，很膜拜吧？呵呵，我也有看过，说下我的感受吧，首先代码很少有注释，一个类文件看下来只有代码，注释非常稀少，不知道他是怎么想的，再简单的代码也要有方法和类注释吧；其次，代码里面有稀疏的注释，好不容易啊，结果是英文的，还有文档里面都是英文的，一个说中文的家伙为什么搞成英文版的呢。另外，打印日志不加级别判断，还有一些编码问题在里面。很想骂几句，但是人家毕竟是开源的，不容易啊！ 精神可以鼓励，但是态度值得怀疑。如果你现在刚编完代码或者要开始编码了，请把代码写好的同时把注释写好吧！如果一个刚入门的程序员能直接通过注释就能读懂你的程序代码，那么你写的注释已经非常成功了。
第三点：代码目录结构。
这点和编码风格是挂钩的，也可以属于代码风格里面的一部分，但是单独拿出来肯定有独特的含义。你有没有想过或者遇到过通过代码目录结构就能够大致看懂该项目是要做什么，有哪些功能，如果看到这样的工程是不是有一种很想再往里面看的冲动？本人有参与这样的项目编码，当时我们做的还比较成功，刚开始做有点不习惯和编码风格不同，关于代码目录结构我们进行了单独的讨论，根据本身的技术架构来制定的，把这点做好，开发者编写代码更加清晰了，效率也有所提高了，后期维护哪怕是新人来维护，只要稍微讲讲，也会很容易的接受，一切都变得更加简单了。
第四点：命名。
这点也可以同属于代码风格。坦白讲单独拎出来说也没有多大意思，因为代码风格里面就会强调，但是你不觉得这么重要的东西很容易忽略吗，比如大小写，id我是写Id还是写成ID呢，没有多少人会在意，只有出现问题了，代码冗余量增加了，才会发现，命名也是非常重要。还有一些，类文件的命名词不达意的，我想提醒你的是，既然这么重要那么请谨慎对你的代码进行命名！
第五点：赞成有必要的重构。
重构需要注意时机，有两个点是最好进行重构了，第一点是在自己编写完代码以后进行优化和重构，转测试之前；第二点就是当项目初期大家没有意识到要去重构，也就是第一点没有做充分，导致代码重复率比较高等一些整体问题，在这种前提下找一个时间段，对整体代码进行一次重构计划，这是有必要的。
第六点：一些提高代码的工具使用。
4.测试
作为一个开发人员所接触的测试首当其冲的就是编写单元测试用例，尽量覆盖每一个场景，这对软件质量起到一个很关键的作用，为了避免与测试人员反复沟通增加无谓的成本，开发能做的就是写单元测试发现一些潜在的问题，把大部分的bug提前发现。从管理角度来讲，测试也会轻松很多。开发一款相对完美的软件绝对是一个优秀程序员的追求。也是在程序员这条道路上的一笔收获。