耗時數(shù)月重做輪子卻發(fā)現(xiàn)意義不大

xie995

從年前開始，基于過去寫的代碼，提取共通代碼大量增補刪改后搭建了一個完整的用C寫后臺服務的框架。
也實際用了下，的確也挺方便，只要關注自己的業(yè)務就可以了。畢竟自己寫的東西用起來很熟練。
因為很多代碼只是基于以前代碼的重新整理，其實實現(xiàn)得也不夠優(yōu)美。有時候花了很長時間重寫一些東西，之后又發(fā)現(xiàn)其他的丑陋的代碼還是很多。
最近移植到多個平臺后，發(fā)現(xiàn)一大堆的＃ifdef之類的東西已經慘不忍睹，完全不符合我的美學觀念了。
也許從一開始就應該用glib、apr之類的跨平臺的庫，或者根本就沒必要自己整這么個小框架，至少沒必要在里面整那么多重新做輪子的事情。
也許唯一的意義就是整理并反復修改了2W行沒多大用處的代碼，增加了code的熟練度，理解了一下自己整框架要考慮的東西。
可憐我這小半年的精力啊，大把大把的業(yè)余時間就得到這么個意義不大的東東。
是不是這也算是技術道路上的一個必經階段呢？先是試圖做輪子，最后發(fā)現(xiàn)直接用更好的輪子就是了。

wwwsq

原帖由 xie995 于 2009-4-10 09:59 發(fā)表
從年前開始，基于過去寫的代碼，提取共通代碼大量增補刪改后搭建了一個完整的用C寫后臺服務的框架。
也實際用了下，的確也挺方便，只要關注自己的業(yè)務就可以了。畢竟自己寫的東西用起來很熟練。
因為很多代碼 ...

在公司里面要盡量避免這種情況，這是對公司資源的浪費。

個人么，看喜好了。

net_robber

把它當作業(yè)余的愛好吧,收益還是很多的,雖然代碼最終不一定要用在生產環(huán)境,

很多東西,不親自付出一下,是無法體會的



重復造輪子的事情,還是需要做的

reiase

俺昨天在Gentoo的plante上看到有人討論了glib在server side的問題，看語氣，好像說glib用在server side上有點勉強
http://blog.flameeyes.eu/2009/04/07/is-glib-ready-for-servers

hellioncu

等你用了現(xiàn)有的跨平臺庫，也會覺得這里那里不爽的，畢竟需求各不相同

jqbsx

基于不同情況，個中選擇，各有利弊。

找到最適合的輪子的概率是極低的， 你選了一個輪子， 開始不錯，可能后來發(fā)現(xiàn)它 太重，太小，沾水就散架，或者根本不圓，想改可就無從下手了。

xie995

原帖由 wwwsq 于 2009-4-10 10:02 發(fā)表



在公司里面要盡量避免這種情況，這是對公司資源的浪費。

個人么，看喜好了。

個人愛好。不給錢的情況下花大量業(yè)余時間給公司干活的可能性已經不大了。只是覺得自己的業(yè)余時間也是有價值的才對。
話說回來，公司自己預研的項目，倒大半都是失敗的或沒有意義的。比較郁悶，呵呵。
不過既然拿了錢又無法改變領導們的想法，就按照領導們的想法實現(xiàn)一些很奇怪的東西也無所謂。
-------------------------
公司有自己的輪子。當然我覺得那個輪子太重太丑陋了，這也是我想自己搞個小輪子玩的起因。
也許一個能正常轉動的輪子就是好輪子。
也許使用glib之類的庫最大的缺陷是，一旦全部的代碼都基于第三方庫堆建起來了，卻發(fā)現(xiàn)第三方庫不符合自己的要求就比較頭大了。
這也是最初不使用第三方庫的原因。但是看來自己做的話，很多東西是比較麻煩的，尤其是跨平臺這點。
只考慮類unix平臺的話還好，一旦考慮windows就會變得很麻煩的樣子。不過Win32版本是否值得去移植也很值得考慮就是了。

smalloc

難道LZ一開始連glib庫都不用?直接自己寫所有的庫?

雨過白鷺洲

Glib用起來還可以

但是我們公司的人都類似樓主，開發(fā)都是使用自己積累的庫

cugb_cat

簡單設計，敏捷開發(fā)。。