Comments 49
Цитатка выглядит так, будто готовилась для feed ленты vk $)
-8
Автор, такое хорошее начало, а в результате скатились до «очень важные сферические советы в вакууме. В большинстве этих статей можно встретить абстрактные философские нравоучения»
+4
Я думаю, основная нормальная мысль статьи в том, что писать код надо попроще, но не говнокодить. И возможно, это сложнее, чем просто писать 100500 классов и фреймверков на каждый день
0
Возможно, для Вас такая стратегия и пригодна (а то и единственно верна), однако часто приходится поддерживать проекты, которым лет 5, а то и 10. Как-то ради интереса посмотрел историю изменений в файле, который создан в 1996 году: 6 коммитов, из них 2 — только добавление комментариев. А всё потому, что этот модуль делает то и только то, что от него требуется.
По мне, так Ваш случай — исключение из правил.
P.S. «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
По мне, так Ваш случай — исключение из правил.
P.S. «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте».
+2
Как я и сказал, нельзя все проекты под одну гребенку подгонять.
+1
А цитата ваша тоже подходит далеко не для всех проектов.
Во-первых, начнем с того, что не каждый проект нужно будет поддерживать.
Во-первых, начнем с того, что не каждый проект нужно будет поддерживать.
+2
Для каждой поставленной задачи должен быть свой подход.
Одного единого решения для всех задач не бывает.
Иногда необходим прототип с полностью продуманной архитектурой, которая легко масштабируемая в дальнейшем, а иногда написанный говнокодом за 1 день.
Одного единого решения для всех задач не бывает.
Иногда необходим прототип с полностью продуманной архитектурой, которая легко масштабируемая в дальнейшем, а иногда написанный говнокодом за 1 день.
0
Все ваши советы — ненаучны, неприменимы для множества случаев и относятся скорее к менеджменту, чем к программированию.
Есть 2 основных (в этом контексте) подхода к разработке программного обеспечения:
1. восходящий — снизу вверх, пишем сначала основные системные модули, потом склеиваем в подсистемы и только потом переходим к интерфейсам и прочему.
2. нисходящий — сверху вниз, делаем сначала интерфейс, потом заполняем логикой (возможно с заглушками) и потом разрабатываем нужные модули в нужном виде.
Так вот, к чему это я. Дело в том, что для восходящего подхода прототип можно сразу в мусор выкидывать, в большинстве случаев, а для нисходящего — спокойно, линейно можно развивать. Почему так:
Восходящий подход. Потому, что при разработке прототипа допускаются ряд упущений, которые кардинально влияют на связи в системных модулях. И если эти упущения небыли предусмотрены грамотно, что очень вероятно, и не всегда возможно иначе, то при переходе к разработке реального ПО мы получим что все связи и все модули нам не подходят, и даже архитектуры целых подсистем, а может и вся архитектура в целом.
Нисходящий подход. У нас есть интерфейс, архитектура и каким-то шаманским образом описана логика. После прототипа, по сути ничего не мешает изменять логику, дорабатывать и разрабатывать нужные модули. Ошибки в интерфейсе — в основном очень дешевые.
И еще, следует заметить, что выбор между этими двумя подходами (если не говорить о другом контексте и разных примесях) явно показывает можно ли будет развивать прототип, или нет. Нисходящий подход используется в основном в более простых задачах, основанных на простом взаимодействии с пользователем (сапер, mspaint, веб сайт), а восходящий на более сложных вещах, где даже что-то сделать сложно не имея пачку модулей (GameDev, браузер, программный видео/аудио плеер).
Все что я хотел сказать: Если приложение напрашивается на нисходящею разработку, из его прототипа будет просто развивать целое приложение, иначе сложно.
В том, что я говорил, я упускал уровни программиста, методологии разработки, менеджмент и прочие. Говорил исключительно в контексте архитектуры.
Есть 2 основных (в этом контексте) подхода к разработке программного обеспечения:
1. восходящий — снизу вверх, пишем сначала основные системные модули, потом склеиваем в подсистемы и только потом переходим к интерфейсам и прочему.
2. нисходящий — сверху вниз, делаем сначала интерфейс, потом заполняем логикой (возможно с заглушками) и потом разрабатываем нужные модули в нужном виде.
Так вот, к чему это я. Дело в том, что для восходящего подхода прототип можно сразу в мусор выкидывать, в большинстве случаев, а для нисходящего — спокойно, линейно можно развивать. Почему так:
Восходящий подход. Потому, что при разработке прототипа допускаются ряд упущений, которые кардинально влияют на связи в системных модулях. И если эти упущения небыли предусмотрены грамотно, что очень вероятно, и не всегда возможно иначе, то при переходе к разработке реального ПО мы получим что все связи и все модули нам не подходят, и даже архитектуры целых подсистем, а может и вся архитектура в целом.
Нисходящий подход. У нас есть интерфейс, архитектура и каким-то шаманским образом описана логика. После прототипа, по сути ничего не мешает изменять логику, дорабатывать и разрабатывать нужные модули. Ошибки в интерфейсе — в основном очень дешевые.
И еще, следует заметить, что выбор между этими двумя подходами (если не говорить о другом контексте и разных примесях) явно показывает можно ли будет развивать прототип, или нет. Нисходящий подход используется в основном в более простых задачах, основанных на простом взаимодействии с пользователем (сапер, mspaint, веб сайт), а восходящий на более сложных вещах, где даже что-то сделать сложно не имея пачку модулей (GameDev, браузер, программный видео/аудио плеер).
Все что я хотел сказать: Если приложение напрашивается на нисходящею разработку, из его прототипа будет просто развивать целое приложение, иначе сложно.
В том, что я говорил, я упускал уровни программиста, методологии разработки, менеджмент и прочие. Говорил исключительно в контексте архитектуры.
0
Описанный алгоритм и подход в целом относится к восходящим или нисходящим подходам?
0
Алгоритм и подход в целом не принадлежат к описанным. Я не понял вашей задачи, вашего подхода к решению.
Скорей всего мешенный подход (расширение ядра), в котором уже большее зависит от других выборов.
Скорей всего мешенный подход (расширение ядра), в котором уже большее зависит от других выборов.
0
То есть, Вы не поняли задачу и подход к ее решению, но при этом написали комент с полстатьи про архаичное деление проектирования софта на восходящий и нисходящий методы? ОК.
+4
То, что я не понял вашей задачи и подхода, скорее ваша ошибка, чем моя. Не принимайте близко к сердцу, но вы описали не задачу и подход решения к ней, а выдержки из каких то задач и методологию решения проблемы использования исходников прототипа в реальном проекте. То, что я написал, оно совершенно в другом контексте, но относится к основной теме статьи.
Да, боюсь что оно таки архаичное, но оно до сих пор имеет определенную силу и влияние, в том числе на тему вашей статьи.
Да, боюсь что оно таки архаичное, но оно до сих пор имеет определенную силу и влияние, в том числе на тему вашей статьи.
-2
Вот же их развелось-то.
+2
А ведь Вы тоже могли бы разбить статью на некоторе количество «постулатов», придумать звучное название, типа "ПЫЩ!" (Прототипное вЫраЩивание) и пополнить копилку баззвордов современного программиста. На Хабре начали бы появляться статьи «Анти-ПЫЩ!» или «Почему ПЫЩ! Вам не подходит». И вот она — известность :)
+11
Я думаю многие воспримут эту статью в штыки, потому что смотрят на неё с точки зрения программиста. А программисту, хорошему программисту, очень важно чтоб его работа была красива, быть может даже совершенно с точки зрения программистов — т.е. хорошая архитектура, новейшие технологии, полное покрытие юнит тестами, высокая производительность и портируемость.
А самое интересное в том, что менеджеру, заказчику всё выше описанное зачастую ненужно. Либо ненужно на данном этапе разработки. Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.
А самое интересное в том, что менеджеру, заказчику всё выше описанное зачастую ненужно. Либо ненужно на данном этапе разработки. Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.
-1
На этом я как раз заострял внимание.
0
Я бы хотел уточнить, что писал эту статью программист.
+1
Нет, это вы описали сферического программиста в вакууме. Профессиональный программист всегда должен действовать эффективно, выполнять то, что нужно, используя целесообразные решения.
0
Ага, вот сейчас как раз сижу за таким проектом, которые писали люди, хорошо знающие предметную область. Может, когда это был прототип и менеджерам показали красивые скриншоты и диаграммы, они пришли в восторг. Но зато теперь, когда баги месяцами не исправляются, а на каждую маленькую хотелку ставят срок в месяц минимум, их это очень и очень огорчает. Причём, сидят и правят баги люди весьма и весьма толковые. Просто объективно проект написан так, что даже самое маленькое изменение в одном месте приводит к совершенно внезапным последствиям в другом. Причём, не спасает даже неплохое покрытие функциональными тестами. Так что грамотная архитектура и нужна для выполнения требования «Единственное что нужно — чтобы всё было сделано в срок и выполняло свои функции.»
+1
Вы ведь не знаете всей истории, правда? Возможно, если бы делалась «правильная архитектура» то конкуренты успели бы раньше, или не хватило бы финансирования.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
0
Вы ведь не знаете всей истории, правда? Возможно, если бы делалась «правильная архитектура» то конкуренты успели бы раньше, или не хватило бы финансирования.
Боюсь, что обычно в этих случаях причина не в спешке. Если изначально грамотно продумывать архитектуру, то времени вполне хватит. Но архитектурой попросту не заморачиваются, ибо попросту считают не нужным. Идут по пути наименьшего сопротивления. Я просто сам уже побывал вовлечён в порождение подобных монстриков, и знаю, как и почему.
По факту, раз проект жив и развивается, есть определённое количество довольно толковых разработчиков, и все видят, что текущая архитектура замедляет разработку — поднимите вопрос о глобальном рефакторинге. Сможете аргументировать зачем, — ну чтож я думаю менеджеры дадут добро. не сможете — значит он там и не нужен.
Раз проект жив и развивается, это значит только одно — пока ещё не кончились деньги инвесторов. Посмотрим, что будет после первого внедрения.
А вот сидеть и молча копать копрокод — это уж извините извращение какое-то. Вы что, действительно ждёте, что менеджеры посмотрят, и скажут что пора бы сменить архитектуру? Скорее они поменяют разработчиков.
Поменяют — отлично. Новые разработчики опять утонут во всём этом, и что дальше? Опять сменить? И ещё раз, пока не надоест?
+1
Боюсь, что обычно в этих случаях причина не в спешке. Если изначально грамотно продумывать архитектуру, то времени вполне хватит.
А вы попробуйте продумать архитектуру, когда требования и даже концепция постоянно меняются. Универсальная архитектура — как правило довольно сложна, для начала, поэтому и делают на неподходящей.
Раз проект жив и развивается, это значит только одно — пока ещё не кончились деньги инвесторов. Посмотрим, что будет после первого внедрения.
Если у вас проект ещё незапущен, но уже требует рефакторинга, и стопорится на пустяках — советую искать другую работу :). В этом случае его уже практически ничего не спасёт (кроме разве что отсутствия конкурентов, тогда быть может есть возможность сделать всё с нуля).
Поменяют — отлично. Новые разработчики опять утонут во всём этом, и что дальше? Опять сменить? И ещё раз, пока не надоест?
будут менять, пока не найдутся те, кто сможет объяснить причину задержек и её исправить. Общатся надо с менеджерами, одно ведь дело делаете.
0
А вы попробуйте продумать архитектуру, когда требования и даже концепция постоянно меняются. Универсальная архитектура — как правило довольно сложна, для начала, поэтому и делают на неподходящей.
Во-первых, требования перед стартом должны хоть как-нибудь более-менее нормально определяться. А этот принцип, когда ещё не решили, что нужно, но уже бросились кодить — это уже менеджерский антипаттерн. И как раз является одной из причин подобной «архитектуры». Во-вторых, программисты и без этого умудряются гнать ересь, в вещах, которые не касаются требований (бывают же чисто технические моменты). Опять же, я знаю о чём говорю, ибо сам участвовал в написании проектов с нуля.
Если у вас проект ещё незапущен, но уже требует рефакторинга, и стопорится на пустяках — советую искать другую работу :). В этом случае его уже практически ничего не спасёт (кроме разве что отсутствия конкурентов, тогда быть может есть возможность сделать всё с нуля).
Ну не надо мне давать таких советов, не обладая полной информацией. Тем более, что вариант «советую искать другую работу» хорош для кремниевой долины ну или для Москвы, например. А есть города, где вообще найти вменяемую работу достаточно тяжело. Причём, бывают ещё и жизненные обстоятельства, которые намертво держат в таких городах.
будут менять, пока не найдутся те, кто сможет объяснить причину задержек и её исправить. Общатся надо с менеджерами, одно ведь дело делаете.
Ну опять же, советы мимо кассы. Но не буду раскрывать подробностей, ибо NDA.
0
Должен скзать, у вас классный английский и рассказываете живо.
+3
Вчера как раз смотрел видео вашей системы интерактивной презентации для университетов: interactivelab.ru/ELEKTRONNYI-UNIVERSITET
Было бы интересно узнать о создании технологии, в чествности в рамках ипользования Unity.
Было бы интересно узнать о создании технологии, в чествности в рамках ипользования Unity.
0
все сводится к простому концепту: Programming, Motherfucker
+1
Не хочу показаться занудой, но:
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
Часто работают всего 1 день во время выставки, а потом выкидываются
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
+3
Вообще не пофиг на внутреннее строение.
Если что-то сломается за час перед запуском, полнейший говнокод починить будет невозможно. А хорошо струтурированный красивый код отлаживается в боевых условиях очень быстро. После чего ставится себе памятник и все идут бухать
Если что-то сломается за час перед запуском, полнейший говнокод починить будет невозможно. А хорошо струтурированный красивый код отлаживается в боевых условиях очень быстро. После чего ставится себе памятник и все идут бухать
0
Естественно говнокод починить будет невозможно. Но что-то мне подсказывает, что в описанных в статье проектах время разработки слишком мало, чтобы объём говнокода достиг критической массы.
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
0
промахнулся, не обращайте внимание.
0
Хороший пост, спасибо
0
«Часто работают всего 1 день во время выставки, а потом выкидываются» — надо выделить, жирно, чтобы всем сразу было понятно для чего используется такой подход. А то научатся плохому, и будут использовать этот подход на проектах в десятки человеко-лет. А в контексте задач, да все правильно, сложная архитектура и качественный код (с точки зрения последующей его поддержки, а не багов) ненужная роскошь для проектов которые разрабатываются пару недель, а живут 1 день. В описанных вами условиях подход отличный, но условия у вас все же согласитесь далеко не стандартные.
+2
С программами в научных областях тоже часто так. Когда пишешь программу, часто не знаешь, подход вообще рабочий или его придется выкинуть сразу, как посмотришь на полученные никуда не годные результаты. И приходится придумывать как по-друому решить задачу, ответ которой неизвестен. Нереально просто быстро склепать десяток программ по всем правилам, если из них жить останется одна (вот потом её и можно будет порефакторить или даже переписать).
0
Четко и структурированно. Никаких тебе Ребята, пишите красивый код! А некрасивый — не пишите! Это же так просто!
Отличная статья с четкой аргументацией и примерами из личного опыта. Приятно и легко читать.
Отличная статья с четкой аргументацией и примерами из личного опыта. Приятно и легко читать.
+2
UFO just landed and posted this here
Согласен, что работает не везде. Но много где!
Даже мир идет к этому — щас все на 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ч и тд), потом делаете запросы к живой базе.
а затем уже проектируете дизайн, верстку и тд под интервалы.
если же дать воображать дизайнерам, то они нарисуют, допустим, какие-нибудь часики круглые, а интервалы от дня и выше, и вся работа псу под хвост.
такие дела. всем успехов!
0
Ну да все верно замечено. Единственное, что мне кажется не учтенным, это то, что автор считает программиста-создателя того самого дерева-прототипа энтузиастом собственной системы. А это, увы, не всегда так :(. Я думаю важно добавить чтобы программисты активно искали и находили те проекты, в которых они были бы энтузиастами.
Всем удачи!
Всем удачи!
0
Это как раз тот случай, когда ради скорости можно жертвовать и дешевизной и, в некоторой степени, качеством…
0
Какое-то время (надо сказать счастливое), довелось работать над подобными быстрыми проектами для рекламы, выставок и прочего BTL. Готов подписаться под каждым словом.
0
Sign up to leave a comment.
Как вырастить программу из прототипа