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

Yevgen Shramko 24.10.2016 10:05

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

Денис Бушуляк 21.10.2016 22:46

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

Денис Бушуляк 21.10.2016 22:57

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 10:51

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

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

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

Денис Бушуляк 22.10.2016 11:43

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 13:30

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

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

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

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

Денис Бушуляк 22.10.2016 16:32

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

Да это и имелось в виду.

Денис Бушуляк 22.10.2016 16:35

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

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

Oleg Kariakin Senior Java Developer 22.10.2016 10:53

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

Vlad Lee SEO Owner "GPDP" 24.10.2016 13:28

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

Олександр Шпак Oarsman в Self Employed 24.10.2016 13:45

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

Vlad Lee

Eugene Suleimanov Senior Software Engineer/Team Lead 21.10.2016 17:56

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

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

}

Vlad Lee SEO Owner "GPDP" 21.10.2016 19:28

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

Олександр Шпак Oarsman в Self Employed 21.10.2016 19:31

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

Vlad Lee

Vlad Lee SEO Owner "GPDP" 21.10.2016 19:34

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

Vadim Kopanev Architect 21.10.2016 19:39

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

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

Vlad Lee

Олександр Шпак Oarsman в Self Employed 21.10.2016 19:51

Но попробуйте меня переубедить!

Якщо ви захочете бути переконаним...

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

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

;)

Vlad Lee

Vlad Lee SEO Owner "GPDP" 21.10.2016 20:48

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

PAAMAYIM NEKUDOTAYIM Trainee engineer в IT 22.10.2016 03:17

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

Нестор Иванович 22.10.2016 06:31

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

PAAMAYIM NEKUDOTAYIM

Олександр Шпак Oarsman в Self Employed 22.10.2016 11:44

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

PAAMAYIM NEKUDOTAYIM

anonymous 23.11.2016 10:34

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

Олександр Шпак Oarsman в Self Employed 23.11.2016 11:16

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

anonymous

undefined pointer 23.11.2016 17:23

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

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

Олександр Шпак Oarsman в Self Employed 23.11.2016 17:28

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

undefined pointer 23.11.2016 18:02

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

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

Олександр Шпак Oarsman в Self Employed 23.11.2016 18:53

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

undefined pointer 23.11.2016 19:08

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

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

Олександр Шпак Oarsman в Self Employed 23.11.2016 19:44

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

Ви спілкуєтеся із практиком. Мати упереджену думку стосовно співрозмовника — показувати ваш рівень, не мій.

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

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

undefined pointer 23.11.2016 19:56

Ви спілкуєтеся із практиком.

я спілкуюсь з текстом постів.

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

Розвиватися та вчитися ніколи не пізно.

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

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

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

Є такий дивний світ, називається XML.

і далі — ну точно, все за сценарієм :)

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

Олександр Шпак Oarsman в Self Employed 23.11.2016 20:22

я спілкуюсь з текстом постів.

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

а всі ці слова звичайні для евангелістів та шахраїв з авантюристами — про свіже мислення

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

Eugene Suleimanov Senior Software Engineer/Team Lead 21.10.2016 23:17

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

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

Vlad Lee

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 10:48

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

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

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

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

Eugene Suleimanov Senior Software Engineer/Team Lead 22.10.2016 11:10

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

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

anonymous 22.10.2016 11:50

-

Eugene Suleimanov Senior Software Engineer/Team Lead 22.10.2016 12:05

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

anonymous

anonymous 22.10.2016 12:10

-

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 11:55

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

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

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

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

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

См. выше.

Eugene Suleimanov Senior Software Engineer/Team Lead 22.10.2016 12:06

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 13:24

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

Oleksii Kuchma Senior iOS developer 21.10.2016 00:16

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

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

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

Александр Шевченко Java developer 20.10.2016 13:48

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

Alex Koshterek погромизд 20.10.2016 14:01

Аджайл же)

Nikita Podgorbunskyi Software Engineer 20.10.2016 16:19

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

Vlad Lee SEO Owner "GPDP" 20.10.2016 16:33

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

Александр Шевченко Java developer 20.10.2016 17:01

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

Vlad Lee

Vlad Lee SEO Owner "GPDP" 20.10.2016 17:49

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

Vladimir Pauchev Don't care 20.10.2016 19:07

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

Vlad Lee

Ievgen Safronenko Senior Software Engineer в zooplus 23.10.2016 13:32

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

зачем? Потом это можно сделать за дополнительную плату

Vlad Lee

Vadim Kopanev Architect 23.10.2016 19:23

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

Ievgen Safronenko

Warriorr Light 20.10.2016 13:17

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

Золотая классика, 15 лет в интернетах.

Aleksey Kolupaev CTO в eduki 20.10.2016 12:35

Николай Юденко 19.10.2016 17:46

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

Vlad Lee SEO Owner "GPDP" 19.10.2016 15:34

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous 19.10.2016 16:38

-

Vlad Lee

Vlad Lee SEO Owner "GPDP" 19.10.2016 16:44

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

anonymous

Котэ гуляющее само по себэ 19.10.2016 15:01

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

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

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

Maslenko Stanislav Senior Slave Rower 23.10.2016 15:36

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

Котэ гуляющее само по себэ

anonymous 19.10.2016 14:25

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

Vlad Lee SEO Owner "GPDP" 19.10.2016 14:28

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

anonymous

Andrey B DevOps в Ciklum 19.10.2016 09:44

(C хабра)

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

Vlad Lee SEO Owner "GPDP" 19.10.2016 10:49

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

Andrey B

Andrey B DevOps в Ciklum 19.10.2016 12:07

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

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

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

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

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

Vlad Lee

Eugene Nuribekov SSE 19.10.2016 15:22

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

Andrey B

anonymous 19.10.2016 16:41

-

Dmytro Lapshyn Solution Architect 24.10.2016 13:15

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

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

Eugene Nuribekov SSE 24.10.2016 14:24

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

Dmytro Lapshyn

anonymous 24.10.2016 19:48

-

Eugene Nuribekov SSE 24.10.2016 19:57

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

anonymous

anonymous 24.10.2016 20:02

-

Eugene Nuribekov SSE 24.10.2016 20:05

95% софта нафиг не нужно.

anonymous

Nataly Johnson COO в WSM 25.10.2016 14:47

очень смешно )))

Andrey B

Дмитро 19.10.2016 08:35

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

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

anonymous 19.10.2016 12:21

-

Дмитро

Oleksiy Zakharov Programmer в - Freelancer 19.10.2016 05:47

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

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

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

anonymous 19.10.2016 12:23

-

Oleksiy Zakharov

Oleksiy Zakharov Programmer в - Freelancer 19.10.2016 13:42

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

anonymous

anonymous 19.10.2016 13:50

-

Oleksiy Zakharov

Vlad Lee SEO Owner "GPDP" 19.10.2016 14:12

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

anonymous

Oleksiy Zakharov Programmer в - Freelancer 19.10.2016 20:24

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

anonymous

anonymous 20.10.2016 11:24

-

Oleksiy Zakharov

Vladimir Pauchev Don't care 18.10.2016 22:54

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

anonymous 18.10.2016 19:01

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

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

Ilia Kondratov Android Developer 18.10.2016 17:53

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

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

Дмитрий Мирошник Lead QA Automation Engineer 18.10.2016 16:36

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

Vlad Lee SEO Owner "GPDP" 18.10.2016 16:50

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

Дмитрий Мирошник Lead QA Automation Engineer 18.10.2016 18:58

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

Vlad Lee

Денис Бушуляк 21.10.2016 22:33

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

Vadim Kopanev Architect 18.10.2016 20:02

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

с каких это делов?) только хрупкая архитектура встречалась до сих пор?

Дмитрий Мирошник Lead QA Automation Engineer 19.10.2016 10:17

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

Vlad Lee SEO Owner "GPDP" 19.10.2016 11:33

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

anonymous 19.10.2016 12:18

-

Vlad Lee

Artem Kurakin software engineer в Microsoft 23.10.2016 07:02

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

Vlad Lee

Vlad Lee SEO Owner "GPDP" 23.10.2016 10:00

Лет 9 как... ))))

Artem Kurakin

Artem Kurakin software engineer в Microsoft 23.10.2016 10:47

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

Vlad Lee

Vlad Lee SEO Owner "GPDP" 23.10.2016 11:25

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

Artem Kurakin

Олександр Шпак Oarsman в Self Employed 23.10.2016 11:27

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

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

Artem Kurakin

Vadim Kopanev Architect 19.10.2016 12:48

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

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

anonymous 19.10.2016 13:03

-

Vadim Kopanev Architect 19.10.2016 13:06

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

anonymous

anonymous 19.10.2016 13:07

-

Vadim Kopanev Architect 19.10.2016 14:51

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

anonymous

anonymous 19.10.2016 16:42

-

Vadim Kopanev Architect 19.10.2016 18:21

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

anonymous

anonymous 20.10.2016 11:26

-

Vadim Kopanev Architect 20.10.2016 12:09

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

anonymous

anonymous 20.10.2016 12:12

-

Vadim Kopanev Architect 20.10.2016 12:15

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

anonymous

anonymous 20.10.2016 12:23

-

Vadim Kopanev Architect 20.10.2016 12:32

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

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

anonymous

anonymous 20.10.2016 12:38

-

Vadim Kopanev Architect 20.10.2016 12:41

аксиома Виктора?

anonymous

anonymous 20.10.2016 12:45

-

Олександр Шпак Oarsman в Self Employed 20.10.2016 12:41

это одна из основ правильной архитектуры

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

anonymous 20.10.2016 12:48

-

Олександр Шпак Oarsman в Self Employed 20.10.2016 13:04

:) Ну, нехай щастить...

anonymous

Vadim Kopanev Architect 20.10.2016 12:50

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

Олександр Шпак Oarsman в Self Employed 20.10.2016 13:05

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

Vadim Kopanev Architect 21.10.2016 00:24

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

Олександр Шпак Oarsman в Self Employed 21.10.2016 01:20

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

Vadim Kopanev Architect 21.10.2016 01:42

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

Олександр Шпак Oarsman в Self Employed 21.10.2016 02:01

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

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 10:56

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

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

anonymous

anonymous 22.10.2016 11:05

-

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 11:48

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

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

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

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

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

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

anonymous

anonymous 22.10.2016 11:52

-

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 11:53

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

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

anonymous

anonymous 22.10.2016 11:57

-

Олександр Шпак Oarsman в Self Employed 22.10.2016 12:12

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

anonymous

anonymous 22.10.2016 12:28

-

Олександр Шпак Oarsman в Self Employed 22.10.2016 12:39

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

anonymous

anonymous 22.10.2016 12:49

-

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 13:28

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

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

anonymous

Valentin Nechayev уповноважений по милицях в Дарницькі печери 22.10.2016 13:24

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

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

anonymous

anonymous 18.10.2016 13:08

-

Vlad Lee SEO Owner "GPDP" 18.10.2016 14:44

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

anonymous

anonymous 18.10.2016 14:48

-

Vlad Lee

Николай Юденко 19.10.2016 11:42

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

anonymous

anonymous 19.10.2016 12:25

-

Николай Юденко

Николай Юденко 19.10.2016 13:01

Не боги горшки обжигают ;)

anonymous

Stan Maleev 18.10.2016 12:41

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

Vlad Lee SEO Owner "GPDP" 18.10.2016 14:45

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