«Юзер платить не за красивий код, а за вирішення його проблеми», або Чому бізнесорієнтованість розробника важлива

Привіт! Я Руслан Газанфаров, Android-розробник в продуктовій компанії Universe, яка спеціалізується на створенні утиліт для iOS та Android-застосунків. Більше як рік тому я доєднався до команди, щоб перезапустити перший експериментальний застосунок на нову для компанії операційну систему, і вже через 9 місяців у нас було понад два мільйони завантажень.

У цьому «блозі-рефлексії» я ділюся своїм досвідом і трансформацією підходів до створення продукту та ролі розробника в бізнесі. Текст буде корисний технічним спеціалістам, які хочуть працювати в бізнес-орієнтованих компаніях, які інколи жертвують «якісним» кодом, а також тим спеціалістам, хто хоче зрозуміти цей майндсет, а не створювати «фічі для фічей».

Досвід у розробці та повернення до базових принципів

На початку літа 2022 року я знаходився у Львові, працював більше ніж півтора роки над застосунком Yakaboo і відповідав за Back-end та Android складові продукту. У нас були круті результати: за три місяці застосунок виріс майже у 100 разів. Проте я починав дивитися в майбутнє і думав, що може мене здивувати після шести років кар’єри розробника, адже побачив я достатньо:

  • роздуті ідеї стартапів, для яких ми писали застосунки в аутсорсі, і які в 95% випадках закривалися через пів року;
  • CRM-платформи, яким чомусь різко захотілося створити мобільну версію продукту, але ними ніхто не користувався;
  • застосунки для водіїв таксі та кур’єрів доставки;
  • купу різних тематичних застосунків, з яких до сьогодні працює 10%.

Рефлексуючи про свій досвід, зловив себе на думці, що індустрія мобільної розробки відійшла далеко від тих принципів, які були закладені у перших версіях App Store та Google Play. А саме:

  • Знайти базову потребу, яка є у великої кількості людей.
  • Зробити застосунок, який цю проблему вирішить.
  • Заробити грошей від вдячних користувачів, які більше не мають цього «головного болю».

Тому я взяв за основу ці базові принципи та розпочав пошуки нового місця роботи. За кілька тижнів співбесід я потрапив в теперішню команду і на момент отримання оферу мені здавалося: «Ну що там писати такого в цих застосунках для сканування документів, це ж просто робота з камерою та файлами, так?»

«Треба тестувати». Про культуру компанії навіть у розробці

Коли я долучився до команди, застосунок на Android вже існував. У вас може виникнути питання: «Чому в продуктовій компанії, яка є лідером в ніші сканерів на iOS, продукт на Android писали на аутстафі?». Все дуже просто — основне гасло в команді «треба тестувати». А тестувати, як правило, треба дешево і швидко, тому я у спадок отримав застосунок, який вже окупився і мав зведену unit-економіку.

З часом я зрозумів, що такий підхід дозволяє команді швидко ухвалювати рішення, базуючись на даних, та не витрачати зайві ресурси (час команди розробки та маркетингу) та фінанси в моменті. Тобто доречність моєї присутності в команді була вирішена ще до моєї появи, а ключовою задачею на випробувальний термін було перезапустити застосунок.

На цьому моменті я одразу оцінив відмінність підходу до запуску продукту від того, що я бачив останні 6 років. Спочатку була перевірена гіпотеза необхідності його існування, а вже потім створювалась окрема команда для його розвитку, а не навпаки. А той аргумент, що застосунок, як мені здавалося, був написаний не за останніми тенденціями в розробці, був нівельований іншим фактом: на той момент застосунком вже користувалися понад 200 000 людей, а якась частка з них вже платила. Адже користувач голосує грошима не за красивий код, який написав розробник, а за те, які потреби вирішує продукт.

Зрозуміти культуру компанії мені допомогло перебування в тісному контакті з командою. Тоді чи не вперше з початку пандемії я зустрів людей, які приходять в офіс не тому, що треба, а тому, що в офісі кайфово. Так мої кілька днів в Києві перетворилися на тиждень. Не міг відмовити собі в задоволенні провести ще кілька літніх сонячних днів на Подолі за рефакторингом код-бази та переведенням застосунку на актуальніші бібліотеки та інструменти.

Робота зі старими звичками

Після кількох років в аутсорсі, де, здавалося, усе найновітніше та свіженьке несуть в продукт для затягування процесу розробки та підтримки рівня захвату розробника, мені довелося добряче попрацювати над старими звичками.

Тож переписував я не тільки шар логіки застосунку, пов’язаної з бізнесом, а також все, що стосувалося бази даних та нетворкінгу — їх я переніс в окремі модулі. Трішки переробив навігацію, оновив бібліотеки, базово пробігся по всіх екранах та доклав максимум зусиль, щоб працювати над нововведеннями було приємно.

Результат, на який пішло трішки більше як три тижні з тестуванням, мав не тільки гарне відображення в крашлітиці, але і приємні покращення метрик в аналітиці. Але те, що мені, на перший погляд, здавалося маленьким застосунком, зовсім не виявилося легкою роботою.

Продукт за кількістю функціональностей та екранів здається невеличким, а кількість користувачів, які потенційно можуть бути його аудиторією, є мільйонною. Кожним екраном та кнопкою користуються десятки тисяч юзерів по всьому світу на такій кількості різних девайсів, що відвалитися може будь-що і будь-де.

Після ретельного тестування почалася велика кількість релізів, пов’язаних з основним підходом компанії. Що ми тільки не тестували:

  • розпізнавання рамок документа на екрані камери;
  • десяток ABC та АВСD тестів на екранах продажу;
  • автоматичний фільтр документа, який прибирав ефект зімʼятого паперу та висвітлював текст;
  • додаткове кешування документів, бо як виявилось, ОреnCV неймовірно вибагливий фреймворк навіть для останніх флагманів;
  • світлу тему додатка, яка виявилась важливішою для користувачів Android, ніж iOS;
  • купу дрібних поліпшень «життя» користувачів, про які вони розповіли нам під час досліджень.

Найцікавішим для мене виявився той факт, що більшість продуктових тестів, які за описом, здавалося, будуть успішними — фейлилися. 80% тестів у нашому сканері не принесли статистично значущих результатів, як фінансових, так і продуктових. Для себе відмітив ще одну річ: успішний продукт не можна побудувати, не опираючись на дані про його фактичне використання, та не генеруючи десятки гіпотез на місяць.

Навіть геніальна, на перший погляд, ідея, після втілення в продукті може не скласти іспит даними. Тому обов’язково треба тестувати, і бажано робити це швидко, іноді нехтуючи тим чи іншим принципом SOLID, не звернувши ретельної уваги на архітектуру, та пропускаючи десь стороною Domain Driven Design з Clean Architecture і всіма іншими модними методологіями у світі розробки.

Бо швидше за все код, написаний сьогодні в динамічному продукті, через місяць треба буде утилізувати, обмінявши його на важливі знання та дані.

Поради для бізнес-орієнтованих розробників

Тож якщо ви так само як і я вирішили попрацювати в data-driven команді, яка працює над продуктом для мільйонної аудиторії, або хочете стати більш бізнесорієнтованим розробником, то маю для вас невеличкий To-do лист:

  • Прокачати навички стратегічного мислення. Це дозволить мати повне розуміння бізнес-процесів, а не вирішувати тільки конкретну проблему певною технологією.
  • Познайомитися ближче з базовими метриками продукту та unit-економікою, навчитись розпізнавати LTV, CPI, CAC, MRR, ARR, ARPPU, ROI, ROMI.
  • Вивчити фундамент A/B тестування, а саме як після проведеного тесту команда буде оцінювати його успіх або провал та як потім реалізувати тест в продукті — це додатковий плюс.
  • Дивитись більше на продукт як користувач, а не розробник.
  • Навчіться думати не класними фічами, а користувацькими потребами та «болями».

А моєю задачею на наступні кілька років буде знаходити баланс між усіма новітніми інструментами у світі розробки, при цьому оперувати ними ближче до рівня контрольованого хаоса, іноді імпровізуючи, а іноді працюючи чітко по нотах. Коли все це сходиться разом — виходить прекрасна музика.

👍ПодобаєтьсяСподобалось22
До обраногоВ обраному11
LinkedIn

Найкращі коментарі пропустити

Прочитавши статтю складається враження, що якісний код — це така примха розробників і бізнес від цьєї якості не отримую користі. Так от — ні, якісний код окупається у середньостроковій та довгостроковій перспективі. Тому це вибір бізнесу — писати щось «на колінці» зараз і потім перепусувати чи робити одразу нормально (дбаючи про майбутнє проекту).

Ще пару місяців тому я був би згідний з заголовком.
Але потрапив на стартап писаний індусами, де в коді порушили абсолютно всі принципи KISS / DRY / SOLID.
Все б нічо, але фікс бага GTM івента родив ще 3 баги, бо один нещасний компонент з кнопкою оформлення замовлення — це три файли на три тищі строк сумарно, напхані дублікат спагетті кодом (де один тільки лоадер-кавер смикається разів двадцать, а не два).
Тут уже вирішуйте самі за що той бізнес платить, але виходу тепер швидкого нема.

Купа таких статей, а потім ідеш на співбесіду в Гугл і там питають літкод і дизайн.
Бізнес орієнтовними є ті розробники які знають за що платять кращі гроші на ринку, а то що ви описуєте тут це хороша робота менеджменту по організації комунікації в команді і вміння ставити зрозумілі цілі

Нормальная такая статья. Яркий пример когда «праграмист» сталкивается с «бизнесом»
Бизнес (как всегда) побеждает, и это хорошо — значит у бизнеса будут деньги заплатить програмисту.
Конечно, очень приятно и щекотно читать про «чистый код», «идеальную архитектуру», «SOLID KISS» и нежно мечтать ночами о том, какое идеально приложение вы в итоге напишете и как все ахнут! Но куда приятнее видеть пуш нотификацию о зачислении средств в банк за «гуд энаф» (и гуд — это еще я вежливо говорю!) приложение, которое «хитрый барыга втюхал доверчивым лохам юзерам».
И важно понимать, что если есть бабло — то приложение (пусть и в теории) можно будет потихоньку редизайнуть (если вдруг кому то будет не лень), а вот если бабла нету, то «идеальный код» в хрен никому не впился, денег нет, еды нет, смерть, гроб, кладбище.

зы задайте себе вопрос, что вы ЛИЧНО выберете: педалить «середнячок» за бабло — или конструировать идеальный кода нахаляву?
И если вы выбрали деньги — то не вижу причин для возмущений.

ззы да, разумеется, надо и меру знать и не гнать ну уж совсем уж фуфел, нарушая даже простейшие (и не имеющие затрат для импоментации) правила разработки.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Це дозволить мати повне розуміння бізнес-процесів, а не вирішувати тільки конкретну проблему певною технологією.

у ваша цена на рынке труда станет близкой к 0
просто потому, что рынок от нас требует требует прежде всего умения решать любые задачи инженерного плана.
условно говоря — сегодня вы строите мост, завтра — дом, послезавтра — вокзал
это требует больших усилия и времени.

и есть выбор — развиваться как инженер или погружаться в бизнес процессы конкретного продукта. А что будет если завтра продукт закроют по хотелке владельца или именно вас уволят ? кому нужны будут эти ну очень специфические знания на рынке труда неких бизнес процессов некой конторы, пусть даже это не рога и копыта ?
НИКОМУ.

Таким образом нормальный инженер — это человек который имеет высокую степень независимости. Если что — пожал плечами и пошел в другое место.
А тот, кто по уши в бизнес процессах то рискует дрожать как осиновый листок от малейшего дуновения ... «а кабы чего не вышло то»

Ринок сильно міняється.
Як би там не ржали з убогості AI я помітив що ChatGPT зараз користуюсь частіше гугла. Так інженери круті будуть і надалі потрібні але у якомусь хайлоад та там де займаються фундаментальними задачами (криптографія там, AI то же).

кому нужны будут эти ну очень специфические знания на рынке труда неких бизнес процессов некой конторы

Кому потрібні інженери, які не розуміють, що саме вони роблять? Знання бізнес-процесу (він один в компанії, все інше просто процеси) дає можливість дешевше та якісніше робити роботу. Процеси в цілому в компаніях однакові, різниця тільки в деяких деталях. Якщо ви в курсі, як, наприклад, проходить процедура підписання, візування, розторгнення договорів, то ви це побачите крізь у всіх компаніях. Якщо ви в курсі, що вас може чекати, то ви можете не робити дитячих помилок, наслідки яких ви будете потім виправляти в нескінченних нічних овертаймах. Якщо ви в курсі, як бухгалтерія працює з грошима, то ви зможете легко приміняти ці знання в інших галузях. Наприклад, як правильно провести сторно.

Тому гарний інженер, це не той, хто вимагає наддетального ТЗ, яке він потім виконає слово в слово, абсолютно не переймаючись про додаткові аспекти. Гарний інженер той, хто може оптимізувати та запропонувати найкраще рішення. А без знань процесів дуже важко це робити.

Якщо ви в курсі, як бухгалтерія працює з грошима, то ви зможете легко приміняти ці знання в інших галузях.

а потом сделать продукт который не соот. нормативным требованиям страны или группы стран
и нанести бизнесу прямой фин. ущерб, думая что все мол одинаково, да что там за глупости могут сказать ба зачем они нужны и так далее

то ви це побачите крізь у всіх компаніях

вопрос в том, что процессы и требования — это не статуя в граните или упрощенная абстракция вида диаграммы.
это что-то вроде океана, и соот. область — она отдельная предметная область, которой надо управлять и отслеживать
у вас банально головы не хватит вместить в полном объеме и то и это, особенно в ситуации когда бизнес сам не до конца понимает как оно в реальности работает то

Гарний інженер той, хто може оптимізувати та запропонувати найкраще рішення.

безусловно. но есть нюанс — инженер не может подменять себя других, каждый должен быть специалистом в своей области.

а потом сделать продукт который не соот. нормативным требованиям страны

Ви дійсно вважаєте, що інженери настільки тупі, що будуть так робити?
Вимоги країни стосовно певних правил обліку дійсно різні. А от процедури — в більшості однакові. Дебет-кредит, все таке. Ми вивчаємо бухоблік в університетах по книжках, які написані не в Україні, і все в нас норм. Ніхто не вмер.

Але інженери вони не такі, вони обовʼязково мусять бути обмеженими та недолугими, щоб не дай бог не напружити мозок чимось іншим... Я вірно все зрозумів? ;)

вопрос в том, что процессы и требования — это не статуя в граните или упрощенная абстракция вида диаграммы.

Якщо ви будете читати книжки по процесах, особливо про автоматизацію, то ви з подивом для себе відкриєте, що там є приклади з реального життя, але в цілому все доволі абстрактно та може використовуватися крізь. Наприклад, процес відвантаження товару клієнту завжди проходить певні стадії. Деталі можуть різнитися, але процес однаковий: потрібно взяти товар десь на умовному складі, передати клієнту в певний час в певному місці, у відповідь отримати підтвердження передачі. Якщо передача не відбулася, повернути товар на склад. Це базовий процес, він буде однаковим у всіх компаній, які мають товари, які треба відвантажувати клієнтам. Деталі, звісно ж, будуть відрізнятися. В когось це курʼєр, в когось це самовивіз, хтось переміщення між складами робить, й тому подібне. Але навіть тут, знову ж таки, є інші процеси, які так само стандартні. Наприклад курʼєрска доставка. Вона працює за однаковими «законами» крізь. Як субпроцес в процеса доставки, або як самостійний процес. Не важливо.

каждый должен быть специалистом в своей области

Я приведу приклад визначення інженера

Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build and test machines, complex systems, structures, gadgets and materials to fulfill functional objectives and requirements while considering the limitations imposed by practicality, regulation, safety and cost.

Не знаходиш, що сильно багато чого мусить вміти інженер, щоб називатися саме так? Якщо інженер не вміє нічого з переліченого, то це банальний кодер.

Я вірно все зрозумів? ;)

Вы пытаетесь переложить функции аналитиков на инженеров. Все остальное — дешевая демагогия в стиле «да тебе слабо, да чего тебе стоит ... ».
Но быть и хорошим аналитиком и хорошим инженером быть невозможно. Вы или средний инженер и средний аналитик или плохой тот или другой.

функции аналитиков на инженеров

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

Но быть и хорошим аналитиком и хорошим инженером быть невозможно

Знання предметної області не про аналітику взагалі. Це про ерудицію.

Дуже крута стаття!
Повністю підтримую позицію автора, чим більше у нас буде бізнес-орієнтованих розробників, тим більше буде успішних українських продуктових ІТ компаній!
А з приводу коментарів — бізнес орієнтованість точно не дорівнює код з багами, який погано працює, бо це якраз зовісім не вирішує проблеми юзера. Є сенс в нього інвестувати, якщо продукт не буде фундаментально змінюватись роками. Але частіше це не так, бо продукти як і потреби змінюються постійно

чим більше у нас буде бізнес-орієнтованих розробників

это решается без громких лозунгов. Если доход человека зависит от дохода бизнеса — автоматически у большей части повышается уровень бизнес ориентированности. Правда такая схема ну ужас как не нравиться менеджерам, которые воспринимают премии сотруднику от % прибыли как личное оскорбление (не могут «сиполапые инженеры» получить больше «белой кости») и потому бегают с плакатами и лозунгами «экономика должна быть экономной» рисуя презентации как они пытаются повысить вовлеченность и лояльность

До речі, згадалося, що дядько Боб у своїх книжках якраз прямим текстом і писав, що так, бізнес може не розуміти необхідності підтримки належної якості коду і роботи з технічним боргом, але це ваш обов’язок, як хорошого програміста — переконати його в цьому.

Взагалі, це проблема, яку дуже влучно англійською описав мій швейцарський колега, приятель і лінійний менеджер, коли говорив про одного кандидата, який ставився до стандартів вельми скептично — «мабуть, він просто ніде не працював достатньо довго, щоб відчути наслідки власних неправильних рішень».
В цьому й суть — треба результат на вчора і хто його буде думати про післязавтра, коли воно може для проєкту і не настати?

Я бачив дистильовний варіант такого підходу — моя наразі остання робота в Україні, британський «вічний» проєкт платформи з P2P-кредитування — в ядрі там був лютий гівнокод, написаний профільними спеціалістами десь в 2010 для втілення їхніх ідей. Ті специ своє отримали, а натомість найняли купу народу в офіс і на аутстафф в Україну, щоб цю красу якось утримувати на плаву і розвивати.

Any full can write a code, computer can understand. Good programmer can write a code human can understand. © Martin Fowler

Everybody asks “What is the code?” But nobody asks “How is the code?”

“How much is the code?”

Тільки буде гальмувати. А так да, ені фул

can you provide proof on this, please? very stupid shit as well

Юзер платить не за красивий код, але за не красивий код платить бізнес х3

У юзерів немає проблем. Проблеми для юзерів вигадують маркетологи і продакт овнери.

Колего, який номер вашої планети в тентурі?

Вони в антітентурі, любий друже.

Any product that sells itself resolves users’ issues as much as possible

Кожному своє, звичайно, але нафіга так жити? Це ж адок якийсь. Ви не девелопите. Ви більше там по маркетингу та тестуванню і крутитеся як білка у колесі із цим постійним циклом тестування. І наскільки я знаю за мобіли не дофіга платять. Зрозуміло наче чому — встановлюють мільйони, користується там дай б-г половина, платить з них пара відсотків разово смішні гроші, які там ще на купу народу розподіляються. Тому мені бачиться величезний профтик у питаннях

Прокачати навички стратегічного мислення. Це дозволить мати повне розуміння бізнес-процесів, а не вирішувати тільки конкретну проблему певною технологією.

і вашої ролі у цьому всьому. Чом не піти у якийсь бекенд? Платять наче більше дещо, а головне — умови людські. Будете спокійно собі займатись саме розробкою (і саме спокійно). Ні, всюди моменти клієнтоорієнтованості присутні, беззаперечно. Але багато де на перший план таки виходить саме розробка, як у книжках написано. Книжки ті таки писали, щоб бізнес проблеми вирішувати. Просто у інших галузях. Більших по коду і по грошах (і я б сказав по впливу). Така от стратегічна пропозиція — обирати особистий кар’єрний шлях в напрямку галузей, де більші гроші, особливо для розробника. Ні, гроші, звичайно, не все. Може вам подобається бути маркетологом, що вміє кодити і розробляти застосунки на пару хвилин на рік покористуватись, роблячи фічі такі, що важко навіть придумати корисну. Що є знаком, що додаток розробляти вже не дуже є сенс і час почати новий і молитись, щоб він вистрелив і якийсь MS/Google вас не вибив з ніши. Це таки дуже не для кожного шлях.

Чому ви у цьому сидите і що ви думаєте робити далі? Де ви бачите себе через 5 років™? Ви просто нічого крім мобіл робити не вмієте? Чи може вам долю від прибутку платять і насправді грошей у вас дофіга, а я тут пургу несу? Мені здається таку мороку менше ніж за 7к нафіг мати (це от подивившись скільки у мобілах платять). Чи може свою контору відкрити думаєте, або в адміністративку якусь свалити? Бо навичкам розробника таке середовище не сприяє.

Насчёт жизни в кайф полностью с вами согласен. Можно за 6-8к писать код, с относительно нормальным ворк/лайв балансом и без вот этого всего бизнеса.
Но если хочешь больше денег, то выбора нет. Надо вникать во все вот это бизнесовое, со всеми вытекающими.

Но если хочешь больше денег, то выбора нет. Надо вникать во все вот это бизнесовое, со всеми вытекающими.

если хочешь больше денег, то да — надо вникать в «бизнесовое», а не в то, как правильно и красиво писать код

Так от питання якраз — чи автору платять ті більше грошей? Бо у дрібній розробці часто буває, що мороки купа, у т.ч. бізнесової, а із грошима — не дуже.

Не думаю что сейчас платят много, но это же путь.
Через 5 лет может быть СТО, ко-фаундером и начнёт собирать дивиденды.

Ну або ні. Ви теж страждали подібним трешем за малий прайс заради шляху?
Там жеж ризики є відповідні, наприклад, що контора гегнеться через ненадійність ніши і доведеться знов на шлях ставати. Із не найкращими навичками розробника. Цей rat race у мобілах не дофіга привабливий, як на мене. Десь ближче до ентерпрайзу теж є цей шлях, але він ближче до грошей. І там трішки більш по книжках код.

В мобилках такая же работа и такие же зп как и везде
jobs.dou.ua/...​n=Senior SE&domain=Mobile
Мы про бизнес подход, когда вместо Рихтера ты читаешь про custdev и бережливый стартап.
Но все специалисты важны, все специалисты нужны.
Конкретно наша постсовковая специфика такая, что у наших разработчиков сильные хард-скилы, но слабые софт-скилы и слабое понимание бизнеса. Поэтому прочитать пару книжек не помешает, а там смотри и понравится)

наша постсовковая специфика такая, что у наших разработчиков сильные хард-скилы, но слабые софт-скилы и слабое понимание бизнеса. Поэтому прочитать пару книжек не помешает, а там смотри и понравится)

Тут даже не в этом дело, как мне кажется. В Украине есть поколение разработчиков, которое профессионально выросло на книгах Гради Буча, того же дяди Боба, Мартина Фаулера и т.п.

А все эти товарищи проповедовали в той или иной мере красивый код, правильную архитектуру, дизайн паттерны и всё прочее, что не сильно сочетается с подходом «тяп-ляп на коленке, абы побыстрее», как наиболее типичным для MVP.

Более того — любые другие подходы они откровенно клеймили как непрофессиональные, что вызывало своего рода когнитивное искажение вида «если я пишу плохой код не по заветам „светил“ — я никуда не годный разработчик»

выросло на книгах Гради Буча, того же дяди Боба, Мартина Фаулера и т.п.

Отличные книги маст-хев для любого профи.
Ступеньки мастерства:
-ты пишешь как придётся, потому что не умеешь по другому.
-ты пишешь хорошо, потому что умеешь.
-ты понимаешь, где надо писать хорошо, а где нет.
И тут не перепрыгнешь надо пройти все.

ты понимаешь, где надо писать хорошо, а где нет.

Это верно, вот только оные авторы вбивали в неокрепшие умы догму, что говнокодить — плохо, причём — безапелляционно плохо. «Вонючий код» и вот это всё.

Единственное — у Фаулера в enterprise architecture patterns помню оговорки, что не всегда вам нужны ORM и доменные модели, в каких-то случаях и transaction script хватит.

Но это, скорее, исключение из общего посыла про качественное проектирование и программирование «на века».

Так что, для достижения последней ступеньки нужно преодолеть ещё и «давление авторитетов»

TLDR: книжки тяжіють до overengineering. Це не здравий ухил, але це не значить, що колись там можна «писати погано».

Архітектура має відповідати функціоналу. Мало функціоналу — мало архітектури, мало абстракцій. Багато — багато. KISS. Але не тупіше функціоналу, інакше його ж не буде.
Дві основни проблеми архітектури — це under engineering, коли прослоєк-абстракцій замало і код перетворюється на спагетті і over engineering, коли їх забагато і невелика зміна логіки дає велику зміну у коді, бува, що і з переписуванням купи абстракцій. І є просто гріх — невіповідність архітектури і функціоналу.
Написати гарну архітектуру важко, тому що майбутнє не відомо. Не відомо, як зміниться функціонал. Не відомо, під що треба закладати архітектуру, а під що ні.

Книжки просто природньо тяжіють до overengineering. Тому що їм треба продаватись, мати контент, дати варіант для найгіршого випадку.

Так от, гарно писати треба завжди. Але гарно — це не значить складно! Я вважаю, що автор топіку — не погано пише. Пише під функціонал, дещо мінімалістично, щоб не нафігачити архітектуруї під функціонал, якого не буде. Спочатку тестами дізнається, що буде, а потім робить якусь архітектуру під це. Схилятись дещо в бік underengineering — це не смертний гріх, не значить писати погано. Ну у автора там майбутнє дуже невідомо, тому наперед архітектуру городити не варто, бо це час і вона потім запросто полетіть до дідька, обставини просто такі. Це всюди і завжди присутнє, просто у дуже різній кількості.

Я писав купу дрібного, там на раз дані конвертнути, тулзи які виростали, або ні, у щось більше. Але з досвідом, навіть прості речі пишеш дещо інакше, не довше, а саме краще, більш відповідно функціоналу, читабельніше, при тому самому об’ємі коду більш розширюємо. Не треба вважати, що це ви робите «неправильно» і це там виклик авторітетам. Треба продовжувати не використовувати те, що не потрібно і намагатись писати просто краще під задачу. Вважати, що ось все, тепер інколи можна писати лайно, я бунтар — це небезпечно.

Мало функціоналу — мало архітектури, мало абстракцій

Согласен, но не совсем так.
Кроме количества функционала, ещё 2 переменные.
-важность конкретного ограниченного контекста (модуля)
-стадия жизненного цикла программного обеспечения
Эмпирическое наблюдение, что большая часть споров подобных этому происходят между разработчиками, которые считают это константами (но разными).

Отличные книги маст-хев для любого профи.

Ну да, инфоцыган дядя Боб должен стоять на любой полке как пример того, как не надо ни делать, ни даже писать книги. Хотя нахрена вообще нужны негативные примеры, когда достаточно положительных?
Буч и Фаулер получше — уже в примеры «иногда таки можно» и «людям удобно думать в таком стиле».

В остальном скорее согласен.

Я страждав.

Їбанувся на цім шляху, та це й не дивно. Але яка розумная цьому альтернатіва?

Альтернатив безліч, одну я написав, до речі. Тут головне ж — розуміти, нафіга ви робите те, що робите. Автор он про шлях нічого не писав. Бізнес бачення для продукту — є, але ж можна подивитись ширше і застосувати оце все

Для себе відмітив ще одну річ: успішний продукт не можна побудувати, не опираючись на дані про його фактичне використання, та не генеруючи десятки гіпотез на місяць.

для власної кар’єри, для себе, любимого.

Висуну контр тезу)

Як на мене в B2C нішах з невисоким LTV до 200$, зазвичай ключовий вплив на ROI та скейл продукту мають ні «красивий код», ні «вирішення проблеми юзера», а ефективний маркетинг, онбордінг та продукт-аналітика

Да, эффективный маркетинг тут заслуженно на первом месте. На втором месте должно быть удобство использования и уровень полезности продукта для пользователей. Что касается продукт-аналитики, то она на десятом месте. Если продукт — никому не нужное неудобное в использовании говно, то тут никакая продукт-аналитика не поможет сделать продукт популярным. Вот грамотный маркетинг может сильно помочь :)

Я мабуть не точно сформулював, мав на увазі, що продакт-аналітика в ключі онбордінгу та конверту (висока конверсія в проходження до salesscreen та якісний баланс конверту в покупку з ARPPU нульового дня + грамотно підібрані підписки, які зроблять можливим стабільне дотягування LTV за умов не ок продукту)

Так, цілковито з вами погоджуюся. Практично неможливо побудувати якісний продукт з дірявим відром лише на маркетингу, даркпатернах та ребілах підписок.

Тут просто до питання кількості наявних ресурсів. На жаль, часто в рамках українських продуктових компаній саме цей підхід є більш релевантним, адже значно важче підняти достатньо інвестицій і залишається лише «арбітражити» щоб зібрати на нормальний прод

Відкриваєш проект а там 7 з 10 екранів це webview, бо так «дешевше» і швидше деліверити фічі на 3 платформи, але після року танців з бубном навколо webview`х приймається рішення написати все нативно. Соррі флешбеки. Потрібно витримувати баланс між webview і TDD, навіть в аутсорсі.

«Познайомитися ближче з базовими метриками продукту та unit-економікою, навчитись розпізнавати LTV, CPI, CAC, MRR, ARR, ARPPU, ROI, ROMI»
<<< от тут повністю погоджуюсь, бажано знати що ці букви означають, бо я починають кидатися цими абрівіатурами то починаєш розуміти як людина не з ІТ слухає розмову ІТівців.

а ще краще було б просто у статті описати ці терміни, щоб люди не гуглили кожен окремий термін

Нормальная такая статья. Яркий пример когда «праграмист» сталкивается с «бизнесом»
Бизнес (как всегда) побеждает, и это хорошо — значит у бизнеса будут деньги заплатить програмисту.
Конечно, очень приятно и щекотно читать про «чистый код», «идеальную архитектуру», «SOLID KISS» и нежно мечтать ночами о том, какое идеально приложение вы в итоге напишете и как все ахнут! Но куда приятнее видеть пуш нотификацию о зачислении средств в банк за «гуд энаф» (и гуд — это еще я вежливо говорю!) приложение, которое «хитрый барыга втюхал доверчивым лохам юзерам».
И важно понимать, что если есть бабло — то приложение (пусть и в теории) можно будет потихоньку редизайнуть (если вдруг кому то будет не лень), а вот если бабла нету, то «идеальный код» в хрен никому не впился, денег нет, еды нет, смерть, гроб, кладбище.

зы задайте себе вопрос, что вы ЛИЧНО выберете: педалить «середнячок» за бабло — или конструировать идеальный кода нахаляву?
И если вы выбрали деньги — то не вижу причин для возмущений.

ззы да, разумеется, надо и меру знать и не гнать ну уж совсем уж фуфел, нарушая даже простейшие (и не имеющие затрат для импоментации) правила разработки.

Здається в нас в країні всі так і думають — юристи, лікарі, будівельники, ну і депутати. Хоча останні здається таки гонять повний фуфел.

Здається в нас в країні всі так і думають — юристи, лікарі, будівельники, ну і депутати. Хоча останні здається таки гонять повний фуфел.

Не понял связи принципа «разумной достаточности» в программировании и вашей тирады.

Юзер-то не платить, але продукт випускають працівникі. І «красівий код» одна зі складових умов труда — як і офіс, робоче залізо, культура і атмосфера в колективі. І відповідно впливає і на продуктивність, і на вмотивованність і на якість виконуємої роботи. Тому юзеру звичайно насрати наскільки красивий код, але якщо насрати менеджменту компанії, то така компанія рано чи пізно піде на дно.

Де зараз Майкрософт? На дні? А код в них далеко не цукор, та не синтаксичний цукор. Камон, деякі глючні продукти працюють роками без змін, всі скиглять, але користуються.

А ви впевпені що Майкрософт це та компанія до якої підходить крітерій що «менеджменту компанії насрати на якість коду»?
Я ось щось сумніваюся. Тим більше, що я ніде не казав що це єдиний крітерій для успішності.
Майкрософт і була на дні саме тоді, коли туди мало хто хотів іти працювати, з різних причин, але в першу чергу із-за внутрішньої культури компанії.

Навіть якщо їм не насрати, вони все одне випустили Вісту, випустили WinME, та купу інших програмних продуктів, якість яких була далекою від ідеальної.

Ты посмотри сорцы дотнеткора да и вообще даже старого фреймворка. Это просто конфетка. Почти идеал для таких объемов.

Один продукт з сотен?

Ви не зовсім правий, це значною мірою залежить від складності продукту.

Чим складніший продукт — тим вищі ризики на фанарь написаного коду, адже шкода від потенційних багів може просто нівелювати кости та час зекономлений на розробці.

Але водночас є купа продуктів з однією фічею та підписками, які можуть давати хороший скейл та ROI, і в таких нішах важливу роль часту грає час: хтось зальє злизаний та написаний лівою ногою функціонал конкурентів на пусту апрувнуту апку в сторі і заробить купу грошей, а хто займатиметься дрочем з архітектурою та кодом і втратить можливість зайти в нішу

Багато в чому згоден, що для клієнта важливо не код, а те, що він робить. Але сам код важливий для компанії розробника, і самих розробників перш за все.
Зрозуміло, що якщо наклепати купу красивого коду, який робить те, що клієнту не потрібно, або ще гірше, не робить те, що клієнту потрібно, це буде фейл з точки зору бізнесу.
Але якщо код писаний ябияк, то коли продукт успішно буде продаватися, і настане потреба його розширяти, то може настати головняк із кодом, бо виявиться, що там така рахітектура, що біда. Я вже мовчу, коли в коді просто купа багів, чи закладено купа технічних боргів. В результаті настане той же фейл для бізнесу.
Тому як казав Т. Шевченко, і клієнта любіть, і за код не забувайте.

З моєю точки зору посил правильний, але висновки дуже суперечливі.

1. Назва «Юзер платить не за красивий код, а за вирішення його проблеми» не дуже бізнес-орієнтована :). Користувач платить за зрозумілий, зручний та якісний сервіс. Йому начхати на код і він не повинен думати про якісь проблеми, користуючись вашим сервісом (це стосується не тільки цифрової частини вашого сервісу).

2. Якщо ваша продуктова компанія надає тільки цифровий сервіс (технологічна продуктова компанія), то основні затрати компанії будуть на розробку (у сервісу може бути багато систем на бакенді, наприклад, мікросервісна архітектура, багато інтерфейсів, таких як мобільні, веб і т.д.), підтримку сервісу (баг фікс, зміна вже існуючих фічів, розробка нових та вбудування їх у ваш сервіс), підтримку інфраструктури та на саму інфраструктуру. Якщо дивитися з точки зору розробників, то вони повинні намагатися знайти оптимальну рівновагу між продуктивністю розроблених систем, витратами на інфраструктуру та часом розробки. Успішність цій рівноваги залежить, як мінімум, від двох факторів — процесс розробки і архітектура вашого сервісу (який може включати багато розроблювальних систем). Тобто, якщо ви (ваша компанія) забиває на архітектуру, то бог вам у поміч, тому що компанії буде нема на кого сподіватися коли почнеться... А воно може початися зі зростом користувачів та компанії :). Тобто я б не радив користуватися вашими порадами про нехтуванням архітектури чи DDD (якщо у вас складний домен). І зовсім не радив нехтувати принципами SOLID у будь якій ситуації при використанні об’єктно-орієнтованої платформи. SOLID ні як не гальмує розробку. Якщо ви не користуєтесь чи не вмієте користуватися SOLID принципами, наприклад, у джаві, то це тільки каже про ваш рівень розробника.

3. Питання до доцільності і час розробки. Є таки сервіси, у яких розроблена фіча доцільна на обмежений час, наприклад, у геймінгу новий модуль (нове проходження) доцільний на свята (жорстка дата делівері) і цим будуть користуватися не більше тижня, місяця... Або вам потрібно зрозуміти доцільність нової фічі, наприклад, у масмакреті. Подібна розробка і впровадження займе не багато часу, якщо у вас продумана та якісна архітектура вашого сервісу (який може включати багато систем, на кшталт мікросервісної архітектури), налагоджений процесс розробки і підтримки, у вас є нормальні розробники (і не тільки розробники), які розуміють, що таке прототипування і що з цим робити у майбутньому. Але щоб усе це було так легко та просто, треба вкластися у багато що, як мінімум у процесс розробки, архітектуру і найм співробітників :).

4. Якщо ваша розробка, а не тестування, орієнтована на data-driven, тобто, розробка більш менш тупого редактора БД чи перенесення даних з точки А у точку Б, то вам зовсім не потрібно перейматися бізнес-орієнтованістю. Вам потрібно перейматися тільки тим, щоб усі ваші дані були вчасно на місці :).

5. З порад автора для бізнес-орієнтованої розробки, як мінімум, я б виключив прокачування навичок стратегічного мислення :). Для розробки це зовсім не потрібно. Більшість компаній не має спеціалістів зі стратегічним мисленням. Більш того, більшість держав не має спеціалістів зі стратегічним мисленням, наприклад, держава України (я не про всіх громадян). Якщо ж вам цікаве стратегічне мислення, то почніть, наприклад, з банди чотирьох — Сергій Дацюк, Юрій Чудновський, Володимир Нікітін і Тарас Бебешко. Можливо вам це зайде :).

Роман, ваша глубока відповідь мене вразила. По цієї відповіді я можу сказати, що у вас глибоке мислення і неймовірна освіченість.

Це результат аналізу і синтезу. Дякую за Ваше розуміння.

Та нема за що дякувати. Бажаю вам у майбутньому ще більш потужний аналіз і синтез вашого мозку, щоб ваші відповіді були більш коротші і у той же час всеосяжні у познані всесвіту.

Якщо Вас раптом забанили у гуглі, то ось Вам посилання

zbruc.eu/node/71386

Надіюсь, розберетеся, про що там йдеться

А для тих, хто не в контексті, чудова підбірка цитат Дацюка zbruc.eu/node/30743

Якщо девелопер пише хороший/поганий код з багами, то теж міняти такого девелопера. Нащо платити за код з багами?!

До нас завітав суперкодер, який ніколи не пише код з багами?

Надо двері якось закрутить — це ж не богадельня, шо вони все лізуть і лізуть ©

Баг — это позор. Если это конечно не какой-то суперграничный кейс, который отыскивать действительно сложно 99% юзерам. Но да, это позор и некачественная работа и вообще неуважение.

Меня тоже так учили ещё в конце 90х — начале 2000х. Но, беда-печаль в том, что окно Овертона сдвинулось, и теперь на баги (если это не что-то уж совсем критичное, из-за чего невозможно нормально пользоваться приложением) — всем плевать.

Главное — быстрее выйти на рынок, выкатить новые фичи. А то, что оно всё сырое, глючное и недоделанное — всем насрать.

Главное — быстрее выйти на рынок, выкатить новые фичи. А то, что оно всё сырое, глючное и недоделанное — всем насрать.

Вы так говорите об этом, будто это что-то плохое
Что лучше — иметь глючно ПО на рынке сейчас — или иметь безглючное ПО на рынке никогда?
В первом случае у вас есть доход и бабло на ЗП и дальнейшее функционирование, во втором — у вас даже чуйства глубокого удовлетворения от хорошо сделаной работы не будет (т.к. вы никогда не напишене ПО без багов)

зы я так монетизацию двух пет проджектов просрал, всё за «идеальным качеством» гнался.

Вы так говорите об этом, будто это что-то плохое
Что лучше — иметь глючно ПО на рынке сейчас — или иметь безглючное ПО на рынке никогда?

Здесь нужно сделать весьма очевидную ремарку, что между «глючное» и «безглючное» — целый спектр значений.

Разумеется, обычное потребительское ПО никто и никогда не будет вылизывать до идеального состояния. Проблема в том, что сейчас пользователя приучили к тому, что даже нормального стабильно работающего ПО он не получит. Неудобный UI, глюки при самом что ни на есть штатном использовании безо всяких «переподвывертов», совершенно тупые и ничем не объяснимые ограничения в функциональности — все это пользователь вынужден «кушать» из-за идиотской гонки за скорость выхода на рынок и/или малобюджетности разработки как таковой.

Неудобный UI, глюки при самом что ни на есть штатном использовании безо всяких «переподвывертов», совершенно тупые и ничем не объяснимые ограничения в функциональности — все это пользователь вынужден «кушать» из-за идиотской гонки за скорость выхода на рынок и/или малобюджетности разработки как таковой.

давно такого не встречал, если честно.
Но я в основном сижу на штатных продуктах МС, там такого нету

Ну вот продукты МС (как бы их не материли в прошлом) — как раз, сейчас — приятное исключение.

С другой стороны, МС вряд ли можно назвать малобюджетной компанией :) Да и они давно нашли и окучили ряд рыночных ниш, в которых с ними никто агрессивно не конкурирует, поэтому могут себе позволить пилить софт качественно, с толком и расстановкой.

Ну вот продукты МС (как бы их не материли в прошлом) — как раз, сейчас — приятное исключение.

Кажется, вы ими не пробовали пользоваться.

поэтому могут себе позволить пилить софт качественно, с толком и расстановкой.

Именно поэтому начиная с Windows 10, да-да, собственный штат тестировщиков был сокращён до минимума, а вся надежда на поиск багов возложена на комьюнити бета-тестеров.

Кажется, вы ими не пробовали пользоваться.

Тут вам неверно кажется — в основном, только ими и пользовался, начиная с конца 90х и где-то года до 2021го.

Именно поэтому начиная с Windows 10, да-да, собственный штат тестировщиков был сокращён до минимума, а вся надежда на поиск багов возложена на комьюнити бета-тестеров.

Не Windows единым... хотя, и на 10ку после какого-то там очередного апдейта у меня практически не было нареканий. Ну так, именно с виндой испокон веков так было, что «до второго сервис пака новую версию ставить нельзя». Слишком сложный продукт, который ещё и должен нормально работать на 100500 различных конфигурациях оборудования — такое невозможно полностью протестировать in-house.

Вместе с тем, тот же MS Office, Visual Studio, VS Code, Microsoft ToDo — вот вообще не доставляли проблем, и я не помню там ни одного бага, который реально бы портил впечатление от пользования данными продуктами.

а вся надежда на поиск багов возложена на комьюнити бета-тестеров.

Я бы с удовольствием почитал статью на эту тему
у вас, разумеется, есть ссылки?
Или вы так — наугад брякнули?

Все относительно. Рассмотрим вот такой кейс. Вы, стартап, выкатываете на рынок полурабочий продукт. В течении полугода вы постоянно выкатываете новые полурабочие фичи, с задержками исправляя старые баги. Вроде как клиенты растут — ваш продукт на текущем рынке не имеет конкурентов. Но вот тут, откуда не возьмись, через те же пол года появляется первый конкурент — имеет более удобный сервис и на порядок меньше багов. И новые фичи у него более чем рабочие. Через еще пол года конкурент вас полностью выкидывает с рынка (вам же как бы надо больше фичей, что бы конкурента задавить). К чему этот кейс? К тому, что срать на баги надо с умом, особенно если у вас есть или может появиться конкурент :). Так что надо искать баланс между рынком и качеством.

Все относительно. Рассмотрим вот такой кейс. Вы, стартап, выкатываете на рынок полурабочий продукт. В течении полугода вы постоянно выкатываете новые полурабочие фичи, с задержками исправляя старые баги. Вроде как клиенты растут — ваш продукт на текущем рынке не имеет конкурентов. Но вот тут, откуда не возьмись, через те же пол года появляется первый конкурент — имеет более удобный сервис и на порядок меньше багов. И новые фичи у него более чем рабочие. Через еще пол года конкурент вас полностью выкидывает с рынка (вам же как бы надо больше фичей, что бы конкурента задавить). К чему этот кейс? К тому, что срать на баги надо с умом, особенно если у вас есть или может появиться конкурент :). Так что надо искать баланс между рынком и качеством.

Всё это красиво, но так получается довольно редко. Т.к. у конкурента те же проблемы что и у вас — но только он еще и заходит в занятую нишу.

Почему редко получается? Вы судите об этом на основе 0.001% удачных стартапов, которые решили поделиться «формулой» своего успеха?

Почему редко получается? Вы судите об этом на основе 0.001% удачных стартапов, которые решили поделиться «формулой» своего успеха?

Нет, я сужу по наличию продуктов на рынке.
Если бы ваше предположение было бы верно, то мы бы имели бесконечный потом сменяющегося по, ведь «конкуренты сделают лучше».
но этого нет. Откуда мы имеем, как минимум, два варианта: или юзерам в целом насрать на к-во багов (и так оно и есть), или конкуренты делают точно такое же говно, так что переходить на него не имеет смысла.
Ну или оппозит — юзеров вполне устраивает высокого качество продукта — а конкурент всё равно не может предложить что-то лучше.

Кейс UMC vs Kyivstar

Угу. Причем сами по себе сети всё еще живут и вполне успешно конкурируют.

Ми так 4 з 5 конкурентів з ринку вижили. Надали продукт з новим UX, швидше початок використання, менше геморою з боку клієнтів на розгортання продукту, та працювало все на порядок швидше. Все, ніша наша.

Ми так 4 з 5 конкурентів з ринку вижили. Надали продукт з новим UX, швидше початок використання, менше геморою з боку клієнтів на розгортання продукту, та працювало все на порядок швидше. Все, ніша наша.

но вас пока еще никто не выжил? Хотя, казалось бы — вы учились на ошибках 4 неудачников, а ваши конкуренты учаться на истории вашего успеха.

Конкурентів більше не було. Той, що залишився, виживав тільки за рахунок того, що клієнти платили йому гроші, але послугами не користувалися. Тримали, щоб не дати померти, боялися, що ми скористаємося монопольним становищем. Інші не з’явилися.

Конкурентів більше не було.

Т.е. область была с минимальной конкуренцией? И вы выиграли не потому что были «лучше всех и выгрызли победу зубами», а «просто повезло» ©
Ок, ничего не имею против, более того — даже немного завидую.

Так, пощастило отримати першого клієнта. А далі були кращими за інших. Ми принципово поміняли підходи, хоча всі казали, що куди ви зі своїм SaaS лізете, тут так не прийнято. Виявилося, що об’єктивно ми були по всіх параметрах кращими за конкурентів. А SPA SaaS був просто вишенькою на тортику.

у конкурента те же проблемы что и у вас — но только он еще и заходит в занятую нишу.

Вспомним тот же приснопамятный МС, который в своё время влёгкую выдавливал конкурентов из ниш просто за счёт того, что имел экспертизу и ресурсы сделать то же самое, но намного лучше.

Когда появился Excel, он был далеко не первым приложением для электронных таблиц. Но названия его тогдашних конкурентов сейчас не каждый и вспомнит. Аналогичная история была и с Word, если не ошибаюсь.

Когда появился Excel, он был далеко не первым приложением для электронных таблиц. Но названия его тогдашних конкурентов сейчас не каждый и вспомнит. Аналогичная история была и с Word, если не ошибаюсь.

Я помню. И даже помню благодаря какой именно фиче ворд/эксель вытеснили конкурентов (обратная совместимость)

Вспомним тот же приснопамятный МС, который в своё время влёгкую выдавливал конкурентов из ниш просто за счёт того, что имел экспертизу и ресурсы сделать то же самое, но намного лучше.

Благодаря «Embrace, extend, and extinguish».

Благодаря откровенно нечестной конкуренции — как пример, скидки тем производителям компов, которые не поставляют другие ОС.

Благодаря личным связям, из-за которых IBM слил почти арбуз баксов на то, с чего не получил никакой пользы как корпорация, зато кое-чей родственник стал первым богачом мира. Хотя да, это вполне ресурсы.

И, наконец, кто же убил Гэри Килдалла, так и не раскрыто, зато кому это было выгодно — очевидно.

кто же убил Гэри Килдалла, так и не раскрыто, зато кому это было выгодно — очевидно.

Убили его в 1994м, когда каток MS уже был слишком мощным, чтобы Килдалл мог как-то существенно навредить Гейтсу. А за книгу... ну я сильно сомневаюсь, чтобы Гейтс «заказал» Килдалла за рукопись в духе «я обиделос»

всем плевать

Все же, стоит сказать, что не всем плевать. Например сырые игры сообществом не принимаются вообще. Некоторые несюжетные недоделки в играх — да, а если недоделка-баг сюжетная, то патч просят сразу и побыстрее — истерика на игровых форумах 24/7.

, то патч просят сразу и побыстрее — истерика на игровых форумах 24/7.

но деньги за игру уже, как правило, уплочены?

зы игропром вообще особая тема. Если игра глючная, то имеет смысл чинить только стопперы, которые не дают продвинуться по сюжету. Остальные баги можно игнорировать. 95% игр — одноразовые, никто не использует их годами, как, к пример, те жн офисные пакеты или среды разработки.

95% игр — одноразовые, никто не использует их годами, как, к пример, те жн офисные пакеты или среды разработки

Зато если попал в 5%, то озолотишься
Игропром это технически сложная индустрия (была до последних пор) с очень высокими рисками

Зато если попал в 5%, то озолотишься

что значит «попал»?
ві заранее не знаете, у вас игра — одноразовая или нет? :)

ві заранее не знаете, у вас игра — одноразовая или нет? :)

То и значит, заранее нельзя угадать как игра будет воспринята публикой.

Игра это не решение проблем юзеров :-)

Даже если программа разработки включает в себя дальнейшую монетизацию и поддержку, все может прогореть в ноль.

А бывает и наоборот. Появляется инди игра и ставит рынок на одно колено по продажам.

То и значит, заранее нельзя угадать как игра будет воспринята публикой.

Ага. т.е. если ві планируете, скажем, «дум єтернал» — то ві предполагаете, что в игру будут играть снова и снова, ждать от вас фиксов и так далее....
Ну ок.

Сепукку треба робити після цього?

Якщо у девелопера час написання «хорошого» коду і поганого однаковий, то для менеджмента у мене дуже погані новини. Тим паче після випуску CodeGPT

Досі здригаюся від згадки про те як я сім років тому місяць витратив на конфігурацію seed’у БД тестовими даними, який пістон прилетів від кастомера і як ми після цього обговорювали це з сіньйор PM (тобто з нормальним як має бути PM-м)... В деталях там я зробив все-таки трохи більше, але суть була в тому, що я справді занадто захопився вузьким технічним питанням з неочевидним вихлопом. Це був останній раз, коли я так робив.

АЛЕ! Якість коду це трохи інше, це те, що множить технічний борг, якщо ним нехтувати.

Як завжди влучно висловився щодо цього мій колега-швейцарець — «Якщо людина не розуміє важливості правильної архітектури та організації коду, то можливо вона просто не була на одному проєкті достатньо довго, щоб зіткнутися з наслідками власних неправильних рішень?».
Ну то він, він трохи ідеаліст і не здає собі справи, що в наших суворих реаліях сервісної розробки цю шишку набиваєш переважно на наслідках ЧУЖИХ рішень :)

1. Пишешь в стиле пьяного индуса — криво, глюкаво, тормознуто, но чтобы оно как-то решало поставленные задачи клиента.
2. Подробно покрываешь код тестами
3. Переписываешь особо конфликтные модули, которые вызывают у клиента максимум батхерта.

Подход коррелирует с китайским марткетингом, решаем текущие задачи клиента, а если у него появятся новые задачи, он купит еще один новый девайс.

Тема коніпасти в індуському коді розкрита не повністю...

Так і не зрозумів — це добре чи погано?

А як 1 та 2 поєднуються? В мому розумінні, щоби зробити № 2 — треба буде переписати, значною мірою, № 1. Чи № 1 це, все ж таки, нормальний код, але «не ідеальний»?

Ну код работает и решает задачу, но архитектура кода вот такая:
online.wsj.com/media/041012pod09_J.jpg

То як його тестами можливо покрити, якщо там все настільки погано?

Тестами покрыть набор кейсов, собственно сгенерированных и багов от пользователей. А дальше его переписывать чтобы тесты проходили. Тоесть нейросеть наоборот, где есть тестовая выборка и код должен её покрывать.

Бізнесоорієнтованість коду — це не про якість, це — про ефективність.

Базова економічна формула звучить просто: максимізація доходів при мінімізації витрат. Розробник не може ніяк прямо вплинути на максимізацію доходів, тільки опосередковано, а от впливати на мінімізацію витрат — легко.

Але тут є купа прихованих підводних каменів. Наприклад, тестування або код-ревью, з точки зору економіки, збільшують витрати при майже нульовому впливу на доходи. Не треба казати про користувачів, які не зможуть користуватися глючними продуктами та закінчать відносини. Є економічні моделі, при яких це взагалі не впливає на рівень продажів, тобто доходів.

Фреймворкизація навпаки, зменшує витрати, бо результату можна досягати швидше. Але розробка фреймворка сама по собі витратна, тому треба чітко оцінювати ефект від його використання. Якщо вам треба розробка простої утиліти, то використання або розробка власного фреймворку, очевидно, буде оверкілом.

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

Якість коду, хоч й звучить дуже болісно для розробників, є в більшості випадків витратною частиною без впливу на доходи. Хтось скаже, що якість зменшує кількість помилок, але архітектура чи певні підходи можуть зробити абсолютно те саме без всіх зайвих танців з бубном. А ще є випадки, коли навіть поганий код краще за якісний, бо він був виданий на ринок вчасно.

Якість коду, хоч й звучить дуже болісно для розробників, є в більшості випадків витратною частиною

Якщо ми говоримо не про throwaway prototype, то я б сказав, що якість коду — це інвестиція в зниження вартості підтримки та подальшого розвитку цього коду.

Інвестиція мусить окупатися. Інакше можна наінвестувати так, що код буде дуже якісним, а компанія дуже мертвою. Тим паче, якість коду — це суб’єктивний показник. А що можна порахувати, так це кількість часу, який потрібно витратити на додавання чи заміну функціональності, кількість мінорних та мажорних багів, кількість ітерацій баг-фікс-баг-фікс або будь-яку іншу кількісну характеристику.

Особисто ти захочеш підтримувати код з такою архітектурою?
online.wsj.com/media/041012pod09_J.jpg

І думаю всім зрозуміло що в такому коді один виправлений баг створить умовно 2-3 нових

Мені байдуже який саме код або архітектура. Є економічна доцільність. Якщо доцільно продовжувати підтримку, то треба продовжувати. Якщо не доцільно, тоді треба зробити все, щоб це стало ефективним.

Ви звідкіля впевнені, що ваш код краще? ;)

так про це і мова. Економічна доцільність як раз залежить від витрат. А витрати залежать від складності підтримки. А складність від того як зроблен код.

А поганий код чи архітектура не свідчать про високу вартість підтримки. Може залежати, а може й ні.

Не треба казати про користувачів, які не зможуть користуватися глючними продуктами та закінчать відносини.

Ага, попрацюй на якомусь фінтеку. Де через баги у користувачів зникнуть гроші. Тоді поговоримо ;)

Зникнуть та з’являться на місце. Це ж фінтек, а не хухри-мухри. Відображення грошей в системі та обов’язки — не одне й те саме.

Наприклад, тестування або код-ревью, з точки зору економіки, збільшують витрати при майже нульовому впливу на доходи.

То Ви просто не навчились рахувати.
І ідеальна архітектура дає свою частку доходу, причому досить солідну. Біда в тому, що до початку використання ніхто навіть не здогадується про «правильну» архітектуру. А от у випадках, коли умовно кажучи «все рівно» що скаже клієнт, то там можна і архітектуру городити ідеальну.

Фреймворкизація навпаки, зменшує витрати, бо результату можна досягати швидше.

От як тут. З одним суттєвим «але»: помилка в бібліотеці зазвичай коштує на порядок дорожче. І чим більш ідеальною є бібліотека, тим більше коштує помилка в ній для кожного конкретного проекту.

То Ви просто не навчились рахувати.

Розкажіть як правильно.

І ідеальна архітектура дає свою частку доходу, причому досить солідну.

Її спочатку треба побудувати, а як будь-який ідеал, вона буде вимагати нескінченної кількості ресурсів.

помилка в бібліотеці зазвичай коштує на порядок дорожче.

Фреймворкізація — це не про код, а про процеси.

Рахуйте затрати на додавання фічі.

Ми колись зменшили з 30-ти днів в індусів до 3-х в нас. Тому нас досі люблять і дають бабло, от вже 24 роки.

Витрати на додавання фіч без аналізу первинних витрат мало про що кажуть. Наприклад, ви три роки будували ядро, щоб потім фічу за три дні викатувати. А хтось витратив лише рік.

Мене дуже дивує, як безліч «програмістів» тут агресивно відстоюють своє положення кодерів, меленьких вінтиків у громадному легасі, які нічого не вирішують і не хочуть вирішувати. Їм достатньо копирсатись роками у своєму модулі (або 2-3 модулях). Зрозуміло, що там дуже комфортно сидіти, поки велика корпорація працює та не рахує гроші на роздуті ІТ відділи, але вас же перших замінять на всілякі ГПТ, адже є архітекти, бізнес-аналітики, маркетологи, etc., які знають що робити і як, а ви для них лише інструмент, який можна замінити на більш ефективний та дешевий.

Впевнений? Може тобі й не платять, але щось мені підказує, що лідам, архітектам, СТО, VP, etc. платять побільше, ніж кодерам 😉

Їх більше у відношенні до кандидатів, які відповідають вимогам таких вакансій.

Ну вот есть на проекте бизнес-аналисты. Они шарят в бизнесе в десятки раз круче чем любой дев на том же проекте. А зп как у миддл-тестировщика. Вот и все.

никогда такого не встречал, обычно они ничего не понимают и у всех все выспрашивают, а потом не пойми о чем документы пишут =\

ужасно. уволить к чертям собачим. бизнес-аналист это ценнейший носитель уникальных знаний. он вообще ничего у девелопера не должен расспрашивать. как раз наоборот. и да. те документы, которые они пишут важнее чем код во много раз.

А мені свого часу пощастило зустріти такого БА — їй можна було задати абсолютно будь-яке питання щодо бізнес-логіки проекту і завжди отримати відповідь. На жаль, бізнес часто економить на таких спеціалістах, а потім девелопер грає роль детектива, намагаючись витягнути бізнес-вимоги як може і в кого може. А таким, як ви описали, дійсно незрозуміло, за що гроші платять.

Мне такой один раз попался, он был со стороны заказчика, а ещё он был индус, но не такой как обычно можно встретить, а прямо образцовый, в конце, правда, оказалось что то, что мы сделали не совпадает с тем, что ожидал заказчик, но это уже другая история :)

Ось коли ці бізнес-аналісти зможуть писати таски в джирі у вигляді, який гптХ буде конвертувати у робочий код, покритий тестами, то отих міддл-тестера та міддл-дева просто звільнять. Але поки вони не можуть навіть для людей-девів нормально задачі ставити, тому й отримують мало

Платять, прикинь.
Тому уточнимо — за це не платять тобі.

Мне то как раз платят, но я фрилансер

Володя, коли вже українською зрештою?!
Платять за що домовишся. Іноді варто казати ротом побажання, якщо немає бажання вести розробку далі невеликого модуля лише тому, що «за інше не платять». Бо там далі є цікаві штуки, наприклад, банальне невміння працювати з більшими частинами рішення, відсутність фундаментальних знань і т.д.

Володя, коли вже українською зрештою?!

Когда мне сделают предложение от которого не смогу отказаться. Ты готов платить, чтобы я тебе писал на украинском, сколько?

Іноді варто казати ротом побажання, якщо немає бажання вести розробку далі невеликого модуля лише тому, що «за інше не платять»

А какие у меня «побажання»? Получить как можно больше сделав как можно меньше. Инициатива наказуема

Пропоную тобі почати писати українською в публічному просторі, а в іншому разі зібрати речі і висунутись в сторону порєбріка. Як тобі «прєдложеніє»?

Скажи це цьому хлопцю t.me/lost_generation_21. «Обожнюю» борцунів

«Обожнюю» стрілочників.

По суті є що сказати? Скажеш те саме російськомовним людям з Херсону, які голіруч танки зупиняли та на мітинги виходили проти пігдогів?
П.С.
А що я бачу, хахах -> dou.ua/forums/topic/34825
А що ж «не срослось» раніше з українською?

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

Завжди було цікаво, чого люди типу тебе завжди переходять на персональні образи? Так себе впевненіше почуваєш, так? Самоствердився? Ну молодець. І де я написав, що українську не треба використовувати в публічному просторі? Звичайно треба. Але треба підштовхувати людей це робити, розумно, а не в бидло-стилі, щоб люди захотіли та зповагою до цього віднеслись, а після коментарів, накшталт твоїх, хочеться промити очі, а не українську мову використовувати.

треба підштовхувати людей це робити, розумно

Ахаха, омг, це як же наприклад? Ну серйозно? Дам відповідь — ніяк. Русифікація настільки щільно пролізла скрізь де тільки можна, що окрім як принципового рішення, інших бути не може. Але, бачу, для багатьох це не аргумент — ок, почекаємо ще років 10 і кілька вторгнень.

Ну дядь, ти ж перший написав про борцунів, ще й стрілки перевів, що ж ти зливаєшся відразу. Хіба це не персональна образа?

Хочеш накинути мені за мої російськомовні статті? Ок, тоді накидуй це усім іншим і власне конторі яка поставила такі умови і до цих пір проводить відкриті лекції, дописуючи маленькими літерками «мова лекції — російська».

Увы, я отн него могу отказаться. А ты предложи так, чтоб не мог

Та ще задачка, але все ж зважте на таке прохання.

Побажання/Робота це баланс цінності для кожної зі сторін. Якщо твоє менше дуже для мене цінне, я буду готовий за це платити більше. Проблема в тому, що переважна частина кодерів (не програмістів чи інженерів) має завищені очікування стосовно цінності власного коду.

Зрозуміло, що там дуже комфортно сидіти, поки велика корпорація працює та не рахує гроші на роздуті ІТ відділи, але вас же перших замінять на всілякі ГПТ

этого не будет, по крайней мере в этом столетии, к этому даже нет предпосылок на данные время

Брехня. Індійці є, були і будуть

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

ну быть тим лидом это дичь еще та, быть тех лидом или синьором разницы особо нет, а быть архитектором это вообще не про программирование, больше половины архитекторов не умеет программировать в принципе. тех кто хочет оставаться программистом вполне можно понять

больше половины архитекторов не умеет программировать в принципе.

це типу композитора, який не знає нот? це як? тоді то не архітектори, а самозванці. Так, архітектор може не знати всіх останніх фреймворків чи нововведень, але дуже швидко це підтягне бо в нього є основні навички: пошук інформації, він знає програмування (не конкретну мову, але краще щоб то була мова його проекту, і він знає саме як програмувати ту чи іншу задачу, які алгоритми, патерни і т.д.), він набагато мат’юріті, він спокійно може підключитися на рев’ю конкретного коду і перевірити, що там пишуть і чи воно йде в правильному руслі, як він задумав. Бо якщо це не так, то його треба гнати «ссаними» тряпками.

Ви намалювали власне бачення задач архітектора. Але це лише ваше очікування. Архітектор може не робити всього того, що ви від нього хочете, але меншим архітектором він не стане.

це не моє бачення, а це ті архітектори, з якими я працюю. може у вас якісь інші, то мені вас дуже шкода.

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

та ви шо :) а я і не знав. ми ж говоримо про розробку програмного забезпечення? і всі перераховані вами не вміють програмувати? лол

і всі перераховані вами не вміють програмувати?

Не удивлюсь если или не умеют совсем, или умеют на базовом уровне.

я ще припущу, що

архітектори стратегічного рівня

не вміє, правда не знаю навіщо його сюди приплели — він ближче до бізнесу ніж до розробки. А от інші? ну то жесть :(

А от інші? ну то жесть :(

А почему бі и нет, собственно?
Вы рассматриваете изготовление ПО с точки зрения низового исполнителя.

Если проводить аналогию с настоящими архитекторами, которые строят здания? Сомневаюсь что они умеют класть кирпич, копать, заливать бетон, возводить стены, красить, проводить проводку и канализацию.
Да, не исключено, что в ВУЗе у них были практические занятия и они даже ездили на стройку что-то делать своими руками — но архитекторы не лучшие каменщики, плиточники и так далее.

Я совершенно согласен с вами, что лучше, если архитектор таки имеет прикладные практические навыки. но считаю что это не всегда и не обязательно нужно.

Если проводить аналогию с настоящими архитекторами, которые строят здания? Сомневаюсь что они умеют класть кирпич, копать, заливать бетон, возводить стены, красить, проводить проводку и канализацию.

ніхто і не каже, що вони це мають робити професійно. але вміти точно можуть і повинні. почитайте про Гауді. І я думаю треба не з архітекторами на будівництві робити аналогію, а з композиторами.

І я думаю треба не з архітекторами на будівництві робити аналогію, а з композиторами.

:)
Композитор как раз и есть «низовой исполнитель»
А вот как насчет «архитектор» = «Дирижер»? :)

«низовой исполнитель»

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

«архитектор» = «Дирижер»

дирижер не знає нот? чи слуху в нього немає? чи він не вміє грати на якомусь інструменті?

дирижер не знає нот? чи слуху в нього немає? чи він не вміє грати на якомусь інструменті?

Думаю, тут ближе «не умеет играть на инструменте» ©

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

Согласен, композитор ближе к техлиду.

Думаю, тут ближе «не умеет играть на инструменте» ©

Я загубив вашу лінію(думку). І що? До чого це все?

Согласен, композитор ближе к техлиду.

Ну да. Ну да. Моцарт тех лід, а бог його архітектор :)

Вони не повинні це робити, якщо їх рівень вище. Значно вище. Там інші задачі та цілі. Не писати код. Не думати про структуру даних, назви класів, та навіть не про вибір фреймворку. Ні, це рівень стратегії. Наприклад, яку саме платформу обрати та які саме рішення підібрати, щоб виконати головні задачі бізнесу на наступні 10 років.

Значно вище.

Про це я і написав. Вони мат’юріті.

Не думати про структуру даних, назви класів, та навіть не про вибір фреймворку.

Де я про це писав? А от як з ваших слів слідує, що вони не вміють програмувати я не бачу.

Вони можуть не вміти програмувати, взагалі. Навпаки, вміння програмувати може таким людям заважати. Архітектура — не про програмування, а про вміння мислити абстракціями високого рівня, процесами, стратегіями.

Вони можуть не вміти програмувати, взагалі.

Можуть, можуть взагалі на роботу не ходити, але то не архітектори, то як я і писав — самозванці. І тому він ніколи не буде Гауді, Моцартом чи Вівальді. Якщо він в «пяном бреду» нарисував собі щось в голові, але воно дале від реальності і він не може це сам перевірити бо не розуіє як програмувати, то треба гнать його «ссаними» тряпками того «архітектора».

І тому він ніколи не буде Гауді, Моцартом чи Вівальді.

Да, у нас как не посмотришь в любую контору — всё сплошь гауди работают
Нам мы Сальери или Черни хотя бы — но вы про них и не вспомнили

Ну судячи з коментів «архітекторів», то відсутність вміння програмування це ок, тому і маємо не архітектуру, а будинок з «гівна і палок»

Я делаю таски когда горит. И PoC пишу. Что со мной не так?(

Дякую! Я працюю з такими архітекторами. І ПР-истворюють, і код дивляться. І запитати в них можна. А не «я не я і хата не моя», то ви щось не так реалізували, а я вялікий все вірно придумав.

судя по твоему линкедину ты до конца еще не понимаешь чем занимается архитектор, как следствие не занимаешься этим и имеешь много свободного времени и чтобы быть полезным делаешь то, что делал раньше. все вполне закономерно. ты можешь легко проверить истинность или ложность моего утверждения ответив себе на вопрос: чем может занимается архитектор в продуктовой компании на 50 человек чтобы быть фултайм занятым (ну и соответственно на все время работы в компании), не выполнять работу, которую могут/должны выполнять допустим техлиды или бизнес аналитики. если у тебя есть ответ на этот вопрос, то почему ты делаешь не свою работу, а чужую за других? если ответа нет, то скорее всего твоя должность просто содержит слово «архитектор» чтобы сделать ее более привлекательной, такое сплошь и рядом последние годы

если в компании где реально нужен архитектор ты начнешь помогать деливери горящие таски закрывать, то сначала получишь тонкий намек что то, что ты делаешь очень важно и полезно для компании, но стоит посмотреть в другую сторону, а при его игнорировании получишь увольнение

Я понимаю, что на суждения влияет личный опыт. А он у всех разный. Везде где я работал/с кем общаюсь архитекторы или кодят или кодили в разные периоды. А в стартапах кодит даже СТО (первые несколько лет + потом для души).
Но вообще это старая тема, еще с нулевых есть мем Architecture Astronaut или с десятых PowerPoint архитектор.
Если пропустили этот холивар, я кратко перескажу.
Примерно так.
Только очень большие компании могут себе позволить высокооплачиваемого юнита, который производит только абстракции (или в аутсорсе, где архитектор это скорее пресейл-менеджер). Но даже если могут, например Амазон, не допускают такого, потому что архитектор, который не кодит теряет навык, отрывается от технологии и не может адекватно оценить последствия своих решений. Не говоря уже о уважении разработчиков (прозвище астронавт, говорит само за себя).
Но с другой стороны, архитектура и разработка это разные обязаности и разные навыки. Поэтому если переборщить с кодом может потерятся перспектива и глобальное видение.
Поэтому консенсус примерно такой. Архитектор ОБЯЗАН программировать % от своего рабочего времени. Где-то % больше, где-то меньше, где-то это продакшн код + PoC, где-то только PoC.
Хотя допускаю, что есть компании где архитектор это менеджерская должность (и такое лучше обговаривать на берегу) просто я таких не видел и соответвенно работать в такой компании не буду.
ЗЫ. Про придумать занятие, что бы ничего не делать и это обосновать поинт не понял. Навык может быть и полезный, но при чем тут архитектура и кодинг)

Везде где я работал/с кем общаюсь архитекторы или кодят или кодили в разные периоды

тут важный нюанс кодили для деливери или нет, потому что если да, то это ну вообще не то что должно быть

А в стартапах кодит даже СТО (первые несколько лет + потом для души).

в такое место лучше не попадать никогда, полно нормальных стартапов

Только очень большие компании могут себе позволить высокооплачиваемого юнита, который производит только абстракции

по продуктовым обычно около 1 архитектора на 100 сотрудников (на всякий случай эти 100 не только технические специалисты, программистов может быть лишь 10я часть от этой сотни).

или в аутсорсе, где архитектор это скорее пресейл-менеджер

здесь обычно статическое количество не зависимо от размера компании, которое особо не растет и не уменьшается

Но даже если могут, например Амазон, не допускают такого, потому что архитектор, который не кодит теряет навык, отрывается от технологии и не может адекватно оценить последствия своих решений.

либо ты говоришь о аппликейшен архитекторе, либо я даже не знаю зачем они это делают, писание кода никак не поможет далать работу от солюшен архитектора и выше

Не говоря уже о уважении разработчиков (прозвище астронавт, говорит само за себя).

это какая-то фигня уже для неуверенных в себе, какая разница кто там что думает =\ а вообще за последние 2 года я разговаривал с разработчиками может в общей сумме часа 3. при чем учитывая что работа никак не пересекается, это были либо краткое общение на общем митинге, либо вопросы после презентации, либо чел меня сам нашел и чет просит помочь

Но с другой стороны, архитектура и разработка это разные обязаности и разные навыки. Поэтому если переборщить с кодом может потерятся перспектива и глобальное видение.

это все сказки такие же как название топика, куда оно денется? можно отстать конечно, если забить на что-то, ну так не забивай на основную специализацию и все

Поэтому консенсус примерно такой. Архитектор ОБЯЗАН программировать % от своего рабочего времени. Где-то % больше, где-то меньше, где-то это продакшн код + PoC, где-то только PoC.
Хотя допускаю, что есть компании где архитектор это менеджерская должность (и такое лучше обговаривать на берегу) просто я таких не видел и соответвенно работать в такой компании не буду.

есть компании где архитектор техническая должность, при этом она не связана с деливери

ЗЫ. Про придумать занятие, что бы ничего не делать и это обосновать поинт не понял. Навык может быть и полезный, но при чем тут архитектура и кодинг)

это был ответ на твой вопрос что ты делаешь не так, ты описал задачи, которыми обычно занимается лид, я тебе написал что есть вероятность что ты занимаешься в основном лидовскими задачами, при этом чем занимаются архитектора можешь и не знать. и предложил способ самопроверки

за последние 2 года я разговаривал с разработчиками может в общей сумме часа 3. при чем учитывая что работа никак не пересекается

Это многое обьясняет. В общем все обьясняет.
Стало самому интересно сколько вакансий с лейблом архитектор на доу сейчас без по вашей терминологии «лидовских задач». Не так много если честно.
PoC + менторство + принятие технических решений почти везде.
Есть без этого, что-то вроде внедрить заказчику коробочное решение, но меньше.

Стало самому интересно сколько вакансий с лейблом архитектор на доу сейчас без по вашей терминологии «лидовских задач». Не так много если честно.

0-1 шт :) обычно действительно либо техлид с лейблом архитектор, либо пресейл-инженер. обе позиции достаточно неприятные, в первой ты остается как и был техлидом, при этом не меняется вообще ничего и получаешь дизмораль что вот он потолок, а все равно все тоже самое, а во второй это вообще выглядит как деградация личности, я вывел методичку на свой второй пресейл и мне больше не нужно было ничего делать, это очень оптимально чтобы много зарабатывать при этом вообще не напрягаясь, но меня пугает то что вся эта рутина автоматизируется и после 5 лет занятий только ею человек больше непригоден ни к чему

Написал маленький парсер, что бы скачать описания вакансий с фильтром архитектор.
И отправил в модель на класификацию Tech Lead | Pre-Sales
Получилось Tech Lead = 36, Pre-Sales = 3
Но я согласен, что там где архитектор Pre-Sales, кодить не надо.
Там где архитектор Tech Lead, кодить надо.

Вкрай упереджене ставлення.

архітектор повинен вміти програмувати. це правило. він не пилить продакшен фічі, не фіксить дефекти(але може бути консультантом в складних випадках), він не рев’ювить код кожного дня і т.д, але запилити POC, бути в курсі як іде проєкт, який він придумав, приходити іноді на пре/планування та ретро — це маст хев. Бо в іншому випадку, його проєкт вмре, або там такого напилять, що воно буде ну зовсім інше ніж те що він задумував.

Архітектура та програмування знаходяться поруч, але не витікають одна з одної. Все, що ви описуєте як вимоги до архітектора, це справа техліда або архітектора програмного рішення. Архітектори рішень можуть не знати взагалі певних мов програмувань, а мікросервіси на них будуть написані та використані. Для API або інтерфейсів неважливо взагалі, на якій мові буде імплементація. Для зв’язання різних систем в одну, теж. Тут важливіше принципи, стратегії, методології, ніж вся низькорівнева реалізація, як то назви методів, класів, функцій, тощо.

Архітектори рішень можуть не знати взагалі певних мов програмувань,

С вашей точки зрения. А рыночек считает по другому.
Архитектор, который как главспец в разработке. Должим быть экспертом в каком-то языке.
Архитектор, который как продавец может и не знать да.

Ринок не закінчується на галерах. Проекти бувають куди більш масштабними.

С вашей точки зрения. А рыночек считает по другому. 

да нет, если идешь на позицию архитектора обычно там считают как Александр пишет. самое забавное что вы оба, похоже, одинаково не знаете что оно там на этих вакансиях и сочиняете как бы оно должно по вашему быть

Архитектор, который как главспец в разработке. Должим быть экспертом в каком-то языке. 

за крайние собеседований 30 мне не задавали вопросов связанных с программированием, хоть я и эксперт в дотнете это ничего мне не дает ровным счетом. учитывая этот факт равновероятно получить данную позицию являясь и не являясь экспертом в каком-то языке

Архитектор, который как продавец может и не знать да.

вопросы на собеседовании любого архитектора ± теже самые, так что умение программировать не будет критерием выбора со стороны нанимателя

ps но мне встречались вакансии с словом архитектор, но без любых связанных с этой позицией требований, зато были все требования, которые обычно хотят от лида. но такая позиция никак не связана с архитекторской работой и дальше этот опыт тебе зачтут как лидовский, если ты расскажешь о нем, а если не расскажешь, и до этого не был архитектором, то будет выглядеть что ты пытаешь обмануть что был архитектором, ведь отсутствие опыта будет сразу видно, а ты декларируешь его наличие

вопросы на со
беседовании любого архитектора ± теже самые,

Две реальные вакансии. По твоему там будут одинаковые собеседования? Или дай угадаю. Первая это архитектор, вторая это тех лид?
jobs.dou.ua/...​ies/230739/?from=list_hot
Other responsibilities will include

Collaborate with the team at Crayon to develop products, solutions, workload, and solution accelerators that can be brought to the market.
Support the sales process by creating content and recommendations for AWS-based solutions, providing proposals, high-level designs, and Statements of Work.
Work closely with customers and partners to present solutions and options, conduct workshops and discussions.
Take ownership of project delivery and cloud assessments, leading teams to ensure that customer satisfaction is maintained and that project milestones are met.
Develop and implement tailored cloud economics and migration plan
jobs.dou.ua/...​ies/232516/?from=list_hot
— Elicit and understand key functional requirements
— Elicit and define non-functional requirements
— Design and document architectural decisions with the level of detail required to satisfy architecturally significant requirements
— Conduct research and implement proofs-of-concept / demos for the team
— Manage architectural debt and long-term vision of the software architecture
— Make infrastructure design decisions to support the solution
— Improve operational efficiency of the software development process and value delivery
— Manage architectural backlog and prioritize with PdMs
— Define strategic expertise needs and identify gaps in teams’ knowledge
— Review the effectiveness of the learning activity
— People mentoring and knowledge sharing
— Conduct training in own field of expertise

первая это хрен пойми что, им идеально подойдет говорливый девопс, ну а по описанию пресейл-инженер

а вторую я знаю, они уже второй год ищут, я у них собеседовался и полностью понимаю что оно, там куча этапов собеседований, на техническое приходят 4 тех специалиста: девопс, фронтенд, бекенд и судя по всему тимлид, который только вводное слово говорит и передает им слово, они гоняют тебя по глубинам своих специализаций. ни одного вопроса для архитектора у них не было, зато мы пообщались за самые глубины разработки. => они искали фулстека, который одинаково хорош везде, при этом будет лидить команду. сейчас после 2х лет неудачных поисков они могли пересмотреть требования, но я не думаю что там произошли кардинальные изменения и они ищут что-то принципиально другое, скорее всего тот же лид-фулстек

як то назви методів, класів, функцій, тощо.

де я писав, що це справа архітектора?

а мікросервіси на них будуть написані та використані. Для API або інтерфейсів неважливо взагалі, на якій мові буде імплементація. Для зв’язання різних систем в одну, теж.

може коли там все дуже і просто і не важливо, а от коли це велика, нагружена система, і є складний дефект, то все навпаки і архітектор, який не розуміє як це працює на тій чи інший мові і не може допомогти команді, завалить проєкт існуючого клієнта.

який не розуміє як це працює на тій чи інший мові і не може допомогти команді

Його волю мусить хтось транслювати в код. Перефразую, в нього мусить бути особа, яка відповідальна за якість коду в певній частині системи. Вона проконтролює все.

Перефразую, в нього мусить бути особа, яка відповідальна за якість коду в певній частині системи. Вона проконтролює все.

систем складна, багато модулів, мікросервісів. Та людина баче тільки свою частину і тільки архітектор може бачити всю картину.

upd. а як архітектор може довіряти тій особі? він її співбесідує?

Архітектор дійсно бачить всю картину, а ця картина не про функції та назви змінних.

upd. а як архітектор може довіряти тій особі? він її співбесідує?

Довіра — це про нормальні процеси в компанії. Ви мусите довіряти людям, інакше ви станете ботлнеком для всієї компанії.

а ця картина не про функції та назви змінних.

ще раз задам питання: де я про це писав? :)

Ви мусите довіряти людям, інакше ви станете ботлнеком для всієї компанії.

Ну так, так :) Уявіть: складна система, куча модулів, тімів всі щось пилять. Прилітає надскладний дефек, від крутого клієнта. Всі тіми написали, що вони не знайшли проблему бо реалізували все вірно. Що далі? М’яч на стороні архітектора.

ще раз задам питання: де я про це писав? :)

Ви може й не писали. Але сусідні коментатори дуже на цьому акцентували увагу.

М’яч на стороні архітектора.

З якого біса він в нього? Якщо дефек існує, то реалізація вже невірна. Але, хто відповідальний за реалізацію? Архітектор? А з якого переляку? Ні, звісно, він може цим займатися, тримати розробників і їжакових рукавицях та роздавати копняків, але тоді він не архітект, а техлід.

Але сусідні коментатори дуже на цьому акцентували увагу.

Не бачив, ну най буде.

З якого біса він в нього? Якщо дефек існує, то реалізація вже невірна

Якого біса це не вірна? А як же довіра? От чоловік, якому архітектор довіряє каже — реалізація вірна і проблема в архітектурі. Що далі?

Архітектор дійсно бачить всю картину, а ця картина не про функції та назви змінних

чтобы видеть всю картину не нужно ничего кроме желания, разработчик точно так же как и архитектор может все это узнать, если оно его интересует. это очередная сказочка от управленцев чтобы манипулировать разработчиком

Знати не значить вміти використовувати. Якщо розробника попросять щось реалізувати нове, з яким він ще не стикався, то вірогідність його фейлу набагато вища за таку в архітектора. Але він може знати все про архітектуру поточної системи. Іншими словами, архітектор вміє передбачати помилки та знає як не допускати їх в майбутньому.

чтобы видеть всю картину не нужно ничего кроме желания, разработчик точно так же как и архитектор может все это узнать, если оно его интересует

O RLY?
Тут вопрос даже не в самом разработчике, а гораздо больше откуда у некоторого количества SME, которые будут рассказывать про «всю картину» будет столько свободного времени чтобы тратить его на любознательного-за-пределами-обязанностей?

Хто буде код писати коли всі підуть в архітекти?

Джуніор-архітекти. З повагою, ваш Кеп

По-перше, всі підуть, але далеко не всі дійдуть ;)
По-друге, хто буде перемальовувати креслення вручну, коли всі підуть проектувати у CADах?

Сейчас контекст gpt для 4-ой версии 30к токенов.
Когда (если) контекст станет размером 30кк токенов количество легаси кодеров сократится в 10 раз. Это даже не прогноз, а просто факт.

с таким количеством токенов он не будет оставаться бесплатным или дешевым, интеллект в нем от этого не зародится это все равно будет тоже самое что есть сейчас только с потенциально большими возможностями, кроме того увеличение количества токенов имеет негативные стороны, кроме увеличенного расхода ресурсов. диплернинг не позволяет выйти на то что ты себе нафантазировал

За меня тебе ответил алгоритм. Ничего не исправлял кнтр-с, кнтр-в.
«Понимаю твою озабоченность ). Как сказал Билл Гейтс: „640 КБ должно хватить для любых задач!“, что оказалось ошибочным предположением. Увеличение количества токенов в контексте ИИ может привести к высоким затратам и увеличенному потреблению ресурсов, но также открывает новые возможности для исследований и инноваций. В будущем стоимость и потребление ресурсов должны оптимизироваться благодаря развитию технологий и инфраструктуры ).

Искусственный интеллект не заменит разработчиков, но совместное использование ИИ и человеческих специалистов может повысить эффективность и качество работы. ИИ может заниматься рутинными задачами и предлагать оптимальные решения, основанные на анализе данных, позволяя разработчикам сосредоточиться на более сложных и творческих задачах ).

Следует помнить уроки, полученные из прошлых ошибок, и быть готовыми к неожиданным изменениям и возможностям, которые могут возникнуть при масштабировании ИИ ).»
ChatGPT

За меня тебе ответил алгоритм

я очень рад, но меня мало интересует профанское мнение. ты можешь мне не верить и думать что с жптчата что-то получится большее чем гугление и рерайтинг по старым данным, которые к тому же содержат много ошибок. но нет этого не будет, мы еще увидим улучшения по его работе, но кроме повышения точности ответов и разбора введенного пользователем текста ничего не будет. ии в нем нет и не появится, это невозможно при выбранном подходе

В работой с кодом сейчас проблема в том, что надо сильно декомпозировать задачу, что тот еще геморой, и легаси системы, которые надо сопровождать.
А так в лямбды или ажур функции генерить код можно уже сейчас.

для небольших проектов это может сработать, но не из-за лямбд, а из-за примитивности решения

с таким количеством токенов он не будет оставаться бесплатным или дешевым

как написал один:
...смотрят на доступный *им* *сегодня* уровень технологий и из него пытаются делать выводы, тогда как в таких разговорах всегда необходимо экстраполировать. Сейчас всем вдруг стала видна GPT (хотя как я не раз писал мы, как и все «в теме» с ней работали уже 2 года плюс минус) — и вы делаете выводы на основе вашего опыта с GPT. Если бы я два года назад писал о том, на что она способна сегодня, меня точно также закидали бы камнями — потому что не с чем было бы сравнить и реакция «не верю» вполне обьяснима.
(конец цитаты)

уже сейчас есть нейросетки которые можно развернуть на обычном ПК.
ессно, они слабее клаудных.
но как в смартфонах уже не один год специализированные блоки SoC позволяют выполнять вычисления нейросеток — то с чего бы «этого не может быть, потому что этого не может быть никогда»?

интеллект в нем от этого не зародится

поделитесь теорией о необходимых условиях зарождения интеллекта?
а попутно определением самого термина?
а то обычно дают определение которое сводится к «интеллект — это то что находится внутри черепа хомо сапиенса», с замечательным выводом — ну а перенести внутренность черепа в компьютер не получится, потому что внутри компьютера — микросхемы из «песка», мозг просто высохнет, вот!

извините за «соломенное чучело», просто антропоморфизация интеллекта — это уныло.

диплернинг

постоянно оптимизируется.
где-то пробегало, что Гугл добились возможностей чатгпт на 30 миллиардах параметров, вместо 175, за счет изменений в обучении. Привирают конечно, но с чего вы взяли что нынешние методы диплернинга финальны?

это вообще забавно — всюду пишут что такого экспоненциального роста во многих изменениях, какой начался после «старта НТР», человечество не знало ранее, но находятся люди которые уверенно утверждают о финализации какого-то процесса, «конце истории»

еще цитатка от того же автора (Anton Antich)
это никакой конечно не AI — это «всего лишь» значительная составная часть Intelligence — возможность в каком-то смысле «понимать» (в том в котором мы обсуждали в части 3 — векторы представлений итп) natural language.
Так вот, сейчас и куча стартапов, и хорошо финансированных «старых» команд, типа того же LeCun в Мете, работают как раз не столько над развитием языковых моделей, сколько над построением полноценных Intelligent Agents. Что будет входить в такие агенты?
— GPT или другая языковая модель, позволяющая «понимать» NLP
— возможность взаимодействовать с внешним миром сначала через запуск разных существующих приложений (OpenAI Plugins тоже шаг в этом направлении), а потом и robotically. Уже сегодня GPT прекрасно из неструктурированного текста делает структурный — а больше для запуска внешних команд ничего особо не надо, все реализуется сегодняшним программированием
— ключевой момент — целеполагание с самообучением. И опять здесь нет совершенно никакой rocket science, Reinforcement Learning, которая позволила машинам обыграть людей в Го и Шахматы, прекрасно справляется с максимизацией целевой функции в непонятных окружениях. Создавать агентов разной сложности, максимизирующих вектор целей — опять же, можно уже на сегодняшнем уровне технологий.

поделитесь теорией о необходимых условиях зарождения интеллекта?
а попутно определением самого термина?

Думаю, под этим имеется в виду та мысль, что ChatGPT и иже с ним — это, скорее, «эрудит», научившийся понимать вопросы на естественном языке и более-менее связно на них отвечать.

Ключевое слово здесь — «эрудит», т.е. эта штука очень эффективна в извлечении знаний из уже имеющихся в его базе и генерировании типовых (!) решений на основе этих знаний.

«Придумать» же что-то радикально новое, требующее применения той же ТРИЗ — ИМХО никакому ChatGPT пока не под силу.

Ключевое слово здесь — «эрудит», т.е. эта штука очень эффективна в извлечении знаний из уже имеющихся в его базе и генерировании типовых (!) решений на основе этих знаний.

Що мабуть покриває 90% існуючих працівників :)

Он не рулит, а скорее стохастический попугай. Что и позволяет ему генерировать новое. Причём в таких количествах что его называют бредогенератором.

А чем радикально новое, от нового отличается — да вопрос интересный.

Применение же ТРИЗ — это как раз костыли для слабого человеческого интеллекта, для преодоления его, ЧИ, ограниченности, косности, зашоренности :)
ИИ такое применять и правда ни к чему.

как написал один:
...смотрят на доступный *им* *сегодня* уровень технологий и из него пытаются делать выводы, тогда как в таких разговорах всегда необходимо экстраполировать. Сейчас всем вдруг стала видна GPT (хотя как я не раз писал мы, как и все «в теме» с ней работали уже 2 года плюс минус) — и вы делаете выводы на основе вашего опыта с GPT. Если бы я два года назад писал о том, на что она способна сегодня, меня точно также закидали бы камнями — потому что не с чем было бы сравнить и реакция «не верю» вполне обьяснима.
(конец цитаты)

уже сейчас есть нейросетки которые можно развернуть на обычном ПК.
ессно, они слабее клаудных.
но как в смартфонах уже не один год специализированные блоки SoC позволяют выполнять вычисления нейросеток — то с чего бы "этого не может быть, потому что этого не может быть никогда«?

если я правильно понял, то посыл в том что научатся делать более дешевое и мощное железо. научатся, только потребности еще больше возрастут, здесь всегда будет не хватать вычислительных ресурсов, пока в корне не изменится технология, а к этому предпосылок нет

поделитесь теорией о необходимых условиях зарождения интеллекта?
а попутно определением самого термина?
а то обычно дают определение которое сводится к «интеллект — это то что находится внутри черепа хомо сапиенса», с замечательным выводом — ну а перенести внутренность черепа в компьютер не получится, потому что внутри компьютера — микросхемы из «песка», мозг просто высохнет, вот!

извините за «соломенное чучело», просто антропоморфизация интеллекта — это уныло.

тут долго отвечать, лучше почитай википедию или еще что-то, про теорию разума и самосознание

постоянно оптимизируется.
где-то пробегало, что Гугл добились возможностей чатгпт на 30 миллиардах параметров, вместо 175, за счет изменений в обучении. Привирают конечно, но с чего вы взяли что нынешние методы диплернинга финальны?

при чем тут оптимизация? уверен что финальны, кроме новых применений, автоматизации и оптимизаций использования за время его существования ничего не происходило существенного. как я выше написал диплернинг не ведет к зарождению интеллекта

это никакой конечно не AI — это «всего лишь» значительная составная часть Intelligence — возможность в каком-то смысле «понимать» (в том в котором мы обсуждали в части 3 — векторы представлений итп) natural language.

именно

Так вот, сейчас и куча стартапов, и хорошо финансированных «старых» команд, типа того же LeCun в Мете, работают как раз не столько над развитием языковых моделей, сколько над построением полноценных Intelligent Agents. Что будет входить в такие агенты?
— GPT или другая языковая модель, позволяющая «понимать» NLP
— возможность взаимодействовать с внешним миром сначала через запуск разных существующих приложений (OpenAI Plugins тоже шаг в этом направлении), а потом и robotically. Уже сегодня GPT прекрасно из неструктурированного текста делает структурный — а больше для запуска внешних команд ничего особо не надо, все реализуется сегодняшним программированием
— ключевой момент — целеполагание с самообучением. И опять здесь нет совершенно никакой rocket science, Reinforcement Learning, которая позволила машинам обыграть людей в Го и Шахматы, прекрасно справляется с максимизацией целевой функции в непонятных окружениях. Создавать агентов разной сложности, максимизирующих вектор целей — опять же, можно уже на сегодняшнем уровне технологий.

это просто оптимизация процессов, просто триггером будет не только человек, но и анализ факторов, которые компьютер сможет получить, по большому счету ничего не изменится, просто есть шанс что людям, которые будут пользоваться этим всем станет немного проще жить. так же стоит не забывать что много людей даже телефоны не осилили и до сих пор пользуются кнопочными, вот и с этим будет так же

тут долго отвечать, лучше почитай википедию или еще что-то, про теорию разума и самосознание

то есть вы ответить не можете, а предлагаете обратиться к чатгпт :)
потому что он — вполне перескажет и википедию, и основные взгляды на заданный мною вопрос.

другими словами — вы на собственном примере показываете что интеллектуально уже слабее его :)

научатся, только потребности еще больше возрастут, здесь всегда будет не хватать вычислительных ресурсов,

ессно. для игр его всегда не хватает, и сейчас тоже.
так в чем же разница тогда между компьютерными играми 80ых и нынешними?

пока в корне не изменится технология, а к этому предпосылок нет

во-первых вы никак не показали — откуда взялось ваше мнение о «пока в корне не изменится». во-вторых не заметили указанных мною предпосылок.

как я выше написал диплернинг не ведет к зарождению интеллекта

вы не смогли ответить ни об интеллекте, ни об условиях его зарождения.
чатгпт вот может. даже нынешний. а вы — УЖЕ не можете :)

по большому счету ничего не изменится

ну ок. зато изменится по маленькому счету :)

то есть вы ответить не можете, а предлагаете обратиться к чатгпт :)
потому что он — вполне перескажет и википедию, и основные взгляды на заданный мною вопрос.

другими словами — вы на собственном примере показываете что интеллектуально уже слабее его :)

я могу ответить, но я настойчиво предлагаю не задавать мне вопросы, ответ на которые более нескольких предложений, мне лень писать много

ессно. для игр его всегда не хватает, и сейчас тоже.
так в чем же разница тогда между компьютерными играми 80ых и нынешними?

они стали значительно примитивнее, но при этом получили относительно красивую графику, ну и сама отрасль отсеяла жанры, которые мало кому интересны. вообще сравнение некорректное, игры делаются на максимальные текущие возможности, где всего точно хватает и за ресурсы платить не надо, а для текущей версии гпт ресурсы клауда являются очень большой статьей расхода. и проблема не в том что ресурсов мало, а в том что это дорого и платить надо не пользователям

во-первых вы никак не показали — откуда взялось ваше мнение о «пока в корне не изменится». во-вторых не заметили указанных мною предпосылок.

1 книги и образование. 2 много текста, неструктурированного, а сумбурно написанного, вот и не заметил

вы не смогли ответить ни об интеллекте, ни об условиях его зарождения.
чатгпт вот может. даже нынешний. а вы — УЖЕ не можете :)

знаешь разницу между возможностью и действием?

ну ок. зато изменится по маленькому счету :)

ага, хорошая игра слом, но смысл того что я писал от этого не меняется

я могу ответить,

могли бы — ответили б. пара предложений для форумного формата — вполне ок.

ага, хорошая игра слом, но смысл того что я писал от этого не меняется

поэтому и заинтересовало — чел сам то понимает что выдает голословные, а местами нелепые фразы, но с какой-то уверенностью Пророка.

нет, не понимает.
например и википедию то не читал, потому что сгенерил какую-то хню о «теории разума и самосознание». а того не знает что такой теории нет. есть внутридисциплинарные определения, которые невозможно объеденить в общее понятие. ну и некоторые соглашения для бытового взаимопонимания.

1 книги и образование

то и прикольно, что скептики обычно демонстрируют крайнюю необразованность, прячущуюся за неким догматизмом, а то и неспособность мыслить о том, что выходит за рамки их профессии :)

а люди с такими характеристиками — первые кандидаты на замену ИИ. потому что люди-автоматы — не имеют преимуществ перед компьютерами-автоматами.

ага, хорошая игра слом, но смысл того что я писал от этого не меняется

вобще-то я «пошутил» что там можно ставить любое прилагательное, потому что никакой силы аргумента выражение «по зеленому счету» не имеет. это просто оборот человеческой речи, для выражения своего субъективного отношения к чему-то такой же оборот как «фу, *ля».

Якщо проєкт під NDA, то думаю наврядчи chatgpt тут в допомогу буде. Італія вже його взагалі заборонила. Хайп трохи пройде, пилюка осяде, і там вже буде видно, що з цим робити. На маска фапали майже всі, ще пару років тому ;-)

На основі гпт можна зробити заточені під окремі мови програмування моделі, які замінять кодерів, як мови програмування високого рівня колись замінили техників, які переводили програми у машині коди й вибивали на перфокартах (якщо ви в курсі що це взагалі).

Це вже і так зроблено генераціями дто, контролерів і т.д. на основі схем, ну буде на основі gpt, одна фігня. Я сьогодні заради експерименту спробував генерувати контролери, дто для спрінга за допомогою gpt, ну таке, поки що. Про бізнес логіку взагалі мовчу, і це ще потім людина має інша зрозуміти.. Індуський код воно може й нафігачить або згенерує тестові данні, це так. Тобто в допомогу девелоперу досить валідна річ, а от замінити повністю, ну дуже сумніваюсь.
І доречі техніки були аналогом компілятора зараз, а не мови програмування

Все вірно — це допоміжна тулза, яка зробить роботу саме розробників ще більш складною та високорівневою. Писати КРУДи стане вже не актуально, а багато хто тут саме за це і тримається

Так на ентерпрайзі якраз і не пишуть круди, там можна місяць баг шукати.

Якщо проєкт під NDA, то думаю наврядчи chatgpt тут
в допомогу буде

Это вопрос открытый.
Есть архитектурные решения, которые позволят кодовую базу хранить локально отправляя в openai только частичные и/или агрегировпнные данные. Пока не понятно куда качнется

Пользователь платит конечно не за код, но кому? Правильно — владельцу бизнеса. А разработчику как раз за код платят. Соответственно, знания проблем пользователя кодеру как раз мешают сосредоточиться на написании кода, тем кто понял проблемы бизнеса нужно и идти в бизнес

І це правда. Проджект овнер, замовник та архітект повинні зійтися яка якість продукту їм потрібна і десь на цьому рівні з замовником вирішити чи швидкість виходу на ринку надважлива чи можливість швидко адаптувати продукт, масштабувати і підтримувати наприклад.

Ти правий, але подібне зашорене розділення тільки заважає видати нормальне рішення. Дефективний майндсет так би мовити. Ось мені девелопер написав код, формально таску закрив, але написав неюзабельне 💩, бо не поцікавився до кінця як і ким це буде використовуватись. А ось інший розробник, який поцікавився, розписав ще кілька додаткових аспектів які варто реалізувати, знову ж таки написав код, але вже такий 🏅, який було і значно легше валідувати і користуватись. І там і там я плачу за код, але з другим розробником ми зробимо значно більше (і заробимо більше) ніж з першим.

Про DDD взагалі хтось чув і про те як важливо правильно сконструювати агрегати? А про CQRS і про те що read модель ніяк не схожа на persistence модель? Це з орієнтованістю на бізнес нічого спільного немає?

Дуже складні концепції для рядового кодера.

Стратегические партерны DDD, это про бизнес. Тактические это про код.
Стратегические > тактических.

з мого досвіду бачу, що підхід, який описаний у статті, підходить для стартапів. Там дійсно потрібно швидко писати і майже завжди не важливо яка якість коду. Головне — якнайшвидше випустити продукт на ринок. Якщо це не стартап, а вже компанія, яка міцно стоїть на ногах, і збирається випустити мобільний додаток (наприклад), то краще випустити на місяць або два пізніше, але код повинен бути таким, який можна буде довго супроводжувати.

Головне — якнайшвидше випустити продукт на ринок.

А то что? В соседнем гаражике сделают быстрее на 2 дня и заполонят рынок? лол

А то бюджет закінчиться, а прибутку так і не буде. От тоді і буде лол...

Довго супроводжувати можна лише той продукт, яким будуть користуватися споживачі. Якщо ви випустите на ринок шмат лайна, то абсолютно не важливо, це буде якісний шмат, чи не дуже.

Оце вже і буде перехід від стартапу до справжнього продукту

Я правильно зрозумів, що справжній продукт — це шмат лайна? :D

погана якість коду зовсім не означає лайно для юзера. Там навіть багів може бути мінімум і все гарно працювати. Але проблеми почнуться потім, коли потрібно буде в коді щось змінити, додати, переписати. І це буде займати не n часу, як очікується, а n*5 чи n*10, бо зміни робити неможливо в тому коді.

Але проблеми почнуться потім, коли потрібно буде в коді щось змінити, додати, переписати.

А может и не начнутся, если приложение «сезонно-ситуативное».

Чомусь мої споживачі не хочуть лайна, а хочуть цукерочку...

Вони хочуть вирішувати власні проблеми, а буде це цукерочка чи маршмелоу, нікого не хвилює особливо

Лайно, яке падає з неба, і є проблемою, яку ми вирішуємо.

Десь до початку цього року також вважав, що код має відповідати усім тим SOLID принципам навіть для ML проектів. Але наш новий директор департаменту представив до нашої уваги свій код проекту: 1 файл з 47000 строчок коду і він каже, що то майбутнє компанії і менеджмент з ним згоден. Він доречі спочатку не планував рефакторити взагалі, так і робив коміти у файлі з 47000 строчками коду.

Ну никакого противоречия. Солид несет намного больше вреда чем пользы. А 47К линий просто разбить на файлы с классами, для удобства навигации. Класс это не что иное как объединение процедур ассоциированных либо с экземпляром либо с именем класса, а не булшит про ооп.

Та ні там один й той же клас повторюється по 4рази тільки один вхідний параметр різний. Той код можливо розбити на багато ІТ-мемів. Я сам не повірив спочатку, думав може то новорічний розіграш.

наш новий директор департаменту представив до нашої уваги свій код проекту

Не хвилюйся, карма його наздожене.

Карма догонит как раз их, когда будут выволочки в стиле «там же только мелочь поправить, почему вы так долго возитесь?!111!?»

Видел я такое говно в стиле «я написал это за три дня, тебе только надо чуть чуть поправить пару мелочей (ну там память течет, сокеты не закрываются, при особом везении можно дедлок по тредами словить, про потербю данных вообще молчу)». В итоге выяснилось что этот кусок го^W простите, кода проще и дешевле с 0 переписать, чем править.

Баланс між часом на вирішення проблеми бізнесу і якістю написаного кода.
Бо якщо заморочитись тільки на першому то потім при зміні роботи буде тяжкувато найти нову.

ІМХО, РО знайшов собі дева-помічника а дев думає що так і має бути.

Це все компетенція продукт овнера (чи продукт відділу якщо проект великий). Це їхня компетенція. Інженери від цього відділяються на найвищому рівні, бо СТО не займається

LTV, CPI, CAC, MRR, ARR, ARPPU, ROI, ROMI.

Для цього є CPO.

Завдання CPO (і людей під ним) сказати що, завдання CTO (і інженерів під ним) сказати як.

Купа таких статей, а потім ідеш на співбесіду в Гугл і там питають літкод і дизайн.
Бізнес орієнтовними є ті розробники які знають за що платять кращі гроші на ринку, а то що ви описуєте тут це хороша робота менеджменту по організації комунікації в команді і вміння ставити зрозумілі цілі

а потім ідеш на співбесіду в Гугл

Не ходите в гугл на собеседования. Или не читайте такие статьи
Ну или если вы читаете такие статьи, опираетесь на них и ходите в гугл — то не возмущайтесь

А чому? Бо це про рівень інженера, а не вимог до конкретного MMP/MVP.

Взагалі зазначені вище речі мають зміст, коли в розробника є можливість і потреба впливати на продукт і немає людей, хто займається метриками, аналітикою, доцільністю і змістом тих чи інших А/Б тестів тощо.
Частіше за все це там, де в людини достатньо свободи і немає інших людей зі схожими амбіціями, яким тісно разом і ладні вгризтися один в одного.
Частіше це — на власному пет-проекті, де або сам, або із добре зіграною командою.
В наймі — скоріше спроба навісити на людину зайву відповідальність, економлячи на людях.

На типових позиціях, куди в нас відкриваються вакансії, це зазвичай, дуже мимо.

І всі ці тренінги і розмови про орієнтованість на бізнес — аби поговорити, чи на рев‘ю причепитись до людини.

Это все прокатывает только на проектах с фриланс-бирж до 1000 долларов.

У всьому потрібно дотримуватися балансу.
Наприклад, можна написати дуже гарний код, який потім буде складно зрозумілим для доопрацювання іншими розробниками.
Саме тому, з погляду бізнесу так званий «гарний код» — це такий код, який можна легко масштабувати, підключивши ще розробників.
Якщо ваш код можуть розуміти джуни і робити нові фічі без багів — ваш код чудовий
Якщо код можуть розуміти тільки міддл і вище — у вас просто гарний код
Але якщо код можуть розуміти тільки синьйори, то у вас... звичайний код

Це одна з тих речей, яких ми навчаємо у наших інтернатурах

На жаль, більшість розробників не вміють адвокатувати свої рішення для бізнесу через проблеми у діловій англійській.

Але якщо код можуть розуміти тільки синьйори, то у вас... звичайний код

а якщо тільки прінципал-архітекти, то взагалі з речима на вихід ...

більшість розробників не вміють адвокатувати свої рішення для бізнесу через проблеми у діловій англійській

такий крінж ще придумати треба :D

Якщо ваш код можуть розуміти джуни і робити нові фічі без багів — ваш код чудовий
Якщо код можуть розуміти тільки міддл і вище — у вас просто гарний код

А вы точно имеете представления что такое код и как его понимать?

З точки зору бізнесу — ідеальний код, який вимагає мінімум підтримки та дає максимум цінностей.
З погляду розробника — ідеальний код, який зрозумілий і не вимагає глибинного вивчення для додавання нових фіч
Тут цінності схожі — чим менше часу буде витрачено на вивчення, тим цінніший код, тому що з ним можна почати працювати

Проблема виникає тоді, коли код написаний одним із учасників так, що він складний для решти команди. Це не означає, що там погані патерни (хоча теж впливає), а просто 80% йде на розуміння, 20% на написання.

Якщо у вас є своє бачення — дайте знати.

Скільки Вам часу потрібно на вивчення, ну наприклад, перетворення Фур’є?

А яку цінність для бізнесу (замовника) дасть це перетворення?

Мне сложно представить такой код, который бы понимали только девелоперы с тайтлом >= мидл, а все остальные трейнии, джуны, асошиейты смотрели бы на него и видели белый шум так как для них это знание недоступно. Просто у вас совсем дилетанское представление о коде и его понимании

Я тебе могу привести очень простой, хоть и несколько экзотический пример — код написан в функциональном стиле (пусть и на знакомом джуну языке программирования).

Причём, по-настоящему в функциональном стиле — с иммутабельностью, монадами и т.п.

Конечно, это будет не «белый шум». Но, время, через которое среднестатистический джун сможет начать продуктивно работать с таким кодом — будет сильно выше, чем если код написан в привычном ему императивном стиле.

Ну так если мидл не имеет опыта с монадами/карированием/любойДругойФичей — для него это точно так же потребует некоторое время на изучение — те. это зависти от конкретного опыта конкретного девелопера, а ситуация, что описывает Зинаида — это где мидл и выше понимает код и девелопит без багов, а джуны смотрят в книгу и видят фигу

У Зинаиды слегка утрировано описан пример, но я и такое видел в своей практике.

Когда-то давным-давно на одном проекте у нас использовалась куча вариантов гридов для показа списка товаров в категории. Я, будучи ещё зелёным senior’ом, радостно навернул для этого дела целую иерархию классов с наследованием, template methods и прочей ООП радостью. При этом, большая часть команды только недавно переползла на ASP .NET, где был VB .NET с честным ООП. А, до этого они педалили старую версию того же проекта на VBScript, где весь код испокон веков писался чуть ли не в процедурном стиле.

И вот переход на ООПшный движок на практике для этих ребят оказался болью и адом, и продуктивность реально просела по сравнению с тем, как если бы они писали как привыкли, только на чуть другом языке.

Саме тому, з погляду бізнесу так званий «гарний код» — це такий код, який можна легко масштабувати, підключивши ще розробників

Масштабування тільки одна з характеристик, якщо би ви розуміли як збираються, документуються та опрацьовуються лист потреб від клієнта то ви би розуміли що всі потреби продукт часто не може задовільнити, наприклад потреба від клієнта може бути такою: швидко за декілька тижнів, дешево за х доларів, якісно щоб багів не було, щоб підтримувало мільйони клієнтів і швидко працювало. Задача бізнес лідерів донести до клієнта що треба якісь потреби пріорітезувати і може бути що масштабування коду як раз не в приорітеті, а якщо воно в приорітеті ви повинні розуміти що це збільшує сроки проекту. Нормальні клієнти це розуміють. «Зрозуміло джуну» це взагалі не опис, це суб’єктивно і залежить від джуна. Правильніше: легко найняти і навчити людину зрозуміти продукт і процеси. Код тільки частина. До речи якщо є потреба в масштабуванні продукти на мільйони користувачів як ви задовільнити потребу щоб джуну було зрозуміло код? Деякі паттерни які використовуються на великих дістріб’ютивних системах джуни ніколи в житті не бачили бо вони ніколи не зтикалися з ситуаціями які вони вирішують.

Чи потрібна інженеру бізнесорієнтованість? Скоріше ні. Щоб знати що хоче бізнес, в це треба інвестувати час, як свій, так і стейкхолдерів, і для цього є спеціяльні юніти, які цим займаються фуллтайм. От що дійсно треба, так це думати про юзера. Це потрібно завжди і кожному. Юзер може бути різним. Це може бути людина, яка тицятиме апку в телефоні, і бажано щоб та апка не лагала. Це може бути саппорт, який полізе в адмінку щось правити, і бажано щоб він не поклав базу через непровалідовані дані. Це може бути фронтендер, який працюватиме з твоїм ендпонтом, і бажано уточнити, чи вирішує всі його задачі цей ендпойнт до того, як починати його імплементацію. Або навіть можеш бути ти сам, коли ти будеш пізніше покривати цей модуль тестами, і виявиться що прийдеться мокати пів модуля, бо при проектуванні було ліньки лишніх інтерфейсів нарізати та DI організувати. Просто подумати «хто і як це буде використовувати», перед тим як починати робити, допоможуть в першу чергу вам потім то все перероблювати меньше. А вчасно задані запитання, навіть якщо вони вам здаються банальними, можуть економити спрінти цілим командам.

Чи потрібна інженеру бізнесорієнтованість? Скоріше ні. Щоб знати що хоче бізнес, в це треба інвестувати час, як свій, так і стейкхолдерів, і для цього є спеціяльні юніти, які цим займаються фуллтайм

Так і є.
Про бізнесорієнтованість — це спосіб придовбатися до розробника і трахати його мозок, що він начебто недостатньо орієнтований на бізнес і під це можна підвести що завгодно, чітких критеріїв немає, для менеджера — ідеальні умови для словоблуддя і непідвищення.

Маячня якась. Проект для кого розробляеться? Якщо не розумiти що потрiбно бiзнесу — то це рiвень принеси — подай

Якщо не розумiти що потрiбно бiзнесу — то це рiвень принеси — подай

Що ж поробиш, що в нас майже всі вакансії, де саме принеси-подай і потрібно.
А ще проводити час на безглуздих мітингах.
Буває й так, що до потреб юзерів далеко — люди свої потреби забезпечити не здатні, щоб хоча б з гілками вірно працювати.

Навісити більше обов’язків скоріше за ті ж гроші.
Ці обов’язки навряд чи будуть збігатись із шляхом на карті особистого розвитку, яку спеціаліст самостійно створив.

Бізнес оріентованість зовсім не означає поганий код. По суті, якщо ти досвічений дев, то твоя якісна робота не сильно буде довшою, а то й коротшою, тому що за рахунок використання практик ти в тому числі економиш свій час, робиш менше багів та інше.

Ви мені гроші, а я вам код. Це вся бізнес орієнтованість яка потрібна розробнику.

Так ще потрібно розуміти як працює бізнес і продукт. Але для цього зазвичай достатньо здорового глузду та елементарної комунікації. Є спеціально обучені люди які вирішують які фічі потрібні, а які ні. І мені по барабану як вони там це навирішували. Це їх робота. Я не буду їх перевіряти, чи робити їх роботу. В мене свого гемору хватає. Задача разробника оцінити та зробити фічу. І бажано зробити фічу «красивим» кодом. Тех долг це твій великий гемор в майбутньому і тобі його розгрібати.

Бізнес орієнтованість така ж лапша на вуха як і копроративні цінності...

Ще пару місяців тому я був би згідний з заголовком.
Але потрапив на стартап писаний індусами, де в коді порушили абсолютно всі принципи KISS / DRY / SOLID.
Все б нічо, але фікс бага GTM івента родив ще 3 баги, бо один нещасний компонент з кнопкою оформлення замовлення — це три файли на три тищі строк сумарно, напхані дублікат спагетті кодом (де один тільки лоадер-кавер смикається разів двадцать, а не два).
Тут уже вирішуйте самі за що той бізнес платить, але виходу тепер швидкого нема.

Так само і я потрапляв на подобні моменти. І, само собою, я їх вирішував, як і в кейсі, описаному в статті, коли я переписав продукт після аутстафа.
Але в певний момент переписування, ігри з архітектурою та з методологіями починають для бізнесу переходити за черту diminishing returns, коли витрачений час не можна нічим позитивним заміряти як в метриках, так і прибутках.
Тому я і закликаю в статті балансувати 🙏

В моєму кейсі переписуванням фронта зайнятись неможливо, тому що треба переписати бекенд ендпоінти і «добра» на це немає. Плюс немає тестування в жодному нормальному вигляді, тобто будь-який рефакторинг це великий ризик все зламати (а спагетті-код ламається моментально).

починають для бізнесу переходити за черту diminishing returns

Залишається тільки почекати, коли цей самий бізнес почне думати про щось крім convertion rate та page speed rank. Бо зараз вони готові деплоїти на продакшн, тестити на ньому, а якщо не так — відкатимо.

тобто будь-який рефакторинг це великий ризик все зламати (а спагетті-код ламається моментально).

рефарторинг никогда не может ничего сломать, а то что ты описываешь — это не рефакторинг, а переписывание с ошибками

Хорошая теория, жаль что не работает.

В практике в последнем случае был баг с показыванием лоадинг оверлея в процессе отправки запроса. Логично что он должен показывается перед запросом и исчезать после его выполнения, т.е. дернуть 2 раза.
Согласно кода, в двух похожих файлах (один для гостей, один для залогиненых) этот диспатч дергают 45 раз.

А теперь расскажи каким волшебным образом это все порефакторить чтобы это не было «переписыванием с ошибками», в условиях отсутствия юнит-тестов, е2е тестов, любого AQA и единственного мануал QA, которая тестит по праздникам и не всегда на стейджинге.

Согласно кода, в двух похожих файлах (один для гостей, один для залогиненых) этот диспатч дергают 45 раз.

А теперь расскажи каким волшебным образом это все порефакторить

никак, это помойный код, который даже если потенциально и может быть отрефакторен, то в этом нет никакого смысла. есть большая разница между рефакторингом и переписываением. и в этой ситуации подходит только переписывание, а стоит его делать или нет это уже другой вопрос

Ми в свій час збільшили швидкість розробки *середньої бізнес-фічі* з місяця до трох днів, написавши фреймворк, який напевне зовсім незрозумілий середньому індусу. Бо в своїй зрозумілій копіпасті вони на той час заплуталися остаточно.

А про кацапів і ендпоїнти в мене інша історія, хоча клієнт той самий...

Розробники пишуть код і він повинен бути простий та легко підтримуваний, що скорочує затрати на його підтримку та розширення, а до чого тут вирішення проблем юзера — не зрозуміло

Ну в мобільщиків майже немає ентерпрайзу, нажаль.

Поки що немає ентерпрайзу :)

На минулій роботі писав мобільний клієнт для облікової системи. Це мабуть не вважається ентерпрайзом, але там було стільки функціоналу, що зробити цей додаток простим на вигляд було дуже «цікавим та складним» (як пишуть у резюме) завданням. І проблема була в тому, що деякі користувачі хотіли мати в мобільному додатку повний функціонал, як і в десктопному. А інші вважали, що мобільний додаток має бути спрощеною версією десктопного.
На деякому етапі було вирішено зробити налаштування у додатку, яке в вмикало спрощений режим. Але це лише ускладнило розробку, тому я відмовився від такого «покращення».
Окрім того, найбільший клієнт компанії постійно вигадував щось нове (і часто непотрібне), що завжди доводилось відсіювати непотріб від реальних потреб.
В результаті щось таки вдалось зробити, але я так і не закінчив додаток, як запланував, бо пішов з компанії з фінансових причин (бо усі завжди хотять космічний апарат за ціною велосипеда).

Стаття написана на прямому протиріччі.
В заголовку «не платять за красивий код», а в статті постійне згадування що свій код переписує та рефакторить щотижня. То нашо ти його переписуєш якщо за це не платять ?

Це ж розробка на мобіли, там мабуть час життя проектів вимірюється місяцями та тижнями. Автор не в курсі великих проектів, які живуть десятиліттями, повинні підтримуватися різними поколіннями розробників і від яких без перебільшення залежать економіки країн.

Так він навіть про простий проект каже що настільки нагівнокодив що його щотижня переписує. Не можу зрозуміти — навіщо

Прочитавши статтю складається враження, що якісний код — це така примха розробників і бізнес від цьєї якості не отримую користі. Так от — ні, якісний код окупається у середньостроковій та довгостроковій перспективі. Тому це вибір бізнесу — писати щось «на колінці» зараз і потім перепусувати чи робити одразу нормально (дбаючи про майбутнє проекту).

Я думаю, що тут немає такої одиниці вимірювання як поганий код/якісний код. Будь який код — це якісний код, якщо він працює і виконує усі поточні/майбутні потреби бізнесу

Code Style ? Якщо шматок коду з десятками костилів працює — це не значить що він працює якісно.

Звісно градація поганий/якісний код існує, і те що код працює — це тільки «нульова вимога» для того щоб код взагалі існував. Поганий код від якісного відрізняється трудоємкістю підтримки, імовірністю скритих потенційних багів, трудоємкістю розширення. І звісно чим складніше розроблена система, тим важливіша якість коду. Це все базові штуки, які кожен програміст відчуває на собі — дивно що ви з цим не стикалися будучі Android Developer.

Будь який код — це якісний код, якщо він працює і виконує усі поточні/майбутні потреби бізнесу

Що ж, для проектів-одноденок це справедливо. І тільки для них.

Oh my sweet summer child.

усі поточні/майбутні потреби бізнесу

Як можливо виконувати «майбутні» потреби бізнесу, якщо вони ще не існують?))

Будь який код — це якісний код,

Ні. Є багато помилок, яких доволі легко уникнути, але які потім стріляють в ногу, що пипець. Можна розглянути приклад з SRP — при написанні з нуля його доволі легко притримуватися. Але якщо цього не робити, вартість підтримки коду зростає у рази.

Тут проблема саме в «майбутні потреби бізнесу», які невідомі в повному обсязі на момент написання коду. Тому використовуються різноманітні архітектурні підходи щоб код було легше підтримувати\змінювати в майбутньому. Ми з колегами зараз дійшли висновку, що «якісний ход» це саме про когнітивне навантаження на програміста. Чим легше такий код підтримувати тим якісніший код. І це як раз про «майбутні потреби бізнесу», бо в майбутньому бізнесу з таким кодом не доведеться витрачати купу часу саме високооплачуваних спеціалістів для підтримки такого коду.

Чим легше такий код підтримувати тим якісніший код.

Вітаю в клюбі!
Наступна фаза — замінити слово «легше» на «дешевше» ;)

есть такая вещь — TTM (Time To Market)
если у горящих голов появляется идея, а чтобы проверить ее — нужно «пол года разработки», с красивой структурой продуманной, кучей тестов, оптимизацией на всем и «а подождите нам надо очередной рефакторинг после бреиншторма» — то никакого бизнеса тут не получится
бизнесу нужна реализация, БЫСТРАЯ, а не красота кода

Є така річ, як MVP. При її розробці й правда важлива швидкість і всі плюють на стиль, архитектуру, документацію, тощо. Але вже при випуску першого продакшен релізу не думати про якість кодової бази і документованості коду — це писець будь-якому проекту на >10k строк. Не зараз, так через рік. Не через рік, так коли звільниться остання людина, яка знає проект з початку.

Є така річ, як MVP. При її розробці й правда важлива швидкість і всі плюють на стиль, архитектуру, документацію, тощо.

Це в ідеальному світі.

А насправді навіть коли робиш MVP завжди повилазять адепти клін коду і оцього всього і починають блокувати роботу бо «улучшайзінг» — бо «ну потім буде важко переробити». Але навіть після MVP ні одна зараза не запарюється писати документацію.

А насправді навіть коли робиш MVP завжди повилазять адепти клін коду і оцього всього і починають блокувати роботу бо «улучшайзінг» — бо «ну потім буде важко переробити».

все так. бо MVP повинно йти в смітник. Але зазвичай воно стає отою архитектурою, яку за одним з тлумаченнням від Фаулера — найважче змінювати.

Але навіть після MVP ні одна зараза не запарюється писати документацію.

Але у кожної зарази другим питанням буде гнівне — а де ваша.наша документація???

ну а першим звісно — йоб, що це архитектура??? хто той/ті йо архитектори??? (див вище про MVP)

«ну потім буде важко переробити»

Тому що саме так, нажаль, і буде. Бо умова

MVP повинно йти в смітник

у реальному житті не виконується майже ніколи.

у реальному житті не виконується майже ніколи.

Это значит что при запуске не было грамотного человека и потом его не наняли, когда появились деньги.
MVP пойдёт в мусорник, но так что бизнес и не заметит, шаг за шагом, модуль за модулем.

MVP пойдёт в мусорник, но так что бизнес и не заметит

«Ха-ха три раза» ©

Нет, так, как вы описываете — тоже может быть. Но, это только в том случае, если заказчик не контролирует плотно, на что потрачен каждый час разработки. Тогда — да, можно аккуратно «прятать шляпу» и постепенно рефакторить.

А если на проекте после первого MVP релиза продолжается гонка вооружений фич в условиях ограниченного бюджета (что очень типично для стартапов, которые пока ещё не получили жирные инвестиции) — ну-ну, очень хочу посмотреть на реалистичность такого подхода

Нет, так, как вы описываете — тоже может быть. Но, это только в том случае, если заказчик не контролирует плотно, на что потрачен каждый час разработки. Тогда — да, можно аккуратно «прятать шляпу» и постепенно
рефакторить.

Не заметит в плане не прятать от бизнеса, а не останавливая производство фич % от спринта тратить на рефакторинг. В продукте это обычная практика.
А на аутсорсе, какая вообще разница? Сделал и забыл.

% от спринта тратить на рефакторинг. В продукте это обычная практика.

В том-то и дело, что далеко не всегда обычная практика. Некоторым заказчикам только заикнись про рефакторинг — сам будешь не рад. «Что?! Мы будем тратить время вместо новых фич на переделки? А вы сразу нормально не могли сделать? Да и вообще, какая разница — работает, значит нечего на это больше тратить время»

И аутсорс / не аутсорс тут, по сути, роли не играет. Если заказчик контролирует происходящее на уровне отдельных тасок (а в стартапах такое более чем вероятно) — тут уже неважно, напрямую ты на него работаешь, или через «прослойку».

Если же «забыл» — это, в смысле, сдал проект и пошёл делать новый, то, вообще-то, галерам выгодно потом затягивать проекты и на поддержку (и угадай, кто будет поддерживать наговнокоденное?) :)

Ніколи нема часу на переписування. Після MVP йде PoC, а потім замовлення і продакшин. Якщо спочатку нормально не писати, будуть проблеми.

Це сумно, що серед
1. Швидко
2. Дешево
3. Якісно
Замовники часто обирать 1 чи 2
Мабуть ще і тому, що 1 і 2 має одиниці виміру. Години та долари. А якість вимірюється лише тим, скільки проблем у замовника буде в майбутньому. І оцінити це можна буде тільки в майбутньому

У своїй статті я хотів донести важливість балансу у прийнятті рішень, коли варто враховувати запит і підлаштовуватися під потреби бізнесу

Коли проект замовника полягає в створенні чергового, нікому не потрібного інтернет магазину, який потім доведеться просувати за допомогою агресивного маркетингу та надокучливої реклами, то такий бізнес орієнтований підхід виправдовує себе на 100%
Цікаво як створюють справді корисні та революційні речі, як то ChatGPT або Falcon Heavy? Я нажаль ніколи над таким не працював, тому справді не знаю. Просто хочеться вірити, що там люди служать технічному прогресу та мистецтву програмування. А не збільшенню чийогось revenue

Просто хочеться вірити, що там люди служать технічному прогресу та мистецтву програмування. А не збільшенню чийогось revenue

i0.wp.com/...​s/2012/10/981-300×259.jpg прости что разрушаю твою веру :)

Открой код хромиума и посмотри. Так делаются топовые продукты мирового уровня.

а какая разница, делай быстро и не качествено, а потом допродашь дебаг и переписывание на качество, одни плюсы вижу

так это надо проговаривать с «бизнесом». иначе они могут засудить тебя за некачественный продукт, который не «взлетел».

можно сразу предложить, дешего с багами или дорого и под ключ и проблем не будет

или дорого и под ключ и проблем не будет

Ах-ха-ха! Проблеми і помилки будуть завжди. От тільки в першому випадку бізнес до цього був готовий, а в другому — ні.

под ключ

в айти можно только визитку на вордпрессе поднять. остальное непредсказуемо все.

все что не продумал заказчик в тз для под ключ, будет дорабатываться отдельно за отдельные денежки, все изящно вообще

все что не продумал заказчик в тз для под ключ

З таким підходом це буде ваш перший і останній замовник.

кто мешает добавить по согласованию все недостаточное за дополнительную плату?

Update:
Статтю я написав ще до вибуху ChatGPT та моїм знайомством з ним.
З огляду на те, наскільки точно моделі GPT пояснюють код та доповнюють його, питання бізнес-орієнтованості розробників стає ще більш важливим.

Той boliporate підхід в розробці, до якого багато хто з нас звик (я і досі переписую свій код раз на кілька тижнів 🙈) і на який іноді витрачається більшість часу при написанні коду та виконанні завдань, не відповідає потребам бізнесів після випуску GPT. Загальна продуктивність у світі різко зростає, і відповідно збільшуються вимоги до прискорення розробки.

Процес розробки та підходи до нього змінювалися майже щокількамісяць, але тепер це відбувається щотижня.

Дуже раджу послухати цю частину інтерв’ю Фрідмана з CEO OpenAI про те, як GPT вплинув і продовжує впливати на розробку:
youtu.be/L_Guz73e6fw?t=1768

Також, якщо ви хочете дізнатися про бізнеси та продукти трішки більше, рекомендую відвідати мій канал, де я викладаю короткі резюме з прочитаних мною книг: t.me/StoriesForNerds 🙌

Дякую

«Загальна продуктивність у світі різко зростає»
геометрично или как? какие то все наивные сейчас, и это очень похоже на стахановские темпы при коммунизме. а люди это что то типа андроидов с набором разных ИИ.
чем дальше в лес, тем грустнее.
даешь 1 миллион строк кода в день!

Не застав

стахановские темпы при коммунизме

але якщо вас непокоять сучасні тенденції, то варто замислитися над цим.

1 мільйон строк коду або будете писати ви, або буде писати хтось інший 😅

удачи вам в будущем писать 1 миллион строк кода
у меня нет такой цели, и единственное, почему мы работаем на «бизнес», это деньги.
есть много других вариантов зарабатывания денег без издевательств над своей жизнью.
может вы и про life/work balance не слышали? есть еще совсем интересная книга про то, как работать 4 часа в неделю и наслаждаться жизнью.
а вам удачи, покажете на гитхабе проект из 100-500 миллионов строк?

Можливо я вас не правильно зрозумів, або ви мене, але GPT як раз і допомогає вам, як розробнику за умовні

4 часа в неделю

написати більше коду, та вирішити більше задач для бізнесу, приклавши до цього меньше інтелектуальних зусиль.

Репозіторії з

100-500 миллионов строк

тепер просто питання часу

Загальна продуктивність у світі різко зростає, і відповідно збільшуються вимоги до прискорення розробки.

Яка ж нісенітниця. Ми намагалися використовувати ChatGPT на великому проекті, майже юзлес, ті шматки коду, які він видає, доводиться ретельно перевіряти і все одно занурюватися в документацію, в цілому продуктивність особливо не змінилася. Скоротився час на пошук ідей та рішень, так, які все одно з повною ретельністю доводиться перевіряти та правити.

Я думав, що може не вмію користуватися, але в середньому такі фідбеки від розробників на тому ж хакерньюс, якщо прибрати піну, то залишається гугл на максималках

Гугл на максималках теж непогана оцінка продукту, який вийшов кілька тижнів тому (GPT-4)

Зі свого досвіду можу сказати, що десь він надає неочевидні речі і скорочує час на пошук/впровадження кратно. А десь він не знає очевидних речей, але всеодно може допомогти навести на потрібний шлях для пошуку

Брати код і впроваджувати в продукті as is ще рано, але це лише поки

Зі свого досвіду можу сказати, що десь він надає неочевидні речі і скорочує час на пошук/впровадження кратно. А десь він не знає очевидних речей, але всеодно може допомогти навести на потрібний шлях для пошуку

он во всех темах разбирается на 3 из 10, там где у тебя 0 кажется что выхлоп от чата огромный, там где у тебя 4+ ты видишь что он пишет полную фигню

Брати код і впроваджувати в продукті as is ще рано, але це лише поки

подход через диплернинг не дает возможности преодолеть эту планку по качеству. можно немного подтюнить и обучить на чем-то конкретном, но все равно хорошего результата не будет, а только сократит количество попыток чтобы получить результат ближе к ожидаемому

Абсолютно згоден. Для пошуку — топ, але для кодінгу — ну хіба дуже ізольовані задачі: регулярки, утілки, сортування, тести і подібне.
Про організацію якоїсь більш складної структури або фікс багів там мова взагалі не йде. Та і навіть щось ізольоване якщо воно складніше ніж 2+2 треба годинами ітеративно дебажити що воно видає і пояснювати як саме виправити.

Загальна продуктивність у світі різко зростає

На одиницю грошей стає більше кілометрів на годину на трасах, квадратних метрів в квартирах, літрів води в крані чи кіловатт-годин у розетці? Що саме стає ефективнішим, що потребує цієї потогонки в ІТ?

Підписатись на коментарі