从步入岗位以来，时至今日前端开发已过半载，技能上虽没有飞跃性的提升，但相比最初的时候也是积累了一些开发经验，现做个总结并分享给大家，同时记录下个人的成长经历，其中不对或不准确的地方希望大家指正批评。
在项目正式着手写代码前，首先要对需求有一个明确的理解，把整个项目功能串起来，才能更好的理解个人承担的模块。后端开发关注的是业务功能逻辑，而我们前端开发更注重的是页面交互逻辑与呈现出的视觉效果，对UED图有更高的依赖性。
分支管理规范，虽然可以使用一个分支完成开发，但假如有什么失误操作，处理起来会很繁琐，因此应严格按照规范进行分支管理。比如一个需求id，就是一个feature分支。严格按照规范开发，虽然有些麻烦，但总体是利大于弊的，应养成这个良好习惯。
熟悉一下项目的基本配置，由于开发过程中会遇到各种各样的情况，每种情况可能又要更改不同的配置，比如调试过程中是测试环境还是预发环境，或者打包时用的哪个打包后缀等，反正我第一次接触这些时，真的是一脸懵。
接下来就是关于日常开发的，写出的都是一些比较基本的内容，如果有不对的地方还望指正批评。
关于静态页面：当拿到ued图后，要熟悉整体的设计风格，然后重点关注自己要着手开发的模块。模块的最外层宽度尽量不要写固定数值，如果用固定宽度，当后期拉取别人代码后，整体布局可能会发生意想不到的效果。
比如上图中框选部分，此处使用width100%，撑满架构预留的右侧部分即可，最外层使用百分比布局可粗略实现自适应的效果。使用html中已有的语义化标签，例如，绘制某一列表页，循环遍历某一元素时，应该使用：
- 元素
- 元素
这种形式，更加一目了然，提高代码的易读性。
还有就是应该多熟悉css的现有属性，有很多情况可以使用内置的方法实现，而不是从头手动实现，遇到陌生的属性养成多查多记的良好习惯。
关于框架：react是一款高效的单页面应用开发框架，熟练使用可做到事半功倍的效用。现今对个人的使用做一下总结与分享。state，保存变量的地方，这里定义的变量对于当前文件来讲属于全局变量，只要使用之前将其解构出来就可以读取该值。无论哪里将state值改变，引用他的地方都会拿到最新值，但也有特殊情况，比如this.setState(),如果想在this.setState()的所在函数内取到最新值，应在setState的第二个参数写回调函数才能实现，例如：this.setState({ newNum: 666 }, () => console.log(this.state.newNum))，
这样才能打印出666，如果不写在这个位置，所得到值会是上一次变化的值。
然后是react的生命周期，拿较为常用的componentDidMount与componentDidUpdate进行举例，componentDidMount：该方法会在组件已经被渲染到 DOM 中后运行，但我个人比较简单粗暴的记忆方法是当你看到页面内容之前执行一次。比如页面需要某些数据时，在这个方法中执行获取数据的具体方法并交给state对象，当页面完全加载完成后就会展示出这些数据。（官方文档原话:componentDidMount() 会在组件挂载后（插入 DOM 树中）立即调用。依赖于 DOM 节点的初始化应该放在这里。如需通过网络请求获取数据，此处是实例化请求的好地方）；
componentDidUpdate：这个方法是当某一props或state发生变化时调用，最常见的用法是componentDidUpdate(prevProps) {
if (this.props.userID !== prevProps.userID) {
this.fetchData(this.props.userID);}
}，
这个方法在比较变量更新变化应该做什么处理时，更为好用。
关于react的hook写法，个人比较推荐这种写法，虽然不至于完全取代class类的写法，但这是react的大体趋势，这里与class没有过多的区别，本人认为最大的区别就是对生命周期的使用。Hook的生命周期用法更加简单简洁，
useEffect(() => {
console.log(6666)
}, [count]); // 仅在 count 更改时打印6666
这个useEffect的第二个参数更加好理解，react会监听这里的‘count’，只有它发生变化时才会执行里面的主题代码，当然不只监听一个变量，可以是很多个。
关于组件化开发：react最强大的地方就是组件化开发。日常开发中，比如某一工具会在多处使用到，就可以把这个工具单独写成一个组件，在使用时直接导入该组件并配置上所需的一些属性或方法就可以直接使用了。或者是开发某一较为复杂的页面时，可以将同一部分或内容独立抽离成一个组件，在另一文件下进行开发，如下图：
这样的风格充分利用了react的组件化开发，不仅阅读与维护更加简洁明了，同时也提高了多人协作时的效率。
善于封装全局高频率使用的小组件：比如‘img’。使用img标签时，经常要考虑到当路径错误或无法正常加载图片时，如何设置默认的兜底图，虽然处理该事件较为简单，但是每用到一次就要配置一次，还是比较麻烦的。所以封装一个全局的img组件是有必要的。比如下面代码：
该组件会监视传进来的图片路径，配合key属性，会保证当前显示的为最新数据的图片路径，使用时也更加便捷，使用示例：
只需传入动态路径、兜底路径已经唯一的标识键就可以放心使用了，减少了每次引用原生img标签时的容错操作。
关于antd：这是一个封装好的插件工具，提供了大量项目中会用到的各类常见插件，当然，像这种插件，没有必要各个都非常熟悉，但一些通用的常用属性或方法还是应该多记一记的，或者是把感兴趣的东西写个demo，以便记忆与理解。平时多看一看，心中有个印象，用的时候就很自然的有‘有个东西好像和我要用的是一样的’印象了。
关于具体功能开发：以前有段时间光顾实现目的，而忽略了代码本身，比如明明可以20行完成，而我绕来绕去50行写完，即使意识到这种写法不好，也不愿意主动去优化，从而导致被项目负责人多次提醒。应杜绝这种陋习，当实现与验证功能后，做一次优化，写一下该有的注释，否则就是给自己挖坑，同时也给他人带来一定的不必要的麻烦。
关于前后端的联调，当进行到这里的时候，静态页面与逻辑方法也基本写完，但自己造的假数据与后台返回的真实数据还是有一定的出入的，因此联调是一个很重要的开发环节。关于联调，主要关注这两个地方：想要的数据与返回的数据是否对齐、请求参数与请求的时机是否正确。如果数据没有对齐，要么我们自己进行数据处理，要么由后端同学处理好后再返回给我们；什么条件下调什么接口，传参的格式正确配置。如果保证这两点，那么基本就不会出现什么错误情况了。在这里推荐一个小工具，就是JSON在线解析，有些情况后端同学会直接给一个JSON格式的字符串，我们调试的时候阅读很麻烦，用这个在线解析，就会显示出具有层级关系的数据格式，比较好用。
以上就是本人半年来积累的一些实际经验，虽然含金量不高，但也算情真意切哈哈，大佬们看到这些可能会想起刚入职的情形，入职不久的同学们读后也是一个相互学习的过程，如果有表述不对的地方也希望大家不吝赐教，一起共同进步，感谢有你，期待相遇！
