# 那些我在 mopcon 資訊組體悟的事情

## 前言

當參加一個活動或是要投入一件事情，一定要想清楚自己到底具體想要什麼，過去的我常常參與活動的時候就是覺得可以學到某些東西，但是我自己又說不出某些東西是什麼東西，導致我最後浪費了時間還要去怪罪說這些活動沒有讓我有學到東西的感覺。這六個月來我參與 mopcon 資訊組，我最初想得到的就是參與開源軟體的共同開發經驗，我得到了比我想像中還要多的東西，寫這篇就是希望如果有人也想要參與，雖然無法保證你跟我的體悟會完全一樣，但是多少你可以參考我在其中所獲的的收穫，問問自己這些東西是你在這個活動想得到的嗎?

## 做事方法

### 非同步工作法

我在大學修課的時候，往往會遇到通識課，大家就會說我們要約一天來做報告，然後就會發生一種情況

有三種工作
1. 找資料 <- 分配給 A
2. 做 ppt <- 分配給 B
3. 上台報告 <- 分配給 C

然後到了約出來做報告那天，A 就開始查資料，剩下 BC 就開始發呆聊天划手機。找完資料了換 B 做ppt AC 就開始發呆聊天划手機。在 C 練習上台報告的內容時，AB 就開始發呆聊天划手機。因此每次做報告，其實大家都只有 1/3 的時間有產值 (假設三人工作量且效率相等)。
以上這種工作方法稱為同步工作法。然而 mopcon 資訊組採用的是非同步工作法，個人覺得非常像 cpu 中 master(主)-slave(奴) 的運作方式。
組長會去安排工作的時程，有事情來的時候，組長(master)就會把事情分配到對應的人(組員 slave)，這樣做相比於同步方法有幾個好處
1. 不用一直約會議，浪費對當下問題不相干的人的時間
2. 做事情的時間彈性，不需要綁死在約好的時間才能做

但也有壞處
1. 如果有人一直不做，但是其他人又要他做完之後才能做怎麼辦?(大學生會約出來的主要原因，因為叫大家回去做都沒人做zzz)
2. 溝通上會比較不即時，有需要合作的部分就比較困難

資訊組以四個方法解決以上問題
1. 以下面的 sprint 工作法監督事情的進度
2. 如果有問題會在 issue 上面留下問題，並且對應的人有空就上去回答，雖然不是向現場一樣立刻回應，但在問題沒有很複雜的情況下是可以運作的
> issue 在英文的意思上為議題，在程式開發中就是針對這隻程式所要改的地方的一些議題，大家會在這上面討論要怎麼樣修改程式。
> [name=Zames]
4. 每個月一次的同步線上會議，一次解決當月累積下來在 issue 上無法解決的問題。
5. 直接敲對應的人(有時候會造成問題被問很多次的情況，因此最好在 issue 上討論大家就都看的到)

### sprint 工作法

先解釋什麼是 sprint ，sprint 是一個時間單位，可以是一個禮拜或是兩個禮拜，mopcon 資訊組是兩個禮拜，一開始會有一個空的 working queue(空的工作列)


每一個 sprint 會做以下的事情
1. 討論需求
2. 把需求丟到 queue 中
3. 從 queue 拿出需求並寫成 issue
4. 將 issue 分配工作給對應的人
5. 將完成的 issue 分配到已完成的地方
6. 檢查這個 sprint 進度有沒有落後的 issue

### MOPCON軟體開發流程
最重要的有兩個環境

1. 穩定的主要環境(master)
2. 開發用的環境(develop)

平常主要開發完任何新功能都會優先更新在 develop 環境上，等到測試一段時間發現沒問題就會再把 develop 與 master 做合併以更新穩定的版本。
當我們要開發一個新功能的時候，會先 fork 該專案，然後基於 develop 的版本上新增一個新的分支
e.g. `feature/mopcon-api`
基於這個分支開發你被分配的 issue 內容，然後發出 pull request。每一個 pull request 都會經過三關才能被 merge。
1. reviewer 認可你的程式沒有需要修改的地方
2. 自動化測試(CI)是沒有問題的
3. 與現有的專案沒有 conflict

然後組長就會幫你把 code merge 進入專案中。

## 待人處事
這篇的內容非常主觀，因為待人處事本來就沒有正確答案，只是以我狹小的目光配合我的少少的人生經驗暫時統整出來的一點小小心得，會覺得不認同很正常，也很歡迎你們跟我討論。
### 怎麼樣的人可以帶你成長
在寫程式領域，只有匠人能夠帶你成長。人成長的養分有兩個來源，一個是高人，一個是資源。高人能夠直接的指導你知識，在你不會的提供你協助，甚至指出你不自己沒發現但是不正確的地方。資源可以是讓你嘗試的機會，也可以是錢，可以是好的器材等等。
我過去曾在微軟實習過，帶我的主管不是一名專業的程式設計師，他給予我許多資源，像是 azure 很高的額度讓我去嘗試各種服務，也帶我參加微軟內部的黑客松等等，雖然他如此認真地給予我資源，但是我自認我沒學到太多東西，我覺得有兩個理由
1. 他無法評估我現在的程度，因此不知道我會什麼我欠缺什麼，也更無法給我難度適中的挑戰
2. 他不知道對軟體工程師來說甚麼方向的知識是重要的

因此他無法引領我對的方向，也無法給我相應程度的挑戰，導致我沒有辦法學到甚麼東西。

但是匠人(高人)不同，一個匠人一看就知道你的程度在哪邊，你所欠缺的知識，因為 CS 東西多如毛，常常是你自己都不知道自己不會什麼，有人告訴你缺乏甚麼挺重要的，他因為了解怎樣的方向是對的，更了解你的程度，因此在分配給你工作時候會給你能夠成長但是有點小困難的任務給你，你更可以透過看他過去的程式碼來加速學習，不會的時候更會協助你解決問題，所以我覺得高人與資源，高人主管的重要性遠勝有資源的主管。

### 關心人就是關心工作進度

我們組長很暖，會在我 pr 修改很多次的時候，來關心會不會讓我覺得氣餒，也會一直詢問我有沒有問題，更會用引導式的方式來讓我自己發現問題在哪邊(不過有時候引導半天我還是不知道他在講什麼?ㄏㄏ)，這樣的態度讓有種我也不能辜負他的心理，這點他很成功，讓我不再只是害怕進度 delay 而去工作，而是會主動地想要盡快完成他交代的事情。
### 勢

我曾在大學修過 李家岩 老師的 企業參謀思維課程，其中提到如果你想改變人的想法，不是直接跟他講你該怎麼做，而是去改變他身邊的環境，而他稱身邊的環境為勢。舉例來說，老闆跟你說早點下班，結果你身邊的同事都還沒下班，你敢自己下班嗎？也許有人敢，但我想多數人會選擇留下來加班。可以看出，往往影響你決定的不是別人對你說甚麼，而是你身邊的人做什麼。

在這次的 mopcon 中我就體悟到老師所說的內容
#### 事件1

組長希望大家可以在群組多多討論，不要害怕，但是大家還是比較少在群組討論，他就希望我可以有問題都放到群組上盡量別用私他的方式，因為這樣可以讓大家知道有問題也是可以在群組上討論的。

#### 事件2

組長希望大家如果有困難，不能工作可以自由提出，可是他怕有些人會硬撐，明明不太方便也要說沒事，就希望我可以在我需要休息的時候在群組上跟大家說，然後他再同意，這樣大家就會知道，想休息不要有壓力只要提出都是沒什麼問題的。

#### 事件3

我在聽完一場演講之後，我答應要幫我朋友跟講者要名片，明明一開始大家也沒有人跟他要名片，但是我跟他要了之後大家就紛紛跟他拿了名片，就這樣大家都拿了一輪，但是大家真的是有需要跟他拿名片嗎？我很懷疑。

**影響你決定的不是別人對你說甚麼，而是你身邊的人做什麼。**

## 程式技巧
### 規劃 api spec
學習到根據設計組提供的 app 和官網界面決定後端的 api 要提供怎樣的資料，規劃完 api 的 spec之後交給前端工程師，讓他確認這樣的資料對他們來說是足夠的，確認後就根據 spec 把內容開發出來，這樣就不會開發完之後才發現說資料有少給，api 要頻繁更動造成更大的成本。
### error handling
剛開始我的 error handing 長這樣，這樣超醜，因為每次做一件事我就要擔心受怕的用 if 去檢查回傳的結果是不是正確的。

<?php
class ifElseErrorHanding {
    function public index(){
        result = requestMopcon();
        if(! result){
            return $self->error(1);
        }
        result2 = requestMopcon2();
        if(! result2){
            return $self->error(2);
        }
        result3 = requestMopcon3();
        if(! result3){
            return $self->error(3);
        }
        return success();
    }
}

但是我學習後才知道 try catch 的美好，同樣的 code 就會變成這樣

<?php
class ifElseErrorHanding {
    function public index(){
        try{
            result = requestMopcon();
            result2 = requestMopcon2();
            result3 = requestMopcon3();
        } catch($e) {
            return $self->error($e);
        }
        return success();
    }
}

### 統一的抽象化界面
組長定義的介面，統一了所有人 return 的格式，不會再發生後端組 return 格式常常因為不同人寫而差距很大 (同一個人也會不一樣)，我從中學到這個漂亮的作法。

<?php
namespace App\Http\Controllers;
trait ApiTrait
{
    /**
     * Api Controller return success response
     *
     * @param string $message
     * @param array  $data
     * @param array  $field
     * @return mixed
     */
    public function returnSuccess($message = '', $data = [], $field = [])
    {
        $field['data'] = $data;
        return response()->json(array_merge([
            'success' => true,
            'message' => $message,
        ], $field), 200);
    }
    /**
     * return bad request status response
     *
     * @param string $message
     * @param array $data
     * @return \Illuminate\Http\JsonResponse
     */
    public function returnError($message = '', $data = [])
    {
        return response()->json([
            'success' => false,
            'message' => $message,
            'data'    => $data
        ], 400);
    }

### Response 過慢
我所負責撰寫的 facebook api功能中，由於 fb 回應速度過慢導致我的 api 速度上表現不好，因此開始被要求加上 redis 的快取功能，這是我第一次使用 redis 這種快取的 server。
### 如何結合大地遊戲與app
我在過程學習到，一個簡單的大地遊戲，想要透過 app 來認證每一關是否有通過，乃至到最後要領獎，我要怎麼樣設計一個 restful 的後端來完成這些功能。

剩下的東西太多了，其實在每一次的 pull request 中，組長跟組員給我的回饋都讓我學習到更多知識，我也很難解釋完。
## 後記
mopcon 結束後，大家去酒店吃慶功宴，在結束要離開的時候，有一個臉黑黑的阿北問我說你們是哪個組織阿，我溫和卻鏗鏘有力地回他: 我們是 mopcon，認同與自豪，就是我當下的心情吧。

喔對了，資訊組有點花時間，忘了講。