前端工做流(draft)

一 前端工做流

   爲了簡化開發流程，提升開發效果，同時研究下桌面app開發。 寫了一個靈通工做流app。 整個app的技術棧 是electron + react + antd。github地址：https://github.com/azl397985856/electron-work-flow

效果大概是這樣:

     預期想要實現的目標就是簡化開發編譯以及發佈的流程。功能還沒作，正在設計整個功能和交互。不過應該能夠從界面看出來要作什麼吧

二  關於註釋與文檔

     不少人說盡可能多寫註釋。 而個人見解可能有點偏激，儘可能少些註釋，若是必需要寫，那必定是業務註釋。 這時候就要考慮業務複雜性，若是業務比較複雜，考慮抽出單獨的文檔，若是不復雜能夠簡練的講述下業務背景便可。 java 有java-doc 能夠將註釋函數簽名生成對應doc， js 有js-doc。然並卵。

    我認爲一個合理有效的作法是，少些註釋，多寫文檔。這樣能夠逐漸將業務邏輯拆離出來，漸漸的培養開發者習慣。 如今MarkDowm很是火，語法簡練，表達性強。github上的readme， issue 等都支持markdown語法。 假如咱們將將業務抽到文檔，咱們就擁有了將文檔生成網站的可能性。 若是把文檔當作是數據， 再加上 theme， 咱們即可以經過一個庫將MD文檔轉化爲網站，豈不是更提升了文檔的可讀性。antd的官網就是基於這個思想的具體實現：

三 中間件機制開發

    中間件的概念相信你們已經不陌生了。 express ， koa 中的 middleware。 redux 中也有middleware。  spring 的 攔截器也是middleware。 一個經常使用的用法就是打印日誌。 那麼這種思想能夠給咱們帶來什麼？ react設計的生命週期使得咱們能夠在組件各個階段控制組件的行爲和渲染。 So what。 假如我正在開發一個公共的組件，如何保持它的簡單性和擴展性？ 原則是咱們只提供最基本的功能，其餘enhancement 若是須要能夠以插件的方式擴展。只要插件實現了個人接口就好了，這麼說可能比較抽象

舉個栗子,咱們寫了一個koa，koa使用中間件的過程大概這樣（僞代碼）：

_pipe(scanPlugin, loadPlugin)();

series([
    // 執行全部註冊到 middleware.before 時間點的插件。
    next => _applyPlugins('middleware.before', next),
    // 執行全部註冊到 middleware 時間點的插件，app 實例會傳遞給插件，用來經過調用`app.use()`註冊 koa 中間件。
    next => _applyPlugins('middleware', next),
    // 執行全部註冊到 middleware.after 時間點的插件。
    next => _applyPlugins('middleware.after', next),
    next => { server = context.server = http.createServer(app.callback()); next(); },
    // 執行全部註冊到 server.before 時間點的插件。
    next => _applyPlugins('server.before', next),
    next => {
      server.listen(port, () => {
        next();
      });
    },
    // 執行全部註冊到 server.after 時間點的插件。
    next => _applyPlugins('server.after', next),
  ], callback);

koa插件註冊過程大概這樣（僞代碼）：

import webpack;
import koa-webpack-dev-middleware;
let webpackConfig;

module.exports = {
  'middleware.before': () => {
    // 獲取默認的 webpack 配置，並和用戶項目裏面的自定義配置合併。
    webpackConfig = getAndMergeConfig();
  },
  'middleware': (args, pluginArgs) => {
    // 返回 koa-webpack-dev-middleware 組件產生的 koa 中間件。
    const comiper = webpack.compiper(webpackConfig);
    return koa-webpack-dev-middleware(compiper)
  },
  'middleware.after': () => { // do nothing },
  'server.after': () => {
    console.log('koa-plugin-webpack-server ready.');
  }
};

這樣若是須要一個新的功能，那麼用戶自定義一個插件，配置一下就OK了。 既知足MVP原則，又提升了軟件的擴展性

四 日誌和崩潰記錄

    以前寫了一個文章《太極生兩儀，兩儀生四象》， 第一條提到了 performance  and crash reporter.也有人在評論中提到window.onerror不靠譜，沒法提供足夠追蹤的信息。那麼如今來看一下怎麼構建一個足夠追蹤問題的信息。 咱們的目的是構建一個完整的第三方系統，以便於其餘項目無縫接入。這裏有一個成功的項目，叫rollbar， 和咱們要作的工做頗爲類似。你們能夠上官網簡單看下介紹。 https://rollbar.com/ 固然人家提供的功能足夠牛逼，有免費版和收費版。好了，開始咱們的構建：

     這裏只講下 crashReporter。 下面是我從另一個有名的crashReporter website  sentry抄過來的東西，前端的錯誤收集的實現是raven.js能夠看出它確實能夠給咱們帶來不少好處

從上面能夠看出，作一個完整的cr(crash reporter)有兩件事：

1. 客戶端

2. 服務器

爲了避免重複造輪子，我找了一個很老的一個庫叫ejs， 最近這個項目遷移到了logger項目， 它能夠提供verbose error message也就是說咱們能夠直接拿過來logger改下做爲咱們的客戶端。@

code ：

//Request type is POST

Logerr.init({
  remoteLogging: true,
  remoteSettings: {
    url: 'REMOTE_URL',
    additionalParams: {
      logged_by: 'Sam'
    },
    successCallback: function () {
      console.log('Im logged.');
    },
    errorCallback: function () {
      console.log('Err! Something went wrong.');
    }
  }
});

output（also payload send to remote server）：

Type: error
Error: Uncaught ReferenceError: a is not defined
File Name: logerr.js
Path: http://localhost:8888/logerr/logerr.js
Line: 51
Column: 12
Date: Tue Jun 28 2016 19:51:22 GMT+0530 (IST)
Debug: http://localhost:8888/logerr/logerr.js:51
Get Help: https://stackoverflow.com/search?q=Uncaught+ReferenceError:+a+is+not+defined

那麼假設第三方登陸服務器已經存在的狀況下，我須要一個crashReporter Server。 server 很簡單就是根據客戶端發送的payload ，結合用戶session 顯示對應的錯誤信息列表，而且具備查詢功能

 

五 SQL

六 調試

條件斷點   XHR斷點   element 斷點

七 Borrow method