Розробка, керована інтуїцією, звучить привабливо в теорії, але ось реальність: блискучі ідеї нічого не варті без надійної реалізації. А коли реалізація повністю залежить від інтуїції? Ви отримуєте поганий код, який ніхто не хоче підтримувати.



Звичайно, можливо, це працює для прототипів V1 або швидких MVP—викидати речі на стіну має своє місце на ранніх етапах. Але при масштабуванні ви швидко натрапляєте на проблеми. Ми говоримо про погані архітектурні рішення, які переслідують вас пізніше, напівзавершені стратегії без реальної основи, вразливості безпеки, які ніхто не помітив, бо не було належної структури з самого початку. І сказати, що для цього не потрібно мати ступінь у галузі CS, щоб помітити, — це очевидно.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 7
  • Репост
  • Поділіться
Прокоментувати
0/400
WhaleInTrainingvip
· 01-17 00:56
直覺哥們兒還是得配上腦子用,不然就是自我欺騙 --- mvp快速驗證我支持,但scale之後全靠感覺?那就是找死 --- 架構爛尾最難受,後來接手的人得罵娘 --- no cap,不需要什麼cs學位,看看那些shit code就懂了 --- 早期試水可以,但得留點buffer給後續重構,不然血淚教訓 --- 直覺驅動開發說白了就是賭博,賭贏了吹牛逼,賭輸了996加班 --- security hole沒發現真的絕了,等到被爆了才慌張 --- 想法再牛逼,執行垃圾也白搭,這就是web3一堆項目的現狀
Переглянути оригіналвідповісти на0
MevHuntervip
· 01-15 23:20
Інтуїтивна розробка? Це як копати собі яму, в будь-якому випадку доведеться рефакторити --- На етапі MVP ще можна погратися, але коли запустиш справжній продукт, тебе чекає купа лайнового коду --- Система без рамок — це як часова бомба, проблеми з безпекою літають навсюди, і ти навіть не знаєш --- Навіть найкрасивіша ідея без правильного виконання — даремна, хто цього не розуміє? --- Архітектуру можна робити як завгодно, але рано чи пізно пошкодуєш, а вартість рефакторингу — це вже зовсім інша історія --- Загалом, потрібні стандарти і процеси, інакше масштабування просто зламається --- Хто буде підтримувати поганий код? Я особисто цим не займаюся --- Коли масштаб зростає, всі проблеми стають очевидними, спочатку лінуєшся — потім доводиться відпрацьовувати борги --- Не обов’язково мати ступінь у комп’ютерних науках, але базове інженерне мислення має бути у кожного
Переглянути оригіналвідповісти на0
fren.ethvip
· 01-15 15:16
Інтуїтивна розробка?🤡 На ранніх етапах ще можна обманути, але коли масштаб зростає, справжнє обличчя проявляється Я бачив багато архітектур, побудованих на сміттєвому коді, і в кінцевому підсумку все одно доводиться підчищати Швидке ітеративне прототипування на стадії може бути корисним, але так не можна робити постійно Вразливості безпеки настільки великі, що це справжня міна замінована Ці слова справедливі, не кожен може побачити ці пастки
Переглянути оригіналвідповісти на0
DogeBachelorvip
· 01-14 12:56
Інтуїтивна розробка? Ем... це ж азартна гра, в кінці кінців доведеться все виправляти На стадії MVP ще можна погратися з фантазіями, але коли йдеться про запуск у виробниче середовище? Хто захоче взяти на себе відповідальність за погану архітектуру Найбільше дратує такі "на основі відчуттів", коли технічний борг накопичується і рано чи пізно вибухне Можна зрозуміти бажання швидко ітеративно розвиватися, але не можна використовувати це як виправдання для ігнорування інфраструктури Говорячи просто, хороша архітектура коду може заощадити багато проблем у майбутньому... хіба це не очевидно
Переглянути оригіналвідповісти на0
ClassicDumpstervip
· 01-14 12:55
Інтуїтивна розробка? Це просто закопувати собі ями, щоб встигнути в термін ### Швидка ітерація дійсно крута, але потім доводиться розплачуватися ### Обманювати на етапі MVP — це тимчасово, а потім ті, хто підтримує, плачуть до смерті ### Код без рамки — це часова бомба ### Ось чому багато проектів у кінцевому підсумку перетворюються на пекло підтримки ### Ідея може бути крутою, але без належної реалізації — даремно ### Можна спробувати на ранніх етапах, але не пускайте сміттєвий код у виробництво ### Погана архітектура — потім доведеться знімати шари, щоб її змінити ### Найстрашніше — це вразливості безпеки, їх важко виявити при інтуїтивній розробці ### Говорячи просто, це лінь планувати, потім доводиться працювати понаднормово, щоб закрити ями ### На етапі прототипу можна обійтися, але при виробництві потрібно серйозно ставитися
Переглянути оригіналвідповісти на0
Ramen_Until_Richvip
· 01-14 12:51
Інтуїція — це розкіш, масштаб — реальність. Ганчірковий код повернеться і вкусить тебе. --- MVP можна робити будь-яким, але при масштабуванні потрібно буде відплатити борги. --- Чесно кажучи, код без рамок — це часова бомба, рано чи пізно вибухне. --- Хочеш писати код на основі відчуттів? Можна, адже обслуговують його не ти. --- Архітектура — це, з одного боку, лінь на початку, з іншого — великий збиток у майбутньому. --- Уразливості безпеки виникають саме так, ніхто не піклується, доки не станеться біда. --- Прототипи можна робити будь-якими, але при виході на продакшн потрібно ставитися серйозно. Це зрозуміло всім. --- Відчуття — це не стратегія, це справжня проблема. --- Кодова заборгованість рано чи пізно доведеться погасити, тож краще швидше створити рамки.
Переглянути оригіналвідповісти на0
CodeAuditQueenvip
· 01-14 12:34
Інтуїтивна розробка — це закладання мін у майбутнє, і коли з’явиться аудит, вже буде пізно жалкувати. --- Швидка перевірка MVP — це добре, але не можна використовувати це як виправдання для постійного лінування, адже зіпсована архітектура згодом обійдеться вдвічі дорожче при зміні. --- Говорячи просто, це попередник повторного входу — на ранніх етапах не налаштували безпекову структуру, і тепер будь-яка халепа може проникнути. --- Найстрашніше в сміттєвому коді — це не сам код, а те, що він може жити дуже довго і отруювати всю екосистему. --- Немає аудиту, немає стандартів, пишете код наосліп? Це так само, як ігнорувати перевірку на переповнення у контракті — рано чи пізно станеться щось погане. --- Якщо масштаб зростає, то все стане очевидним, і змінити щось вже буде неможливо, доведеться просто здатися.
Переглянути оригіналвідповісти на0
  • Закріпити