转前端开发的“苦逼”记录 二
时间紧，任务重，一脸懵逼，这是我刚进到这个组的第一感受。公司还是很开明，自打我申请做前端之后不久就分到了这个项目。项目使用Xamarin.Forms开发，简单说来就是类似于WPF那一套东东的跨平台框架。（当然WPF我也不是很熟悉，苦笑）。老大们的意思是除去一些别的原因外，Xamarin也是基于C#，所以可能相对来说我更好上手一些。没想到这一上手就开启了“无尽”的加班模式。
业务流程不长，只有几个页面，对应一些基础的增删改查的功能，并且前端除我之外还有另一个精通WPF的大佬一起开发，所以我还是很有信心完成任务的。然而理想总是与现实有不小的差距。大佬除这个项目之外还要参与维护另外的一些项目，所以不能全天放在这个项目上。并且因为一些原因，大佬中间还请了一周的假。知道这个消息时，我的内心是崩溃的。毕竟之前对前端的内容可以说是一无所知，只能硬着头皮上了。
记得刚上大学的时候军训，教官和我们讲“逼一逼自己，否则就不知道自己的潜力有多少。”没办法，不懂的东西就学吧，做得慢的东西就多花点时间罢。最终，四个周末里加了六天班，算是把这个项目啃下来了。我这个人对技术大佬有一种天生的崇拜。有一说一，同组的这个大佬技术方面很牛，代码很优雅，看起来很舒服。虽然比起刚毕业时我自己的代码也有了不少进步，但还是远达不到这种水平。但技术以外的方面，比起之前的领导，其实我是有点失望的。大家应该都明白，一个项目的生命周期中远不止“写代码”这一部分，至少还包含需求分析，计划安排，任务分配，功能实现，代码评审，测试等多个方面。但这位大佬似乎只关心自己所负责的功能的实现这一部分了。也不是说我不愿意承担更多的责任，但我加班到十点，您五点半下班。我周末来两天，您周末双休是不是有点过分？后来项目经理也找我谈过这位大佬的一些情况，要接送小孩上下学什么的，我只能说我尽量去理解吧。只是这样的对比，多少心里有些不爽。
之前的博文有说过，遇到好的技术领导会帮助你很多，另外遇到不靠谱，不管事的技术领导其实也一样，因为坑要你一个一个踩。虽说按时完成了，但要我让我自己评价这次的代码质量的话，我只能说一团奇妙的组合在一起能运行的垃圾。（主要指的是我写的那一部分，苦笑）。虽然这次少了很重要的代码评审的环节，但代码写的烂根源还是在我身上。时间太紧，开发过程中大佬的经常性请假，又更加重了我这边的任务。而我在此之前对前端内容又不是很了解，只能一边查资料，一边做功能，一边修bug，一边调样式，恨不得一心多用。
但也是因为这样，整个前端项目中涉及到的各个方面都了解到了。虽说Xamarin很小众，但我想相对其他的前端开发语言来说，本质还是一样的。一个移动应用，怎样也逃不过页面样式，用户交互，数据存储，与后台数据交互，错误处理等几个方面，而什么时候应该用什么东西做什么事，我也多少有了一些了解。有时结合之前一些做后端开发的经验，看问题的角度确实有了变化。并且和后端小伙伴集成时也能理解他们开发过程的一些难处。并且有一点感到很惭愧，之前做后端的时候设计接口，model的定义很多时候没有经过深刻的思考，导致前端同事的“返工”。还在写API的日子里，觉得不就是多个少个字段，把一个list放到一个对象里这些嘛，没什么大不了的。但现在才意识到，也许你只是觉得你改变了一个字段的类型，或者稍微改了一下结构，但对前端的影响可能是巨大的。另外一个深刻的感受在代码的健壮性方面。做后端开发时，某个异常没有catch到，无非就是某个接口返回值错误，或者严重一些500错误了，当然也比较严重，但还是没能引起足够的重视。App这边就不一样了，同样是一个异常，可能导致你整个应用崩溃掉，如果是某些复杂的一连串的操作，可能你前面的操作全部作废了。并且对客户来说，经常闪退的应用是极度讨厌的。而导致闪退的可能仅仅是某个小小的错误。
有的人是用一年的工作经验工作了十年，有的人是十年的工作经验。两者的差别我想在于反思与总结。这次的代码很烂，开发过程也很艰辛，问题在哪里呢？
- 我使用的是Visual Studio for Mac，大佬使用的Visual Studio然后remote到另一台Mac上进行开发。虽然后来我们都使用了Xaml Style这样的工具，但仍存在一些format的问题。而这些format导致了我在merge代码时有时会出现整个文件冲突的情况，合并起来费时费力。
- 我对git命令行操作很有兴趣，并且觉得这样做很“酷”，是“程序员该有的样子”。虽然整个项目中我也没有因为git的使用而出现什么差错，但相比起来SourceTree，fork这些工具，效率真是低多了。尤其是出现冲突时。我的问题，应该合理的利用工具。
- Visual Studio的强大众所周知，怀着这样的想法，踏上了Visual Studio for Mac的贼船。结果是不停的卡顿，几个小时一次的崩溃，莫名其妙的监听不到断点，时不时的不响应，真的很无奈。希望Visual Studio for Mac能越来越好吧，但项目早起我就应该再申请个Windows的机器来remote到Mac上的。
- 代码方面，页面布局大量的使用了hard code，导致有时设计上的一个小改动，我需要调整的地方很多很多。其实这个问题我一直在想办法解决，但闭门造车，没想到一个好的办法。问题根源在于，单看设计稿，我是可以确定一些比较共用的样式与颜色来作为资源。然后这些相同的地方去使用这个资源。比如Title可能和页面左上方的导航按钮，和下面Button是同一个颜色，但如果设计师在某次和客户的确认后只是更新了Button的颜色，我该怎么办呢？只是单独设置Button的颜色么，那么和现在的HardCode有什么区别? 另外我可能会观察到一些共用的Margin属性，但每个页面可能有一些细微的差别。这种时候我应该怎么做呢？是无视这些差别统一使用共用的Margin(与设计稿不符合)，还是为每个小改动单独设置Margin(和Hard code有什么区别)？如果有哪位园友能指点迷津，还望不吝赐教。
- 一些业务的处理，太接近底层的实现，不抽象，代码公用程度太低。比如根据某个布尔值去显示或隐藏某个button,项目初期我在每个地方都会去写一次转换布尔值的逻辑，后面才意识到有Converter这种东东。原因在于一方面对所使用的前端语言不够熟悉，另一方面过于在乎进度，忽略了“思考”的环节。换句话说，只想着砍柴，没想想怎么好好磨刀。
- 没有思考或者寻找一些“最佳实践”，很多时候做某个功能只是靠自己的YY，想了个大概，然后动手去做。比如一个Popup，单单弹出来是没问题，在模拟器上也可以比较好的运行。到真机上一运行才发现，真机上输入框会弹出一个虚拟键盘，而这个键盘影响了我的布局，导致这个Popup乱掉了。这个主要的原因在我，时间不充足没时间去研究也是一个方面，另外正常项目中的 代码评审 中应该也会减少一部分这样的情况。
- 心态上的问题，之前两年的后端经历中，基本不会遇上什么技术上的难题，即使有，也知道大概要往哪个方面去查找。而这次有很多时候我花了很多时间去解决的问题，其实只要很简单就能解决。我应该给自己设定一个时间，在某个问题上的研究超过了这个时间就积极的寻求帮助，也许别人早就遇到了这种情况，也许是你以为的问题的key不对，所以你花再多时间google可能也找不到想要的答案。
虽然很苦逼，被Xamarin.Forms + Visual Studio for Mac折磨的欲生欲死，但这么总结一下收获还是蛮多的。相较下来，我可能还是更喜欢后端开发一些，有了方向了，努力吧。
