• 17

請教在軟體業界的版友

kevinant2 wrote:
tracer100...你果真跟我處境很像,我也是在一家公司做In-house 開發,有一個分析師+三位工程師

難怪上次說的你都聽懂了,我深深的感觸道如果隨便用低薪請一個學生來寫,但是沒有培訓的資源的話會發生多恐怖的事情.

其實要不要Documentation是看情況決定,然而這就是管理者需要做決策的地方,也就是技術的通常看不到的地方



tsaipifong兄的公司應該是在幫客戶架系統賣軟體賣案子的,所以他的觀點會偏向文件能完整就完整

但是in house team的開發,順序就完全不同了 (我指的不是軟體開發的需求文件,這個在哪邊都需要)

還有,不要認為in house的software team就小喔

美國很多大公司特別是online的,成百上千工程師的in house teams也是相當常見的

只是大家可能待的地方不同,觀點也會有落差,這其實沒有對或錯

要賣東西給客人,當然要寫完整的說明書,因為是給別人用

如果做東西給自己公司用,會想寫個"程式開發與邏輯解釋說明書"把每段code都細做說明嗎? 除非你要被炒,案子換人做了,不是嗎?

kevinant2 wrote:
還有通常有2~4年技術的會覺得他很懂,然後會衍生出其他問題,所以這也是管理者需要擺平的地方,我的策略就是用明文規定Coding Style/Rules,這樣比較不容易吵架.


不知道Tracer100大大怎麼想,我是覺得在我的情況開發文件算是蠻重要的,因為我們通常開會都因為大家都忘記需求是啥,或者是資料庫架構而花了一個小時討論,這樣真的非常沒效率,當然你的組織型態可能也不一樣,我比你年輕許多所以也請多多指教,最近因為繼承一堆亂七八糟東西所以遇到了真的很多鳥問題要解決.


你太客氣了,我也僅能分享我本人的經驗,也不見得真的很好

我公司的系統我自己親手開發了不少的applications

後來公司讓我建team,帶team, in house team的數量也越來越多,跨不同platform

上司也要我把coding style/rule寫出來,定出大家開發的"原則"

但是,這種東西寫了也只是聊備一格的"文件"

相信我,除非你是"新生訓練",或者是相當基本的(如naming convention),
否則這些文件根本沒人會真去好好讀,也不能解決真正的問題

讀了也不一定都用得到 (好比教你如何使用另一個系統的service,有哪些規定或語法,一堆)

而我們做事的人只要一多,最怕的就是不同的team遇到類似的問題,卻用不同的方法去解決 (也不一定誰好誰壞)

這種往往造成各team開發的project做法不一致,各唱各的調,寫出來的library or service各team也不一定用得順手

後來誰要寫新的東西,除非是公司沒類似的project與技術作法,我永遠都要求工程師給我去參考人家的寫法,並安排另一位熟這系統的工程師一起去做

為的就是要公司寫project的作風要盡可能一致 (當然仍會有不同,畢竟不同的人)

另外,開發文件當然要,你說的是客戶跟使用者的需求文件,這種文件不管是不是In house team,都會需要寫,還要對方劃押才行,否則每次開會,使用者都忘了他們要的,或者是改變心情,我們就會很累了

另外資料庫或者程式處理的方式 (前端做還是後端做? service裡面做還是front end team做)

這些,除了各部份的專業工程師提出意見,

還是要有高一層的技術主管或首席工程師(principal)來做決定(獨裁一點,只要本身技術能力強)

否則大家往往都會把難的推給別人,出錯時也容易吵

討論基本上只是給主管意見,主管聽完就要下決定,若是跨部門的會議,兩邊最好都有能做決定的人

我覺得開會除非能做出決定 (大家認同),否則開會根本是浪費大家時間
KillerChen2013 wrote:
我知道你很想證明你是對的
而且在我看來


method宣告附加throws NullPointerException
這個你是對的,的確可以這樣寫

在此特向你及shukae道歉

至於throw exception只是在此討論暫用
實際當然要以適當命名的Exception子類別為宜
例如SomeBusinessException

其他部份,我依然堅持我的看法
KillerChen2013 wrote:
其實每個人都是以自己...(恕刪)


謝謝,您客氣了。

我其實很喜歡這樣子的吵架,多看多聽,也不害怕參加,因為這是一種吵完之後會進步的架。不過講到年資薪情,大家還是收一下為好,真的很傷。

tsaipifong wrote:
method宣告附加throws NullPointerException
這個你是對的,的確可以這樣寫

在此特向你及shukae道歉
...(恕刪)
其他部份,我依然堅持我的看法...(恕刪)


本人相信所有的人都會同意,這段話讓一位工程師(或者是分析師、設計師…台灣名詞好多)身價又高了幾萬。


這一切,讓我想起多年前的scjp考試,我第一次沒過,第二次勉強及格…
整個讓我好想吐
ScarleTAKE wrote:
這一切,讓我想起多年前的scjp考試,我第一次沒過,第二次勉強及格…


很厲害了
我至今沒證照
哇,變成在討論程式碼,說再多也沒有用,直接比一場看誰分數高最客觀了。

與其在版上哈拉個好幾個晚上,不如就直接上解題網比個就小時見真章!

可惜ACM的比賽年底才有,ITSA最近一場的報名截止日是昨天,也來不及了,

不如就到topcoder如何??https://www.topcoder.com/reg/

倒底是誰強呢?是年資最久最資深超過20年的,還是年資2~3年的小毛頭??好期待答案

幾位高手神人麻煩帳號報一下給咱這些後生小輩見識見識觀摩學習!
哀哀.....現在我看來不能重整了,只能希望少出點事情

自從接任這職位以後,事情仍然還是頻繁出來,雖然畢業生已經辭職了,工程師全部換成5~10年經驗的碩士工程師,卻把畢業生升為主管,負責借貸金流系統的商業邏輯及整個In-house的系統開發,因為我才剛畢業沒多久,所以對於所設計的商業邏及及會計制度也沒多大把握,也不知道為啥這主管位置做得有些虛.

在這之中已經盡力了,剛開始前任離任的時候把所有資料刪得一乾二淨,所以整個都得以重建,包括邏輯在內.

雖然那些工程師都是已經有工作5~10年經驗的,甚至在大的銀行做過看過的系統架構也比我多,但是他們剛開始的時候說沒有Framework他們就不會做. 尤其因為我是主管,再加上沒有商業需求文件,所以他們所有程序,商業邏輯及資料庫架構都需要經過我批准做決定然後再開發,然而因為我沒經驗,所以如果他們設計不出資料表的話都是我在設計,但是我設計的資料表大多欄位過多,因為我從來沒看過金流系統如何規劃,所以全部都是亂猜亂規劃,因為我是主管所以他們也照著決定這樣開發.況且雖然他們都是很有經驗的工程師,可是出現的狀況也讓我傻眼.

第一位: 七年工作經驗,對系統架構Framework,那些要放Global Constant及哪些要規劃class有些概念. 但是會出現以下問題:
1.說一次聽不懂,要重複說五次才聽的懂.
2.雖然架構會,但是常常些許粗心,細節也不太知道,所以需要我常常去幫她Debug
3.像Java 22.9999999這種問題他也不會解決,還要我想辦法解決
4.計算兩個日期中有幾天她直接用calendar一天一天的算....


第二位: 六年工作經驗,對架構有些認知但是沒有完全,大多從網路學.最恐怖的缺點是很懶,逃避問題,如
1.說一個Server沒辦法裝兩個SSL Certificate, 沒想到愛省事省錢的老闆居然會聽信他的
2.說不同的user要改Header是很難的事情
3.最後說要大規模的增加記憶體,用64GB記憶體的Xeon 8 core Dedicated Server來包闢他的錯誤,經查是他的程式有memory leak,有些東西修理不完全.

第三位: 三至四年工作經驗,作是比較實在說了就聽的懂.但是由於經驗不太夠,所以很多東西該用Constant的時候她都沒用,也沒有跟另外工程師溝通.另外遇到問題如稍有麻煩就說做不到,還需要我去想辦法幫她寫,如要把google map加進iframe的功能.


說真的我很希望能夠把這個部門分割出去,然後由財務部門提供需求讓他們自動自發的能夠寫出來,用一位比較有經驗,能力及擔當力當Principal Engineer/Software Architect負責資料庫設計及管理程式的總架構,然而這三位工程師我並不覺得有這擔當的能力.之前老闆說要再請另一個人看看能不能夠做頭,我原本面試的時候就問對方做過類似project的經驗,對方答不太出來,我就之道不能讓他做principal engineer,沒想到老闆要直接問closed question,甚至問一堆架構的問題,但是因為老闆根本啥都不懂然後對方說了一堆open source的架構如spring & Hibernate等,老闆就以為他很厲害,
後來老闆又發了省錢及走捷徑的老毛病,跟我說他只請他來一個月來負責做framework隸屬於我的部門,真的是瘋掉了.

我看現在要解決這個問題很有可能要搬出非常嚴格的紀律,如果有人在跟老闆說要我幫她去debug的話我就建請直接炒人.我發現老闆沒碰到真問題還會以為真的沒問題,還覺得我去幫人家debug是天經地義的事情.畢竟我們沒有文件打迷糊仗已經很久,每次開會老闆看心情及突發想法改變他的requirement,大家都做得很累,已經六個月都需要連續加班,老闆現在也不是看效率而決定人的表現,反而是以加班時數感覺大家的表現,導致非常大的惡性循環.


其實不只只有程序的部位出問題,由於我沒有任何寫product document的經驗,所以他們覺得我做出來的document看起來都不太專業.
然而更重要的是,我也沒看過金融系統的規劃(我前任有八年經驗),所以我打出來的商業邏輯很有可能也不太專業,而且對於流程也不太清楚都是用猜的.
然而裡面所算的大多都是費用及其中的稅務,這些都是需要有商業經驗的來做,我和老闆每次都在討論這些需求,但是因為我不是會計畢業的所以對會計制度及稅務也不太清楚,設計的商業程序不符會計規則,而有時老闆覺得怪怪的就去問會計事務所,然而真的是有問題,結果要重新設計寫程式花了更多時間,這樣來來回回的花時間就很久.況且我也沒對帳的經驗,老闆希望全部對帳可以很精準而且還要我做道能跟會計系統連線,這些我也沒很大的把握.我不知道一旦放出來之後會出現蝦秘問題.


難怪家人覺得我太早做主管管雜七雜八的東西會荒廢專業是不好的事情.我也因為專業知識及經驗卻不足,導致我做的很累也沒把握.我還是比較希望能夠做金融模型當個金融業務員,因為那個東西至少我是有把握的,也有做成功的案例過,而不是做一堆遠超我能力的事情,況且業務員當久了會更加掌握商場的事實,對以後會更有幫助.


希望大家能提供一些意見,畢竟迷糊仗已經打了十個月了,老闆不希望這樣,我更是不希望這樣,但是我看到問題癥結點老闆每次"省錢走捷徑"毛病都會發作,導致問題無法解決.












kevinant2 wrote:
雖然那些工程師都是已經有工作5~10年經驗的,甚至在大的銀行做過看過的系統架構也比我多,但是他們剛開始的時候說沒有Framework他們就不會做


這很正常,因為如果之前的經驗就是一進公司就有framework做事
多半也只會在上面做東西

大公司工作分很細

裝架構的不一定要寫程式,寫程式的可能就"專心寫程式"

有些封閉的大公司還有一堆獨門技能,別家根本用不了,公司故意來防止跳槽

這些人工作態度上都是有問題的。

kevinant2 wrote:
哀哀.....現在我...(恕刪)


你需先把公司的結構建立起來。這些給你做參考,如果現在沒有,

1.Version control Subversion 比較適合你. TortoiseSVN, http://www.collab.net/downloads/subversion,或是 Git (我偏好這個)。
2. Bug tracking http://www.bugzilla.org/ 或是 Trac

以上是免費的,還有其它的可以用,我現在公司是用 IBM 的的東西,

你可能要增加一個 QA|Build 的工作, 如沒有預算,可以由大家分擔。為了能夠管理上能夠客觀,你可能需避免自己去找所有問題。

訂個固定的時間開會討論Bug tracking,請負責人説明,對應方法,優先順序之類...基本上所有問題都可以由這追蹤。這樣你會有共識,追得是問題,責任分明,減少人與人之間的磨擦。

-------------------------------------------------------------------
3.
再來,需要有個 Build/Testing/Release的程序。一搬公司是晚上做 Build,之後自動的regression testing..做完後相關人士會收到email 的總結。

我現在是用這個,

http://www.urbancode.com/html/products/devops/default.html?utm_source=urbancode&utm_medium=banner&utm_content=devops_readmore&utm_campaign=homerotator

這個是Java寫的,scripting 也是 Java. 但是滿複雜的,對你的公司來説可能會太麻煩。如果你沒預算,至少你可以了解這過程。我們的 build farm 有幾十台機器,加上 AWS 的 overflow。所以我們有一個團隊在管。不同產品是由PM做細節的設定.
村小民 wrote:
哇,變成在討論程式碼...(恕刪)


你大概不認識這個。我由儲藏室裏挖出來的 10 多年前做的原形機,最後成品好像被園丁給偷走了

  • 17
內文搜尋
X
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 17)
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?