元哥的筆記

職f涯地圖發展

https://dotblogs.com.tw/regionbbs/2011/12/15/62133
團體工作注意事項

1.交代事情紀錄不確實，容易忘。

2.你永遠要記得, 不只這裡, 外面也一樣, 一個team有一個team日常的默契與用語,

  就像我們的程式命名規範一樣你只想自己的用自己的說自己的, 永遠沒辦法溝通,

  就像全部人命名規則用，駝峰式命名法,你非要用一個中文命名(創造名詞的，造

  成溝通的誤差)。

3.凡是在討論或是說話的時候必須先思考過，在說出來，減少言語對人的殺傷力。

4.做事情千萬不要急性子，要嘗試沉穩，從沉穩當中去解決問題，千萬別為了急性

  子，擾亂方向。

5.別亂插話，別人在討論的時候，千萬別打斷他人的討論，不管在系統維運或是討

  論時候，用心地去聆聽與感受對方說的話，等對方描述完之後，再與對方交談，

  確保溝通和討論的完整性、完善性。

6.在幫助人的時候，要適當的在時機點，機緣到了再幫助，還要懂得察言觀色，對

  上對下，要懂得揣摩和了解對方彼此，因為太早幫助和尚未了解自己狀況的時候，

  兩人就會走冤枉路，得不償失。

7.表達和溝通要不斷的學習。

8.軟體正式上版的時候，在上版前得必須加入退版流程的考量。

9.對不懂的人，要清楚描述引導；對懂的人，則要簡單扼要講出你想講的重點。

10.注意自己對網管與流程知識欠缺和無知的狀況下，勿把錯怪他人與其他部門
    上，而是要保持溝通與合作把問題解決。

    EX：很多時候硬體或是跑簽核流程問題，或是職責不明的狀況，而是因為自
             己對自己網管和Server與設定上的無知下或是職責模糊和流程問題狀況
             ，性子急的狀況，怪罪他人與相關部門是不對。

11.抽空的時候，記錄今日做哪些事情，以便明日早上review自己的昨天做了哪
    些事情，能夠進入狀況。

12.自己承諾人家開發完成日，EX：PM、SA、SD，如果開發延遲了.........
    請在完成日以前的的前幾天告知，回報SA專案進度與狀況，不然時間到SA才
    發現你延遲了，等於讓SA裡外不是人，你是在補他刀.......
    SA也是要對上交代進度的...在時間前幾天回報，是要確保PM或SA相關的人掌
    握進度的...這牽扯到信任與誠信問題，SA和PM又不是你的蛔蟲，他怎麼知道你
    開發到哪，問題是什麼哩= =?

13.一但系統出現重大需求變更狀況，先了解狀況，不要太著急，先與相關人員與會
    一起合作討論怎麼解決。

14.系統向來都有職責與權責的問題，從物件導向程式的角度切入，單一職責分類清
    楚，是為了明確定義系統範圍與界定。不然通通都變成義大利麵，日後業務擴編
    的時候職責不清楚狀況會延伸出推皮球，推責任之類的問題延伸，該做的分類與
    職責還是要區分，必要的時候，還是要懂得說不和拒絕。

15.程式開發的時候必要時候就要遇到越複雜的程式，越需要職責分離，越要簡化它
    一但上線之後，要改寫或是重構難度變高。

16.查bug異常，要稍微注意看細部業務邏輯運算是否合理，不能只修當下的bug。

17.有時候遇到盤較大系統或是table schema時候、建議拆成小模組或是一部分table
    分批進行來完成任務。

18.在報告或是表達的時候，要補助白板看圖說故事，或是說重點，把從頭到尾的
    事情，濃縮重點，並表述的時候，要能夠聚焦，多用白板，舉例，易懂。

19.遇到系統問題，且不熟的時候，先沉穩，先看，了解，在回應。

20.與主管相處的注意事項：首先要認清誰決定了你這家公司的前途，如果有一個人
    決定你的考績、調薪、升遷、那個人就是你的主管，主管他可以在職涯他是你助
     力或是阻力。

21.多觀察，掌握你主管心中那一把尺，EX：有些底下認定讓工作穩定，達到較高品質
   主管想的是不段改善，求更高機會，如果員工想法跟主管想法不一樣，可以問問那些
   被主管升遷，或是主管認為優秀的人，是了解主管要的是什麼之類。

22.說出口的每一句話，都會影響自己的人際關係發展。

23.很多時候主管不是真正的決策者，必須理解，彈性調整中得到利益的人是你，但為整件事情
   背書，付出風險則是他。

24.與主管保持良好合作關係，績效不差，工作態度積極主動，公司內有一些人脈，對公司政策
    保持樂觀，會接近升遷必要條件之一。

25.不要溝通的時候採用討好和委屈求全方式。

26. 我在聽人家對方描述和需求的時候，沒有搞清楚，嚴格來說，是只聽我自己想要的關鍵之類，其實有遺漏出其他更重要東西。

27.(26,18結合)：在聽別人描述與需求，會有可能遺漏需求狀況，透過聆聽的方式，遺漏狀況，可能表達出來的可能文不對題，無法聚焦，可以多記錄、多整理、在說出。

28.表達力與邏輯力問題。

29.要有高超能力，但同時保持低調姿態，通常用來描述一個人有優秀技能和專業知識，但並不張揚自己的成就，而是謙虛態度對待自己工作與貢獻。

30.一個人有很高的能力，它們往往有更多經驗與智慧，能夠了解世事變化，這種對事物的深刻理解會讓它們更加謙虛，不會因為自己成就而驕傲自滿，反之如果一個人如果沒有太多能力和經驗，往往會更加自負，甚至自以為是，以至於不能夠正確看待自己的地位和貢獻，再依定程度上能力越高，姿態就越低調。

 

工作政治心態調整

1.很多時候都是在等待、浪費、慢半拍的狀況下，要懂得順勢得讓它走下去，捨棄自己的
  所期望與實際期望的期待，這樣得失心不會這麼重

2.做案子如果遇到大軍兵團狀況下，這是很正常，因為過程必須會提出一些意見和未經過
  整理的需求和資訊，所以很難做有價值和做對的系統，必須要先過整理過和篩選過，在
  朝向正確的道路方向去進行(這部分有解法是腦力激盪)，如同做Paper的過程是一樣的

28.系統操作手冊，要寫得很白話，要一步一步的寫，步驟方式寫非IT的人看得懂
 

29.專注自己工作，態度應該要等別人來求助和請益才回答!

重構問題

1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人.

2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1).

3. 假設改完會有衝突, 那表示你做的不是重構.

4. 如果完成再重構會花更多時間, 那表示你做的不是重構.

5. 你要用他的 code , 跟你要整理重構, 是兩回事.

所以你要先搞清楚你要做的事情, 是解決你的事情,
還是幫別人改(你未必有取得授權的) code.

你拿別人的東西, 改成自己能用的 common lib,
用自己的 common lib, 這樣基本上應該不至於被靠北.

但去動別人正在開發的東西, 說穿了, 你知道人家在幹嘛嗎?
你權責上能對人家時程負責嗎?

或說穿了, 你可以負起 fix conflict 的責任嗎?

另外有個版友說重構是農閒的事情,
其實重構是越忙的地方越需要, 因為會忙通常就是沒在重構,

但是這篇原文講得並不是重構,
而是在僭越職責的前提底下自作聰明改別人的程式碼.

厲害的人應該是會抽出正確的 common,
當A 跟B都做完的時候, 拿 common 套回去不會很久的.

會被開發拖著走的 common, 表示需求根本就還沒穩定到可以共同重構啊.

 

 

需求問題

1.不要讓使用者自己想，當使用者提出構想的時候，我們要整理出一條路和方案出來
  避免使用者無限擴大，無限擴想和想法。

2.先等使用者提出構想，然後幫他整理出需求，避免擴大需求變更和增加，有時候
  開發者過多考量，增加多於功能，只會增加BUG...。

3.熟悉系統操作面的東西，有時候透過系統操作面的東西和搭配程式開發就能完成問題

  例如：切換活動樣板需求，透過後台的頁面設定，時間不同進行切換的頁面。

4.必須要以系統完整性的輪廓去切入需求分析。

5.從整體的需求分析，分析出使用者操作的系統流程，把流程和需求確認必須釐清。

6.細節的問題，先以解決問題為主、當問題解決，再去思考其他問題。

7.系統釐清需求的時候，必須要先請使用者提出流程，怎麼做，在依
  照怎麼做的方式，提供可行性的做法，和可不可行。

8.當需求提出來的時候，要明確說出，解決方案出來，制定規則出來。

9.當看到文件的時候或是email的時候，需經過整理出來，在撰寫邏輯。

 

        (例如：刮刮樂的每日交叉折價券的邏輯)

10. 誰給你需求，要保留EMAIL的通知與紀錄，口頭的話，請他寄送EMAIL
     或是會議開完會之後，寄送EMAIL給我。

11. 網頁上的(正常運行)https://  發現按下搜尋沒有，在撈的資料有可能有http:// 才導致沒有 https://
 

 

 

 

系統的維運問題

先診斷系統有沒有問題
註記：先看資料正確性(再由使用者單位資料修正和調整)     例如：地址當中  基隆市中山區調和街(隔壁工地)    地址錯誤請由客服人員修正資料。
.從系統的log當中看是否有人工介入。
假設  1.說明SOP   2.人工判斷   3.廠商判斷   取決於流程know how了解。
多觀察Email，其他IT的人是怎麼回應訂單處理流程，從中去學習know how。

(註記：需求的時候，一定要求email往來確認)

 

 

 

程式修改注意事項：

1.當要異動舊有程式，舊有欄位變更時候，要注意是否有影響到其他程式和其他模組，
  以及是否有影響到其他人的程式，並確實告知，並進行同步修改和協同作業開發。

2.程式能盡量動態就盡量動態運作，不要寫死程式，程式寫死是非必要才會用。

 

科學實驗的基本三步驟
一、遇到問題產生疑問
二、大膽假設
三、小心求證

 

大膽假設不是問題，最重要的是小心求證
結果錯了，前面都是錯的
慣性是不確定答案或是方向時，就不要猜了，直接問

 

 

測試重點說明

1.程式的格式驗證測試
  例如：數量輸入0.5，跳出異常，長度測試
  日期格式驗證：例如日期輸入數字

2.規則測試

3.業務邏輯的測試，例如：申請日期大於截止日期

4.如果網站是要加入XSS和SQL過濾函數問題

5.先符合user最簡單的輸入跟輸出

 

 

 

 

 

未來職涯問題

1.如果要考慮主管部分：得找一家夠大夠穩的公司，歷練者五年以上，才能發展到決策層核心，
  若走顧問路線，得找一個專業顧問，跟他摩個兩、三年，才慢慢轉型顧問

2.切記：若到財富自由階段想退休，千萬不能辭職，因為一旦辭職退休，就會跟外面脫節，技
  術脫節，人脈脫節

元哥的筆記