2017年終總結(jié)

2017呢做了一份喜歡的工作，感謝領(lǐng)導(dǎo)讓我自由發(fā)揮。

首先談下思維的轉(zhuǎn)變，從一個(gè)程序員思維，慢慢向產(chǎn)品用戶思維轉(zhuǎn)變。這個(gè)過程其實(shí)是很痛苦，記得在做第一個(gè)產(chǎn)品原型的時(shí)候，心里一直嘀咕，太難了，不是我該做的事，需要一只產(chǎn)品狗來做，我還要寫程序，一直抵觸，而且其實(shí)邊想需求邊實(shí)施，時(shí)間和進(jìn)度不可控，導(dǎo)致進(jìn)度延后，這也是痛苦的一個(gè)原因。大概這么來回幾個(gè)月其實(shí)自己已經(jīng)適應(yīng)了多角色的擔(dān)當(dāng)，我覺得我現(xiàn)在可以做的更多。而且形成了一個(gè)善于發(fā)現(xiàn)問題然后去解決的思維，其實(shí)在整個(gè)move on的過程中，會遇到很多未知的東西，這其實(shí)是挑戰(zhàn)，過去的經(jīng)驗(yàn)和認(rèn)知不夠去處理這些挑戰(zhàn)，所以解決問題的思路就尤為重要，以產(chǎn)品體驗(yàn)為導(dǎo)向，體驗(yàn)不好的想辦法優(yōu)化，這個(gè)過程無形之中也在提升自己的技術(shù)水平。

第二呢，從編程的角度來說。當(dāng)時(shí)考慮到可能做項(xiàng)目的人不多，還需要做iOS和Android版，所以決定采用跨平臺的方案。

跨平臺的解決方案很多，以前也用純H5做過一個(gè)應(yīng)用，總的來說體驗(yàn)不是太好，所以選擇框架的時(shí)候，性能和生態(tài)這兩點(diǎn)應(yīng)該是考慮比較多的，當(dāng)然學(xué)習(xí)成本也要考慮。

比較過vue，react native , angular，weex之后，最后還是采用react native。react native最讓我看中的是前端解決不了的可以用原生來寫，其實(shí)這點(diǎn)就極大的超越了純H5框架。

在實(shí)施的過程中，還是體驗(yàn)到了學(xué)習(xí)門檻，我從零開始搭建環(huán)境，選擇各種框架，了解里面的各種概念、名詞，不懂的地方扒源碼，學(xué)習(xí)最新的es6的語法，解決各種奇葩的問題，優(yōu)化性能，從一個(gè)人開發(fā)到3個(gè)人協(xié)作的工作安排，到最后應(yīng)用上線。整個(gè)過程讓人興奮又疲憊，而且這還只是Android版的。

到了實(shí)施iOS版的時(shí)候，時(shí)間應(yīng)該是充裕畢，可是還是低估了iOS小白實(shí)施難度和蘋果嚴(yán)格的審核流程。

在預(yù)研的時(shí)候，糾結(jié)過用swift還是oc，因?yàn)閟wift和js相似的語法，會更容易上手，但最后還是采用oc是因?yàn)橐蚦語言混編，還有reactnative在oc的生態(tài)上更有優(yōu)勢。

開干之前首先擼了一遍Objective-C程序設(shè)計(jì)這本書，把oc語法、蘋果的UI框架和foundation框架熟悉一下，然后搭環(huán)境(其實(shí)只要下一個(gè)xcode)，熟悉xcode里各種配置，最后找?guī)讉€(gè)視頻看看，大概就知道怎么回事了。具體問題開發(fā)的時(shí)候再去解決。

這個(gè)應(yīng)用需要用oc寫的代碼包括藍(lán)牙連接、與設(shè)備通信的協(xié)議包裝與解析、一個(gè)原生界面、sqlite數(shù)據(jù)庫的管理，還有一些定時(shí)和并發(fā)的任務(wù)，這些有對應(yīng)的java代碼，可以看著java代碼的業(yè)務(wù)把oc擼一遍。

在應(yīng)用上appstore的時(shí)候，因?yàn)槭孪妊芯坎蛔惚获g回過許多次，其實(shí)可以提前根據(jù)前人總結(jié)的上架經(jīng)驗(yàn)減少駁回的次數(shù)。感謝同學(xué)和同事在我工作的過程中給我提供的指導(dǎo)和幫助，幫我少走了許多彎路。

以上大概總結(jié)了一下2017的工作內(nèi)容。