Highload fwdays — спікери зі Stackoverflow, Netflix, Google, AWS, Rovio | Київ, 5 жовтня
×Закрыть

Сизифо-мартышкинский труд, или технический долг убьет тебя!

Н-да... Технологии — новые. Аналогии — старые.
Есть такое понятие, как «коррупционный налог». Коррупционный налог — это часть стоимости жизни, которую мы платим за различную лабудень, типа нечестность чиновников, взятки, разбитые дороги (и как следствие разбитые машины и погибшие люди). Да! Смерть Кузьмы — это коррупционный налог в чистом виде. Возможно ваша смерть, когда-то, тоже будет его частью...
Это преамбула.

Амбула такова: технический долг убьет тебя!
Он так же велик в большинстве компаний, приложивших ручки к написанию кода, как и коррупционный налог. Только вот прямой вред от него подсчитать гораздо сложнее.
Украли цемент со стройки — рухнул дом. Погибли люди.
Написали корявый код...
Ну, да. Кое-что подсчитать все-таки можно. От вас сбежали программисты, которые наваяли всю эту кучу... чистого золота. Те, кто пришли после них упорно предлагают переписать все заново и им очень трудно возразить. Конкуренты смеются, правда сквозь слезы! У конкурентов то же самое. Клиенты уходят, потому, что внести изменения в программу стоит дороже, чем полет на Луну.

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

Проблема эта кросс платформенная и не зависит от языка программирования.

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

Главный источник технического долга и неповоротливости готовых приложений — человеческий фактор. Но есть и другие.
программа создается в конкретной рыночной ситуации: есть бюджет, есть дедлайн. Более-менее фундаментальные исследования требуют выведения какой-то части персонала из конкретных проектов и перевод их из сферы практики в теорию. А это накладно.

Так и живем...

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

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

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

LinkedIn

Лучшие комментарии пропустить

(C хабра)

Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.

Амбула — нет такого слова.

Кузьма — не нарушал бы скоростной режим, остался жив.

Работает — не трожь. Суть бизнеса заработать деньги, а не построить красивую архитектуру, и слабать шикарный код. Если он решает поставленную задачу, значит он достаточно хорош!
Конкуренты не будут сидеть ждать сложа лапки, пока конкурирующая команда, в которую инвестор вложил деньги, изъебщеряется паттернами и глубокомысленными высказываниями о Папе Джоне и пяти гиппопотамах архитектуры со смузи на кухне.
Тем более, что понятие «хорошего кода» существуют исключительно в воображении говорящего о нем, ведь своё, как известно, не пахнет.

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

Говорить, что все проекты должны иметь превосходную архитектуру и отсутствие технического долга, это как говорить, что все машины должны быть Мазератти, а квартиры — пентхаусами с видом на Днепр.
Реальность такова, что большое количество бизнес-идей просто не взлетают. И тратить на разработку сомнительной идеи большие деньги просто не рационально.
Вы видели, когда-нибудь, что происходит со взлетающим стартапом? Туда просто нанимают толпу специалистов, которые со временем переписывают весь код на более качественный. Когда же количество пользователей становиться проблемой, нанимают консультанта, который умеет Highload. Это существенно экономит деньги и позволяет держать в разработке несколько бизнес-идей с последующей концентрацией на самых перспективных.

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

P.S. Ваш код в большинстве случаев ни стоит не копейки. Вы можете написать сколько угодно копий Инстаграма, но никогда ни продадите их за миллиард.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

«технический долг» = «убогий менежмент» :)

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

Архитектура — это высокоуровневая часть проекта приложения, каркас, состоящий из деталей проекта (Buschman etal., 1996; Fowler, 2002; Bass Clements, Kazman 2003; Clementset al., 2003). Архитектуру также называют «архитектурой системы», «высокоуровневым проектом» и проектом высокого уровня«. Как правило, архитектуру описывают в единственном документе, называемом «спецификацией архитектуры» или «высокоуровневым проектом».

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

Связана. У архитектуры может быть такой же долг.

Любимый пример Страуструпа: пока класс «самолёт» — потомок класса «двигатель», не может быть самолётов с двумя двигателями.

У архитектуры долга быть не может. Архитектурный план или есть или его нет, или он правильный или нет.
А технический долг — это когда все работает как ожидается (всегда a+b=c ), но внутри могло бы выглядеть лучше, и порой даже должно выглядеть лучше если это основа для расширения будущего функционала.

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

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

но внутри могло бы выглядеть лучше

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

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

Что-то в этом есть.

Ну да, вместо того чтобы запилить фичу за 2 часа, делается 3 недели, попутно что-то ломая. В самом деле, причем здесь архитектура?

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

А що є «погана архітектура» в вашому розумінні?

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

while (haveAnyTask) {
if (задача_чуть_сложнее_чем_шлёпнуть_очередную_форму) {
— Надо бы сделать всё как нужно.
— Но мы не умеем / не успеваем / дедлайн не за горами / т.д. (нужное подчеркнуть).
— Варианты?
— Давайте наговнокодим, а потом разгребём.
} else {
— Делаем то, что умеем.
}

}

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

Вам трудно будет в это поверить, но это не является проблемой.

В такое — да. Но попробуйте меня переубедить!

любая компания согласится на любое требование, если оплата устроит

только заказчику вряд ли надо

Но попробуйте меня переубедить!
Якщо ви захочете бути переконаним...

Є такий дивний світ, називається XML. Цілий Всесвіт! Під нього написано гекатонни коду, зроблено купу СУБД, які підтримують XML, в тому числі нативно (або опосередковано). Структура даних може бути якою завгодно, мінятися як завгодно, в тому числі й в режимі «в польоті», трансформуватися в інші структури тощо. Для красивих та надзвичайно зручних запитів існує XQuery, завдяки якому можна робити дива. Старенький XSLT хоч і сиплеться пісочком, але все ще може виконувати свою роль трансформатора структур.

Архітектура, яка базується на XML, зазвичай схожа на систему керування потоками даних. В додатку із реактивним підходом та мікросервісами можна отримати надзвичайно гнучкий конструктор. Якщо додати BPM, то і взагалі забути про програмування та перейти до керування (створення бізнес-правил та сценаріїв виконання коду)

;)

слету ответить не готов. Почитаю.

Пообщайтесь с людьми, которые саппортили «архитектуру, базирующуюся на XML» :)

у меня кулаки зачесались, дядку отойдите я мальчика у№бу

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

Троллинг высшей категории. У джавистов прочитавших это — знатно разбомбит!

У ждавістів із всесвітом XML все добре, як раз. Інколи, навіть, набагато краще, ніж у всіх інших.

XML головного мозга, однозначно.

Джавистов и правда перекосит от такого восторга от xml 😁

А нічого що одна із XMLDB написана повністю на Java?

на джавi стiльки всього написано що це якийсь дитячий аргумент.
Як i незнання того що типовий джавiст мрiэ триматись вiд xml як найдалi. Але — вiн входить до обов’язкового у кривавому ентерпайзi — конфiгi, jaxb, soap, i т.д.

Але так, я не пригадую щоб зустрiчав програмiстiв з xml головного мозку. Буду знати що й така хвороба э 😁

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

вибачте, але мені не цікаве спілкування з євангелістами, «упоротыми» та інш :)

ви знайшли срібну кулю? Вітаю, це буває. з часом проходить :)

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

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

Розвиватися та вчитися ніколи не пізно.
так, так, для людини що знайшла срібну кулю всі інші — йолопи, бо не знайшли.
так, так :D

текст ваших постів з самого початку, як я його побачив, мав всі ознакі, що там далі буде, у наступних постах :)

випадково побачив

Є такий дивний світ, називається XML.
і далі — ну точно, все за сценарієм :)

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

я спілкуюсь з текстом постів.
А, чого одразу не сказали, що любите поспілкуватися самі з собою... :D
а всі ці слова звичайні для евангелістів та шахраїв з авантюристами — про свіже мислення
А як вас ще витягти зі своєї мушлі? Я ж точно знаю, що ви останні 10 років лупаєте одну й ту саму скелю в одному й тому самому місці. Одними й тими самими інструментами. Рік за роком. А поряд є цікаві світи, де всі оті ваши звички, норми, правила, паттерни виглядають безглуздими. Ні, краще лупайте скелю, чим менше в мене конкурентів, тим цінніше мої послуги. ;)

Если клиент хочет что-то существенно менять — пусть оплачивает время разработчиков — проблема решена.
Команда оценивает сроки и делает всё как нужно, а не через колоду.
Успех.
Если захочет менять что-то ещё, то как у классика: «утром деньги — вечером стулья...».

Пару раз заплатит — в третий раз задумается, а так ли уж нужно что-то существенно менять.

Нет такого понятия.

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

либо есть следующая ситуация:

Вот она и создаёт тот самый долг.

1. Исправление ошибок — результат того, что кто-то не сделал как нужно сразу.
2. Саморазвиваться за счёт заказчика — не самая лучшая идея (нам платят за то, чтобы мы работу работали, а тренировались «на кошках»).
3. Какой смысл собственные ошибки прикрывать «техническим долгом», а разгребание той кучи, которую наваливаем в проекте — «рефакторингом».

P.S.: всегда радовало понимание рефакторинга в большинстве случаев, как: «Извините, мы тут какую-то ерунду написали, теперь хотелось бы всё это исправить. Встречайте — версия 100.500.800» :)

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

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

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

1. Исправление ошибок — результат того, что кто-то не сделал как нужно сразу.

Предсказание даже на полгода уже хромает (грубо говоря, может быть точным процентов на 80, не более), на год — до 50, на 3 — любые прогнозы будут ошибочными. Архитектура же невольно живёт дольше.

2. Саморазвиваться за счёт заказчика — не самая лучшая идея

Откуда домыслы про «саморазвиваться»?

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

См. выше.

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

Ну и какой смысл в этой цитате без пояснения? Я и так знаю, что я говорил.

Говорить, что все проекты должны иметь превосходную архитектуру и отсутствие технического долга, это как говорить, что все машины должны быть Мазератти, а квартиры — пентхаусами с видом на Днепр.
Реальность такова, что большое количество бизнес-идей просто не взлетают. И тратить на разработку сомнительной идеи большие деньги просто не рационально.
Вы видели, когда-нибудь, что происходит со взлетающим стартапом? Туда просто нанимают толпу специалистов, которые со временем переписывают весь код на более качественный. Когда же количество пользователей становиться проблемой, нанимают консультанта, который умеет Highload. Это существенно экономит деньги и позволяет держать в разработке несколько бизнес-идей с последующей концентрацией на самых перспективных.

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

P.S. Ваш код в большинстве случаев ни стоит не копейки. Вы можете написать сколько угодно копий Инстаграма, но никогда ни продадите их за миллиард.

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

Прям мой случай, только началось с «можно нам простенькую рассылку емейлов».

И почему вы не берете это себе на вооружение? Ну, будут же менять, просить еще... Значит надо наперед делать так, чтобы легко добавлять и масштабировать, а странички начальные пилить задней левой ногой.... но нет! Сидят, ждут дедлайна... В туалет бы вы так ходили...

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

а не надо нагружать одного клиента стоимостью такой разработки.

А смысл? Выгоднее тянуть деньги потом

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

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

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

Вспомнилась статья про пекарей и архитектуру ;)
habrahabr.ru/post/153225

Нужно кое-что уточнить.

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

Сегодняшний взгляд программиста на программу приблизительно такой: «Заказчик! Отдай мне свои деньги! Больше денег! Теперь возьми этот мой хороший код и свали уже куда-нибудь, как ты надоел!»

Такое слово, как «абстракция», упоминать в присутствии программистов и женщин считается дурным тоном. Сложить вместе слова «абстракция» и «архитектура» и получить в результате «абстрактная архитектура» — верх неприличия!
Почему?
А потому, что это требует слишком больших умственных усилий. Это то же самое, что в Средневековье заявить, что Земля вращается вокруг солнца, а не наоборот...

Но Земля вращается.

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

Значит кто-то найдет способ эти издержки уменьшить и что тогда будете делать ВЫ?

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

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

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

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

Развитие технологий удешевляет продукт и уменьшает потребность в людях, обслуживающих технологии.
В один прекрасный момент извозчики обнаружили, что деньги, которые раньше доставались им, теперь достаются метрополитену. Когда MAERSK придумал контейнеры, тысячи грузчиков покинули порты (и портовые кабаки).

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

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

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

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

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

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

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

и они согласятся вложить немного денег в независимость от плохих решений наглых людей.
Ну так не вкладывают, кроме Гугла с Мелкомягкими. Только эти пытаются что-то делать в области ИИ, чтобы по итогу списсать разумных обезьян в биоректор (почему-то мне кажется, что часть из этих обезьян сообразит, как себя улучшить, чтобы не ликвидировали).

Я имею ввиду качественный скачек, когда архитектура сама по себе ликвидирует большинство возможностей для ошибки. Это уже происходит. Гугл и ММ — молодцы!
Ну и программеры разные. Даже средние.

Амбула — нет такого слова.

Кузьма — не нарушал бы скоростной режим, остался жив.

Работает — не трожь. Суть бизнеса заработать деньги, а не построить красивую архитектуру, и слабать шикарный код. Если он решает поставленную задачу, значит он достаточно хорош!
Конкуренты не будут сидеть ждать сложа лапки, пока конкурирующая команда, в которую инвестор вложил деньги, изъебщеряется паттернами и глубокомысленными высказываниями о Папе Джоне и пяти гиппопотамах архитектуры со смузи на кухне.
Тем более, что понятие «хорошего кода» существуют исключительно в воображении говорящего о нем, ведь своё, как известно, не пахнет.

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

agile — корень зла — а теперь идите поговорите об этом с вашими менеджерами которые не умеют работать эффективно

Ждал, когда єто скажу не я! Вся ж заметка о том, что нельзя так жить! ))))))

(C хабра)

Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.

Смешно, но неправда.
Так можно харахориться, пока не взлетят «инженеры в белых халатах». Вон, рассею лохматые уже построили...

Так можно харахориться, пока не взлетят «инженеры в белых халатах»

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

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

да, самому такие подходы не очень по нраву, т.к частенько скатываются в откровенный %уяк-%уяк —> продакшен.

имхо — Lean software development наиболее приближен к идеалу.

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

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

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

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

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

На рынке самолетов тоже не все так радужно. Посмотри на последнюю драчку Боинга с Эйрбасом. По итогу оба выпустили очень сырые самолеты, сейчас баги фиксят.

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

Потому как там есть жетский набор требований, которые нужно соблюсти обязательно и все крики маркетологов и т.п. идут лесом, если они нарушают эти требования.
Если к софту выставить подобные требования он тоже будет сравним по качеству.
Просто к софту чаще всего требования в стиле, чтобы хоть как-то иногда что-то делал.
Вот когда-то работал на RECIF. В моем ведении был софт по наладке тех железяк. Софт падал, но начальтсво категорически запретило тратить время на его приведение в порядок. Для конторы было дешевле, если инженер его после падения просто снова запускал (да софт тот постоянно сохранял свое состояние и поднимал его при старте).

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

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

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

Думается мне, что примерно 8000+ лет назад люди так и дома строили, но быстро поняли, что без проекта и расчетов — в итоге дороже. Поэтому сейчас проекты/расчеты строек занимают огромную часть времени самой стройки. Даже провести газ — сделать проект 1-2 мес., сама проводка 1 день.

Вот когда с софтом будут такие огромные потери (напр., 2-3 ядерных взрыва, из-за зависшей винды) — будут норм проекты.

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

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

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

Это ты не согласен с тем, что я выше написал?

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

И понятно почему так. Физические характеристики бревна не изменишь, а вот программинг основывается всего на двух состояниях бита и 3 логических операциях. Это и провоцирует желание любых изменений.
Хотя в ДНК почти также, вот только жизнеспособное существо получается только при определенных комбинациях. С программами тоже, жизнеспособная программа получается только при определенных комбинациях.
А вообще посмотри на ДНК — там вся архитектура — это то что сформировалось алгоритмом эволюции с горой костылей и багов. Ну и существа такие же в итоге получаются, достаточно кривенькие. Понадобилась некая функциональность для более успешного выживания — она добавилась в виде костыля.
Прилетел метеорит, стер часть говнокода, эволюционный алгоритм поехал дальше костыли лепить.

Да вы мыслите в правильном направлении!
ДНК — наше все!

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

Ты думаешь твое предложение удивительно? Нет.
Не найду сходу ссылки, но недавно видел продукт, что юзает GA для подбора формулы, описывающей временной ряд данных и не с коэффициентами некоторой формулы работает, а именно строит формулу и набора стандартных. И даже у авторов неплохо получается.
так что генерацияей жабыскрипта тоже всё возможно. И лет через 5-10 мы это увидим (может не для жабаскрипта. а для чего более нового).

Если програмный продукт не приносит денег на прямую — это все не важно. Сегодня один проект, а завтра другой, а то и другая компания. Зато человек который деливерит фичи более успешен, чем тот кто делает рефакторинг. Правда жизни

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

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

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

Есть у «дяди Боба» Мартина две замечательные книги — Clean Code и Clean Coder. Первая представляет из себя практически готовое описание code style и наглядно демонстрирует, что сделать быстро, делая плохо, невозможно. Что нужно «спешить медленно». Вторая больше акцентирует внимание на том, что профессионал не соглашается на вариант «времени нет, поэтому будем делать абы как» и в конечном итоге является единственным ответственным за читаемость и изменяемость кода.
Рекомендую купить обе в бумаге, прочитать, отметить маркером не менее одной-двух важных фраз на развороте (иногда это сложно, но надо стараться) и периодически обращаться к конкретным разделам и перечитывать полностью. Написаны великолепно, структурированы именно так, как должны быть структурированы программы, — сам текст следует тому же стилю, который предлагает.

Технический долг — это штука динамическая. Никто не мешает выделить 20% времени спринта на его фиксы. Необходимо объяснить заказчику, к чему приведёт его накопление, чтобы получить разрешение на утилизацию 10 — 30% (зависит от ситуации на проекте и желания заказчика выкатить фичи побыстрее любой ценой) времени спринта.
Насчёт архитектуры — тут другая проблема. Как я уже когда-то писал, архитектура — это компромисс между временем, затраченным на её создание и поддержание и масштабируемостью. Можно наваять тонкого клиента для hello world, но время, затраченное на создание архитектуры, многократно превысит время, потраченное на создание программы. Соответственно, такой расклад не имеет смысла. Поэтому на этапе разработки архитектуры приложения лид (или архитектор, если есть) определяет те области, в которых планируется расширение функциональности, чтобы быть к этому по возможности готовым. Waterfall меньше подвержен этим проблемам, поскольку при идеальном раскладе вся функциональность известна заранее, соответственно, есть возможность спланировать архитектуру. В agile костылей и граблей не избежать. Архитектура — это одна из вещей, которыми agile платит за готовность к изменениям. Альтернатива — постоянный рефакторинг архитектуры, что становится очень болезненным при объёмных приложениях.

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

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

Хотел продолжить мысль, что «долг» также растет по причине того, что сам разработчик обучается пока пишет приложение — в начале он видит очень простой путь к созданию компонента — быстро, понятно, без лишнего залога на псевдо будущее. Но на 3-4м компоненте обнаруживает, что есть неявная (в начале) закономерность, и что есть смысл сделать немного по другому. И таким образом у нас появляется технический долг. А обучается он, потому что каждый следующий проект индивидуален — та же платформа, тот же framework, те же контролы, но другая суть, другая модель.

Архитектура — это одна из вещей, которыми agile платит за готовность к изменениям. Альтернатива — постоянный рефакторинг архитектуры, что становится очень болезненным при объёмных приложениях.
с каких это делов?) только хрупкая архитектура встречалась до сих пор?

Смотри, есть следующие расклады:
1). Приложение, в котором требования детализированы полностью на момент старта проекта и меняться будут незначительно.
а) Если сложность приложения невелика или у команды был опыт разработки похожих приложений, есть шанс получить приложение с хорошей архитектурой.
б). Если сложность приложения высокая (ну, например, создать ERP лет эдак за 5..7) — то принципы agile по минимизации фазы анализа сыграют против архитектуры, потому что месяц на проведение полноценной фазы анализа никто не выделит. Таким образом, хорошая архитектура получится очень вряд ли.
2). Требования к приложению неизвестны на момент старта проекта или будут часто изменяться на протяжении цикла разработки.
В этом случае получить хорошую архитектуру невозможно в принципе, поскольку угадать, как будут изменены требования, невозможно.
Итого, применяя agile, мы можем получить хорошую архитектуру в 1 раскладе из 3-х приведенных.

Хорошая архитектура (ИМХО) не может быть чувствительна к изменениям. Если ты действительно разработал что-то стоящее — пусть заказчик вносит изменения каждый день — нам это ни по чем. Если вы страдаете из-за неопределенности в требованиях заказчика — у вас нет архитектуры, в моем понимании.

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

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

Давно из страны эльфов? Какой-то юношеский максимализм.

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

Был такой момент, когда компромис стал равнозначен самоубийству. Порешали без компромисов. Все ОК! ))

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

Візьмемо будь-який сучасний MVC фреймворк. Хоч PHP, хоч Java, хоч JS, хоч на будь-якій іншій мові. Сам принцип MVC не поганий, його можна описати трохи іншими словами: дані окремо, візуалізація — окремо (темплейтування); бізнес-логіка мусить бути винесена окремо; спілкування системи візуалізації та системи управління бізнес-логікою мусить проводитися через фіксований протокол(-и). Тепер запитання, скільки систем необхідно для реалізації патерна MVC? Всі вважають, що одна. А тепер уявіть, що систем буде три: FE (V, templating), middleware (C, routing), та DBMS (M, business logic).
Тепер стандартизуємо протоколи обміну даних між системами:
FE <- XML -> MW <- XML -> DBMS
І ми отримаємо гнучку систему, побудовану на патерні MVC, але не моноліт.

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

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

не завязана на фичи != одинаковая для всего

Т.е. газ и вода — это не фичи?
И там и там провод. И с мостом и там и там сторительство.

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

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

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

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

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

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

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

Всё тоже самое и в строительной архитектуре, только менять там сложнее (или проще) многое. Ибо физические ограничения еще есть.
Также и программной, если заложил где-то возможность расширяемости, то расширишь, если нет, подобъешь костылем. Но много костылей в итоге приведут к тому, что проект рассыплется под собственным весом.
Универсальная же расширяемость на все возможные случаи — это ничего. Вот было ничего — оно расширилось до нашей вселенной. Но кто запрещает этому ничего расшириться до другой вселенной.
Но в нашей ту же скорость света ты уже не сменишь или гравитационную постоянную и т.п.. Т.е. обычное архитектурное ограничение.

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

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

Универсальная же расширяемость на все возможные случаи — это ничего.

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

это одна из основ правильной архитектуры
Або неправильної архітектури. Залежить від задач. Ви ж не будете для мікроконтроллера, де війна йде за кожний байт пам’яті, писати “конструктор”.

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

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

Не второпав трохи, чому саме ці дві дефініції я плутаю?

ты это косвенно сказал прошлым комментарием: ты предлагаешь неоправданные компромиссы для того чтобы решить задачу, к тому же я помню свежий разговор dou.ua/...rums/topic/18785/#1001440

Так все життя — суцільні компроміси.
Легке розширення може бути зайвим. Раніше я теж любив гіперболи й грести під одну гребінку. ;)

а теперь постарел и волнует только чтобы ноги в тепле были?

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

Или архитектурное решение для прокладки газопровода используешь для водопровода?

Какой-то сомнительный пример. В обоих случаях это всего лишь труба, причём сходного диаметра.
Ладно, я бы понял идею «рассчитывали на 2 трубы, а тут 22»...

Твое высказывание на 100% базируется на твоем незнании.
Хуже, что после ручек таких программистов квартиры и дома взрываются.
Есть тонны норм и правил, что требуется учесть при создании архитектуры и их не мало, в частности и их узучением занимаются на соответсвующих факультетах соответсвующих ВУЗов 5 лет.

Твое высказывание на 100% базируется на твоем незнании.

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

Есть тонны норм и правил,

Верно. И где упомянуто хотя бы одно?
Я подхожу именно как программист: без описания подробностей предметной области я не имею никаких данных, от слова «вообще».

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

И, кстати, в Карпатах великий Уренгой-Помары-Ужгород это просто труба, местами над автодорогой. Так что практически есть данные, что не всё так там страшно :)

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

Я просто смотрю на практический факт: вижу одно и то же с точностью до плюс-минус.

Потому я и говорю ровно о том, что конкретная аналогия неудачна.

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

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

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

А потом на них впав метеоріт, та нічого переробляти не прийшлося.

Если уж про взрыв газа и последствия вспоминать, то лучше на этих роликах:
www.youtube.com/watch?v=kb5RIGnu-jQ
www.youtube.com/watch?v=NVf1CyZqTCg
они как-то показательнее.

Хотя основной вывод на все случаи тут «не живите в панельных хрущобах», всё остальное второстепенно.

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

Да. Потребуется. Но при чём тут мост?

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

Ну да... и вы готовы с этим жить? Любой плотник лучше относится к своей работе, чем программист! Хотя, у этого явления есть и объективные предпосылки.

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

ИИ — искуственный интеллект что-ли?
А кто его создаст, теже программисты? ;)

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

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

И да, и интересно получается: вам не надоела эта ситуация?

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