拒絕碼農 - 從自身做起

下文為文檔《報表需求 - 儀表盤樣式》中的一部分。

2016年11月21日 下午7:26

@XXX

  1. 箭頭下的百分比調整的樣式已套用,并已部署在測試環境。
  2. 服務器設置的百分比為正數時不顯示 +,負數會顯示 -
  3. 百分比長度測試未覆蓋,比如 12.3%, -12.3% 會樣式越出框線。(服務器百分比保留一位小數)

關于前端代碼思路、性能考慮、文字寫作提些建議:

  1. 帶著思考敲碼是開發者或工程師,堆積代碼是碼農。

    • 1.1 幽靈代碼

      # mobile_v2.1.css: 27-29
      .databox .databox-vertical .databox-top, .kpi-text-align-center {
          text-align: left!important;
      }
      

      為什么會出現這樣的代碼,類名寫的很清楚 *-text-align-center,它的作用就是讓文本水平居中,如果你想水平居左應該創建新類,名稱叫 *-text-align-left 才對。

      這樣指東說西的堆積代碼是不可能健壯穩定的,遲早會成為幽靈代碼;自己寫的代碼必須要知道它會如何運行,并一定這樣執行,使用你能想到的方式嘗試做到這一點。

      作業: 前端 javascript/css/images 命名規范。

    • 1.2 怕沖突為何還要繼續制造更沖突

      # mobile_v2_group_165_role_7_kpi.html: 14-15
      <link href="assets/stylesheets/mobile_v2.css?1479639589" media="screen" rel="stylesheet" type="text/css" />
      <link href="assets/stylesheets/mobile_v2.1.css?1479639589" media="screen" rel="stylesheet" type="text/css" />
      

      明明添加一個新類就可以解決的問題你使用了上述告訴別人居中,實際居左的幽靈寫法,怕繼續代碼沖突新建樣式腳本這種做法雖消極但也能接受,那為何還要加載可能沖突的樣式腳本文件?單文件內代碼可能沖突,把兩個樣式腳本文件放在一起豈不是更沖突?

      作業: 前端性能最佳實踐方式。

      • 1.3 沒有測試意識

        箭頭下的百分比數據是抽取代碼中沒有的,需要手工添加,為何那么多儀表盤框都只寫 +0.1%? 實際場景肯定不會這么單一,為何不把可能的幾種狀況都寫一下:

        • +0.1%
        • +10.1% (走到這里,樣式就開始失常)
        • +10.1%
        • +100.1%
        • ...(測試出樣式支持的最大字符長度)

        若是有測試意識的添加數據,上述問題會一步到位或減少交流次數,協作效率肯定是現在狀態的數倍。

        作業: 前端如何更高效率的與后臺開發同事協作。

  2. 做對僅僅是及格,如何做得更好,再更好

    當前已卡在第一條,強調這條似乎有些多余,但這條才是我們團隊要求的最基本條件。

    多加載一個樣式腳本文件會增加瀏覽器解析壓力,增大客戶端樣式文件體積,是在浪費各種資源。我們的目標在做減法,做減法與做加法的難度是不在同一個級別上的,是具有挑戰性的,雖然我們更多的是在做加法,但要有做減法的意識。

    搬磚是壘不出高樓大廈的,更何況我們想建造的是摩天大樓。albert 與每位團隊成員都有過單獨交流并有這樣的契約:設定自己的目標同時團隊協助他成長,這就是為什么簡單的一件工作協作小問題引出這么一大段反饋的原因。

  3. 文字寫作

    有一個時間段說不上時間長也不算短大概一個月多點,讓大家熟悉使用 markdown 語法寫作任何工作交流文檔,甚至后來進來的同事在考核測試任務中都包括使用 markdown 寫作。

    大家每天都在使用 markdown 寫工作日志,應該熟能生巧才對,可現在的工作文檔內容不得不說日漸凌亂,一直在用的東西都沒有充分吸收,不知道該如何描述這種感覺,想的東西做出來或在努力的嘗試做出來才能得到別人的尊重,否則堂而皇之說自己想變得更強更棒永遠都是笑話。

    該段落小標題是文字寫作,鍵盤敲出來的都是文字,碼農搬碼算不得寫作,日常交流中詞不達意、錯字連篇的文檔都算不上寫作,其實寫作就是一種態度,用心想、用心寫、用心交流,公司項目文件夾中稱得上寫作的文檔太少。

    延伸一下用心交流,希望各位在點擊發送、共享前再認真閱讀一遍,大家協作的是工作,而非因你的亂語、錯字反問具體想表達什么意思,做好這一點我想相信對大家的生活習慣也會有益處。

    項目中的每一行代碼、每一段文字、每一張圖片都需要大家用心琢磨如何才能做得更好,大前提是要了解項目中有那些代碼、文字、圖片,這個需要大家自覺去理。工作職位是明確的,那你知道項目中那些模塊是需要你負責的嗎?

第一條是針對代碼問題反饋給XXX的建議,其他兩條是寫給每一位同事的,每個成員都是管理者,都具有發言權。

我希望團隊更好更棒更強,今天我發言。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • Android 自定義View的各種姿勢1 Activity的顯示之ViewRootImpl詳解 Activity...
    passiontim閱讀 173,373評論 25 708
  • 問答題47 /72 常見瀏覽器兼容性問題與解決方案? 參考答案 (1)瀏覽器兼容問題一:不同瀏覽器的標簽默認的外補...
    _Yfling閱讀 13,805評論 1 92
  • Spring Cloud為開發人員提供了快速構建分布式系統中一些常見模式的工具(例如配置管理,服務發現,斷路器,智...
    卡卡羅2017閱讀 134,948評論 18 139
  • ¥開啟¥ 【iAPP實現進入界面執行逐一顯】 〖2017-08-25 15:22:14〗 《//首先開一個線程,因...
    小菜c閱讀 6,535評論 0 17
  • 女孩,如果你很幸運,20歲出頭有個愛你的男孩子,勇敢的對你說“我養你”。請你感動的同時,理智的思考自己到底想要什么...
    懶懶豬豬閱讀 405評論 1 0