![]() |
引用:
|
引用:
:on_03: ............................... |
引用:
不難發現;「設計」在前;「編程」在後, 所以後來我都使用「編程師」而不用「程式設計師」。 在完成「系統分析」之後,許多發展團隊就直接進入「編程作業」, 可是較有經驗的團隊負責人,會先完成;包含「分工及整合辦法」的「程式規劃」; 以及「硬體需求規劃」。 而「程式規劃」是八到十年以上的專案團隊成員,才能勝任的工作。 在定奪前,老練的專案經理都嘛會把大伙兒都找來一起檢視可行性,一起為此案背書。 到了之後的「編程作業」時,一切動作就都要按照規矩來,否則提出問題;否則滾蛋。 :on_14: :on_14: :on_14: :on_14: 大陸的用字,真是先人用得巧;後繼卻無人落實。:on_36: :on_03: ........................................................ |
引用:
|
引用:
|
引用:
|
看來大家至少都有涉獵程式語言
所以歡迎大家在此版區踴躍發言 :on_45: |
引用:
你該不會在做專案經理吧:on_61: 鬼才讓我感覺起來...自己一個人做就很厲害了...:on_44: ...不需要我這個永遠的程式新手:on_36: |
引用:
鬼才 .... 適合自由軟體世界啊!!(我覺得啦):on_14: 我還以為d大真的是記者 ... :on_44: |
引用:
引用:
兩岸的編程鬼才常都有排他性...:on_14: :on_14: :on_14: :on_14: 沒事就喜歡搞山頭;讓我不爽...:on_12: :on_12: :on_12: :on_12: 這還會讓專心做事的小子變壞...:on_59: :on_59: :on_59: :on_59: 三犯絕不手軟;見一個殺一個...:on_23: :on_23: :on_23: :on_23: 反正兩岸高手如雲;鬼才若何...:on_15: :on_15: :on_15: :on_15: |
引用:
早就升社長啦~~~ 胞胞們不都嘛知道~~~:on_61: :on_03: ............................................................................................. |
引用:
|
引用:
「好用與否」,與「有人在用嗎?」不一定有直接的關係... 這和行銷能力、市場定位、教育訓練、作業方法... 等等項目都有關係... 有時一個軟體敗下陣來;並不一定就是「寫得不好」,可能的原因很多唷... 有時一個軟體所向披靡;並不一定就是「寫得很好」,可能的原因很多唷... 「格X英語」曾經就發展過專用套軟,但敗北的第一個原因是: 「第一線工作人員害怕工作價值下降;移轉到專案軟體上;」 「所以拒絕給予使用者介面正面評價,因此業主不滿意專案團隊的研發能力,及專案價值。」 在那個案例中,如果業主不願正視櫃抬小姐的恐懼,而接受建議,提供適當的教育訓練;或溝通, 甚至換血;那麼後面的動作都是浪費而已,程式發展得再好也是個屁。:on_14: :on_14: :on_14: :on_14: |
引用:
|
許多人認為,程式本身的易讀性不是很重要,反正在重要的地方會詳加注解。
但事實上,這造成了「大型專案 - 拆解 - 重組」的「不可行性」。 到了專案升級的時候,之前的程式幾乎成為「雞肋」。 是該「全部重寫」;還是「拆解 - 重組」? 這種事情;去問問灑銀子的老板;馬上就有答案了。 那就是為何不少大型專案要求編程師在「定義涵數」時; 必須直接使用「統一的原始英文名稱」的原因。 下一次專案系統升級時,可能已經過了好幾年了, 人事早就異動到不知道誰幹了什麼好事的境地了。 如果一目不能瞭然...:on_22: 很多堪用的東東就祗好放棄了。 如果您是業主,您會有什麼感覺~?:on_36: :on_03:........................................................... |
所有時間均為台北時間。現在的時間是 04:05 AM。 |
Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2025, Jelsoft Enterprises Ltd.
『服務條款』
* 有問題不知道該怎麼解決嗎?請聯絡本站的系統管理員 *