Re: [閒聊] 環境令人無力orz

看板Soft_Job作者 (超級白)時間14年前 (2010/03/29 08:44), 編輯推噓0(0推 0噓 92→)
留言92則, 5人參與, 最新討論串5/18 (看更多)
※ 引述《yauhh (喲)》之銘言： : ※ 引述《yauhh (喲)》之銘言： : : → yauhh:你不接受卻只是因為你個人的技術信仰. 這就變成很難溝通. 03/28 15:27 : : → yauhh:那你不接受共同的作業方式,怎麼辦?也許他請你走,或你自己走. 03/28 15:28 : : 推 superpai:信仰嗎？你要慶幸很多人對自己該做的事情有所信仰 03/28 15:29 : : → superpai:缺少職業道德...你稱之為信仰的世界你自己想看看會有多糟 03/28 15:30 : : → superpai:先是說是「創新」，再來是「信仰」，明明只是很簡單 03/28 15:32 : : → superpai:對的事情而已，你好像很不認同 03/28 15:32 : 我認為,你沒有弄清楚我認同什麼而不認同什麼. : 首先,使用CSS,並不是創新; CSS跟table是二種風格的排版要素,不能因為CSS好用 : 而說table不是排版要素. CSS和table二者在我眼中是平等的. 因此,CSS只是一個 : 技術選項,改用或不改用,對公司的流程改善幫助不大. 這真是大錯特錯 table在web的規範裡從來不是排版要素，和css好不好用一點關係都沒有 如果你不懂的話請去w3c看過一次<table>的spec再來討論 我相信會寫程式的人看簡單的html的文件一點問題都沒有 不然的話請給專業一點基本的「尊重」 : 然後我不能理解你所謂「明明只是很簡單」是什麼意思. 你究竟考慮到多少? : 如果你只看過一本CSS書,書中鼓吹著CSS在排版方面的好處,因為書上文字單方面 我不只看過一本css的說 我看過二十本以上css的書 不過這不是重點 而是要用CSS來排版不是一種好處而是正確的事情 當然我知道你和有些人表示技術沒有對錯 但是我在這個版上以及其他軟體討論區不知道看過多少抱怨說同事不寫註解啦 寫作風格不統一啦，公司文件不齊啦 這種時候我就很少人出來指責說應該順著公司的風格 難道這些就不在技術沒有對錯的範圍 然後有人也說客戶看得到結果公司收得到錢就好 這我只能說這是職業道德的問題 就像醫院為了賺錢，也可以叫醫生猛開壓制症狀的藥，狂丟抗生素 病人又分不出來病因，就以為醫生醫術很好 現在我看到的是一個尊重自己專業的網頁設計師 所以我覺得是應該給與一些認同 至於要他了解現實之類的話是多餘的 只要為了薪水，沒有人是不了解現實的 只有有些人自以為只有自己懂。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 124.11.67.57
→
03/29 08:46, , 1F
不過table「可模擬」排版要素這也是不爭的事實。 XD
03/29 08:46, 1F
→
03/29 08:46, , 2F
在過去這麼長的一段時間table也扮演過不少次排版要素，如果
03/29 08:46, 2F
→
03/29 08:47, , 3F
說table跟css在區塊設計上沒有這麼難以修改的原罪，其實也不
03/29 08:47, 3F
→
03/29 08:48, , 4F
見得會被淘汰。採用css應該是遵循原創者的理念與實務開發上
03/29 08:48, 4F
→
03/29 08:49, , 5F
真的比較有利的選項，我用這東西符不符合原開發者創立的理念
03/29 08:49, 5F
→
03/29 08:51, , 6F
通常不是人們所關心的。
03/29 08:51, 6F
→
03/29 08:53, , 7F
不過我覺得原PO蠻倒楣的，我待過得公司大多可以接受css排版
03/29 08:53, 7F
→
03/29 08:53, , 8F
因為css排版真的很有效率跟很有彈性，原po應該多嘗試幾家 XD
03/29 08:53, 8F
→
03/29 08:55, , 9F
客戶不在意這很正常 我比較意外的是開發者不挺開發者
03/29 08:55, 9F
→
03/29 08:56, , 10F
或許這是一個設計師與工程師的差異
03/29 08:56, 10F
→
03/29 08:57, , 11F
你也要看看跟你討論的人是不是能對等瞭解的人啊 XD 如果像我
03/29 08:57, 11F
→
03/29 08:57, , 12F
們這種熟知css優點跟頻繁應用的人，那自然就不會有這種言論
03/29 08:57, 12F
→
03/29 08:58, , 13F
我會覺得原po碰到的幾間公司很扯，不思改進毫無競爭力可言，
03/29 08:58, 13F
→
03/29 08:59, , 14F
就跟我常常接手看到一堆cp code的source會很幹一樣。
03/29 08:59, 14F
→
03/29 09:00, , 15F
不過對不瞭解的人他們沒辦法理解你職業道德那塊的言論啦XD
03/29 09:00, 15F
→
03/29 09:01, , 16F
如果他們瞭解就不會這麼說了，如果你把這個例子比喻成習慣用
03/29 09:01, 16F
→
03/29 09:01, , 17F
版本控制的人連續碰到幾間不用版本控制的公司所以很幹，那我
03/29 09:01, 17F
→
03/29 09:01, , 18F
一堆cp(copy paste？) code是一種沒道德的行為意思？XD
03/29 09:01, 18F
→
03/29 09:01, , 19F
想能感同身受的人會更多...XDDDDD (沒版本控制根本是蓄意殺
03/29 09:01, 19F
→
03/29 09:02, , 20F
對我來講，可以透過友善設計來減少重複的程式碼而不去做，是
03/29 09:02, 20F
→
03/29 09:03, , 21F
沒有程式道德的事情。像是一個大站要改個置底banner要改n頁
03/29 09:03, 21F
→
03/29 09:04, , 22F
view code，我就不是很想去忍受。（不過有工具可以大量取代.
03/29 09:04, 22F
→
03/29 09:05, , 23F
不要拿設計師跟工程師畫圈圈啦XD 身為一個工程師，我也是有
03/29 09:05, 23F
→
03/29 09:05, , 24F
我的職業認同、道德跟自我要求的。呵
03/29 09:05, 24F
→
03/29 12:30, , 25F
請再仔細看看原po公司不採用原po技術的理由,
03/29 12:30, 25F
→
03/29 12:31, , 26F
最少我個人認為,原po公司所持的理由,在"工程"上是很正確的
03/29 12:31, 26F
→
03/29 12:32, , 27F
原po公司最少考慮到了兩點, 其一是維護的人力
03/29 12:32, 27F
→
03/29 12:32, , 28F
第二是與過去的模組一致. 這不是單用技術面考量就可以處理的
03/29 12:32, 28F
→
03/29 12:34, , 29F
樓上所講的也是一個問題~就算要翻~那誰來翻?如果是原po來
03/29 12:34, 29F
→
03/29 12:34, , 30F
翻~那要用什麼時間來翻?上班時間?翻掉這件事在某些只看結
03/29 12:34, 30F
→
03/29 12:35, , 31F
果的人眼裡~可能會被歸類為"沒有產出"~那他怎麼會讓你用上
03/29 12:35, 31F
→
03/29 12:36, , 32F
做為一個程式師,是該就自己所知的技術提出解法, 但要成為
03/29 12:36, 32F
→
03/29 12:36, , 33F
工程師, 甚或是一個團隊的主導者, 務必要考量技術以外的事.
03/29 12:36, 33F
→
03/29 12:36, , 34F
反了吧，就因為模組化才能夠允許不同子模組各自發展，因為
03/29 12:36, 34F
→
03/29 12:37, , 35F
模組和模組之間應該是黑箱且獨立的，至於維護的人力……現在
03/29 12:37, 35F
→
03/29 12:37, , 36F
會table的人只會越少不會越多。
03/29 12:37, 36F
→
03/29 12:37, , 37F
至於什麼時間來翻，也不會沒事去翻掉所有舊的模組吧；
03/29 12:37, 37F
→
03/29 12:37, , 38F
Tony兄,若是在已經有一堆舊有模組的情況下呢?
03/29 12:37, 38F
→
03/29 12:38, , 39F
「工程」是為了適應環境才演變的，而不是用來作為種種限制的
03/29 12:38, 39F
→
03/29 12:38, , 40F
班時間來翻?不專業帶領專業的結果往往都是這樣...
03/29 12:38, 40F
→
03/29 12:38, , 41F
若是舊有模組與新模組必需同樣包給別人用,像是函式庫的情況?
03/29 12:38, 41F
→
03/29 12:39, , 42F
藉口吧。已經有舊有的模組自然是沿用啊。:)
03/29 12:39, 42F
→
03/29 12:39, , 43F
而且說實在的,原po公司的處理方式,我們並不清楚
03/29 12:39, 43F
→
03/29 12:39, , 44F
只要介面一致，那有什麼問題？假設是嚴謹「工程」的前提下。
03/29 12:39, 44F
→
03/29 12:39, , 45F
你要講工程，我們就講「工程」啊。不就是這樣？XD
03/29 12:39, 45F
→
03/29 12:40, , 46F
若是原po公司有舊有的工具,能讓使用table跟使用css差不多時,
03/29 12:40, 46F
→
03/29 12:40, , 47F
以joomla為例，很多module是table design，也有css design的
03/29 12:40, 47F
→
03/29 12:40, , 48F
看狀況選用囉。
03/29 12:40, 48F
→
03/29 12:40, , 49F
那為什麼要花心力去更動?
03/29 12:40, 49F
→
03/29 12:40, , 50F
如果真的舊有的工具就能夠適應新需求，那還叫原PO寫個屁。XD
03/29 12:40, 50F
→
03/29 12:41, , 51F
所以我說舊有的模組如果能動照用啊，不需要去改，但是新發展
03/29 12:41, 51F
→
03/29 12:41, , 52F
那原po有把介面包起來嗎? 還是只是想用css?
03/29 12:41, 52F
→
03/29 12:41, , 53F
的module，為什麼在嚴謹黑箱的「工程」前提下不能異動？
03/29 12:41, 53F
→
03/29 12:41, , 54F
不清楚的地方太多了...
03/29 12:41, 54F
→
03/29 12:41, , 55F
你談論的是就「工程」觀點，我在跟你說「工程」觀點啊。XD
03/29 12:41, 55F
→
03/29 12:42, , 56F
當你說出「工程」觀點的時候很多條件你應該要先去考慮原po的
03/29 12:42, 56F
→
03/29 12:42, , 57F
環境符不符合你所謂的「工程」，再來開口說「工程」。
03/29 12:42, 57F
→
03/29 12:43, , 58F
如果一間公司的基底就亂七八糟疊床架屋，要用「工程」觀點
03/29 12:43, 58F
→
03/29 12:43, , 59F
來看維護人力跟新模組設計，這才有趣......
03/29 12:43, 59F
→
03/29 12:45, , 60F
那我們想法不一樣,個人認為不論過去基底如何,都可適用"工程"
03/29 12:45, 60F
→
03/29 12:45, , 61F
的方法來看
03/29 12:45, 61F
→
03/29 12:46, , 62F
對我而言,工程的精神在於知識的累積以及溝通.
03/29 12:46, 62F
→
03/29 12:46, , 63F
我這麼說好了「工程」應包涵設計-再設計的循環
03/29 12:46, 63F
→
03/29 12:46, , 64F
這也是近年來我們一直在強調重構的重要性的理由。
03/29 12:46, 64F
→
03/29 12:47, , 65F
就是為了讓舊有的結構能夠隨著知識的增進、時代的演變，而能
03/29 12:47, 65F
→
03/29 12:47, , 66F
夠更加適應環境跟需求。
03/29 12:47, 66F
→
03/29 12:47, , 67F
考慮過去的包袱,也會是工程上的一個重點.
03/29 12:47, 67F
→
03/29 12:49, , 68F
我同意你說的,要能夠一直隨環境演進, 但我不認為這是能單方
03/29 12:49, 68F
→
03/29 12:50, , 69F
是，所以我認為如果要談論「工程」也要原PO的公司真的有達到
03/29 12:50, 69F
→
03/29 12:50, , 70F
能談工程的標準。
03/29 12:50, 70F
→
03/29 12:51, , 71F
面去促成的,如之前推文所述,最少原po得有心理準備,要改變得
03/29 12:51, 71F
→
03/29 12:51, , 72F
我自己看過兩個屬於很多年疊床的結構，模組分的很粗劣，而且
03/29 12:51, 72F
→
03/29 12:51, , 73F
先考慮怎麼讓其他人也瞭解,願意使用新技術,同時做出相應的努
03/29 12:51, 73F
→
03/29 12:52, , 74F
又不思改進，導致狀況百出卻又抓不到痛點，就因為這兩個理由
03/29 12:52, 74F
→
03/29 12:52, , 75F
所以你用工程跟這兩個理由來提的時候，我是覺得蠻有趣的XD
03/29 12:52, 75F
→
03/29 12:53, , 76F
剩下的其實我都同意，我只是認為這個公司對這種事情的危機處
03/29 12:53, 76F
→
03/29 12:53, , 77F
理做的有些差勁。
03/29 12:53, 77F
→
03/29 12:53, , 78F
力. 而不是只有在自己的部分使用,而後質疑公司或其他人技術
03/29 12:53, 78F
→
03/29 12:53, , 79F
上的過時與不求進步.
03/29 12:53, 79F
→
03/29 12:55, , 80F
這基本上根據我的經驗是管理者所該去做的努力.不管PM或老版
03/29 12:55, 80F
→
03/29 12:55, , 81F
這整體上是一個管理的問題，還是應該歸責在組織上。
03/29 12:55, 81F
→
03/29 12:56, , 82F
不過這基本上是個很複雜的議題啦，但是我覺得既然這個事件不
03/29 12:56, 82F
→
03/29 12:56, , 83F
上面這段看不太懂,是指推廣技術一段嗎?
03/29 12:56, 83F
→
03/29 13:01, , 84F
推廣技術要由上而下推才有用，再來就是組織找錯的人擺錯位置
03/29 13:01, 84F
→
03/29 13:01, , 85F
基本上你說得這些我都同意，我不同意的只是你所謂「工程」的
03/29 13:01, 85F
→
03/29 13:01, , 86F
觀點；因為我覺得這樣的理由正違背了所謂的工程理想。
03/29 13:01, 86F
→
03/29 13:02, , 87F
就如cgary所說，就行銷成本的角度來看，這則或許是成功的。
03/29 13:02, 87F
→
03/29 13:04, , 88F
個人很有興趣想聽聽對"工程"不同的想法,Tony兄願意分享一下
03/29 13:04, 88F
→
03/29 13:04, , 89F
嗎? 想法不同是一定會的...也請讓在下參酌看能否有所助益?
03/29 13:04, 89F
→
03/29 14:03, , 90F
已回文，就實務面針對與atst2這段討論的狀況分析所謂工程。
03/29 14:03, 90F
→
03/29 17:45, , 91F
這…篇…推…文…看…得…頭…好…暈…
03/29 17:45, 91F
→
03/29 17:45, , 92F
(尤其是因為 TonyQ 與 atst2 的 ID 都是 5 個字元... XD)
03/29 17:45, 92F
‣ 更多 superpai 的文章
文章代碼(AID): #1Bh_VXHZ (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 5 之 18 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共18篇)
‣ 更多 superpai 的文章
文章代碼(AID): #1Bh_VXHZ (Soft_Job)