1. 程式人生 > >【碼農日記01】一個很有意思的想法

【碼農日記01】一個很有意思的想法

  既然選擇了就用心去玩味,不喜歡就放下,少一點抱怨和徘徊,人生短短几十年,認定就去做!不知道下一步該怎麼走,就做好當下的事!——share猿

時間:2018-11-16

天氣:多雲轉小雨

星期:星期四

  我是一名奮鬥在二線城市的菜鳥級程式設計師,大學學的製藥工程,從大二開始就一直想自己未來要做什麼?大學畢業要什麼?想通了未來要做什麼,未來要做一名企業家,為這個社會創造更大的價值,但不知道下一步該如何走。終於在大三的時候我想通了,我要進入網際網路行業,怎麼進入那?就在自己猶豫不決時,一個院系的小夥子給了我思路,學軟體,搞程式設計,就這樣入了這個坑,後來在我小姨家哥的幫助下選擇了java這門高大上的語言,真的是一入java深似海呀!到大三下半學期開始自學,除了考二級的時候學過一點vb,再根本沒有一點軟體基礎,現在想想真的佩服自己當時的勇氣,每天抱著電腦看傳智播客的視訊,剛開始看的那種感覺真心難受,一遍看完根本不知道人家在說什麼,強忍著淚花把這一套視訊看完,看完感覺跟沒看差不多。

  後來,在一次和發小聊天中瞭解到,他也是做軟體開發的,我諮詢了他讓他給我一點建議,他建議我想找一份實習的工作,然後邊幹邊學習,慢慢的就提高了!我要到了他們公司人事的電話,溝通過後在智聯招聘上投了簡歷,很幸運約到了面試,面試當天穿的西裝革履,帶著列印的彩色簡歷,現在想想真的很懷戀那時候對一件事的堅持和熱情,有時候對人對事的態度真的很重要,一件事一個人你從內心用什麼態度一般情況下就會預示著未來會取得什麼樣的結果,用真心去生活真的很重要,知道自己要什麼?做什麼?未來要成為什麼樣的人?心中要有尺度!面試過後我也入願進入一家在家鄉比較大的軟體公司開始了我的軟體生涯,一直到現在,在這兒過程中遇到了很多挫折,好多問題其實只要別人指導一下就可以解決,但是死磕到底雖然解決了問題但是效率不高,沒有真正將時間用在刀刃上,為此那我想通過記錄我這個菜鳥每天的軟體歷程以及在日常工作的所感所悟記錄下來,希望能給這個行業帶來一些價值,為這個社會帶來一些價值,我認為一個人活著的意義在於創造。

想法

  把自己在軟體行業的每天所感所悟所學記錄下來,一方面作為自己對一天生活的總結和下一天生活的計劃,另一方面希冀能夠為共同奮鬥在一線行業的同行們提供一些行業知識的素材,可能我的諸多理解很淺顯或者是錯的,大家可以提出來指正,把我們共同的故事記錄在這裡為後來人帶來些許幫助。

日記更新週期

  工作日必更,節假日看更!

今日曆程

  今天的主要工作是大家在一起測試各自的介面,為什麼大家要做在一起測,老大說大家做在一起測試一方面可以測試出介面存在的問題,同時大家可以在一起商量重構程式碼和整體的架構微調,大家不做在一個桌面上,有些問題是沒辦法暴露出來的,團隊成員也感知不到各自之間的差距,大家做到一起才能真正的切實感觸到,事實證明這次測試效果很好。

  比較遺憾的是我今天沒有準備充分,耽誤了大家很多時間我感到很愧疚。究其原因主要在自己對每天的工作沒有計劃導致的,尤其像這種團體性活動更不能粗心大意,不然到頭你耽誤的是大家的時間,每人十分鐘一個小時就過去了,這是赤裸裸的“謀財害命”,只有尊重大家的時間才能得到大家的尊重,我深刻的檢討自己此次在工作中的失誤,那麼在介面測試中需要做什麼預備工作那???我簡單的列舉一下我的總結,大家如果覺得缺少什麼可以在評論中做以補充,謝謝!

  • 筆記本準備(我本次就是因為安裝了ubuntu桌面版的系統沒有安裝好相關軟體耽誤了大家的時間)
  • 程式碼規範約文件
  • 測試環境
  • 測試資料
  • postman介面整理
  • 介面文件整理

  相信經過以上的準備,大家在一起測介面的過程中會事半功倍,效率更高。在測試的過程中要及時的記錄問題,梳理成文件,方便團隊成員之間進行查閱,因為好多問題都是共性的問題,一旦發現成員在下去就可以及時修改,這是一個良性迴圈,這樣在後面問題也會越來越少,測試效率也越來越高。

本次測試過程中我總體感覺是沒有秩序,究其原因我總結了以下幾點:

  • 流程不明確(大家一起先測介面還是先看程式碼,介面測試是先測介面是否正常還是先測引數問題等等我覺得這些都是可以流程化的東西)

  • 準備資料不全(比如:postman介面誰開發的就可以誰錄好,大家共同登入,因為postman本然就是可以多人同時線上的,或者匯出來發給大家。)

在本次測試中也發現了很多問題,讓我受益良多,下面我一一列舉。

  • 沒有定義規範導致在開發過程中團隊成員之間程式碼每個人都不一樣。比如註釋規範沒有定義導致出現了多種不同的註釋方式,路徑命名規定沒定義,有的人在路徑前面加了api/v1(加這個的意義在於程式碼的升級),大家引用的常量不一樣,通用欄位的命名和型別長度不一樣,處理異常的方式不一樣,返回碼不統一,校驗方式不統一等等,我個人認為,這些事應當是架構師統一去約定和規範,好的架構師一方面要保證架構的穩定,同時還要約定要規範,包裝好一些通用的東西,這樣才能讓下面的人更好的去開發。

  • 列舉型別沒有檢驗。在java的引數檢驗中我們常用封裝好Spring-validate進行校驗,這裡只提供一些基本的檢驗,比如非空校驗、長度檢驗。要檢驗列舉我們只能自己自定義註解去校驗了,自定義註解我們可以在網上搜到,這裡不做過多的闡述,大家可以自己去尋找,總結出自己的套路和方法,好多事情沒有咱們想的那麼難。

  • 介面要保持單一性。在這次測試過程中遇到一個問題,我把新增和編輯寫成了同一個介面,我們在常規作miss系統的過程中一般是這樣去做的,但是在介面開發中為什麼要分開那?聽了老大的講解後恍然大悟,分開確實有分開的道理,首先是方便前端人員的對接,另一方面新增和編輯裡面的邏輯也不一樣,分開可以處理各自的業務和邏輯。

  • 給前端返回實體。在miss系統中我們一般是全部返回的,但是在介面開發中,前端需要什麼就返回什麼,我們可以新定義一個vo去返回給前端,這樣一方面避免把自己的資料庫結構爆露出去,防止敏感欄位的洩漏,讓對接的介面的前端人員也更加舒服,讓自己程式碼可讀性好,讓別人看著自己程式碼或者文件舒心這是程式設計師的基本素養。在實體相關值複製到vo的過程中,我一開始用的BeanUtis去copy的,但是大家說這樣效率有點低下可以用Json進行復制效率相對高一點。

感悟

  牛逼的技術非一日之功,要沉下心慢慢去沉澱,多向身邊的人去學習,學識不分大小,這個行業不分資歷只憑學識,活到老學到老。

  今天的日記就寫到這裡,第一天寫有諸多的不足,希望大家及時提出,我不怕噴。

掃描以下公眾號關注小猿↓↓↓↓↓↓↓↓

更多資訊請在簡書、掘金、CSDN都可以通過搜尋**“Share猿”**找到小猿哦!!!