Comments 66
Жизненный цикл обсуждение, начало разработки разработка готово сдача должен проходить не менее 10 раз. Выбирайте сроки итерации. С нового ружья и нового прицела сразу в цель не попадёшь.
> Жизненный цикл обсуждение, начало разработки разработка готово сдача должен проходить не менее 10 раз.
Какие промежутки времени между итерации Вы считаете оптимальными?
Какие промежутки времени между итерации Вы считаете оптимальными?
У нас неделя и меньше
Часто при таком цикле в каждой итерации открываются новые моменты, из-за которых необходимо заметно переделывать код?
Я, пока что, придерживаюсь такой позиции: «Хуже отсутствия ТЗ, может быть только меняющееся ТЗ». т.е вот обсудили все, вот составили ТЗ, вот написан код решающий задачи из ТЗ, а потом оказывается что «нужно тут сделать не так, а иначе», «вот тут по-другому, я думал это уже знают все и не описывали это в ТЗ». В общем это убивает всю тягу делать проект, постоянные изменения в ТЗ, и из-за этого постоянные правки(переписывание) уже написанного кода.
Я, пока что, придерживаюсь такой позиции: «Хуже отсутствия ТЗ, может быть только меняющееся ТЗ». т.е вот обсудили все, вот составили ТЗ, вот написан код решающий задачи из ТЗ, а потом оказывается что «нужно тут сделать не так, а иначе», «вот тут по-другому, я думал это уже знают все и не описывали это в ТЗ». В общем это убивает всю тягу делать проект, постоянные изменения в ТЗ, и из-за этого постоянные правки(переписывание) уже написанного кода.
Да, неизбежно, мы переделываем и код и графику и интерфейсы и сюжет наших игр. Вы знакомы с миром agile разработки? Мы исповедуем kanban. Надо делать не до состояния заказчик так хочет, а до того как фича заработает, когда пользователи будут использовать функционал. Если его сделали как хотел заказчик но пользователи не пользуют, значит надо переделать, или выкинуть. И тут проще делать по чуть чуть и проверять.
Это может и работает когда пользователи слабо зависят от заказчика, но когда заказчик их в приказном порядке обязывает пользоваться фичей…
Они всё равно не будут ей пользоваться. Ну т.е. будут, но активность использования всё равно будет изменяться от качества. Или время затраченное на использование фичи. Например будет специалист поддержки по 10 минут тратить на заведение тикета. И это плохо. И работать надо над уменьшением этого времени в таком случае. И то что требования заказчика исполнены ещё ни о чём не говорит. Вопрос в том изменилось ли значение целевой метрики. А кроме количества пользований или времени можно ещё оценить количество жалоб или обращений в поддержку.
И работать надо над уменьшением этого времени в таком случае.
Проблема ли это разработчика? Не заказчика ли? Ну и поддержка первой линии замкнута на том же заказчике — до разработчиков доходит только то, что он «заапрувил».
Если вы готовы делать лажу, скрываясь за тем что «заказчик мудак», отлично. Если вы честны, прежде всего перед собой и ваша работа используется плохо, или не работает вовсе, то это проблема вас и вашей кармы, не зависимо от того сколько уровней корпоративного болота или субподряда стоит между вами и пользователем.
Более того, иногда например приходится менять структуру хранилища или ещё чего-то достаточно фундаментального. Потому что вчера не нужно было а теперь надо. И когда программисты и вся команда вовлечены и понимают какие бизнес процессы за этим стоят нет никаких проблем. Это просто по честному делать работу хорошо, а не для галочки типа заказчик так принял.
Если честно, именно такие фундаментальные изменения и привносят разочарование: зачем мне придумывать лучшую структуру, задумываться над тем как лучше реализовать и на это потратить силы, если они окажутся напрасными и нужно делать по-другому. После таких вот изменений пришла мысль: не надо писать хорошо, надо писать что бы просто работало и тратить минимум усилий.
В этом и есть крутость профессионала, написать так чтобы мы потом не бегали и не искали где взять ещё пару камазов серверов, при обсуждении изначально мы бы заложились на расширение. Но при этом не нагородить большего чем надо. Можно очень долго проектировать фичу которая не получит развития. Да есть опасность что придётся переделать 3 раза с нуля. Но также есть шанс из 5 решений бастрых понять какие 2 нужны а 3 выкинуть, и эти два уже переписать нормально и в итоге выиграть.
MVP, реально минимум, выход и итерации итерации итерации. С регулярнейшим самоконтролем.
Да да, а мне еще говорят «разберись как нибудь, ты же умный...», приходится соответствовать и включать телепатический модуль.
— Анализ требований — обязательно
— Проектирование — обязательно.
Вообще, хороший программист должен уметь проектировать на UML. Во время этого процесса узнаешь много нового и намного раньше, чем дико спасаешь свое время в дальнейшем.
Без выполнения этих пунктов проект точно в какой-то момент затопчет сам себя.
— Проектирование — обязательно.
Вообще, хороший программист должен уметь проектировать на UML. Во время этого процесса узнаешь много нового и намного раньше, чем дико спасаешь свое время в дальнейшем.
Без выполнения этих пунктов проект точно в какой-то момент затопчет сам себя.
Вообще, хороший программист должен уметь проектировать на UML.Спорное утверждение. UML, в первую очередь, нотация. Достаточно удобно использовать нестрогое подмножество UML для облегчения взаимодействия между разработчиками.
Использовать же его, как инструмент проектирования — дело вкуса. Я нашел для себя полезным sequence diagram и, иногда, state diagram. Остальное — куда реже и сильно упрощенно. А всякие кодогенераторы, принимающие UML class diagram на вход, IMHO не нужны.
Чаще всего на практике, конечно выходит, что какой-то один-два типа диаграмм используется.
Расписывать каждый проект обязательно по всем диаграммам — верх невежества.
Я говорю про грамотность! Какой программист хороший, когда ему показываешь диаграмму, а он говорит, что не понимает, что это «объясните на пальцах»
Расписывать каждый проект обязательно по всем диаграммам — верх невежества.
Я говорю про грамотность! Какой программист хороший, когда ему показываешь диаграмму, а он говорит, что не понимает, что это «объясните на пальцах»
Вообще я UML рассматриваю, как универсальный инструмент общения между программистами и с заказчиком (или его представителем — продукт менеджером)
А реальный опыт есть, которым можете поделиться? Я так в жизни и не встретил реально работающего проекта, в котором общение организована посредством UML-взаимодействия между участниками (как сказали выше — сиквенс или стейт диаграмму нарисовать на бумажке, когда что-нибудь на митинге разбирали). Было ощущение, что нет желания ни у программистов их использовать, ни у заказчика-менеджера в них разбираться.
Боюсь, что часто опыт такой упирается в знание самого языка. Соглашусь, что он не прост. Самого меня в него неплохо погрузили в универе, и предупредили, что не все признают UML.
Реальный опыт таков, что я его использую при составлении требований, когда понимаю, что после прочтения
больших текстов описания (под-)системы возникнет еще больше вопросов, чем до. Также иногда применяю для наглядности представления создаваемого модуля, притом даже если над кодом работаю только я один.
Реальный опыт таков, что я его использую при составлении требований, когда понимаю, что после прочтения
больших текстов описания (под-)системы возникнет еще больше вопросов, чем до. Также иногда применяю для наглядности представления создаваемого модуля, притом даже если над кодом работаю только я один.
UFO just landed and posted this here
«эйфория от UML сошла на нет, когда внезапно оказалось, что из неправильных картинок получаются неправильные программы» (с) :-)
Источник приведите, пожалуйста
Источник неизвестен :)
www.rsdn.ru/forum/other/1014270.all
www.rsdn.ru/forum/other/1014270.all
Вероятно народная мудрость…
Не только UML, а вообще любое дизайнерское представление крупного в виде диаграммок и подобных UML-ей есть очень большое зло. Не как дополнительный, а как ведущий инструмент…
Например тут можно почитать почему. И это не только в Microsoft, это вообще в любом крупном околопрограммном бизнесе так.
И на счет «затопчет» (ваш коммент выше) — это как правило с точностью наоборот. Хотя на UML-грабли в свое время понаступали все, ну или почти все.
Вообще эйфория вокруг UML мне например и многим другим «бородатым» разрабам была изначально не понятна: инструменты проектируются и создаются для упрощения решения задач — UML же был создан imho, чтобы возможно немного упростить жизнь проект-менеджеру или проект-дизайнеру, но одновременно максимально усложнить жизнь разработчика. В проектах, где непосредственно разработка занимает только 10%, а проектирование 90% времени это возможно и оправдано — однако это, imho, утопия.
И пожалуйста, без флуда на тему UML-Reverce Ingenering (эти грабли помоему, бьют по башке так, что вообще отбивают охоту программировать).
Не только UML, а вообще любое дизайнерское представление крупного в виде диаграммок и подобных UML-ей есть очень большое зло. Не как дополнительный, а как ведущий инструмент…
Например тут можно почитать почему. И это не только в Microsoft, это вообще в любом крупном околопрограммном бизнесе так.
И на счет «затопчет» (ваш коммент выше) — это как правило с точностью наоборот. Хотя на UML-грабли в свое время понаступали все, ну или почти все.
Вообще эйфория вокруг UML мне например и многим другим «бородатым» разрабам была изначально не понятна: инструменты проектируются и создаются для упрощения решения задач — UML же был создан imho, чтобы возможно немного упростить жизнь проект-менеджеру или проект-дизайнеру, но одновременно максимально усложнить жизнь разработчика. В проектах, где непосредственно разработка занимает только 10%, а проектирование 90% времени это возможно и оправдано — однако это, imho, утопия.
И пожалуйста, без флуда на тему UML-Reverce Ingenering (эти грабли помоему, бьют по башке так, что вообще отбивают охоту программировать).
Я не фанат UML, я говорю о том, что функция «подумать заранее» работает и дает результаты лучше, чем перепроектирование на ходу.
Хорошо, но вы же проектируете как-то предварительно систему? Скажите, как вы описываете сложные системы, опираясь на свой опыт!
Хорошо, но вы же проектируете как-то предварительно систему? Скажите, как вы описываете сложные системы, опираясь на свой опыт!
Я обычно проектирую в виде прямоугольничков со стрелочками. Если получается очень много прямоугольников и стрелочки начинают сильно путаться или пересекаться, проект фиговый, надо заново рисовать.
«Проектирую в виде прямоугольничков со стрелочками.» — это когда нужно сделать небольшой проект и сам себе проект-лид и сам же исполнитель. Когда проект/продукт огромен, активно развивается — вплоть до 10-ков человеко лет, над ним работает команда — тогда все это, простите, ерунда.
Например если я сгенерирую диаграмму связей только статической составляющей банка данных части одного проекта и распечатаю — этим можно будет небольшой зал как обоями обклеить. И что вам скажет такая диаграмма? Видите ту табличку в 5-ти метрах, нет не ту — метр ниже, вот от нее имеем n2m foreign key связь которая ведет вон к той, на ту стену…
Я утрирую конечно, но иногда это просто не реально, даже если дробить на участки, модулям и т.д.
К тому же как такое версионировать? Как потом визуализировать изменения (историю)? И т.д. и т.п.
То, что часть проекта «фиговая» тоже выясняется иногда не на этапе проектирования, а во время разработки.
Например если я сгенерирую диаграмму связей только статической составляющей банка данных части одного проекта и распечатаю — этим можно будет небольшой зал как обоями обклеить. И что вам скажет такая диаграмма? Видите ту табличку в 5-ти метрах, нет не ту — метр ниже, вот от нее имеем n2m foreign key связь которая ведет вон к той, на ту стену…
Я утрирую конечно, но иногда это просто не реально, даже если дробить на участки, модулям и т.д.
К тому же как такое версионировать? Как потом визуализировать изменения (историю)? И т.д. и т.п.
То, что часть проекта «фиговая» тоже выясняется иногда не на этапе проектирования, а во время разработки.
Вообще, это шутка была. Я имел в виду, что мне непонятно, зачем вести такого рода диаграмму вместе с проектом? На моей памяти такие диаграммы применялись либо если нам давали адский говнокод с гигантским количеством компонентов и связей и надо было проект привести в порядок, или кошмарную базу данных, которую нужно было почистить и нормализовать. Вот тогда любым способом из кода/базы генерились те самые прямоугольнички со стрелочками и вешалась гигантская простыня на стену, где можно было порисовать. Ну и если планировали какой-то проект, рисовали на доске схемы, чтобы поделить на куски.
У меня, если появляется желание нарисовать схему проекта, перво-наперво я задаю себе вопрос: Какую проблему проекта я сейчас решаю? Не раз сталкивался со случаями, когда начальник отдела или даже проджект заморачивал кучу народа рисовать никому не нужные схемы и бесполезные отчеты.
У меня, если появляется желание нарисовать схему проекта, перво-наперво я задаю себе вопрос: Какую проблему проекта я сейчас решаю? Не раз сталкивался со случаями, когда начальник отдела или даже проджект заморачивал кучу народа рисовать никому не нужные схемы и бесполезные отчеты.
Хорошо, но вы же проектируете как-то предварительно систему? Скажите, как вы описываете сложные системы, опираясь на свой опыт!В трех этапах (важно что более-менее «предваритьельно» происходит только 1-й этап):
— ТЗ описывает требования заказчика и/или максимально подробно описывает задачу "Что нужно сделать". [joke](Если заказчик вместо «Что», пропихивает «Как» — получит по лицу;)[/joke]
В идеале — это вообще текст, отформатированый спец. образом, чтобы наша IDE его понимала — а главное можно было залить для «версионирования» в svn/git/любимое подставить. Особенно важно если работа ведется в несколько рук;
— Проъектное решение максимально подробно описывает "Как мы это будем делать": где нужны диаграммы они там будут (редкое явление если честно). Это тоже как правило текст под IDE…
— Девелопер пишет код, сопровождая его подробными коментариями, коммитит в svn/git/любимое подставить сопровождая каждый коммит подробными коментариями, потом это все собирается в документацию;
Если на каком-то этих 3 «этапов» в каком-либо модуле/функции была допущена конструктивная ошибка, откатываемся до предыдущего этапа и разрабатываем этот модуль/функцию и т.д. по новой. Каждое изменение посмотреть в соответствующей версии, вплоть до всей истории, откатить назад и т.д.
Тестеров, quality control и т.д и т.п в рамках вашего вопроса не рассматриваю (но как минимум ридонли доступ к репозиторию проекта они имеют).
И часто у вас проекты по этой схеме работали в идеале?
Всегда, по крайней мере очень приближено.
В идеале конечно много бы чего изменили бы, но к примеру корпоративные политики к сожалению не позволяют. Например, очень хотелось бы привязать тикетинг с обратной связью (чтоб клиент тоже мог участвовать напрямую). Но тогда согласно корпоративной полиси за номером N бери MKS (потому что стандарт и что-нибудь другое наружу не выпустят). MKS же тащит с собой совершенно не юзабельную, имхо, систему контроля версий. Во всяком случае на нее после svn/git перелазить нет никакого желания, а паралельно вести ревизии в обоих сводит все приимущество такой привязки тикетинг-системы на нет.
В идеале конечно много бы чего изменили бы, но к примеру корпоративные политики к сожалению не позволяют. Например, очень хотелось бы привязать тикетинг с обратной связью (чтоб клиент тоже мог участвовать напрямую). Но тогда согласно корпоративной полиси за номером N бери MKS (потому что стандарт и что-нибудь другое наружу не выпустят). MKS же тащит с собой совершенно не юзабельную, имхо, систему контроля версий. Во всяком случае на нее после svn/git перелазить нет никакого желания, а паралельно вести ревизии в обоих сводит все приимущество такой привязки тикетинг-системы на нет.
Знать — безусловно должен. Использовать — не обязательно, благодаря новым инструментам разработка ускорилась и сейчас можно меньше времени уделять проектированию. Мощные фреймворки закладывают приличную гибкость для стандартных задач. Для нестандартных и сложных нужно уметь визуализировать свои идеи.
p.s. Самое главное, что программист не должен ругать других за идеи вроде UML и не минусовать брызжа слюной, как сделали с вашим постом. Детский сад.
p.s. Самое главное, что программист не должен ругать других за идеи вроде UML и не минусовать брызжа слюной, как сделали с вашим постом. Детский сад.
Эх, как же я все это понимаю… брат! :)
На самом деле, программирование — это просто, надо только овладеть искусством декомпозиции :)
[offtopic]
Не смог прочитать МакКоннелла ни с первого ни со второго подхода. ИМХО, толщина книги соответствует количеству «воды» в ней. Гораздо больше нравится «Программист — прагматик».
[/offtopic]
Не смог прочитать МакКоннелла ни с первого ни со второго подхода. ИМХО, толщина книги соответствует количеству «воды» в ней. Гораздо больше нравится «Программист — прагматик».
[/offtopic]
UFO just landed and posted this here
Да, с паттернами та же история. Но её всё-таки прочитал, чтобы потом пользоваться как справочником, знать где что искать, и узнать общую терминологию.
GoF ценна общим языком для взаимодействия между разработчиками.
это книги, которые структурируют знания
На мой взгляд, именно в этом, в первую очередь, ценность «классических» книг — они не сообщают революционные вещи, а приводят в порядок кашу из разрозненных знаний в голове. Бывает, что это приносит значительно большую пользу.
А мне там многое понравилось. Особенно запомнилась идея программ, управляемых данными. Теперь я постоянно использую эту идею.
Вы упомянули про «5-7 объектов в поле внимания» и что это мешает понимать сложную систему. По-моему это был опыт у Вундта, когда это число показали экспериментально, обьем сознания, так это они называли — замеряли, сколько тактов метронома человек может запомнить и различить. Но штука была в том, что в дальнейшем выяснилось, что люди могут запомнить гораздо больше тактов, просто структурируя сигналы более крупными единицами, выделяя группы, как, например, припев и куплет мелодии. Соответственно сложность системы может быть довольно велика, если она удачно структурирована. 5-7 обьектов вполне хватит.
Кстати, в главе из книги Турчина, на которую я дал ссылку в списке доплитературы, содержится ещё более сильное утверждение: «честная» ёмкость человеческого внимания — до 3 объектов, более крупные группы человек дробит на атомарные. То есть, 5-7 объектов это, на деле, атомарная группа атомарных групп.
Я совершенно согласен, разбиение системы на не более чем 5-7 подсистем это как раз один из эффективных способов борьбы со сложностью. Фаулер в «Рефакторинге», кажется, прямо об этом говорит. Я не могу вспомнить, там ли это, или где-то ещё, был красивый оборот про «два плюс два равно четыре, но четыре плюс четыре уже не равно восемь».
Я совершенно согласен, разбиение системы на не более чем 5-7 подсистем это как раз один из эффективных способов борьбы со сложностью. Фаулер в «Рефакторинге», кажется, прямо об этом говорит. Я не могу вспомнить, там ли это, или где-то ещё, был красивый оборот про «два плюс два равно четыре, но четыре плюс четыре уже не равно восемь».
Когда программиста достигает такое озарение — это как взрыв сверхновой — видно со всех концов вселенной. Для этого нужно лишь набрать критическую массу нерешенных проблем, чтобы мозг взорвался от попытки охватить все и сразу.
Не понимаю, зачем себя так мучить. Жизнь одна, imho нельзя выбирать себе род деятельности, потому что это «почётно и круто», но при этом «невыносимо сложно». Лично я работаю программистом, потому что это легко :-)
А я работаю, потому что мне нравится. На сколько бы высокооплачиваемой работы не была, не вижу смысла на ней работать, если она не приносит удовольствия и морального удовлетворения.
Есть нюансы. Если работа приносит удовольствие и моральное удовлетворение, но денег на привычный образ жизни и/или осуществление долгосрочных планов (типа покупки недвижимости или пенсионного страхования) не хватает, то многие предпочтут побольше денег, пускай и без удовольствия, но не ломая привычки.
+ А также Боб Мартин «Чистый код».
Вроде бы небольшая, но прелестная такая статься получилась. Простая, человеческая…
Sign up to leave a comment.
Невыносимая сложность программирования