大家晚安，因為本身沒什麼朋友在新創上班，自己也是第一次在新創
所以想在這邊詢問大家開發上的一些小疑問
開發環境是react.js + create react app + firebase
目前公司是MVP剛上線的狀況還在補足一些功能
好讓老闆出去推銷，尚未盈利也還沒確認商業模式
不過在開發過程中其他工程師會提一些作法，說是為了未來著想
例如：
1. PR要merge的時候做Squash，因為這樣git tree比較好看
2. function超過一百行，就想要拆出來
3. 完全遵照eslint的規範，任何warning都不能出現
4. 時常想回去重構程式
5. 想把所有非同步的function都改成promise
6. 想導入TDD以及jest，讓系統減少錯誤發生機率（目前沒人會這東西）
7. 註解盡量刪除，只留jsdoc，減少封裝程式碼
上面除了第六項其他都開始做了
不知道大家的公司的情況是怎麼樣
我沒有想過這些東西的壓力會遠大過我思考服務架構的問題
這些東西讓我覺得滿煩的，沒有制度化都是看個人喜好
可能哪天他看到一個別的覺得不錯又要用了
還是說新創本來就是這樣，可能我比較適合回去一般公司
這輩子第一次覺得寫程式這麼煩＝＝
作者:
xephon 2018-04-24 21:36:00這跟新創有什麼關係?
職位一樣，說過很煩，但還是會一直念到code改好為止因為我在一般公司沒遇過,想說是不是新創技術人員都這樣
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-04-24 21:51:00這些都還好阿......
作者:
touurtn (vv)
2018-04-24 21:51:00這個問大家也沒有用阿 難不成大家說好 你就會適應?
時程允許的話養成好習慣是好事，等真的推銷出去想做更沒時間了
這些都還好+1...不過新創有時間搞這些也是滿神奇的
作者:
gn60311 (Peterman)
2018-04-24 21:54:00看時間允不允許比較重要+1,我的經驗是剛上線的MVP應該是忙到沒時間搞這個才對XDDD
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-04-24 21:54:00比起這些 看到網路上一些新工具就急著導入還比較煩人MVP上線 補功能的時候 2 3 5 7也能同時做不是？
作者:
knives 2018-04-24 21:59:005 為什麼不要直接跳await 就好，反正你都要重構了
剛起步的startup應該沒時間管這麼細才對XDDDD
大部分的新創真的都是這樣子，然後，大部分的新創真的都會失敗。FYI
作者:
othree (OOO)
2018-04-24 22:23:00await 也是接 promise 啊～ 這些我也覺得還好不過真的要說那個影響比較大，我會先從測試開始加上
作者:
ChoDino (Dino)
2018-04-24 22:24:00跟新創沒關係，這些都說個人習慣的養成。
作者:
othree (OOO)
2018-04-24 22:24:00不一定要 TDD，不過有自動測試，未來改東西比較心安
樓上大錯，這跟新創有絕對的關係新創TDD=To Die Die
這最基本...而且FUNCTION寫到100行以上不拆真的是
作者:
naoomi (奈米)
2018-04-24 22:33:00新code可以照新規範但重構算了吧 新創先賺錢再燒錢r千行有點扯，可以看個clean code
作者:
ken1325 (優質水瓶男)
2018-04-24 22:34:00這家公司倒掉的機率高達87%
作者:
Argos (Big doge is watching u)
2018-04-24 22:36:00跟程式沒有關係 先問 這間新創金主是誰倒不倒是看金主的
作者:
vencil (vencs)
2018-04-24 22:38:00好習慣可以養成，不過初期哪來的時間給他常常重構
作者:
vencil (vencs)
2018-04-24 22:48:00老闆貸款活下來的也有...不過資金深度應該就...
作者:
Argos (Big doge is watching u)
2018-04-24 22:49:00哇 那就只好祝您 一路順風 珍重再見 XDDD
作者:
vencil (vencs)
2018-04-24 22:50:00你的同事需要有認知，他想的未來可能遠在公司的存亡線後了
作者:
mozume (米蟲)
2018-04-24 23:01:00這些都還好吧，很多都只是習慣動作，eslint裝工具不就好，test該寫的部份還是要寫，不然將來更麻煩
作者: WiseLin1125 (Wise) 2018-04-24 23:07:00
其實很難懂，為何新創總是喜歡先搞app…app很燒錢的…
你說的這種同事我有遇過，如果你有權力，請立刻開除他！有他在只是加速敗亡！這種人只是在追求自己心中的理想世界，根本不在乎這個新創的成敗可憐的是，新創很容易吸引這種敗類
作者:
alihue (wanda wanda)
2018-04-24 23:21:00看環境，如果是用vs+c#，一個檔案千行還是容易trace
作者:
lintsu (真闇の張鈞法)
2018-04-24 23:23:00function 100 行要求好寬
作者:
NCUking (中大王)
2018-04-24 23:28:00工作十年了居然可以接受千行function XDDD
作者:
justben (BEN)
2018-04-24 23:30:00你是去上班嗎 那就看誰比較硬 你比較強就不用鳥他沒股份 沒分紅 新創這兩個字也是唬爛而已 不用想太多
不是吧 他剛畢業 你畢業那麼久了...怎還會有這種問題
作者:
NCUking (中大王)
2018-04-24 23:31:00不過程式碼品質也要等公司活下來再考慮吧
作者:
justben (BEN)
2018-04-24 23:31:00回首才發覺 以前真的是幫公司想太多了 自以為老闆 哈哈
作者:
NCUking (中大王)
2018-04-24 23:32:00陣亡了 程式再漂亮也沒有用1到3沒問題 本來就該有規範4在草創時期只是浪費時間5跟7要看情況6的話 TDD未必要實行 但無論如何至少有自動化測試程式不過產品上線才是第一優先
作者:
othree (OOO)
2018-04-24 23:40:00剛沒仔細看，搞到 delay 是不好啦
作者: za755188 2018-04-24 23:43:00
我一個function 超過20行就覺得有點長了
作者:
senjor (哞哞)
2018-04-24 23:53:00public的方法裡如果有不靠註解就不能懂的，就包成functionfunction的名字就命名成你想打的註解
作者:
guest0079 (SpongeBob SquarePants)
2018-04-25 00:05:00A大你怎麼不出來嘴啊 說啥不照著規範做系統會不穩啊 要clean code啊 不然到時候程式會改不動啊 你怎麼不罵po這篇的是寫爛code的老屁股啊 怎麼不幻想他是領底薪只會寫簡單網頁的coder啊
function包的好 看的速度快很多又好測試 要改也容易
PR 不一定要 squash 而是不要 bug feature 喇在一起eslint 可以幫你抓很多typo的低級錯誤，code format可以改用 prettier 自動化處理重構的前提是有測試去防護
我的經驗是能順手做的就做需要多花時間的一律不做，你是滿早期的新創就是要欠債搶時間測試市場，能不能活過下個月都是問題還在想未來根本無言。等到活下來有時間再重構還債簡單來說早起新創不要求程式品質能動就好
但是不管是新創還是大公司 都要學著跟技術債和平相處也許在新創作這些邊際效益不高，但也都是好習慣
我覺得你們應該要有個架構師或資深工程師來管這件事，新創老闆貸款給工程師玩不熟的新技術？如果沒delay一切好談，delay就什麼都不用談啦
那我覺得你同事太激進要引入這些規範了 慢慢來比較好
作者: dnabossking (少狂) 2018-04-25 00:57:00
5跟7又不一定比較好
作者:
skizard ( )
2018-04-25 01:03:00認為新創不用先遵守3跟4 市場時機比較重要
作者: dnabossking (少狂) 2018-04-25 01:04:00
如果是全新的前所未有商業模式，我覺得不適合寫TDD
作者:
Masakiad (Masaki)
2018-04-25 01:05:00還好啦 除了你上述的之外，我們還有coding style，function 行數30行內一堆規定。
作者: dnabossking (少狂) 2018-04-25 01:05:00
應該寫BDD
作者: t64141 (榕樹) 2018-04-25 01:16:00
很不錯阿，如果能消化下來，可以藉此養成一些好習慣
作者:
justben (BEN)
2018-04-25 01:31:00補充不用想太多的意思: 一個測試寫一個星期也沒差你有本事主導 你弄也沒差 老闆爽你有錢拿就好瞭嗎? 公司成敗不干你的事 不用去想那些 甚麼商業甚麼的都是幻覺 除非你有股份 有分紅 或是其他東西 @@
作者: b004020018 (Rosalie Rabbit) 2018-04-25 01:55:00
人家想養的是個人能力啊 公司倒了他能活的很好的不會這樣要求自己的工程師比較可怕...
其實除了4跟6之外，都是開發上順路就能作，不需要多花多少時間的吧
作者:
x123356 (x123356)
2018-04-25 02:17:00所以這七點哪個具體拖慢了開發時程嗎 看不出來欸是不是tdd先不說 不寫測試你只是搞死自己做了十年了還不懂這點 你還真的只符合老屁股一點也許你適合回大公司養老 不要出來害人了
作者:
prag222 (prag)
2018-04-25 03:16:00function100行就想拆?業界要拆的不是都千行以上?
作者:
x123356 (x123356)
2018-04-25 07:59:00所以癥結點在重構 是對系統有幫助的重構 還是單純求好看如果是前者 是什麼原因驅使必須重構 如果是後者 就擋掉菜鳥本來就容易為了重構而重構 資深人員應該阻止這件事
作者:
APTON (瑋瑋)
2018-04-25 08:13:00好奇問，你十年的經歷中，都沒寫過測試嗎@@？
作者:
a9564208 (YOU OUT!!)
2018-04-25 08:58:00我以為新創都是先上線再說...
作者:
aks (我白爛 固我在)
2018-04-25 09:17:00這些好習慣沒養成 以後維護的人會更煩 眼光要放遠 加油!
作者:
yongb (火系見習魔法師 )
2018-04-25 10:06:00請問是台北小巨蛋站附近的公司嗎？
作者:
Ekmund (是一隻小叔)
2018-04-25 10:22:00不錯是不錯 但怎麼看都很花時程 能說服出錢的嗎QQ畢竟是新創 驗證概念能回本應該比擴展能力重要要是不賺 這麼多初期投入不就吃土惹...雖然說就算公司倒掉 你有學到也ok啦...
作者: newways 2018-04-25 10:34:00
資金有問題還花時間在搞這些...賺到錢再請人重構阿
作者:
johnny94 (32767)
2018-04-25 10:39:00講真的，這些都很重要沒錯，但你在新創阿連商業模式都還沒確立，做這些只是工程師的自我滿足而已。但如果你只是個打工仔，對這間新創也沒什麼熱情，你就當累積經驗 嘻嘻
作者:
deray (Deray)
2018-04-25 12:28:00你這個劣幣
作者:
senjor (哞哞)
2018-04-25 12:39:00後來重新看看我的CODE，連超過30行的都很少 ww
作者:
chuegou (chuegou)
2018-04-25 13:18:00新創需求更改很頻繁吧 現在就重構...是沒其他事了喔...
作者:
frouscy (流浪吧。)
2018-04-25 13:32:00做這些和建置架構和解決問題沒衝突R
作者:
art1 (人，原來不是人)
2018-04-25 14:14:00比較可怕的是沒有寫測試的經驗卻一直想重構
作者:
Ekmund (是一隻小叔)
2018-04-25 15:15:00聽起來你們老大有錢有閒 那就當賺到學學吧QQ
作者:
srwhite (魯蛇阿白)
2018-04-25 16:31:00我倒很羨慕有制度的公司 不然每次改別人code都很厭世
作者:
TSW (翹班帝國)
2018-04-25 16:59:00大部分都是一些好習慣，雖然會增加工作量跟壓力，但還是建議儘早適應吧。
作者:
Argos (Big doge is watching u)
2018-04-25 17:06:00沒有什麼差？開心就好 錢也照領 不是嗎？XD
作者:
tsl3333 (我們都寂寞)
2018-04-25 18:35:00我覺得你同事觀念很好 有機會絕不欠債
作者: ku399999 2018-04-25 20:30:00
4很難評斷 但其他根本還好 什麼好公司介紹一下？2 100行這數字也沒什麼必要連promise都懶得用寫什麼react...
建議以結果來論, 不管要怎麼作, delay就是問題, 要嘛提早把要作的事估進來,中間再加而delay這很有問題然後你喜歡作架構,就把架構畫好,彼此分工畫清楚你的東西請他不要管,他的東西你也不用管只要彼此把承諾的介面作出來即可雙向的溝通很重要, 同事間若無法溝通也無法尊重彼此就...請上級出來協調吧至於是他不溝通還是你不溝通看不出來,說不定他來po又完全是另一回事
作者:
Ghamu (貓丸)
2018-04-25 22:20:00說真的 有幾點是基本職業道德吧？ func上百行code? 你他媽應該只有作者看得懂吧？
作者:
Argos (Big doge is watching u)
2018-04-25 22:49:00道德？等下樓上有人會回你 拎北出來是要賺錢講啥道德？作功德嗎？ XDDD最好一個func一千行 一個class一萬行 整個APP只有10個class
新創絕對沒有比delay更嚴重的問題 老闆放任這樣是有問題 建議還是勇敢跟老闆溝通一下 請他出面解決
作者:
kinda (天天)
2018-04-25 23:52:00好公司介紹一下 找工作中~
作者:
sharku (明珠求瑕)
2018-04-26 00:18:00有個問題 他想重構的部分是誰的code?
作者:
upyours (hijos de puta)
2018-04-26 01:22:00不跳過promise直接await/async嗎？
作者: jefflu 2018-04-26 02:01:00
我覺得都很合理耶 完全就是好習慣 這的大公司內部都說制度化 這些蠻正常的 你不喜歡反而是你的問題 其實你應該開心自己可以學到新東西跟好習慣推文亂了不好意思 大公司內部都有自己的規範 可能是全部也可能是某個組 我覺得這是必要的當然不是說全部的點 像100行是有點誇張 但整體來說是合理的
很多是為了避免技術債 你如果還過你就知道有多重要了XD
作者:
Argos (Big doge is watching u)
2018-04-26 09:45:00老實說啦 只是你不願意學習而已 2 3 6 7這些做熟了根本不花時間 長期來看甚至更省時間 本來抓bug要三天現在只要3 hr什麼新創不新創的也不是藉口 因為其實根本不會慢那現在因為時間趕 你也大概不想學 我看就算了 他搞他的你寫你的 不然就開履歷囉
作者:
Ekmund (是一隻小叔)
2018-04-26 15:09:002 3 4 5 6 都很花時間呀...從內文來看 並不是從頭做是把舊有的打掉 順便導入沒人試過的新開發流程光錯誤嘗試和測試就不曉得要繞到哪了當然新的東西進去時 最好遵照新的規則走會想重構一定有原因的QQ
作者:
Argos (Big doge is watching u)
2018-04-26 19:29:00改舊的 拆func跟刪註解哪會花啥時間啊....？到底？新創產品是有多龐大？一週能不能做完？說不定三天就OK了
7不一定是好事. 有時有些功能近似的function, 在A,B,C都有做某事而在D選擇不做的話, 會在那行附近寫原因在JavaDoc寫的話compile後外面的人會看到因此不會在那邊寫, 就樣release版的錯誤信息不該有implementationdetail一樣
作者:
KanoLoa (卡)
2018-04-29 14:18:00是你習慣不好啊 重構你的釦才拖慢大家