職場筆記
職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.專注自己工作，態度應該要等別人來求助和請益才回答!
重構問題
- 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人.
- 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1).
- 假設改完會有衝突, 那表示你做的不是重構.
- 如果完成再重構會花更多時間, 那表示你做的不是重構.
- 你要用他的 code , 跟你要整理重構, 是兩回事.
- 所以你要先搞清楚你要做的事情, 是解決你的事情,還是幫別人改(你未必有取得授權的) code.
- 你拿別人的東西, 改成自己能用的 common lib,用自己的 common lib, 這樣基本上應該不至於被靠北.
- 但去動別人正在開發的東西, 說穿了, 你知道人家在幹嘛嗎?你權責上能對人家時程負責嗎?或說穿了, 你可以負起 fix conflict 的責任嗎?
- 其實重構是越忙的地方越需要, 因為會忙通常就是沒在重構,但是這篇原文講得並不是重構,而是在僭越職責的前提底下自作聰明改別人的程式碼.
厲害的人應該是會抽出正確的 common,當A 跟B都做完的時候, 拿 common 套回去不會很久的.
會被開發拖著走的 common, 表示需求根本就還沒穩定到可以共同重構啊.
需求問題
- 不要讓使用者自己想，當使用者提出構想的時候，我們要整理出一條路和方案出來，避免使用者無限擴大，無限擴想和想法。
- 先等使用者提出構想，然後幫他整理出需求，避免擴大需求變更和增加，有時候開發者過多考量，增加多於功能，只會增加BUG...。
- 熟悉系統操作面的東西，有時候透過系統操作面的東西和搭配程式開發就能完成問題，例如：切換活動樣板需求，透過後台的頁面設定，時間不同進行切換的頁面。
- 必須要以系統完整性的輪廓去切入需求分析。
- 從整體的需求分析，分析出使用者操作的系統流程，把流程和需求確認必須釐清。
- 細節的問題，先以解決問題為主、當問題解決，再去思考其他問題。
- 系統釐清需求的時候，必須要先請使用者提出流程，怎麼做，在依照怎麼做的方式，提供可行性的做法，和可不可行。
- 當需求提出來的時候，要明確說出，解決方案出來，制定規則出來。
- 當看到文件的時候或是email的時候，需經過整理出來，在撰寫邏輯。 (例如：刮刮樂的每日交叉折價券的邏輯)
- 誰給你需求，要保留EMAIL的通知與紀錄，口頭的話，請他寄送EMAIL或是會議開完會之後，寄送EMAIL給我。
- 網頁上的(正常運行)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.切記：若到財富自由階段想退休，千萬不能辭職，因為一旦辭職退休，就會跟外面脫節，技
術脫節，人脈脫節。
元哥的筆記