圖解網路史

圖解網路史

留言

張貼留言

這個網誌中的熱門文章

工作後寫程式的收穫

    這三個月下來，從中心同事的身上學到不少東西，這些都是他們累積下來的經驗，讓我收穫良多，謝謝他們。工作已經將近三個月，有很多的心得，職場、寫程式都有不少心得，今天先從程式談起好了，以前在學校無論是寫作業，接case，算一算也寫了不少程式，但真正工作寫大型的軟體後。發現產品跟之前寫的程式完全不一樣，要考慮的事情也多了很多，我從程式的設計、開發、測試三個部份來說好了。 設計   之前寫程式雖然知道事前的設計很重要，但都是粗略的想一下就著手進行開發了，往往在開發完成要使用的時候遇到需要改很大的問題，額外又多花很多時間修改。看書上寫多多紙上談兵，設計的修改往往比成式的修改省時，但那時沒甚麼感想。現在外面工作之後，才真正在實務上遇到，我們花很多時間在討論新的功能如何實做，以及會遇到各式各樣的問題都事先預想，怎樣跟其他組整合才不會影響到原本的功能，甚至討論到快吵起來。不過最後討論出來的東西雖然稱不上完美，但也非常好了。而且在我們的team中，大家的設計都是往right things to do 的方向想，也會兼顧目前的時程，我覺得非常的好。有非常多的人事物值得我學習。 開發前多想一點多考慮一點，以後的修改與錯誤就少一點。 開發 開發的部分也有很多跟以往經驗不同的地方，最讓我印想深刻的就程式的容錯性，因為我們開發的是儲存系統，上面儲存的的是重要的資料，所以容錯性非常重要，在這常常需要考慮到，系統crash後再啟動，資料是否能正確的被保留下來，系統是否能正常運作，在這個部份我是完全的新手。但在我們組內，每個人開發都會考慮到容錯性，還有錯誤還原等問題，這是我不足的地方，也是我在這裡努力的方向。程式的效能也是一大的考量，之前再開發教學網站就有預到類似的問題了，這種問題處理起來也蠻累人的。在工作之後，這個問題也是每天會討論到的問題，希望在這裡可以學到這方面的經驗。不過在這邊的開發也有一些問題，文件的不足(我之前想到公司學的就是開發的文件化)，由於我們中心也才成立第三年，很多流程制度等也還不夠成熟，很多都是藉由大家的努力持續在改善中，文件我想過一陣子開發的進度不那麼忙的時候就會被注意到了，到時候就做中學吧。還有一個很大的不同，就是以前很少開發multi-thresad的程式，這邊幾乎都是，所以在除錯上的困難度對我來說很高，我有找一個同...
閱讀完整內容

SVN :Keep your feature branch up to date

 前言 在我工作的團隊中，幾個月前我們改變了我們使用svn的方法，加入了feature branch的概念，就是每開發一個新的功能就需要從主幹開一個branch出來做開發，以免開發中的功能影響到其他人的作業(bug fix ...)。我們在改變規則的時候討論了很多次，原本以為規則已經很OK了。殊不知，才是惡夢的開始。 老舊的branch 有些功能branch分出來之後，此功能可能初步開發完成，尚未測試完成。但因為專案時程與需求變動的關係，導致這個功能的優先順序降低，所以不能跟著下次的release出去，且被assign更緊急的工作，這個feature branch 從主幹分出來太久，之後要merge回主幹可能會有一大堆衝突與問題。而你也沒辦法保證被svn auto merge後的結果一定是正確的，這個時候問題就來了。 如何解決老舊的feature branch? 我找了一些資料，這篇stackoverflow上是跟我一樣的問題 Subversion Branch/Trunk Best Practice - keeping Branch Up-to-Date? ，其中提到的我覺得OK的做法有幾點: 常常把主幹的code merge到你的feature branch，也就是說常常更新你的feature branch，就像每次開發前要update code一樣(好像有點爛，不過這好像已經是最好的辦法了 主動教你的團隊如何把code merge做好，且誰做更動的就應該由更動的人做merge的動作 我也覺得要常常更新feature branch，但為時已晚ㄎㄎ，我還是需要merge一大堆change，解決一大堆衝突，慘兮兮。既然都要做了順便提一下如何 Keep your feature branch up to date. 有人有更好的辦法歡迎留言告訴我。 Keep your feature branch up to date. SV作法其實很簡單，就是把主幹merge到branche就好。 Keeping a Branch in Sync Svn book - Branching and Merging  > Keeping a Branch in Sync Without...
閱讀完整內容