今天整理電腦，發現了去年入職試用期時的每週工作心得。可惜只在試用期公司規定寫了，轉正後就沒寫過了。現在看看這些心得，本人其實也是個有思想的人呢。曬曬。
(2012.08.13-2012.08.18)
這週在封裝station資料庫時，對於某個功能的方法該寫在哪個類裡，類該如何分布，按什麼來組織類，怎樣讓人很快的明白這個結構的意思… …發現自己在對於整體程式結構布局上還存在一些欠缺。目前來說使用c#語言完成某個功能或某個模組已經不存在多大問題了，但是怎樣才能寫出質量很高，架構更清晰的**還需要多進行思考，要思考程式設計思想的理論如何在實踐中體現出來。
(2012.08.20-2012.08.25)
這週寫了一些**，包括修改的和新寫的。寫的時候只是為了解決某一問題而寫，寫好後再返回來看整個**覺得不夠嚴謹，於是再修改。後面測試功能的時候，又發現再換一種寫法可能效率更高，再次做修改。從中體會到了兩點： 1、
寫**時和寫**後都要多方面思考，將各種可能出現的情況在**中做好處理，這樣才能減少bug的出現，軟體才讓人用的放心； 2、
寫**前要做好設計，雖然每次也做了設計，但是不夠詳細。設計應該大於等於寫**的時間，因為只有在寫之前做好了設計，畫好流程圖，將各個分支都列出來，在寫**時就能考慮的更全面，這樣寫好的功能模組問題就少一些。
(2012.08.27-2012.09.01)
這週在測試功能的時候發現乙個規律，自己寫好的**很難測出問題，因為自己寫的流程，那麼在操作的時候就按照自己預先設計好的流程來測試，這樣有些極端情況就發現不了。而且由於以前的慣性總是：寫好**——交付測試——改bug。自己對於測試不是很看重。其實作為乙個成熟的程式設計師來說，測試也是寫**的一部分，因為如果寫好了**然後交付測試，測試後沒有發現bug，那一定是大牛的水平。所以現在對於自我測試還應該多加強一些。
(2012.09.03-2012.09.08)
這周修改bug，有的一次性就改好了。有的本地測試沒有問題，但是經過測試部還是測出了bug，然後又修改。比如導航條的問題，因為之前用的是沒有修改，但是給測試的版中有的被刪掉了，結果就有問題了，後來改的時候將這個模組裡所有的導航都改為listbox了。以前看過一句話：如果某件事情可能會出錯，那它一定會出錯。**也是一樣，如果覺得這裡有可能出問題，那麼到時候bug一定會有。所以在寫的時候需要將所有的可能性都列出來，然後通過調整流程，增加判斷進行逐一避免。最好的結果是：寫出的**可以有流程上的問題，但是一定不能有功能上的問題。
(2012.09.10-2012.09.15)
這周相對事情比較少，改bug一般都是對細節的調整。對乙個軟體來說細節也確實很重要，乙個小bug、乙個小細節的不人性化或者讓使用者不會使用都可能讓使用者失望。從程式的角度來說就是要做好程式的邏輯和程式的結構合理，邏輯正確的話對於就能很好的避免可能出現的問題；而且在排查bug時也比較確定這段**是否有問題。而程式的結構也很重要，結構合理對於後續新增功能和調整舊的功能來說都比較方便，而且能避免由於改動引起的問題。程式做好了之後，應該再從程式設計師的角度看一下使用者體驗怎麼樣，因為程式寫出來後程式設計師對於內部的流程是最清楚的，所以也很清楚**可能出錯、**可以通過一些小方法提供方便、什麼樣的流程會導致程式執行容易出錯、以及現有的資源能做哪些功能，效果如何，是否需要做等等。所以一款使用者體驗好的軟體不僅需要策劃人員好的創意，測試人員的用心測試，更需要程式人員的負責態度和防患於未然的心態。
(2012.09.17-2012.09.22)
對於軟體來說是不可能單獨執行和工作的，它是需要硬體的支援，以及一些對操作者的約定，比如要用到系統檔案，系統檔案就必須存在；要用到的必要的配置檔案，那麼配置檔案就必須有。
因此，在編寫**的時候需要考慮這些外界條件，因為即使**本身沒有問題，但是當外界條件不滿足而導致程式崩潰，這也是程式的問題。所以，程式總是要考慮到最壞的情況，這樣才能保證程式的健壯性。
當然，僅僅將程式做的很健壯，還是不夠的。畢竟一款軟體的最終目的是為了給使用者解決問題，如果程式正常了，但是硬體環境沒有達到要求，使用者不能正常使用，那麼對於軟體來說還是失敗的。所以，在程式部署的時候，也是需要軟體人員來關注的。必須需要哪些硬體支援都需要告知硬體部署人員，以及可能會碰到哪些情況，對於硬體來說應該如何避免，哪些現象是什麼原因等。
所以軟體是否做完，不是**編寫完成，而是最終在使用者環境上，使用者是否能完成預期的操作才算完成。
(2012.09.24-2012.09.29) 1、
寫**還是需要細心。在寫預訂功能時，將預訂方法的返回結果寫成了乙個類，但是在客戶端每次當呼叫到這個方法時，服務自動停止了。找了很多可能出現的問題包括重新設定了服務的超時，還是不起作用。最後才發現，寫這個返回結果的類中乙個屬性的get set 寫錯了。
[datamember]
public string paylimittime
set }
結果就死迴圈了，程式直接崩潰。vs提示功能太強了，一不小心就寫錯了，所以還是應該小心一些。
(2012.10.07-2012.10.13)
這周硬體同事反映了持續供電電源的問題，程式執行中切換持續供電電源的資料線埠導致接收不到資訊。因為這種情況在真正使用中是不可能有這種操作的，所以寫程式時沒有做相應處理。但是在特定的情況下出現了，導致懷疑程式本身有問題。
其實對於軟體產品來說，程式是最重要的一部分，但是程式並不能百分之百保證產品的正確，比如操作的不當、硬體產品不達標等都會影響到程式的執行。往往這些問題會被歸咎為軟體的問題，這需要軟體人員和其他負責產品的人員共同交流，查詢問題根源並解決問題。要認識到在產品中軟體不是孤立的，而是和其他各方面協作的，是乙個產品的組成部分。
(2012.10.15-2012.10.20)
1、看了專案中的一些**，可能是程式設計習慣的不同，總感覺有的部分邏輯不好，沒有考慮效能等問題。不過還是先從自己的**入手，之前雖然對負責的模組做了一些優化，但是還不是很徹底，有些沒有用上的**，當時沒有仔細看是幹嘛的，所以也沒有刪除。後面需要抽時間清理掉。
2、想法要及時實現。有時總想寫個什麼功能，但是過一會兒又覺得可能用不上，就算了。其實這樣不好，有了想法就應該馬上用**實現了，可能用不上，但是後面至少為類似的問題提供了乙個參考。
當年的試用期周工作心得
今天整理電腦，發現了去年入職試用期時的每週工作心得。可惜只在試用期公司規定寫了，轉正後就沒寫過了。現在看看這些心得，本人其實也是個有思想的人呢。曬曬。2012.08.13 2012.08.18 這週在封裝station資料庫時，對於某個功能的方法該寫在哪個類裡，類該如何分布，按什麼來組織類，怎樣讓人...
試用期工作小結
我於2018年6月19日成為公司的試用員工，來到乙個新的環境，開始時有點擔心與新同事怎麼相處，如何開展工作 但是很幸運，我們公司的工作氛圍寬鬆融洽 團結向上，使我很快的融入新的環境。就在人事通知我準備轉正資料的時候，我才意識到三個月的時間就這樣過去了，好像所有的還發生在昨天一樣。這段時間我收穫了很多...
it試用評估 it行業試用期工作總結
it 行業試用期工作總結 it試用期工作總結從xx 年月日入司已經三個月時間，在此期間公 司領導和同事在工作和生活方面給予我很多幫助，it試用期 工作總結。公司客戶服務中心剛上線階段，通過日常工作學 習自己對客戶服務中心建設和客戶服務有了更高的認知，同 時積極與領導和同事進行溝通，盡快的融入了東興 ...