Комментарии 49
Цитатка выглядит так, будто готовилась для feed ленты vk $)
Автор, такое хорошее начало, а в результате скатились до «очень важные сферические советы в вакууме. В большинстве этих статей можно встретить абстрактные философские нравоучения»
Я думаю, основная нормальная мысль статьи в том, что писать код надо попроще, но не говнокодить. И возможно, это сложнее, чем просто писать 100500 классов и фреймверков на каждый день
Возможно, для Вас такая стратегия и пригодна (а то и единственно верна), однако часто приходится поддерживать проекты, которым лет 5, а то и 10. Как-то ради интереса посмотрел историю изменений в файле, который создан в 1996 году: 6 коммитов, из них 2 — только добавление комментариев. А всё потому, что этот модуль делает то и только то, что от него требуется.
По мне, так Ваш случай — исключение из правил.
P.S. «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
По мне, так Ваш случай — исключение из правил.
P.S. «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
Для каждой поставленной задачи должен быть свой подход.
Одного единого решения для всех задач не бывает.
Иногда необходим прототип с полностью продуманной архитектурой, которая легко масштабируемая в дальнейшем, а иногда написанный говнокодом за 1 день.
Одного единого решения для всех задач не бывает.
Иногда необходим прототип с полностью продуманной архитектурой, которая легко масштабируемая в дальнейшем, а иногда написанный говнокодом за 1 день.
Все ваши советы — ненаучны, неприменимы для множества случаев и относятся скорее к менеджменту, чем к программированию.
Есть 2 основных (в этом контексте) подхода к разработке программного обеспечения:
1. восходящий — снизу вверх, пишем сначала основные системные модули, потом склеиваем в подсистемы и только потом переходим к интерфейсам и прочему.
2. нисходящий — сверху вниз, делаем сначала интерфейс, потом заполняем логикой (возможно с заглушками) и потом разрабатываем нужные модули в нужном виде.
Так вот, к чему это я. Дело в том, что для восходящего подхода прототип можно сразу в мусор выкидывать, в большинстве случаев, а для нисходящего — спокойно, линейно можно развивать. Почему так:
Восходящий подход. Потому, что при разработке прототипа допускаются ряд упущений, которые кардинально влияют на связи в системных модулях. И если эти упущения небыли предусмотрены грамотно, что очень вероятно, и не всегда возможно иначе, то при переходе к разработке реального ПО мы получим что все связи и все модули нам не подходят, и даже архитектуры целых подсистем, а может и вся архитектура в целом.
Нисходящий подход. У нас есть интерфейс, архитектура и каким-то шаманским образом описана логика. После прототипа, по сути ничего не мешает изменять логику, дорабатывать и разрабатывать нужные модули. Ошибки в интерфейсе — в основном очень дешевые.
И еще, следует заметить, что выбор между этими двумя подходами (если не говорить о другом контексте и разных примесях) явно показывает можно ли будет развивать прототип, или нет. Нисходящий подход используется в основном в более простых задачах, основанных на простом взаимодействии с пользователем (сапер, mspaint, веб сайт), а восходящий на более сложных вещах, где даже что-то сделать сложно не имея пачку модулей (GameDev, браузер, программный видео/аудио плеер).
Все что я хотел сказать: Если приложение напрашивается на нисходящею разработку, из его прототипа будет просто развивать целое приложение, иначе сложно.
В том, что я говорил, я упускал уровни программиста, методологии разработки, менеджмент и прочие. Говорил исключительно в контексте архитектуры.
Есть 2 основных (в этом контексте) подхода к разработке программного обеспечения:
1. восходящий — снизу вверх, пишем сначала основные системные модули, потом склеиваем в подсистемы и только потом переходим к интерфейсам и прочему.
2. нисходящий — сверху вниз, делаем сначала интерфейс, потом заполняем логикой (возможно с заглушками) и потом разрабатываем нужные модули в нужном виде.
Так вот, к чему это я. Дело в том, что для восходящего подхода прототип можно сразу в мусор выкидывать, в большинстве случаев, а для нисходящего — спокойно, линейно можно развивать. Почему так:
Восходящий подход. Потому, что при разработке прототипа допускаются ряд упущений, которые кардинально влияют на связи в системных модулях. И если эти упущения небыли предусмотрены грамотно, что очень вероятно, и не всегда возможно иначе, то при переходе к разработке реального ПО мы получим что все связи и все модули нам не подходят, и даже архитектуры целых подсистем, а может и вся архитектура в целом.
Нисходящий подход. У нас есть интерфейс, архитектура и каким-то шаманским образом описана логика. После прототипа, по сути ничего не мешает изменять логику, дорабатывать и разрабатывать нужные модули. Ошибки в интерфейсе — в основном очень дешевые.
И еще, следует заметить, что выбор между этими двумя подходами (если не говорить о другом контексте и разных примесях) явно показывает можно ли будет развивать прототип, или нет. Нисходящий подход используется в основном в более простых задачах, основанных на простом взаимодействии с пользователем (сапер, mspaint, веб сайт), а восходящий на более сложных вещах, где даже что-то сделать сложно не имея пачку модулей (GameDev, браузер, программный видео/аудио плеер).
Все что я хотел сказать: Если приложение напрашивается на нисходящею разработку, из его прототипа будет просто развивать целое приложение, иначе сложно.
В том, что я говорил, я упускал уровни программиста, методологии разработки, менеджмент и прочие. Говорил исключительно в контексте архитектуры.
Описанный алгоритм и подход в целом относится к восходящим или нисходящим подходам?
Алгоритм и подход в целом не принадлежат к описанным. Я не понял вашей задачи, вашего подхода к решению.
Скорей всего мешенный подход (расширение ядра), в котором уже большее зависит от других выборов.
Скорей всего мешенный подход (расширение ядра), в котором уже большее зависит от других выборов.
То есть, Вы не поняли задачу и подход к ее решению, но при этом написали комент с полстатьи про архаичное деление проектирования софта на восходящий и нисходящий методы? ОК.
То, что я не понял вашей задачи и подхода, скорее ваша ошибка, чем моя. Не принимайте близко к сердцу, но вы описали не задачу и подход решения к ней, а выдержки из каких то задач и методологию решения проблемы использования исходников прототипа в реальном проекте. То, что я написал, оно совершенно в другом контексте, но относится к основной теме статьи.
Да, боюсь что оно таки архаичное, но оно до сих пор имеет определенную силу и влияние, в том числе на тему вашей статьи.
Да, боюсь что оно таки архаичное, но оно до сих пор имеет определенную силу и влияние, в том числе на тему вашей статьи.
Вот же их развелось-то.
А ведь Вы тоже могли бы разбить статью на некоторе количество «постулатов», придумать звучное название, типа "ПЫЩ!" (Прототипное вЫраЩивание) и пополнить копилку баззвордов современного программиста. На Хабре начали бы появляться статьи «Анти-ПЫЩ!» или «Почему ПЫЩ! Вам не подходит». И вот она — известность :)
Я думаю многие воспримут эту статью в штыки, потому что смотрят на неё с точки зрения программиста. А программисту, хорошему программисту, очень важно чтоб его работа была красива, быть может даже совершенно с точки зрения программистов — т.е. хорошая архитектура, новейшие технологии, полное покрытие юнит тестами, высокая производительность и портируемость.
А самое интересное в том, что менеджеру, заказчику всё выше описанное зачастую ненужно. Либо ненужно на данном этапе разработки. Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.
А самое интересное в том, что менеджеру, заказчику всё выше описанное зачастую ненужно. Либо ненужно на данном этапе разработки. Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.
На этом я как раз заострял внимание.
Я бы хотел уточнить, что писал эту статью программист.
Нет, это вы описали сферического программиста в вакууме. Профессиональный программист всегда должен действовать эффективно, выполнять то, что нужно, используя целесообразные решения.
Ага, вот сейчас как раз сижу за таким проектом, которые писали люди, хорошо знающие предметную область. Может, когда это был прототип и менеджерам показали красивые скриншоты и диаграммы, они пришли в восторг. Но зато теперь, когда баги месяцами не исправляются, а на каждую маленькую хотелку ставят срок в месяц минимум, их это очень и очень огорчает. Причём, сидят и правят баги люди весьма и весьма толковые. Просто объективно проект написан так, что даже самое маленькое изменение в одном месте приводит к совершенно внезапным последствиям в другом. Причём, не спасает даже неплохое покрытие функциональными тестами. Так что грамотная архитектура и нужна для выполнения требования «Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.»
Вы ведь не знаете всей истории, правда? Возможно, если бы делалась «правильная архитектура» то конкуренты успели бы раньше, или не хватило бы финансирования.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
Вы ведь не знаете всей истории, правда? Возможно, если бы делалась «правильная архитектура» то конкуренты успели бы раньше, или не хватило бы финансирования.
Боюсь, что обычно в этих случаях причина не в спешке. Если изначально грамотно продумывать архитектуру, то времени вполне хватит. Но архитектурой попросту не заморачиваются, ибо попросту считают не нужным. Идут по пути наименьшего сопротивления. Я просто сам уже побывал вовлечён в порождение подобных монстриков, и знаю, как и почему.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
Раз проект жив и развивается, это значит только одно — пока ещё не кончились деньги инвесторов. Посмотрим, что будет после первого внедрения.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
Поменяют — отлично. Новые разработчики опять утонут во всём этом, и что дальше? Опять сменить? И ещё раз, пока не надоест?
Боюсь, что обычно в этих случаях причина не в спешке. Если изначально грамотно продумывать архитектуру, то времени вполне хватит.
А вы попробуйте продумать архитектуру, когда требования и даже концепция постоянно меняются. Универсальная архитектура — как правило довольно сложна, для начала, поэтому и делают на неподходящей.
Раз проект жив и развивается, это значит только одно — пока ещё не кончились деньги инвесторов. Посмотрим, что будет после первого внедрения.
Если у вас проект ещё незапущен, но уже требует рефакторинга, и стопорится на пустяках — советую искать другую работу :). В этом случае его уже практически ничего не спасёт (кроме разве что отсутствия конкурентов, тогда быть может есть возможность сделать всё с нуля).
Поменяют — отлично. Новые разработчики опять утонут во всём этом, и что дальше? Опять сменить? И ещё раз, пока не надоест?
будут менять, пока не найдутся те, кто сможет объяснить причину задержек и её исправить. Общатся надо с менеджерами, одно ведь дело делаете.
А вы попробуйте продумать архитектуру, когда требования и даже концепция постоянно меняются. Универсальная архитектура — как правило довольно сложна, для начала, поэтому и делают на неподходящей.
Во-первых, требования перед стартом должны хоть как-нибудь более-менее нормально определяться. А этот принцип, когда ещё не решили, что нужно, но уже бросились кодить — это уже менеджерский антипаттерн. И как раз является одной из причин подобной «архитектуры». Во-вторых, программисты и без этого умудряются гнать ересь, в вещах, которые не касаются требований (бывают же чисто технические моменты). Опять же, я знаю о чём говорю, ибо сам участвовал в написании проектов с нуля.
Если у вас проект ещё незапущен, но уже требует рефакторинга, и стопорится на пустяках — советую искать другую работу :). В этом случае его уже практически ничего не спасёт (кроме разве что отсутствия конкурентов, тогда быть может есть возможность сделать всё с нуля).
Ну не надо мне давать таких советов, не обладая полной информацией. Тем более, что вариант «советую искать другую работу» хорош для кремниевой долины ну или для Москвы, например. А есть города, где вообще найти вменяемую работу достаточно тяжело. Причём, бывают ещё и жизненные обстоятельства, которые намертво держат в таких городах.
будут менять, пока не найдутся те, кто сможет объяснить причину задержек и её исправить. Общатся надо с менеджерами, одно ведь дело делаете.
Ну опять же, советы мимо кассы. Но не буду раскрывать подробностей, ибо NDA.
Должен скзать, у вас классный английский и рассказываете живо.
Вчера как раз смотрел видео вашей системы интерактивной презентации для университетов: interactivelab.ru/ELEKTRONNYI-UNIVERSITET
Было бы интересно узнать о создании технологии, в чествности в рамках ипользования Unity.
Было бы интересно узнать о создании технологии, в чествности в рамках ипользования Unity.
все сводится к простому концепту: Programming, Motherfucker
Не хочу показаться занудой, но:
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
Часто работают всего 1 день во время выставки, а потом выкидываются
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
Вообще не пофиг на внутреннее строение.
Если что-то сломается за час перед запуском, полнейший говнокод починить будет невозможно. А хорошо струтурированный красивый код отлаживается в боевых условиях очень быстро. После чего ставится себе памятник и все идут бухать
Если что-то сломается за час перед запуском, полнейший говнокод починить будет невозможно. А хорошо струтурированный красивый код отлаживается в боевых условиях очень быстро. После чего ставится себе памятник и все идут бухать
Естественно говнокод починить будет невозможно. Но что-то мне подсказывает, что в описанных в статье проектах время разработки слишком мало, чтобы объём говнокода достиг критической массы.
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
промахнулся, не обращайте внимание.
Хороший пост, спасибо
«Часто работают всего 1 день во время выставки, а потом выкидываются» — надо выделить, жирно, чтобы всем сразу было понятно для чего используется такой подход. А то научатся плохому, и будут использовать этот подход на проектах в десятки человеко-лет. А в контексте задач, да все правильно, сложная архитектура и качественный код (с точки зрения последующей его поддержки, а не багов) ненужная роскошь для проектов которые разрабатываются пару недель, а живут 1 день. В описанных вами условиях подход отличный, но условия у вас все же согласитесь далеко не стандартные.
С программами в научных областях тоже часто так. Когда пишешь программу, часто не знаешь, подход вообще рабочий или его придется выкинуть сразу, как посмотришь на полученные никуда не годные результаты. И приходится придумывать как по-друому решить задачу, ответ которой неизвестен. Нереально просто быстро склепать десяток программ по всем правилам, если из них жить останется одна (вот потом её и можно будет порефакторить или даже переписать).
Четко и структурированно. Никаких тебе Ребята, пишите красивый код! А некрасивый — не пишите! Это же так просто!
Отличная статья с четкой аргументацией и примерами из личного опыта. Приятно и легко читать.
Отличная статья с четкой аргументацией и примерами из личного опыта. Приятно и легко читать.
НЛО прилетело и опубликовало эту надпись здесь
Согласен, что работает не везде. Но много где!
Даже мир идет к этому — щас все на Continuous Integration строится в Вебе. Баду релизит каждый день (кстати прикольный релиз-сценарий у них, видел на HPC), супер-ребята из TargetProcess сидят на CI — Сервере.
Релиз каждый день — сам Бог велел иначе строить разработку.
1. Подпишусь всеми щупальцами за. Я мечтал написать такую статью год, но в основном писал к PM. А теперь от вас такая мощная, и в тему. Спасибо! Хабр — your dreams come true.
2. Отдельно выделю живые данные.
Если, мля, вы разрабатываете или тестируете на «qqq» / «йцукен» — ставьте себе два.
Следующие вещи точные для промышленных проектов (кроме там искусственного сердца, самолетов итд)
— Вы гарантированно получите баги на живых данных.
— Вы гарантированно сделаете в функционале что-то не так.
— А иногда в принципе не сможете сделать.
Два примера из практики.
а) Автоматизировали подачу заявок в договорной отдел ( + генерацию договоров и тд, Workflow короче)
Файлы хранятся в системе, версионность между договорами на номере договора — то есть в одной заявке видны все остальные заявки по этому договору (новые заявки приходят типа добавить приложение).
И кто бы подумал, что появятся номера которые КАЖДЫЙ ГОД обнуляются. Изначально все было заточено на «бесконечный рост» — нумерация нигде не обновлялась с новым годом и это не планировалось.
В итоге в заявке показывается прошлогодний договор на другого клиента с таким же номером.
б) в системе идет логгирование даты взятия заявки в работу, и даты закрытия.
время исполнения заявки = дата закрытия — дата взятия в работу.
необходимо сделать отчет с группировкой, в первом столбце интервал времени исполнения заявки, во втором число таких заявок.
логгирование сделали изначально, чтобы данные накапливались + экономия времени (см. пост выше))), отчет не делали и не думали о нем.
так вот, сначала вы выбираете интервалы наугад (0 <t <= 1 ч, 1 ч < t <= 2ч и тд), потом делаете запросы к живой базе.
а затем уже проектируете дизайн, верстку и тд под интервалы.
если же дать воображать дизайнерам, то они нарисуют, допустим, какие-нибудь часики круглые, а интервалы от дня и выше, и вся работа псу под хвост.
такие дела. всем успехов!
Даже мир идет к этому — щас все на Continuous Integration строится в Вебе. Баду релизит каждый день (кстати прикольный релиз-сценарий у них, видел на HPC), супер-ребята из TargetProcess сидят на CI — Сервере.
Релиз каждый день — сам Бог велел иначе строить разработку.
1. Подпишусь всеми щупальцами за. Я мечтал написать такую статью год, но в основном писал к PM. А теперь от вас такая мощная, и в тему. Спасибо! Хабр — your dreams come true.
2. Отдельно выделю живые данные.
Если, мля, вы разрабатываете или тестируете на «qqq» / «йцукен» — ставьте себе два.
Следующие вещи точные для промышленных проектов (кроме там искусственного сердца, самолетов итд)
— Вы гарантированно получите баги на живых данных.
— Вы гарантированно сделаете в функционале что-то не так.
— А иногда в принципе не сможете сделать.
Два примера из практики.
а) Автоматизировали подачу заявок в договорной отдел ( + генерацию договоров и тд, Workflow короче)
Файлы хранятся в системе, версионность между договорами на номере договора — то есть в одной заявке видны все остальные заявки по этому договору (новые заявки приходят типа добавить приложение).
И кто бы подумал, что появятся номера которые КАЖДЫЙ ГОД обнуляются. Изначально все было заточено на «бесконечный рост» — нумерация нигде не обновлялась с новым годом и это не планировалось.
В итоге в заявке показывается прошлогодний договор на другого клиента с таким же номером.
б) в системе идет логгирование даты взятия заявки в работу, и даты закрытия.
время исполнения заявки = дата закрытия — дата взятия в работу.
необходимо сделать отчет с группировкой, в первом столбце интервал времени исполнения заявки, во втором число таких заявок.
логгирование сделали изначально, чтобы данные накапливались + экономия времени (см. пост выше))), отчет не делали и не думали о нем.
так вот, сначала вы выбираете интервалы наугад (0 <t <= 1 ч, 1 ч < t <= 2ч и тд), потом делаете запросы к живой базе.
а затем уже проектируете дизайн, верстку и тд под интервалы.
если же дать воображать дизайнерам, то они нарисуют, допустим, какие-нибудь часики круглые, а интервалы от дня и выше, и вся работа псу под хвост.
такие дела. всем успехов!
Ну да все верно замечено. Единственное, что мне кажется не учтенным, это то, что автор считает программиста-создателя того самого дерева-прототипа энтузиастом собственной системы. А это, увы, не всегда так :(. Я думаю важно добавить чтобы программисты активно искали и находили те проекты, в которых они были бы энтузиастами.
Всем удачи!
Всем удачи!
Это как раз тот случай, когда ради скорости можно жертвовать и дешевизной и, в некоторой степени, качеством…
Какое-то время (надо сказать счастливое), довелось работать над подобными быстрыми проектами для рекламы, выставок и прочего BTL. Готов подписаться под каждым словом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как вырастить программу из прототипа