Comments 21
Очень верно написано в конце про баланс. О коде забывать не стоит, но на первом месте продукт, как итоговый результат работы
Итоговый продукт — не код, а решенная проблема. Особенно отлично, когда проблема решается вообще без нового кода, например, уместным использованием sed, grep и awk.
Многие программисты же отчего-то свято веруют, что их единственная задача состоит в написании кода. Да и как бы (зачастую внешне) трепетно один программист не относился к своему коду, всё равно потом придёт другой и скажет «тут всё неправильно, надо переписывать».
Задача программиста — формализовать задачу и все возможные варианты и исходы, и решить её за минимально возможное время оставляя точки для расширения в зависимости от предполагаемых будущих требований )
Дядя Боб в книжке «Идеальный программист» рассказывал, почему всякие популярные ошибочные предположения 20-летней давности типа избавиться от кода и предоставлять решение задачи на более высоком уровне абстракции — например в виде диаграмм понятных любому человеку(Model-driven architecture), не избавит нас от необходимости найма программистов.
Ну и, такие вещи всё же нужно чем-то обосновывать
Дядя Боб в книжке «Идеальный программист» рассказывал, почему всякие популярные ошибочные предположения 20-летней давности типа избавиться от кода и предоставлять решение задачи на более высоком уровне абстракции — например в виде диаграмм понятных любому человеку(Model-driven architecture), не избавит нас от необходимости найма программистов.
«Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the
problem is code. But code is not the problem. It has never been the problem.
The problem is detail.»
Да и как бы (зачастую внешне) трепетно один программист не относился к своему коду, всё равно потом придёт другой и скажет «тут всё неправильно, надо переписывать».
Ну и, такие вещи всё же нужно чем-то обосновывать
Потому что это основная и первостепенная задача. Если работодателю нужно починить кран или забить пару гвоздей, то для этого не обязательно программистов нанимать.
Особенно отлично, когда проблема решается вообще без нового кода, например, уместным использованием sed, grep и awk.
думаю, в статье рассматриваются не те случаи, когда можно обойтись коротким скриптом.
UFO just landed and posted this here
Вы ведь недавно во всем в этом? Вариантов намного больше, чем 2: "с дизайном" и "без". Наше ремесло в оценках. Сколько будет жить продукт? Будет ли время его дорабатывать? Что для этого продукта "достаточно хорошо"? Всегда городить долг — неверно, поскольку не решит всех задач. Всегда делать идеальную расширяемую архитектуру равно неверно, поскольку тоже не решит всех задач. Наше ремесло в трезвых оценках и выборе нужных инструментах, как мне видится сейчас.
Приведенный график не даёт ответа на вопрос, в какой же момент времени дизайн системы начинает окупаться
Собственно это — самый главный вывод. Как писали, если не ошибаюсь, Том с Тимом: «Все говорят что им нужно качество. Угадайте от чего отказываются в первую очередь?»
По моему скромному опыту (почти 15 лет), хороший код бизнесу не нужен. Совсем. Бизнесу важно, чтобы в первую очередь все работало как должно, во-вторую, чтобы быстро можно было впилить очередное поведение/хотелку. Собственно, на этом все. Если все работает на костылях и программист Вася умеет строить новые костыли поверх старых, то и отлично. Иногда этот самый Вася хочет все разломать и сделать по-нормальному. Он приходит к бизнесу, спрашивает про переделки и часто получает ответ в стиле Золушки: конечно, сделай все хорошо, но вот все должно работать через неделю. Как-то так, все вышесказанное это только мой личный опыт.
Мне не совсем понятна ваша терминология. Разве тот факт того что в код можно легко и быстро вносить изменения не ломая всё остальное не есть качественный код? Что тогда значит сделать «по нормальному»?
И если все же код состоит из костылей — что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код? Что будет когда Васю попросят поменять что-то спустя пол года как он сделал какую-то фичу, он так же сможет разобраться со всем что он нагородил до этого?
P.S.
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
И если все же код состоит из костылей — что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код? Что будет когда Васю попросят поменять что-то спустя пол года как он сделал какую-то фичу, он так же сможет разобраться со всем что он нагородил до этого?
P.S.
Если все работает на костылях и программист Вася умеет строить новые костыли поверх старых, то и отлично
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
Разве тот факт того что в код можно легко и быстро вносить изменения не ломая всё остальное не есть качественный код
У меня не было про «легко», у меня было про «быстро». Это примерно как если что-то отвалилось, то есть разные варианты починки: заменить, склеить или замотать скотчем. Бизнесу тут часто достаточно скотча. Да, в какой-то момент скотч отвалится и Вася будет придумывать что-то еще или более крепкий скотч… Еще, в какой-то момент Вася может прийти стукнуть кулаком по столу и сказать, что либо он увольняется, либо тратим время на рефакторинг. Это тоже может прокатить.
что будет если бизнес захочет рядом с Васей посадить ещё Петю, будет ему так же легко вносить изменения в код?
Нет, изменения будет тяжело вносить. Но бизнес это мало заботит, к сожалению. Со временем Вася расскажет Пете про все виды костылей и все.
То есть тот факт что бизнес остановится в развитии как только Вася заболеет/уволится это отлично?
Нет, это ужасно. Но бизнес остановится без Васи в любом случае, даже если бы он писал идеальный код, т.к. знание предметной области никто не отменял. Еще раз, я все это не оправдываю, просто к сожалению, часто такое встречал.
Да, в какой-то момент скотч отвалится и Вася будет придумывать что-то еще или более крепкий скотч…
Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать. Ну и если это обходится дешевле чем обзавестись программистами поопытнее… Видимо основной продукт бизнеса вовсе не ПО.
Со временем Вася расскажет Пете про все виды костылей и все.
Опять же, какие размеры у проекта, что чтобы его понять хватит «рассказать про виды костылей и всё»?
Нет, это ужасно. Но бизнес остановится без Васи в любом случае, даже если бы он писал идеальный код, т.к. знание предметной области никто не отменял.
Есть два отличия:
— Если Вася оставит костыли и уволится, они не будут понятны никому. Предметную область же скорее всего знает кто-то кроме Васи.
— Можно посадить Петю до того как Вася уволится, и он тоже сможет вникнуть в предметную область
я все это не оправдываю, просто к сожалению, часто такое встречал.
Ну… Если бы я этого не встречал, не появилось бы этой статьи )
Мой посыл как раз в том что так делать не нужно.
То есть… Треугольник Стоимость-Время-Качество никто не отменял, но об этом нужно задумываться, оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутся
Мне кажется далеко не каждый бизнес может смириться со стабильными сбоями в системе и давать одному Васе время их разбирать.
Немножко уточню, это не сбои обычно, а хотелки. Т.е. приходит бизнес с горящими глазами и требованием сделать новый функционал, который в текущую архитектуру не укладывается совсем. Но функционал этот не просто нужен, а «нужен вчера». И остается вариант прикрутить это все синей изолентой к текущей архитектуре.
И еще, тут Вася это не обязательно один программист, это может быть команда или отдел.
оценивать риски и находить грамотные компромиссы, а не лепить как попало пока проблемы не начнутся
Это все правильно, но я не видел живого проекта, приносящего деньги, где все было сделано хорошо в этом плане. Везде присутствуют костыли, где-то меньше, где-то больше.
Мне доводилось видеть и Очень крупный бизнес. Там ровно так же, как сказал товарищ в начале ветки. Если Вася не в состоянии показать, что вот сейчас вот для этого куска или сервиса имеет смысл потратить время на долг и тогда вот какие-то конкретные, нужные бизнесу, фичи выйдут в более краткий срок, то Вася пойдет обратно к ноуту фигачить фичи и код без особой архитектуры.
Слона надо есть по частям, переписывать всё и сразу в рабочей системе из легаси-кода (не покрытого тестами) конечно не вариант. Нужно писать новый функционал «как положено» и заодно немножко подчищать старое, пресловутый принцип бойскаута. Вообщем всё давно придумано, главное чтобы разработчик дорос до соответствующего уровня и понимания. По своему аналогичному не менее скромному опыту, начинает приходить это как раз лет через 10, и надеюсь не закончится, всё-таки приятно каждый год понимать, что ты всё делаешь лучше, чем год назад.
Часто бизнес понятия не имеет, что «быстро» и «качественно» как-то связаны. Для него детали разработки находятся «под капотом». Адские костыли, отсутствие тестов, плохая архитектура, велосипедостроение — все это для бизнеса, как правило, не видно вовсе, пока все работает как должно и новые фичи пилятся быстро. Проблема в том, что бизнесу обычно не с чем сравнить — что означает «быстро» при разработке новых фич и «работает как надо» при сопровождении. Все, что видно бизнесу, — это как все устроено с его личным продуктом. Разве что сравнить с конкурентами, у которых почему-то новые фишки появляются быстрее, регрессии и баги — реже, а высокая нагрузка не приводит к даунтаймам. Но это обычно достаточно закрытая информация, а то, о чем бизнес знает — это как обстоят дела с его собственным продуктом (который «под капотом» кривой, косой, плохо масштабируемый и ужасный в сопровождении).
Это как если вы сдаете машину в аренду какому-то водителю, интересуясь только количеством заказов и прибылью, и однажды обнаруживаете, что автомобиль не просто почти не приносит прибыли, а с трудом ездит и убит в хлам, потому что водитель экономил на ГСМ и запчастях, ни разу не делал техобслуживания и был крайне неразборчив в выборе пассажиров и грузов. Вполне возможно, что к моменту обнаружения истинного положения дел автомобиль будет уже не в том состоянии, когда его рентабельно восстанавливать — придется покупать новый.
С плохим кодом та же самая история. Если бизнес не понимает, что от качества кода, архитектуры, культуры разработки зависит способность итогового продукта приносить деньги, то однажды бизнес обнаружит, что продукт не просто не прибылен, а что он убыточен и уже не может стать прибыльным снова — дешевле переписать его с нуля или заменить на готовое решение от третьей стороны.
Это как если вы сдаете машину в аренду какому-то водителю, интересуясь только количеством заказов и прибылью, и однажды обнаруживаете, что автомобиль не просто почти не приносит прибыли, а с трудом ездит и убит в хлам, потому что водитель экономил на ГСМ и запчастях, ни разу не делал техобслуживания и был крайне неразборчив в выборе пассажиров и грузов. Вполне возможно, что к моменту обнаружения истинного положения дел автомобиль будет уже не в том состоянии, когда его рентабельно восстанавливать — придется покупать новый.
С плохим кодом та же самая история. Если бизнес не понимает, что от качества кода, архитектуры, культуры разработки зависит способность итогового продукта приносить деньги, то однажды бизнес обнаружит, что продукт не просто не прибылен, а что он убыточен и уже не может стать прибыльным снова — дешевле переписать его с нуля или заменить на готовое решение от третьей стороны.
Как-то брал для другого ресурса интервью у Staff Engineer из HBO (до этого поработавшего и в Amazon). Чувак очень старался донести мысль, что бизнесу нужен только говонкод, а в индустрии всех это устраивает. Не уверен, можно ли тут давать ссылки на сторонние ресурсы, но, кому интересно, могу кинуть в личку.
У меня было внедрение ярко показывающее отношение к этому вопросу заказчиков.
Переводил 2 с лишним года назад компанию с 1С: Предприятия 7.7 (Бухгалтерия и Торговля и Склад) всё переписано под клиента, особенно ТиС на 1С: Предприятия 8 (Бухгалтерия 3 и Управление торговлей 11). Я был третьим кто за это у них взялся и тем кто это наконец выполнил. Доработки были в основном в УТ 11 их было много и учитывая специфику клиента без них действительно нельзя было обойтись. Разговора о рефакторинге того, что было сделано до меня не было, в прочем как и времени на это.
С нового года клиент начинает работать в новых программах. К концу февраля отлаживаю работу, так что клиент решает что этот этап выполнен и надо приступать к следующему большому этапу доработок с учётом всех новых возможностей 8 версии 1С: Предприятия.
Готовлю ТЗ и первым пунктом ставлю рефакторинг того что было дописано в УТ11, прошу на это месяц с соответствующей оплатой. Объясняю, что за время запуска мне столько костылей пришлось наделать в коде моих предшественников, что дальше двигаться мне просто совесть не позволяет.
Дело даже не в том, что что-то я сделал по другому. Просто понимание специфики работы клиента до запуска реальной работы и после разные. А мои предшественники и близко к реальной работе не подошли. Плюс исправление ошибок в условиях когда для тебя главное обеспечить непрерывность работы.
В результате кроме того, что клиент не согласился на рефакторинг, у него ещё изменилось отношение к сделанному и в том числе ко мне. Они думали, что всё хорошо, а я сам говорю что не очень.
В итоге клиент нанял нового разработчика. За мной оставили поддержку сделанного.
Новые ребята рефакторинг делать не стали, но 3 месяца изучали, то что было сделано до них. Хотя я на всё просил 5 меяцев. Потом тупо перетащили все доработки в 1С:CRM. Через год клиент так и не получил того, что было в первоначальном ТЗ. Ещё через два месяца они наняли штатного программиста 1С.
Через несколько месяцев я им позвонил, узнать как дела. Мне сказали, что штатный программист пока делает ревизию (не рефакторинг) доработок.
Переводил 2 с лишним года назад компанию с 1С: Предприятия 7.7 (Бухгалтерия и Торговля и Склад) всё переписано под клиента, особенно ТиС на 1С: Предприятия 8 (Бухгалтерия 3 и Управление торговлей 11). Я был третьим кто за это у них взялся и тем кто это наконец выполнил. Доработки были в основном в УТ 11 их было много и учитывая специфику клиента без них действительно нельзя было обойтись. Разговора о рефакторинге того, что было сделано до меня не было, в прочем как и времени на это.
С нового года клиент начинает работать в новых программах. К концу февраля отлаживаю работу, так что клиент решает что этот этап выполнен и надо приступать к следующему большому этапу доработок с учётом всех новых возможностей 8 версии 1С: Предприятия.
Готовлю ТЗ и первым пунктом ставлю рефакторинг того что было дописано в УТ11, прошу на это месяц с соответствующей оплатой. Объясняю, что за время запуска мне столько костылей пришлось наделать в коде моих предшественников, что дальше двигаться мне просто совесть не позволяет.
Дело даже не в том, что что-то я сделал по другому. Просто понимание специфики работы клиента до запуска реальной работы и после разные. А мои предшественники и близко к реальной работе не подошли. Плюс исправление ошибок в условиях когда для тебя главное обеспечить непрерывность работы.
В результате кроме того, что клиент не согласился на рефакторинг, у него ещё изменилось отношение к сделанному и в том числе ко мне. Они думали, что всё хорошо, а я сам говорю что не очень.
В итоге клиент нанял нового разработчика. За мной оставили поддержку сделанного.
Новые ребята рефакторинг делать не стали, но 3 месяца изучали, то что было сделано до них. Хотя я на всё просил 5 меяцев. Потом тупо перетащили все доработки в 1С:CRM. Через год клиент так и не получил того, что было в первоначальном ТЗ. Ещё через два месяца они наняли штатного программиста 1С.
Через несколько месяцев я им позвонил, узнать как дела. Мне сказали, что штатный программист пока делает ревизию (не рефакторинг) доработок.
Я на 100% согласен с последним абзацем:
Нужно искать компромисс, хотя если рассмотреть две крайности:
второй все же предпочтительнее.
В любом случае, самое главное — достижение грамотных компромиссов и нахождение той самой золотой середины, что позволит не утопить проект в яме технического долга в погоне за функционалом, и не уступить интересную нишу конкурентам, занимаясь дизайном системы вместо функционала.
Нужно искать компромисс, хотя если рассмотреть две крайности:
- неработающий проект с идеальной архитектурой
- работающий проект с невозможностью вносить изменения
второй все же предпочтительнее.
Sign up to leave a comment.
Почему бизнесу нужен хороший код