Комментарии 124
На своей шкуре уже несколько раз испытал ситуацию №2. Самое обидное, что от внезапных озарений заказчиков в последний момент не спасет ни выделенный разработчик-архитектор, ни даже самое тщательное продумывание. :(
Спасает только хорошая спецификация, жёсткая позиция руководителя, который может чётко довести до заказчика, что даже самое мелкое с его точки зрения изменение может потребовать большое количество времени на рефакторинг.
Если маленькое изменение требует «большого рефакторнига» — это признак сильно связанного когда и неудачной архитектуры. Система должна быть готова к изменениям, которые неизбежны, и сопротивляться им бессмысленно т.к. система которая не изменяется — это мертвая система. Конечно, хорошей спецификацией можно в случае чего прикрыть свой зад, но продукт от этого нужной фичи не получит и лучше не станет.
НЛО прилетело и опубликовало эту надпись здесь
Вы начали совершенно верно: если стоит задача написать расчет факториала, необходимо, следуя принципам KISS и YAGNI, максимально просто реализовать расчет факториала :) Заказчик обязательно попросит вас добавить еще один метод расчета, и вы это сделаете, никуда не денетесь. А вот когда он попросит добавить третий — вот тут и проявится качество архитектуры. Если на втором шаге вы все сделали правильно, избежали дублирования, это не займет много времени.
Кстати, то ли у Мартина, то ли у Шаллоуея была описана точно такая же ситуация, только там был не факториал, а программа для копирования. Сначала она должна была копировать из файла в файл, потом из файла на принтер и так далее. На простом примере хорошо иллюстрируется как должен расти качественный продукт.
Кстати, то ли у Мартина, то ли у Шаллоуея была описана точно такая же ситуация, только там был не факториал, а программа для копирования. Сначала она должна была копировать из файла в файл, потом из файла на принтер и так далее. На простом примере хорошо иллюстрируется как должен расти качественный продукт.
Есть еще класс задач «переосмысливание базовых понятий». Например, изменение поведения базовых классов. Или изменение принципа работы с транзакциями в транзакционно-критичной задаче.
«Добавьте такую фичу: пользователи Системы могут быть не всегда пользователями, не всегда авторизованными, при этом должны иметь возможность проводить транзакции абсолютно аналогично обычным пользователям), при этом работать так как будто у них есть авторизация (хотя ее нет), возможно как-то обходя ограничения SSL.» ;)
«Добавьте такую фичу: пользователи Системы могут быть не всегда пользователями, не всегда авторизованными, при этом должны иметь возможность проводить транзакции абсолютно аналогично обычным пользователям), при этом работать так как будто у них есть авторизация (хотя ее нет), возможно как-то обходя ограничения SSL.» ;)
Для небольших и некритичных проектов долго проектировать архитектуру, и писать код правильно — экономически нецелесообразно. В таких проектах проще по быстрому написать что-нибудь простенькое на грани с говнокодом.
И вот когда такой проектик внезапно надо начать развиваться, и возникает ситуация «маленькое изменение требует большого рефакторнига». Начинаем рвать на себе волосы и кричать «эх… надо было нормально все делать, но кто же знал что этот проектик будет расти!»
И вот когда такой проектик внезапно надо начать развиваться, и возникает ситуация «маленькое изменение требует большого рефакторнига». Начинаем рвать на себе волосы и кричать «эх… надо было нормально все делать, но кто же знал что этот проектик будет расти!»
Для получения хорошей архитектуры ее вовсе не обязательно проектировать, тем более долго. А для получения качественного кода нет необходимости прикладывать каких-то дополнительных усилий, достаточно следователь некоторым простым, но важным принципам. Говнокод же даже в самых небольших проектах всегда вылазит боком, значительно увеличивая стоимость любого последующего изменения.
> код правильно — экономически нецелесообразно
Не верю ©! Экономически затратно, как всегда, любое внедрение. В том числе и хорошего, правильного стиля программирования — надо тратить время на то, чтобы обучать команду «как надо» и «как не надо». После этого любой код становится правильным, независимо от затраченного на его создание времени. Хорошие программисты по-другому не могут.
С людьми надо работать, прежде всего. А уж потом с цифрами и процессами.
Не верю ©! Экономически затратно, как всегда, любое внедрение. В том числе и хорошего, правильного стиля программирования — надо тратить время на то, чтобы обучать команду «как надо» и «как не надо». После этого любой код становится правильным, независимо от затраченного на его создание времени. Хорошие программисты по-другому не могут.
С людьми надо работать, прежде всего. А уж потом с цифрами и процессами.
Писать код правильно — это всегда сокращение затрат.
Как минимум на тестирование и поддержку.
Правильный код показывает дисциплину и уровень разработчика. Хороший разработчик не позволяет себе опуститься до говнокода. Конечно, бывают ситуации, когда на небольшой рефакторинг не хватает пару-тройку часов (релиз завтра!), но даже тогда это место локализуется, отделяется интерфейсами и т.д., по максимому соблюдая инкапсуляцию. И обязательно оставляются комментарии.
В дальнейшем (после выкладывания очередного релиза) этот код обязательно переписывается по-человечески.
Как минимум на тестирование и поддержку.
Правильный код показывает дисциплину и уровень разработчика. Хороший разработчик не позволяет себе опуститься до говнокода. Конечно, бывают ситуации, когда на небольшой рефакторинг не хватает пару-тройку часов (релиз завтра!), но даже тогда это место локализуется, отделяется интерфейсами и т.д., по максимому соблюдая инкапсуляцию. И обязательно оставляются комментарии.
В дальнейшем (после выкладывания очередного релиза) этот код обязательно переписывается по-человечески.
Это верно, но только требует много денег на хороших девелоперов, а их может и не быть.
Воспитывайте сами в таком случае. В любом более-менее крупном городе хотя бы один технический ВУЗ да есть. Найдите себе студента поприличнее, и пусть он растёт вместе с вашим проектом.
Но ради Бога, ради нашей профессии и уважения к пользователям и вашим будущим сотрудникам, не нанимайте на работу «шваль от программирования» осознанно!
Но ради Бога, ради нашей профессии и уважения к пользователям и вашим будущим сотрудникам, не нанимайте на работу «шваль от программирования» осознанно!
есть целая индустрия говнокодинга, и для них этот тезис не совсем справделив.
я лично наблюдал студию веб-дизайна, в которой только 1 человек приблизительно знал, как работает HTML. Я был вторым, но быстро сбежал ;) Исполнители, работающие за три копеечки, серая бухгалтерия, дешевые сайты по демпинговым ценам. Несмотря на это, они делали как минимум несколько сайтов в день и гребли бабло лопатой.
я лично наблюдал студию веб-дизайна, в которой только 1 человек приблизительно знал, как работает HTML. Я был вторым, но быстро сбежал ;) Исполнители, работающие за три копеечки, серая бухгалтерия, дешевые сайты по демпинговым ценам. Несмотря на это, они делали как минимум несколько сайтов в день и гребли бабло лопатой.
Дело даже не в сообразно-несообразно, бывает так, что в самом начале и проектировать-то, вроде, нечего — запрашивается тривиальная маленькая временная утилитка. А потом вдруг оказывается, что она каким-то образом превратилась в важнейший инструмент…
У меня был такой случай. Меня попросили написать ма-а-аленький инструментик, буквально страничку для ввода данных с тремя-четырьмя полями, и скриптик, который эти поля определённым образом запишет в файлик. При этом объяснили, что пользоваться скриптом будет один, ну максимум два человека, и что вообще всё это временно, пока этот функционал не будет включён в другой инструмент.
Потом попросили добавить ещё два маленьких поля… потом появилась маленькая развилочка в логике… Притом всё это всегда происходило в режиме «быстренько-быстренько, не отвлекайся от своего основного проекта, это всё временно». Мда…
В общем, через примерно год я вдруг обнаружил, что:
— Инструментом пользуются — и очень активно — человек 10.
— Они, оказываются. воспринимают эту временную залепуху как один из основных инструментов.
— Никто и не думает включать эту функциональность ни в какой другой инструмент;
— Временный код разбух и превратился в чёрт знает что, а времени на переписывание и приведение в приличный вид никто давать не хочет.
Я, конечно, сам виноват — не уследил. Но и до сих пор я не понимаю до конца — в какой именно момент надо было остановиться, упереться рогом и всё переделать? И как было в необходимости этого убедить начальство?..
У меня был такой случай. Меня попросили написать ма-а-аленький инструментик, буквально страничку для ввода данных с тремя-четырьмя полями, и скриптик, который эти поля определённым образом запишет в файлик. При этом объяснили, что пользоваться скриптом будет один, ну максимум два человека, и что вообще всё это временно, пока этот функционал не будет включён в другой инструмент.
Потом попросили добавить ещё два маленьких поля… потом появилась маленькая развилочка в логике… Притом всё это всегда происходило в режиме «быстренько-быстренько, не отвлекайся от своего основного проекта, это всё временно». Мда…
В общем, через примерно год я вдруг обнаружил, что:
— Инструментом пользуются — и очень активно — человек 10.
— Они, оказываются. воспринимают эту временную залепуху как один из основных инструментов.
— Никто и не думает включать эту функциональность ни в какой другой инструмент;
— Временный код разбух и превратился в чёрт знает что, а времени на переписывание и приведение в приличный вид никто давать не хочет.
Я, конечно, сам виноват — не уследил. Но и до сих пор я не понимаю до конца — в какой именно момент надо было остановиться, упереться рогом и всё переделать? И как было в необходимости этого убедить начальство?..
В общем и целом — согласен. Но тут ключевое слово с его точки зрения.
Пример из жизни: есть у вас проект с картой и отмеченными на ней «булавками». Заказчик говорит — а пусть теперь близкие объекты при отдалении карты группируются. С его точки зрения — сущая мелочь. А мы (как раз, руководствуясь этим самым YAGNI) вообще не предусмотрели возможности группировки нескольких объектов на карте. Нужен рефакторинг. Если спека не «прекрывает зад», то приходится всё делать «за свой счёт», соответственно, торопиться и экономить. В результате — пластилин.
Пример из жизни: есть у вас проект с картой и отмеченными на ней «булавками». Заказчик говорит — а пусть теперь близкие объекты при отдалении карты группируются. С его точки зрения — сущая мелочь. А мы (как раз, руководствуясь этим самым YAGNI) вообще не предусмотрели возможности группировки нескольких объектов на карте. Нужен рефакторинг. Если спека не «прекрывает зад», то приходится всё делать «за свой счёт», соответственно, торопиться и экономить. В результате — пластилин.
В аджайле хорошие отношения между заказчиком и исполнителем, а самое главное, доверие заказчика к исполнителю являются одним из важных факторов успеха проекта. В случае с «плохим» заказчиком, вполне возможно, что подробное ТЗ и спецификации могут очень пригодиться при решении конфликтов, с этим спорить не буду.
«Маленькое» изменение с точки зрения заказчика != маленькое изменение с точки зрения исполнителя.
Спецификация тоже к сожалению не спасает.А бескомпромиссная позиция — часто оказывается ошибочной.
Что же нас может «спасти»?
1)Стремиться планирование проекта таким образом, чтобы самые важные функции были реализованы в первую очередь — если «в конце» проекта выяснится что сроки нельзя подвинуть по объективным причинам, а сделать «всё» не успели по любым причинам- продукт можно будет запуститься с неполной функциональностью, и доделать оставшееся после запуска.
2)Диалог и поиск компромисса. Новые «фичи» появляются всегда (заказчики могут быть идиотами, подрядчики могут быть идиотами, да и просто в предметной области произошли изменения — отсюда всегда появляются новые фичи). Если реализация этих фич требует значительных затрат — заказчик должен об этом знать и они должны оплачиваться.
Что же нас может «спасти»?
1)Стремиться планирование проекта таким образом, чтобы самые важные функции были реализованы в первую очередь — если «в конце» проекта выяснится что сроки нельзя подвинуть по объективным причинам, а сделать «всё» не успели по любым причинам- продукт можно будет запуститься с неполной функциональностью, и доделать оставшееся после запуска.
2)Диалог и поиск компромисса. Новые «фичи» появляются всегда (заказчики могут быть идиотами, подрядчики могут быть идиотами, да и просто в предметной области произошли изменения — отсюда всегда появляются новые фичи). Если реализация этих фич требует значительных затрат — заказчик должен об этом знать и они должны оплачиваться.
даже самое мелкое с его точки зрения изменение может потребовать большое количество времениСколько раз я слышал от заказчика нытье:
— «Я не понимаю, почему добавление такой маленькой функции требует столько человеко часов. Вы меня явно пытаетесь развести на деньги. Грузите какими то вашими умными терминами типа рефакториг, изменение связей в RDBMS...».
Нарисуйте ему примерную схему работы, но без технических терминов, поищите более понятные аналогии :-)
Часто работаю с проектно-строительными фирмами, помогает аналогия со зданиями: вот я закажу вам построить здание, согласуем ТЗ на проектирование, сделаете проект по всем ГОСТам и СНиПам, утвердим, дом уже почти построити, останется фактически только чистовая отделка, но тут я захочу пару окон ещё, внутреннюю капитальную стену передвинуть на полметра, подземный гараж и т. п. Неужели вы примите мой довод «внешне почти ничего не изменится» для выполнения этих работ за 5% от начальной сметы? Правда, может помогает, что всё-таки инженеры и знают что такое проект и смета, да ещё получше нас :)
Согласен. Именно аналогии и помогают их убедить.
А далее часто следует следующая хитовая фраза заказчика. «А почему вы меня заранее не предупредили что такое изменение будет сложным? Ведь вы же профессионал!».
(Т.е. я должен быть провидцем и телепатом.)
И самое смешное, про половину таких проблем я их как раз предупреждал, но тогда они не хотели вникать и слушать.
(разумеется такая беда происходит только небольшой частью заказчиков)
А далее часто следует следующая хитовая фраза заказчика. «А почему вы меня заранее не предупредили что такое изменение будет сложным? Ведь вы же профессионал!».
(Т.е. я должен быть провидцем и телепатом.)
И самое смешное, про половину таких проблем я их как раз предупреждал, но тогда они не хотели вникать и слушать.
(разумеется такая беда происходит только небольшой частью заказчиков)
Ну вы тоже не предупредили бы, что капитальную стену на полметра передвинуть сложно :)
Вот со стеной почему-то всем понятно.
А вот то что «маленькую кнопочку» иногда трудно добавить — не всегда верят. Она же маленькая! ))
А вот то что «маленькую кнопочку» иногда трудно добавить — не всегда верят. Она же маленькая! ))
Самое ужасное, когда в это не верит непосредственный начальник. С кнопочкой примера не припомню, но был случай с перестановкой колонок: правую налево, левую направо. И всё бы хорошо, если бы весь шаблон не был свёрстан (не мной, конечно) под неправильный, а значит неработающий доктайп, и не рассыпался при малейшем изменении. Кстати, особенно ужаснуло, что этот шаблон коммерческий, его в России, вроде, довольно активно продают.
Не знаю, где первоисточник этой байки, про «Вы же профессионал» поэтому ссылкой на поиск яндекса)) Но это описывает многих заказчиков, а многим дает понять, что они хотят невозможного :) yandex.ru/yandsearch?text=%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D1%83%D0%B9%D1%82%D0%B5+%D0%BA%D1%80%D0%B0%D1%81%D1%81%D0%BD%D1%8B%D0%B5+%D0%BB%D0%B8%D0%BD%D0%B8%D0%B8+%D0%B2%D1%8B+%D0%B6%D0%B5+%D0%BF%D1%80%D0%BE%D1%84%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB&clid=139040&yasoft=chrome&lr=20243
Как интересно. Я, к примеру, когда ищу этот текст, использую запрос «семь красных перпендикулярных линий». Ваш запрос — «нарисуйте красные линии вы же профессионал».
P.S. Хотя авторское название — «Совещание» alex-aka-jj.livejournal.com/66984.html
P.P.S. Экранизация:
The Expert (Short Comedy Sketch) (RUS SUB) www.youtube.com/watch?v=BKorP55Aqvg
The Expert (Русский дубляж) www.youtube.com/watch?v=UoKlKx-3FcA
P.P.P.S. И, собственно, само решение (все требуемые цвета, включая прозрачный, тотальная перпендикулярность, и одна линия в форме котёнка): D. Scott Williamson, Expert (RUS SUB) www.youtube.com/watch?v=B7MIJP90biM
P.S. Хотя авторское название — «Совещание» alex-aka-jj.livejournal.com/66984.html
P.P.S. Экранизация:
The Expert (Short Comedy Sketch) (RUS SUB) www.youtube.com/watch?v=BKorP55Aqvg
The Expert (Русский дубляж) www.youtube.com/watch?v=UoKlKx-3FcA
P.P.P.S. И, собственно, само решение (все требуемые цвета, включая прозрачный, тотальная перпендикулярность, и одна линия в форме котёнка): D. Scott Williamson, Expert (RUS SUB) www.youtube.com/watch?v=B7MIJP90biM
НЛО прилетело и опубликовало эту надпись здесь
Гораздо хуже, когда заказчик=руководитель. Тогда имеем ситуацию, когда вечером на разрабов орут «чо так долго», а утром — «я тут подумал/мне приснилось, надо еще вот это и это добавить, а это убрать».
И так день за днем. В итоге такие монстры выползают чудесные!
И так день за днем. В итоге такие монстры выползают чудесные!
Тут есть одна особенность: сроки проекта — отвественность ПМа, а новые фичи — менеджера по продукту. Поэтому сначала надо договориться им. Особенно, если это один человек :).
А вообще — ещё со времён работы на custom development у меня выработалось чёткое правило: во ВСЕХ ошибках проекта виноват руководитель. Поэтому презираю тех руководителей, которые орут на программистов. Эти люди пытаются свои ошибки и ответственность (за неправильные оценки, неправильную работу с командой, неправильную постановку задач) перевалить на плечи программистов, которые и так страдают от всего вышепересичленного.
А вообще — ещё со времён работы на custom development у меня выработалось чёткое правило: во ВСЕХ ошибках проекта виноват руководитель. Поэтому презираю тех руководителей, которые орут на программистов. Эти люди пытаются свои ошибки и ответственность (за неправильные оценки, неправильную работу с командой, неправильную постановку задач) перевалить на плечи программистов, которые и так страдают от всего вышепересичленного.
Интересно, ответ плюсуют только программисты, имея в виду своих руководителей? :)
прикольно, когда руководителя просто нет. Есть заказчик (начальник), который выдает абстрактный заказ группе своих подчиненных, а как уж они будут это делать — не важно. Но результат будет спрашивать часто и со всех сразу. Правда, я таких «начальников» видел в основном на продажах, а не на программировании ;)
«Гораздо хуже, когда заказчик=руководитель»
Вы ведь привели пример не просто когда заказчик = руководитель, а когда руководитель — (мягко говоря) плохой руководитель. Орет на программистов, не знает чего хочет, не понимает, что делает и т.д.
Вот у меня сейчас ситуация: проект — игра, делалась кучей разных людей в разное время, довольно посредственный код, как раз таки «пластилин», но приносит деньги и ее нужно поддерживать, развивать и выводить на другие платформы (образно говоря). Руководитель = заказчик, при этом когда он говорит «я тут подумал/мне приснилось, надо еще вот это и это добавить, а это убрать», я думаю и говорю — «такая-то часть будет запарной потому-то и потому-то, а такую-то часть прикрутим без проблем», он тоже думает, и если фича позарез нужна, то он знает, что это займет время, и почему. И в общем все довольны, все хорошо. Так что непосредственно в том, что «заказчик=руководитель» не вижу ничего плохого, главное чтобы люди были адекватные и думающие.
Вы ведь привели пример не просто когда заказчик = руководитель, а когда руководитель — (мягко говоря) плохой руководитель. Орет на программистов, не знает чего хочет, не понимает, что делает и т.д.
Вот у меня сейчас ситуация: проект — игра, делалась кучей разных людей в разное время, довольно посредственный код, как раз таки «пластилин», но приносит деньги и ее нужно поддерживать, развивать и выводить на другие платформы (образно говоря). Руководитель = заказчик, при этом когда он говорит «я тут подумал/мне приснилось, надо еще вот это и это добавить, а это убрать», я думаю и говорю — «такая-то часть будет запарной потому-то и потому-то, а такую-то часть прикрутим без проблем», он тоже думает, и если фича позарез нужна, то он знает, что это займет время, и почему. И в общем все довольны, все хорошо. Так что непосредственно в том, что «заказчик=руководитель» не вижу ничего плохого, главное чтобы люди были адекватные и думающие.
Более того, по-моему, «заказчик=руководитель» при прочих равных лучше для проекта в целом, т. к. задача у исполнителя и заказчика по сути одна. В теории, по крайней мере. Когда заказчик внешний, то для исполнителя главное сдать работу, чтобы заказчик был доволен; когда внутренний — чтобы проект был успешным.
>Не начинайте писать код, не продумав архитектуру, если вы — программист.
Иной раз ТЗ так сформулировано, что придумывать особо нечего. То есть работа изначально предполагается итеративной, девиз: «запустим маленький кусочек (фактически прототип), а дальше будем собирать фидбэки, реализовывать фичерквесты, править баги и оптимизировать ресурсы». Продумывать расширяемую архитектуру, не зная что может понадобиться расширить, сродни преждевременной оптимизации: 80% продуманной (и реализованной)расширяемости не будет использоваться (типичный пример DBAL), а 80% необходимых фич во вроде бы продуманную архитектуру всё равно не впишется и либо придётся её менять, либо лепить «пластилин» (понравилось выражение, респект :) ). В таких случаях, по-моему, лучше реализовывать только то, что надо здесь и сейчас, меняя архитектуру только когда или новая фича не вписывается в существующую, или без её смены нарушаются принципы DRY, KISS, SOLID и т. п. ( и то, не слишком увлекаясь)
Конечно, гибкость и расширяемость нужно иметь в виду, но только иметь, а не реализовывать пока, и если не понадобится.
Иной раз ТЗ так сформулировано, что придумывать особо нечего. То есть работа изначально предполагается итеративной, девиз: «запустим маленький кусочек (фактически прототип), а дальше будем собирать фидбэки, реализовывать фичерквесты, править баги и оптимизировать ресурсы». Продумывать расширяемую архитектуру, не зная что может понадобиться расширить, сродни преждевременной оптимизации: 80% продуманной (и реализованной)расширяемости не будет использоваться (типичный пример DBAL), а 80% необходимых фич во вроде бы продуманную архитектуру всё равно не впишется и либо придётся её менять, либо лепить «пластилин» (понравилось выражение, респект :) ). В таких случаях, по-моему, лучше реализовывать только то, что надо здесь и сейчас, меняя архитектуру только когда или новая фича не вписывается в существующую, или без её смены нарушаются принципы DRY, KISS, SOLID и т. п. ( и то, не слишком увлекаясь)
Конечно, гибкость и расширяемость нужно иметь в виду, но только иметь, а не реализовывать пока, и если не понадобится.
Прототип — он всегда «пластилиновый» по своей сути.
Но! Первое правило прототипирования — «выкинуть всё после подтверждения теории, которую проверяем или демонстрации заказчику». Это многие серьёзные люди говорят (Брукс, например).
К сожалению, это настолько «больно» — выкинуть «почти готовую систему», что я не видел практически ни одного руководителя, который бы не попытался сделать из прототипа рабочий проект.
Я ни в коем случае не говорю в топике про гибкость и расширяемость. Я говорю про возможность развития и поддержки продукта, не более.
Но! Первое правило прототипирования — «выкинуть всё после подтверждения теории, которую проверяем или демонстрации заказчику». Это многие серьёзные люди говорят (Брукс, например).
К сожалению, это настолько «больно» — выкинуть «почти готовую систему», что я не видел практически ни одного руководителя, который бы не попытался сделать из прототипа рабочий проект.
Я ни в коем случае не говорю в топике про гибкость и расширяемость. Я говорю про возможность развития и поддержки продукта, не более.
Чтобы не было так больно выкидывать прототип можно его писать на языке или использовать технологии, которые явно не могут пойти в релиз, где-то видел такие рекомендации :) Я в веб-проектах начал для этого использовать GAE+Django, а релиз на PHP, правда пару раз «пришлось» так и оставить по просьбе заказчика.
«Развитие» и «гибкость и расширяемость» для меня практически синонимы, ведь развитие это чаще всего либо замена фич (гибкость), либо их добавление (расширяемость). Где я ошибаюсь?
«Развитие» и «гибкость и расширяемость» для меня практически синонимы, ведь развитие это чаще всего либо замена фич (гибкость), либо их добавление (расширяемость). Где я ошибаюсь?
Ещё можно делать прототип с отвратительным дизайном, сразу видно, что прототип.
Ты так говоришь, будто «GAE+Django» — что-то плохое :))
По сравнению со своим сервером во многом да :) Тем более нигде не могу найти юридическое обоснование (не)законности его использования с территории России для хранения и обработки ПДн. Такое ощущение, что нормативных актов для трансграничной передачи ПДн ещё не выработали. Одни говорят, что нужен серфикат на соответствие и самого GAE и приложения,, другие — что только приложения, третьи — что ничего не нужно.
А у нас такой проблемы не нет.
В том смысле, что нам не нужны «хорошие спецификации» и «жесткие позиции». Ни дизайнер, ни руководитель, ни клиент, ни какой-либо еще человек не может изначально определить все спецификации на месяцы работы вперед. В процессе работы всегда ясно, как сделать что-то лучше.
Мы так и пишем код — чтобы было легко изменить то, как все работает. Потому что мы не защищаемся от улучшений, а применяем их при каждом удобном случае.
За последние полгода так точно ни одно изменение не заставало нас врасплох. И вам того же желаем — любите изменения, а не бегайте от них. Улучшайте проект, а не выполняйте спецификации или избавляйтесь от тудушек.
В том смысле, что нам не нужны «хорошие спецификации» и «жесткие позиции». Ни дизайнер, ни руководитель, ни клиент, ни какой-либо еще человек не может изначально определить все спецификации на месяцы работы вперед. В процессе работы всегда ясно, как сделать что-то лучше.
Мы так и пишем код — чтобы было легко изменить то, как все работает. Потому что мы не защищаемся от улучшений, а применяем их при каждом удобном случае.
За последние полгода так точно ни одно изменение не заставало нас врасплох. И вам того же желаем — любите изменения, а не бегайте от них. Улучшайте проект, а не выполняйте спецификации или избавляйтесь от тудушек.
Великолепно!
Могу поспорить, что на то, чтобы «так и писать код — чтобы было легко изменить то, как все работает» вы тратите достаточно мыслительных ресурсов :). Это же и есть главная мысль моей статьи: надо думать.
Вероятно, она скрылась за
Больше чем уверен, что ваша архитектура совершенно не напоминает комок пластелина.
Могу поспорить, что на то, чтобы «так и писать код — чтобы было легко изменить то, как все работает» вы тратите достаточно мыслительных ресурсов :). Это же и есть главная мысль моей статьи: надо думать.
Вероятно, она скрылась за
Больше чем уверен, что ваша архитектура совершенно не напоминает комок пластелина.
Очень хорошо написали. Проблема в том, что отрасль позволяет. Черный ящик с фичами и ладненько. Нет снипов, гостов и тому подобных вещей, через которые бы заставляли прогонять получившийся продукт. Стандарты, практики, методики есть, но они для команды разработки. На выходе все тот же черный ящик…
Почему это ГОСТ-ов нет?
А СНИП — это из другой оперы.
Не смотря на всякие угрозы, я наслаждаюсь дефицитом бюрократии и всяких лютых норм при кодинге, как бы внутренних норм и ограничений среды хватает.
Да, есть большие риски получить говно, но при этом несколько методик и здравый смысл творят чудеса.
А СНИП — это из другой оперы.
Не смотря на всякие угрозы, я наслаждаюсь дефицитом бюрократии и всяких лютых норм при кодинге, как бы внутренних норм и ограничений среды хватает.
Да, есть большие риски получить говно, но при этом несколько методик и здравый смысл творят чудеса.
В мире креативно-художественного рисования красками по холсту всякий трэш к потребителям искусства не пускают критики.
К сожалению (или к счастью, учитывая желание любого человека быть фрилансером и заниматься интересной работой) программирование пока имеет больше общего с рисованием красками по холсту, чем с вытачиванием миллиардов чушек формы X на токарном станке Y под надзором злобного бригадира Z.
Учитывая разнообразие кистей, холстов, стилей и методов рисования — всеобъемлющие ГОСТы и прочую нормативную документацию написать для отрасли нереально. Более того, бессмысленно, потому что инструменты здесь стареют быстрее их создателей.
Выход один — выращивать адекватных менеджеров проектов, брать на работу хороших разработчиков, обеспечивать качество решений регулярным аудитом и не жать единицы человекочасов для решения проблем, чреватых человекогодами.
К сожалению (или к счастью, учитывая желание любого человека быть фрилансером и заниматься интересной работой) программирование пока имеет больше общего с рисованием красками по холсту, чем с вытачиванием миллиардов чушек формы X на токарном станке Y под надзором злобного бригадира Z.
Учитывая разнообразие кистей, холстов, стилей и методов рисования — всеобъемлющие ГОСТы и прочую нормативную документацию написать для отрасли нереально. Более того, бессмысленно, потому что инструменты здесь стареют быстрее их создателей.
Выход один — выращивать адекватных менеджеров проектов, брать на работу хороших разработчиков, обеспечивать качество решений регулярным аудитом и не жать единицы человекочасов для решения проблем, чреватых человекогодами.
Еще, нужно почаще показывать промежуточные результаты заказчикам и побольше с ними общаться. И, может быть, стремиться в первую очередь сделать то, что в спецификации вызывает больше всего вопросов, может прототипчик какой-нибудь сделать… Мда, мечты, короче.
Есть такие заказчики, которым лучше не показывать промежуточные результаты. Иначе после каждого показа у них будут появляться «гениальные идеи», добавляющие кучу пластелина. Причем оплачивать этот пластилин они откажутся.
Таким лучше сразу отдать готовый проект, полностью соответствующий ТЗ и все. А потом заключить отдельный договор, на создание следующей версии.
Естественно это касается только небольших проектов, и особого вида заказчиков, которых надо научиться распознавать.
Таким лучше сразу отдать готовый проект, полностью соответствующий ТЗ и все. А потом заключить отдельный договор, на создание следующей версии.
Естественно это касается только небольших проектов, и особого вида заказчиков, которых надо научиться распознавать.
Практически во всех гибких методологиях:
— нет разработчика, отвечающего за архитектуру;
— нет инспекции кода;
— нет спецификаций;
— архитектура не продумывается заранее;
— нет специализации у участников команды.
При этом гибкие методологии отлично работают и вытесняют «классические». Так что все данные советы как минимум сомнительные.
— нет разработчика, отвечающего за архитектуру;
— нет инспекции кода;
— нет спецификаций;
— архитектура не продумывается заранее;
— нет специализации у участников команды.
При этом гибкие методологии отлично работают и вытесняют «классические». Так что все данные советы как минимум сомнительные.
— нет разработчика, отвечающего за архитектуру;
она создается совместными усилиями
— нет инспекции кода;
еще как есть. Открытое взаимодействие — один из базовых принципов agile-концепции
— нет спецификаций;
Зато agile предполагает постоянное общение с заказчиком
— архитектура не продумывается заранее;
Но тем не менее она продумывается. По ходу разработки. По кусочкам.
она создается совместными усилиями
— нет инспекции кода;
еще как есть. Открытое взаимодействие — один из базовых принципов agile-концепции
— нет спецификаций;
Зато agile предполагает постоянное общение с заказчиком
— архитектура не продумывается заранее;
Но тем не менее она продумывается. По ходу разработки. По кусочкам.
>Но тем не менее она продумывается. По ходу разработки. По кусочкам.
Как по мне так к процессу формирования архитектуры при некоторых agile-методиках сложно применить слово «продумывается», пускай и по кусочкам. Она просто получается хорошей в процессе рефакторинга, если разумно следовать методикам и принципам и, что немаловажно, в тоже время не получается избыточной.
Как по мне так к процессу формирования архитектуры при некоторых agile-методиках сложно применить слово «продумывается», пускай и по кусочкам. Она просто получается хорошей в процессе рефакторинга, если разумно следовать методикам и принципам и, что немаловажно, в тоже время не получается избыточной.
Ну почему же… Спорные моменты всегда возникают и приходится обсуждать их, а обсуждение спорных моментов, связанных с архитектурой — это ли не продумывание ее по сути?
Можно и так сказать, но я имел в виду, что в процессе решения конкретных проблем («как нам протестировать вот это поведение модели, не обращаясь к реальной СУБД») хорошая архитектура вырисовывается «сама», специально о ней никто не думает, а потом с удивлением видят, что получилась реализация того или иного паттерна :)
Обсуждения дольше 10 минут обычно заканчиваются фразой show me the code, и все возвращается к тому, что удачно описал VolCh :)
Вы меня поправить пытаетесь или дополняете? :) Если последнее, то все написанное верно. Единственное, я бы в качестве альтернативы инспекции называл бы коллективное владение кодом и частично практику парного программирование.
Сколько я не видел реализаций Agile со всякими Скрамами в этой стране (понятно, что большинство из них ещё и пропитано нездоровым фанатизмом заимствования), в том числе и со стороны девелоперов — хочется плакать от рабочего процесса и получающихся в результате выкидышей.
Да, архитектура создаётся хайв-майндом в режиме on-demand. Но её каркас вместо изящной конструкции параллельных линий выглядит, как комок связанных друг с другом палок. Местами параллельных, но, в общей массе, — хаотично налепленных.
Да, инспекция кода есть. Но за отчётами, встречами, обсуждениями, она превращается в тупую выдачу ЦУ и крики «Говнокод, говнокод»! Без оглядок на критичность участка, значимость для архитектуры, оптимизацию под скорость и прочие вещи. А, учитывая суперэго каждого участника процесса (особенно «хороших», антикомандных суперпрограммистов) этот балаган может только ухудшать качество кода, когда ситуация начинает пахнуть конфликтом. Российское женское антиконфликтное воспитание, уж простите.
Постоянное общение с заказчиками, к сожалению, тоже не способствует ликвидации аморфности структуры. Потому что заказчик в этой стране, несмотря на жонглирование терминами «ТЗ», «ТУ», «Документация» сам не знает (в подавляющем большинстве случаев), что ему нужно. И аджайл, в силу прибойной и стихийной природы процесса, а, также, что-то-ориентированности, не сильно помогает ловить целостную картину. «Давай доделаем фичу, покажем, а там порефакторим. Если время останется...».
В общем и целом — аджайл хорош для выдачи прототипа, для работы над модулями-в-себе хорошо продуманной модульной системы, или для генерации типовых решений на отлаженной платформе. А разрабатывать с помощью этих методологий хороший софт… Ну вы поняли.
Да, архитектура создаётся хайв-майндом в режиме on-demand. Но её каркас вместо изящной конструкции параллельных линий выглядит, как комок связанных друг с другом палок. Местами параллельных, но, в общей массе, — хаотично налепленных.
Да, инспекция кода есть. Но за отчётами, встречами, обсуждениями, она превращается в тупую выдачу ЦУ и крики «Говнокод, говнокод»! Без оглядок на критичность участка, значимость для архитектуры, оптимизацию под скорость и прочие вещи. А, учитывая суперэго каждого участника процесса (особенно «хороших», антикомандных суперпрограммистов) этот балаган может только ухудшать качество кода, когда ситуация начинает пахнуть конфликтом. Российское женское антиконфликтное воспитание, уж простите.
Постоянное общение с заказчиками, к сожалению, тоже не способствует ликвидации аморфности структуры. Потому что заказчик в этой стране, несмотря на жонглирование терминами «ТЗ», «ТУ», «Документация» сам не знает (в подавляющем большинстве случаев), что ему нужно. И аджайл, в силу прибойной и стихийной природы процесса, а, также, что-то-ориентированности, не сильно помогает ловить целостную картину. «Давай доделаем фичу, покажем, а там порефакторим. Если время останется...».
В общем и целом — аджайл хорош для выдачи прототипа, для работы над модулями-в-себе хорошо продуманной модульной системы, или для генерации типовых решений на отлаженной платформе. А разрабатывать с помощью этих методологий хороший софт… Ну вы поняли.
мне кажется, вы тут какой то свой конкретный неудачный опыт вспоминаете. there is no silver bullet и аджайл, конечно, не панацея. и да, суперпрограммисты-примадонны часто тянут одеяло на себя и тормозят процесс.
1. любой процесс — и аджайл и вотерфолл требуют адекватных людей в команде. их надо тщательно подбирать, растить, и с ними надо дружить. с суперпрограммистами особенно. работу с людьми в проекте никто не отменял, тут никакой процесс ничего сделать не может
2. инспекция кода = code review? зачем отчеты-встречи-обсуждения? это как раз бывает в команде, где нет взаимоуважения, когда вместо того, чтобы думать как лучше и качественнее сделать систему, люди тянут одеяло на себя, выпускают свое раздутое эго погулять.
уже несколько лет у нас в проектах коде ревью выглядит так — человек закончил кодить таску, завел таску на коде ревью на другого человека, тот посмотрел ченжи, написал письмо с мыслями-замечаниями-предложениями с копией на всех, автор поправил, или, в случае, когда несогласен, пришел-поговорил. если вопрос спорный, привлекается лид. паралелльно хорошей практикой стал ежедневный коде ревью всех ченжей, сделанных в проекте, лидом.
я к тому, что не должно быть большой бюрократии по поводу коде ревью, он должен быть простой и быстрый, иначе очень быстро сойдет на нет.
3. а зачем вам целостная картина? задача любого процесса реализовывать пожелания заказчика. и это очень трудно — сразу сходу описать готовую систему, человеческий мозг сам по себе так устроен, детали появляются только по ходу дела, а лучше всего — когда уже видишь что-то работающее. редко бывают заказчики — по совместительству тех райтеры.
для того-то xp, потом переименованный в эджайл, чтобы заказчики не пугались, и был создан, чтобы быстро и легко реагировать на изменения. просто ситуация типа «Давай доделаем фичу, покажем, а там порефакторим. Если время останется...» — совсем не аджайл, а типичный ватерфолл. в аджайле было бы так — «давайте напишем тест, отрефакторим, доделаем фичу и покажем, оцени таски и вышли заказчику наш эстимейт»
вообще один из главных принципов в таком процессе — самоорганизация процесса. по ходу работы те вещи, практики, которые мешают делать качественный продукт, должны отбрасываться (всякие ненужные митинги и излишние обсуждения) а новые подходы — включаться в процесс.
вот хрен знает, какой у нас процесс. если заказывается большая фича, требующая глубокого понимания бизнес области, пишется спека, по ней забиваются таски, если просто есть куча требований — просто забиваются таски. таски бьем на подтаски не больше дня. зная свой велосити (у нас примерно 4 идеальных часа на день) и обьем команды, забиваем спринт тасками на две недели. и побежали. каждое утро на скраме говорим какие таски закрыли вчера, над какими будем работать сегодня.
в конце спринта выкладываем результат на дев энвайромент, показываем заказчику. когда все таски из релиза сделаны несколькими спринтами, пакуем, делаем релиз нотес и отдаем команде UAT, подключаем тестировщиков. Они формально прогоняют наши тесты (кавередж 70 процентов), проводят еще свое тестирование, грузят систему перфоманс тестами, подписывают релиз.
тут и не ватерфолл и не эджайл, а что то между. но Deutsche Bank, в котором я работаю, по крайней мере мой департамент, потихоньку переходит на такой процесс.
1. любой процесс — и аджайл и вотерфолл требуют адекватных людей в команде. их надо тщательно подбирать, растить, и с ними надо дружить. с суперпрограммистами особенно. работу с людьми в проекте никто не отменял, тут никакой процесс ничего сделать не может
2. инспекция кода = code review? зачем отчеты-встречи-обсуждения? это как раз бывает в команде, где нет взаимоуважения, когда вместо того, чтобы думать как лучше и качественнее сделать систему, люди тянут одеяло на себя, выпускают свое раздутое эго погулять.
уже несколько лет у нас в проектах коде ревью выглядит так — человек закончил кодить таску, завел таску на коде ревью на другого человека, тот посмотрел ченжи, написал письмо с мыслями-замечаниями-предложениями с копией на всех, автор поправил, или, в случае, когда несогласен, пришел-поговорил. если вопрос спорный, привлекается лид. паралелльно хорошей практикой стал ежедневный коде ревью всех ченжей, сделанных в проекте, лидом.
я к тому, что не должно быть большой бюрократии по поводу коде ревью, он должен быть простой и быстрый, иначе очень быстро сойдет на нет.
3. а зачем вам целостная картина? задача любого процесса реализовывать пожелания заказчика. и это очень трудно — сразу сходу описать готовую систему, человеческий мозг сам по себе так устроен, детали появляются только по ходу дела, а лучше всего — когда уже видишь что-то работающее. редко бывают заказчики — по совместительству тех райтеры.
для того-то xp, потом переименованный в эджайл, чтобы заказчики не пугались, и был создан, чтобы быстро и легко реагировать на изменения. просто ситуация типа «Давай доделаем фичу, покажем, а там порефакторим. Если время останется...» — совсем не аджайл, а типичный ватерфолл. в аджайле было бы так — «давайте напишем тест, отрефакторим, доделаем фичу и покажем, оцени таски и вышли заказчику наш эстимейт»
вообще один из главных принципов в таком процессе — самоорганизация процесса. по ходу работы те вещи, практики, которые мешают делать качественный продукт, должны отбрасываться (всякие ненужные митинги и излишние обсуждения) а новые подходы — включаться в процесс.
вот хрен знает, какой у нас процесс. если заказывается большая фича, требующая глубокого понимания бизнес области, пишется спека, по ней забиваются таски, если просто есть куча требований — просто забиваются таски. таски бьем на подтаски не больше дня. зная свой велосити (у нас примерно 4 идеальных часа на день) и обьем команды, забиваем спринт тасками на две недели. и побежали. каждое утро на скраме говорим какие таски закрыли вчера, над какими будем работать сегодня.
в конце спринта выкладываем результат на дев энвайромент, показываем заказчику. когда все таски из релиза сделаны несколькими спринтами, пакуем, делаем релиз нотес и отдаем команде UAT, подключаем тестировщиков. Они формально прогоняют наши тесты (кавередж 70 процентов), проводят еще свое тестирование, грузят систему перфоманс тестами, подписывают релиз.
тут и не ватерфолл и не эджайл, а что то между. но Deutsche Bank, в котором я работаю, по крайней мере мой департамент, потихоньку переходит на такой процесс.
У меня с аджайлом был, наоборот, только удачный опыт. Но нервов оно высосало столько, что этот опыт стал единичным.
1,2. Начнём с того, что суперпрограммисты для аджайла — зло. Потому что силы и время уходят на них, а не на решение проблем. Либо надо отдавать им на откуп то, что они делают, либо нещадно драть и всячески ущемлять эго (в хорошем смысле этих слов; надеюсь, вы его в них найдёте) для блага общего дела. Просто потому что это коллективный процесс. Хороший подбор персонала — первое больное место аджайла.
3. Продолжим тем, что целостная картина — это ключ к хорошему софту. Об этом и статья, по большому счёту. Вы сейчас сами себе противоречите, говоря, что для аджайла не нужна целостная картина — нет же, она нужна. Без неё не раскидать по спринтам фичи. Потому что получится редкостный однобокий уродец. Процессы процессами, модель разработки моделью разработки, но без проектирования архитектуры ничего не построить. Как показывает практика, любую (даже очень сложную) систему можно на 2/3 спрототипировать и подготовить к реализации на маркерной доске или в визио по вечерам. А уже потом наращивать на неё мясо согласно любой методологии краткосрочного планирования.
Видите, вы сами говорите про то, что у вас нет чистого аджайла. А ведь это не просто так — чистый академический аджайл неприменим там, где нужен реальный продукт с красивой, чистой и долгоиграющей (а в идеале — и с легко перестраиваемой) инфраструктурой. Он всё равно перерастёт либо в маразм, либо в test-driven спираль, квантованную по задачам, либо в серию задокументированных водопадов. Ну так вот получается с академическим творчеством на территории нанешней России :(
1,2. Начнём с того, что суперпрограммисты для аджайла — зло. Потому что силы и время уходят на них, а не на решение проблем. Либо надо отдавать им на откуп то, что они делают, либо нещадно драть и всячески ущемлять эго (в хорошем смысле этих слов; надеюсь, вы его в них найдёте) для блага общего дела. Просто потому что это коллективный процесс. Хороший подбор персонала — первое больное место аджайла.
3. Продолжим тем, что целостная картина — это ключ к хорошему софту. Об этом и статья, по большому счёту. Вы сейчас сами себе противоречите, говоря, что для аджайла не нужна целостная картина — нет же, она нужна. Без неё не раскидать по спринтам фичи. Потому что получится редкостный однобокий уродец. Процессы процессами, модель разработки моделью разработки, но без проектирования архитектуры ничего не построить. Как показывает практика, любую (даже очень сложную) систему можно на 2/3 спрототипировать и подготовить к реализации на маркерной доске или в визио по вечерам. А уже потом наращивать на неё мясо согласно любой методологии краткосрочного планирования.
Видите, вы сами говорите про то, что у вас нет чистого аджайла. А ведь это не просто так — чистый академический аджайл неприменим там, где нужен реальный продукт с красивой, чистой и долгоиграющей (а в идеале — и с легко перестраиваемой) инфраструктурой. Он всё равно перерастёт либо в маразм, либо в test-driven спираль, квантованную по задачам, либо в серию задокументированных водопадов. Ну так вот получается с академическим творчеством на территории нанешней России :(
а что такое чистый аджайл? в тот вся и соль, что его чистым не бывает, это просто набор принципов, которые можно соблюдать в любом процессе. парни просто сели и записали то, что любой адекватный разработчик и тех лид должны понимать и так
По вашей ссылке — почти коммунизм. А «чистый аджайл» — это то, что пытаются делать тимлиды по профильным книжкам.
Видите, я же тоже сужу субъективно — с чем сталкивался, про то и пою. А сталкивался с книгами, отзывами о реализации, одной приличной реализацией, в которой сам участвовал, и несколькими десятками не очень приличных, о которых мне рассказывали знакомые разработчики, друзья и просто хорошие люди.
Так что дальше бузить не буду — моя аджайл-карма скорее отрицательная, чем положительная. А это плохо сказывается на котятах, суждениях и мировой энтропии :)
Видите, я же тоже сужу субъективно — с чем сталкивался, про то и пою. А сталкивался с книгами, отзывами о реализации, одной приличной реализацией, в которой сам участвовал, и несколькими десятками не очень приличных, о которых мне рассказывали знакомые разработчики, друзья и просто хорошие люди.
Так что дальше бузить не буду — моя аджайл-карма скорее отрицательная, чем положительная. А это плохо сказывается на котятах, суждениях и мировой энтропии :)
Не нужно брать в команду людей с суперэго :) В любой гибкой методологии на первый план выходит команда: коллективное владение кодом, коллективная ответственность, ну и так далее. Слаженная команда способна разрабатывать качественный, подготовленный к изменениям, хорошо протестированный продукт.
Кстати, TDD дает наибольший профит как раз в системах со сложной бизнес-логикой, когда заранее спроектировать архитектуру просто нереально. Не знаю, из чего следует утверждение о прототипах и типовых решениях.
Кстати, TDD дает наибольший профит как раз в системах со сложной бизнес-логикой, когда заранее спроектировать архитектуру просто нереально. Не знаю, из чего следует утверждение о прототипах и типовых решениях.
Ну, во-первых, не всегда возможно полностью команду сформировать. Если такой возможности нет, и человек с «суперэго» уже в команде надо его приспособить к окружающим. Это долго, сложно, болезненно для вас и для него. Но, если подходить с умом, обязательно получится. В крайнем случае, всегда можно предложить расстаться по-хорошему.
Ну а про методологию… Я не люблю это слово. Как только мы говорим «методология», мы, обычно, перестаём замечать людей. Нет в мире ни одной методологии, которая увеличила бы производительность в IT. Это говорил ещё Брукс, это подтверждается исследованиями (максимальная отдача от внедрения методологии — около 35%, но, обычно — в районе 5%, данные Роберта Гласса, чтобы не быть голословным).
На мой взгляд, успешным проект делает не методология, а команда. И та методология хороша, которая помогает команде кристаллизоваться, вырасти профессионально и делать своё дело, не отвлекаясь на ненужные вещи.
Ну а про методологию… Я не люблю это слово. Как только мы говорим «методология», мы, обычно, перестаём замечать людей. Нет в мире ни одной методологии, которая увеличила бы производительность в IT. Это говорил ещё Брукс, это подтверждается исследованиями (максимальная отдача от внедрения методологии — около 35%, но, обычно — в районе 5%, данные Роберта Гласса, чтобы не быть голословным).
На мой взгляд, успешным проект делает не методология, а команда. И та методология хороша, которая помогает команде кристаллизоваться, вырасти профессионально и делать своё дело, не отвлекаясь на ненужные вещи.
С исследованиями не знаком (взял на заметку), поэтому прокомментировать не могу. Но могу смело утверждать, что мы сумели увеличить качество кода, уменьшить количество ошибок, и, как следствие, повысить производительность, в разы.
При этом путь мы прошли довольно тяжелый: пол года безуспешно пытались внедрить XP, затем, начав с чистого листа, стали использовать Scrum. И только после того, как почувствовали уверенность, стали постепенно добавлять инженерные практики из XP. В результате мы получили уникальную гибкую методологию, которая подходит именно для нашей команды.
> На мой взгляд, успешным проект делает не методология, а команда.
А на мой взгляд, хорошая методология позволяет максимально раскрыть потенциал любой команды. И гибкие методологии, как раз за счет своей гибкости и адаптивности, идеально для этого подходят. Это не противоречит сказанному вами, так что вполне можно утверждать, что методология + команда = успех проекта.
При этом путь мы прошли довольно тяжелый: пол года безуспешно пытались внедрить XP, затем, начав с чистого листа, стали использовать Scrum. И только после того, как почувствовали уверенность, стали постепенно добавлять инженерные практики из XP. В результате мы получили уникальную гибкую методологию, которая подходит именно для нашей команды.
> На мой взгляд, успешным проект делает не методология, а команда.
А на мой взгляд, хорошая методология позволяет максимально раскрыть потенциал любой команды. И гибкие методологии, как раз за счет своей гибкости и адаптивности, идеально для этого подходят. Это не противоречит сказанному вами, так что вполне можно утверждать, что методология + команда = успех проекта.
Tomcat уже всё разложил по полочкам (спасибо ему, кстати, за хороший пример с данными Гласса).
Утверждение о прототипах и типовых решениях — исключительно из обобщённого опыта. Извините, я, резко привёл — по поводу аджайла и встречи с ним я выше уже оговорился.
Утверждение о прототипах и типовых решениях — исключительно из обобщённого опыта. Извините, я, резко привёл — по поводу аджайла и встречи с ним я выше уже оговорился.
> Но её каркас вместо изящной конструкции параллельных линий выглядит, как комок связанных друг с другом палок.
если заказчик не платит отдельно за качественное прямое решение (= не выделяет время на рефакторинг), то с какой стати стараться вывозить это на себе забесплатно? Знал, что получится куча костылей, зааппрувил это — получает по полной программе. В полном соответствии с ;)
если заказчик не платит отдельно за качественное прямое решение (= не выделяет время на рефакторинг), то с какой стати стараться вывозить это на себе забесплатно? Знал, что получится куча костылей, зааппрувил это — получает по полной программе. В полном соответствии с ;)
Вы сами же в результате погрязнете в болоте своих костылей. И ничего дальше не сможете. В том числе не сможете исправить баги, которые являются критичными для проекта и без исправления которых заказчик вам просто не заплатит (и будет иметь на это полное право). И полностью сорвёте все сроки, пытаясь их исправить.
Я пытаюсь донести простую мысль — писать аккуратный код и продуманную архитектуру, прежде всего, в ваших интересах. Заказчику нужно только «чтобы работало». А если заказчик должен выделять время на рефакторинг в середине проекта — то это очень похоже на развод с вашей стороны: «мы вот что-то пописали, написали какашку — дай ещё денег поправить». Вы же, в конце концов, начальный скоуп сами оценивали!
Я пытаюсь донести простую мысль — писать аккуратный код и продуманную архитектуру, прежде всего, в ваших интересах. Заказчику нужно только «чтобы работало». А если заказчик должен выделять время на рефакторинг в середине проекта — то это очень похоже на развод с вашей стороны: «мы вот что-то пописали, написали какашку — дай ещё денег поправить». Вы же, в конце концов, начальный скоуп сами оценивали!
«Проект» — это такая штука, которая имеет начало и конец. Мы ответственны только за тот scope, который описан в договоре, и который мы гарантировали обеспечить, верно? Когда-нибудь этот scope закончится, как заканчивается всё в этом мире. Поэтому вот такого:
> не сможете исправить баги… полностью сорвёте все сроки,
не будет ;) Важно дожить до конца своего скопа а потом… потом он отправится к следующим индусам, как когда-то достался вам из чьих-то индусских рук.
но если заказчик хочет продолжения банкета — это новая сделка, новый договор, новый проект. В начале него можно обговорить что угодно, в том числе и рефакторинг. Не хочет — пусть следующую итерацию делает кто-то другой, баба с возу… Это рабочая схема, чо ;)
… комментарии к посту читаю с наслаждением :) Вы донесли мысль :)
> не сможете исправить баги… полностью сорвёте все сроки,
не будет ;) Важно дожить до конца своего скопа а потом… потом он отправится к следующим индусам, как когда-то достался вам из чьих-то индусских рук.
но если заказчик хочет продолжения банкета — это новая сделка, новый договор, новый проект. В начале него можно обговорить что угодно, в том числе и рефакторинг. Не хочет — пусть следующую итерацию делает кто-то другой, баба с возу… Это рабочая схема, чо ;)
… комментарии к посту читаю с наслаждением :) Вы донесли мысль :)
Не соглашусь. Может быть, мы разными вещами занимаемся, но у нас в компании не принято кидать заказчика так, как вы описали. Более того: мы заинтересованы, чтобы нашей работой он остался доволен и пришёл к нам с новым проектом (я сейчас говорю про custom development).
Да и сомнения большие, что вы с такими подходами смогли бы довести проект до конца. В любом случае, не хотел бы у вас что-то заказывать. Ничего личного :).
Да и сомнения большие, что вы с такими подходами смогли бы довести проект до конца. В любом случае, не хотел бы у вас что-то заказывать. Ничего личного :).
я про проекты, которые передаются аутсорсерам в состоянии «шеф, всё пропало!», и нужно оживить проект если не до состояния «скорее работает», то хотя бы «можем написать спеку, что имели в виду предыдущие разработчики». Постоянно аврал и паника: мы начали работать над проектом неделю назад, а заказчику-то результат был нужен два года назад! :) Поэтому часто разговор идет в том русле, что исполнители всегда виноватые. Объяснять про рефакторинг как про отдельную задачу приходилось часто, цитировать договор наизусть — тоже.
сейчас устроился в компанию, где люди работают над custom development в более мягкой обстановке. Приятно ;)
сейчас устроился в компанию, где люди работают над custom development в более мягкой обстановке. Приятно ;)
Сочувствую. Но есть опасность. Как известно, кто сражается с чудовищами, тому следует остерегаться, чтобы самому при этом не стать чудовищем.
Давайте не будем равняться на отстойный «индусский код» и сами уподобляться им не будем. Я всё таки говорю о профессиональном программировании :).
Решение о смене компании — единственное на мой взгляд правильное в данной ситуации.
Давайте не будем равняться на отстойный «индусский код» и сами уподобляться им не будем. Я всё таки говорю о профессиональном программировании :).
Решение о смене компании — единственное на мой взгляд правильное в данной ситуации.
Есть опыт в странных (для айтишника) областях типа продаж и организаторства. Таланта к программированию (по сравнению с теми живыми легендами, которые видишь каждый день) — нет, хотя понимание есть. Нет высшего образования,
В Гуголь и Майкрософт не возьмут из принципа, в ооо «артель „напрасный труд“ или зао „сайты за три копейки“ устраиваться самому обломно.
Предпринимательство пробовал — сложно, страшно, пока не справляюсь.
Оставшихся действительно интересных точек приложения силы — осталось не так много.
В Гуголь и Майкрософт не возьмут из принципа, в ооо «артель „напрасный труд“ или зао „сайты за три копейки“ устраиваться самому обломно.
Предпринимательство пробовал — сложно, страшно, пока не справляюсь.
Оставшихся действительно интересных точек приложения силы — осталось не так много.
Знаете, это высшая мера отсутствия самоуважения, уважения к другим людям и к любимому делу.
ок, заказчику представляется выбор: сделать хорошо за сумму N$, или сделать кое-как за сумму N/8$. Он выбирает второй вариант, тупо потому, что у него нету денег на первый. По-моему, это уважение к желанием заказчика… и море головной боли для себя ;)
Вообще говоря принципа «как платите, так и работаем» никто не отменял. Одно дело, когда вы выбираете с кем из заказчиков работать, когда из них очередь к вам стоит и они готовы оплачивать ваш труд повременно и совсем другое когда наоборот и вам надо чтобы заказчик выбрал вас из многих и оплачивать он готов только нужный ему на сегодня результат, а не простоту развития и поддержки в будущем.
К тому же перфекционизм (практически) бесконечен. В любом вроде бы готовом проекте можно что-то улучшить, что-то оптимизировать, убрать оверхид с излишне универсальных библиотек/фреймвоков, переписать его на ассемблере или С++ (я про веб) или наоборот, предусмотреть все теоретически возможные варианты развития до уровня «поставить галочку в админке». Но вот кто будет оплачивать пару человеко-лет на уменьшение времени генерации страницы сайта-визитки со 100 мс до 1 мс или то, что из этого же сайта-визитки можно сделать гугл (в смысле все его сервисы) только проставив галочки в админке?
Нужно искать вместе с заказчиком компромисс между трудоемкостью (а значит и ценой) и качеством (в широком смысле) кода. Я не имею в виду «кидок клиента», когда обещаешь ему, что код будет легкорасширяемый и гибкий под почти любые потребности, а сам гонишь спагетти и копипаст. Я про «за эти деньги я могу сделать эту функциональность, но вот если вы захотите её расширить или, скажем, масштабировать приложение горизонтально, то не исключено, что придётся переписывать всё заново.
К тому же перфекционизм (практически) бесконечен. В любом вроде бы готовом проекте можно что-то улучшить, что-то оптимизировать, убрать оверхид с излишне универсальных библиотек/фреймвоков, переписать его на ассемблере или С++ (я про веб) или наоборот, предусмотреть все теоретически возможные варианты развития до уровня «поставить галочку в админке». Но вот кто будет оплачивать пару человеко-лет на уменьшение времени генерации страницы сайта-визитки со 100 мс до 1 мс или то, что из этого же сайта-визитки можно сделать гугл (в смысле все его сервисы) только проставив галочки в админке?
Нужно искать вместе с заказчиком компромисс между трудоемкостью (а значит и ценой) и качеством (в широком смысле) кода. Я не имею в виду «кидок клиента», когда обещаешь ему, что код будет легкорасширяемый и гибкий под почти любые потребности, а сам гонишь спагетти и копипаст. Я про «за эти деньги я могу сделать эту функциональность, но вот если вы захотите её расширить или, скажем, масштабировать приложение горизонтально, то не исключено, что придётся переписывать всё заново.
Конечно, когда заказчик готов на что-то, и вполне понимает, чем ему грозит реализация — можно сказать «Угу, давай сделаем так, быстро, с применением самых низкооплачиваемых студентов и самых неотлаженных технологий». А если за те же деньги можно сделать не самый лучший продукт, но и не самое чёрное пятно на репутации?
У меня тут есть пример. Недавно (лет семь назад) одна контора сделала одному заводу один сайт. Сделала и сделала, но вместо приличной админки на продакшн выкатила старую и убогую по обоюдному согласию, потому что денег у заказчика на новую не было. Хотя деплоить новую и обслуживать было бы дешевле.
В этом году один завод задумался о интранет-решении с документооборотом, криптопровайдерами, видеонаблюдением и прочими вкусностями. К той конторе он больше не пошёл, несмотря на неоднократные предложения со стороны конторы.
Вот. Собственно, один пример недальновидной экономии на технологиях.
Выводы — если заказчик и исполнитель понимают, что потери в качестве обоснованы именно экономическим фактором, и понимают, чем это грозит в будущем — ок, можно заниматься. Если не понимают, или с одной из сторон какой-то шкурный интерес — эта экономия обязательно всплывёт, прямо или косвенно ударив по репутации исполнителя или заказчика.
У меня тут есть пример. Недавно (лет семь назад) одна контора сделала одному заводу один сайт. Сделала и сделала, но вместо приличной админки на продакшн выкатила старую и убогую по обоюдному согласию, потому что денег у заказчика на новую не было. Хотя деплоить новую и обслуживать было бы дешевле.
В этом году один завод задумался о интранет-решении с документооборотом, криптопровайдерами, видеонаблюдением и прочими вкусностями. К той конторе он больше не пошёл, несмотря на неоднократные предложения со стороны конторы.
Вот. Собственно, один пример недальновидной экономии на технологиях.
Выводы — если заказчик и исполнитель понимают, что потери в качестве обоснованы именно экономическим фактором, и понимают, чем это грозит в будущем — ок, можно заниматься. Если не понимают, или с одной из сторон какой-то шкурный интерес — эта экономия обязательно всплывёт, прямо или косвенно ударив по репутации исполнителя или заказчика.
То есть у них была какая-то новая админка и какая-то старая, а заводу предлагали их на выбор по сути как коробочные решение, по цене обусловленной функциональностью, а не трудоемкостью внедрения? Если да, то тут контора ССЗБ или не очень удачно пытается усидеть на двух стульях.
Я же про ситуации когда заказчик готов оплатить скажем только 1000 человеко-часов, хотя исполнитель считает, что хотя можно сделать и за 1000, но это будет «быдлокод» и нужно 1500, чтобы упростить дальнейшее развитие и поддержку. Можно пойти на компромисс: договориться с заказчиком об урезанном функционале, за 1000 часов реализовать нормально 2/3 изначального функционала, а затем, когда заказчик разбогатеет, доделать оставшуюся треть за 500, имея в виду что четвёртая треть (не предусмотренный заранее функционал) обойдётся заказчику в 500 часов (добавить функциональность, ничего из реализованного не переделывая, в общем 4/3 изначального функционала 2000 часов), а не в 1333 (переписать практически всё заново, т. к. новый функционал никак не прикручивается к «спагетти-коду», в общем 2333 часа).
Я же про ситуации когда заказчик готов оплатить скажем только 1000 человеко-часов, хотя исполнитель считает, что хотя можно сделать и за 1000, но это будет «быдлокод» и нужно 1500, чтобы упростить дальнейшее развитие и поддержку. Можно пойти на компромисс: договориться с заказчиком об урезанном функционале, за 1000 часов реализовать нормально 2/3 изначального функционала, а затем, когда заказчик разбогатеет, доделать оставшуюся треть за 500, имея в виду что четвёртая треть (не предусмотренный заранее функционал) обойдётся заказчику в 500 часов (добавить функциональность, ничего из реализованного не переделывая, в общем 4/3 изначального функционала 2000 часов), а не в 1333 (переписать практически всё заново, т. к. новый функционал никак не прикручивается к «спагетти-коду», в общем 2333 часа).
Да. За исключением того факта, что функциональность у них была примерно одинаковая, но качество реализации внутренностей — в разы отличалось. Аудиторы завода изучили качество продукта, способы его интеграций/адаптаций и рекомендовали больше с конторой не связываться. Несмотря на то, что контора в настоящий момент процветает.
Да, понял вашу точку зрения. Вопрос один — хватит ли разницы между оплатой 1000 и 1500 ч/ч на закрытие потенциальной будущей дыры в репутации и косвенных потерь, с этим связанных? И стоит ли вообще рассматривать этот вариант с «условным быдлокодом»?
Деньги деньгами, но я (опять же, условно говоря) лучше сам в свободное время подключусь к проекту команды, например, и поработаю над архитектурой, нежели буду смотреть на то, как получается «нечто за 1000». Как-то так.
Да, понял вашу точку зрения. Вопрос один — хватит ли разницы между оплатой 1000 и 1500 ч/ч на закрытие потенциальной будущей дыры в репутации и косвенных потерь, с этим связанных? И стоит ли вообще рассматривать этот вариант с «условным быдлокодом»?
Деньги деньгами, но я (опять же, условно говоря) лучше сам в свободное время подключусь к проекту команды, например, и поработаю над архитектурой, нежели буду смотреть на то, как получается «нечто за 1000». Как-то так.
Например тот же SCRUM четко не регламентирует роли. Так что если есть архитектор хорошо, нету — тоже хорошо. Его может не быть, если все девелоперы являются по праву сеньорами. Если это не так, то без архитектора такого нагородят.
Про инспекцию кода тоже самое.
Спецификацию можно фиксировать в виде комментов к задаче. Лучше так, чем совсем никак. Потом никому ничего не докажете. Я имею ввиду тестеровщику, ПМу, аналитику и т.д.
Вещи типа ДАЛа, расслоения системы, архитектуры контролов лучше все же продумать заранее.
Про инспекцию кода тоже самое.
Спецификацию можно фиксировать в виде комментов к задаче. Лучше так, чем совсем никак. Потом никому ничего не докажете. Я имею ввиду тестеровщику, ПМу, аналитику и т.д.
Вещи типа ДАЛа, расслоения системы, архитектуры контролов лучше все же продумать заранее.
Позвольте вас поправить. Скорее должно звучать так «в некритичных системах, создаваемых небольшими командами, гибкие методологие вытесняют классические».
Реально же IBM, MS, множество средней руки Java-аутсорсеров проектируют свои проекты до посинения.
Причем оба подхода ошибочны, как оба — верны. Крупные системы надо регулировать и сверху вниз, и снизу вверх. Нельзя проектировать архитектуру, не вникая в нюансы; как нельзя сохранить стройность системы, не посмотрев на нее «с высоты архитекторского полета».
Умение держать баланс — важный для архитекторов/тимлидов скилл.
Реально же IBM, MS, множество средней руки Java-аутсорсеров проектируют свои проекты до посинения.
Причем оба подхода ошибочны, как оба — верны. Крупные системы надо регулировать и сверху вниз, и снизу вверх. Нельзя проектировать архитектуру, не вникая в нюансы; как нельзя сохранить стройность системы, не посмотрев на нее «с высоты архитекторского полета».
Умение держать баланс — важный для архитекторов/тимлидов скилл.
Первый пункт из моего списка можно вычеркнуть — неверно интерпретировал послание топика..)
И, да, отчасти все же соглашусь с Вами — кое-какие советы после чтения «не по-диагонали» вызывают сомнения.
И, да, отчасти все же соглашусь с Вами — кое-какие советы после чтения «не по-диагонали» вызывают сомнения.
Слишком категорично. Вы давно гибкими методологиями в реальных условиях занимаетесь?
— Спецификация это вводные данные и ее наличие с методолгией разработки не связано.
— Инспекции кода являются той же частью рабочего процесса что и покрытие тестами. И не происпектирваная фича завершенной считаться не должна.
— специализация пусть и не явно выражена все равно будет. мыслить надо не участниками а фичекомандами
— архитектура даже если не продумывается досконально, но на скелетном уровне все равно будет пусть и не столь жесткая. тем более что опытный архитектор, который таки должен быть в команде, имеет достаточную квалификацию для чтобы дешево проектировать приложение используя типовые решения.
— Спецификация это вводные данные и ее наличие с методолгией разработки не связано.
— Инспекции кода являются той же частью рабочего процесса что и покрытие тестами. И не происпектирваная фича завершенной считаться не должна.
— специализация пусть и не явно выражена все равно будет. мыслить надо не участниками а фичекомандами
— архитектура даже если не продумывается досконально, но на скелетном уровне все равно будет пусть и не столь жесткая. тем более что опытный архитектор, который таки должен быть в команде, имеет достаточную квалификацию для чтобы дешево проектировать приложение используя типовые решения.
Достаточно давно, и что более важно, как раз в реальных условиях.
1. Для старта проекта достаточно концепции и краткой информации о предметной области, детальная спецификация не нужна.
2. Классической инспекции тоже нет, есть коллективное владение кодом и, в случае с XP, парное программирование — я об этом выше писал.
3. Мыслить надо командой. Естественно, неявной специализации не избежать, но обычно это выражается в том, что известно, к кому лучше обратиться за советом.
4. В гибких командах нет архитектора ровно как и проектирования «наперед».
В общем все это до меня уже описано и пережевано в умных книжках, я могу лишь подтвердить, что это работает на практике :)
1. Для старта проекта достаточно концепции и краткой информации о предметной области, детальная спецификация не нужна.
2. Классической инспекции тоже нет, есть коллективное владение кодом и, в случае с XP, парное программирование — я об этом выше писал.
3. Мыслить надо командой. Естественно, неявной специализации не избежать, но обычно это выражается в том, что известно, к кому лучше обратиться за советом.
4. В гибких командах нет архитектора ровно как и проектирования «наперед».
В общем все это до меня уже описано и пережевано в умных книжках, я могу лишь подтвердить, что это работает на практике :)
И вы и ТС слишком обобщенно видите ситуацию. Страничка для заказа пиццы и банковская ERP это несколько разные штуки, как деревянная модель кораблика и авианосец.
И то и другое можно сделать плохо и сделать хорошо и даже есть некоторые общие свойства, но не более того.
И то и другое можно сделать плохо и сделать хорошо и даже есть некоторые общие свойства, но не более того.
Всё, что вы перечисляете всё равно в том или ином виде есть. Если бы при работе по Agile архитектура тем или иным образом не продумывалась вообще, Agile бы просто исчез не родившись, т.к. отсутствие архитектуры (читай — структуры проекта) гарантированно приводит к краху, независимо от любых методологий.
Другое дело, что она вырабатывается не одним махом, а путём последовательных приближений и непрерывного рефакторинга. В гибких методологиях процесс, обычно, дробный. Но если кто-то возмётся утверждать, что не продумывает части системы и их взаимодействие при разработке — я сочувствую тем, кто будет его продукт потом поддерживать.
А вообще — если внимательно приглядитесь, совет у меня, собственно, один — не надо выливать в код поток сознания. Сначала надо его упорядочить, обдумать и понять его место в остальном проекте.
Другое дело, что она вырабатывается не одним махом, а путём последовательных приближений и непрерывного рефакторинга. В гибких методологиях процесс, обычно, дробный. Но если кто-то возмётся утверждать, что не продумывает части системы и их взаимодействие при разработке — я сочувствую тем, кто будет его продукт потом поддерживать.
А вообще — если внимательно приглядитесь, совет у меня, собственно, один — не надо выливать в код поток сознания. Сначала надо его упорядочить, обдумать и понять его место в остальном проекте.
В том или ином виде во всех методологиях можно найти что-то общее :) Более того, любая итеративная методология — это почти классический водопад, только длинной в одну итерацию. Очевидно, что в аджайле присутствуют планирование, проектирование, тестирование и прочие фазы, но их роль сильно уменьшена, а акцент смещен именно на разработку и максимально быстрое получение рабочего кода.
Весьма забавно, что почти все «проблемы плохого кода» связаны совсем не с разработкой и потому в «разработке» решены быть не могут. (В разработке необходимо и достаточно чтобы все участники понимали и стремились придерживаться DRY, DI,SRP. Если в группе разработки все будут придерживаться этих принципов, то даже есликогда внутри классов присутствует откровенный говнокод, взаимодействие между классами как правило достаточно простое и позволяет «расширять» и «углублять» в нужных местах по необходимости)
Все описанные в посте проблемы растут из неспособности т.н. руководителей к диалогу (впрочем неспособность к диалогу присуща многим) + иногда стремление «руководить» а не «решать задачу».
P.S. «вдруг оказывался совершенно запутанным» — вот это вот «вдруг» — очень повеселило.
Все описанные в посте проблемы растут из неспособности т.н. руководителей к диалогу (впрочем неспособность к диалогу присуща многим) + иногда стремление «руководить» а не «решать задачу».
P.S. «вдруг оказывался совершенно запутанным» — вот это вот «вдруг» — очень повеселило.
К чему относится «внезапная» смена API внешних проектов, на которые «завязана» база кода?
Имеется в виду, скорее, разница между SQL и NoSQL-базами, чем разница между Win98 и Win7 (или между ядром Linux версии 2.2.x и 2.6.x).
Имеется в виду, скорее, разница между SQL и NoSQL-базами, чем разница между Win98 и Win7 (или между ядром Linux версии 2.2.x и 2.6.x).
Как ни странно, но все проблемы описанные автором довольно хорошо разжеваны в книге «Совершенный Код» за авторством Макконнелла
И не только эти!
Макконел книга — из разряда must read для любого профессионального программиста.
Макконел книга — из разряда must read для любого профессионального программиста.
В проекте должен быть явно выделенный разработчик, отвечающий за архитектуру системы
— нет! Ни в коем случае нельзя делать одного выделенного системного архитектора.
1. Он может банально уволиться в середине проекта.
2. Он может счесть себя богом, и начать творить самодурство в проекте.
3. Он может быть аутистом и психопатом, и вместо общепринятых в мире решений — начнёт делать свой собственный велосипед под каждую задачу.
Архитекторов в проекте должно быть как минимум двое, причём разных типов личности. Парное программирование, кстати, ещё никто не отменял.
— нет! Ни в коем случае нельзя делать одного выделенного системного архитектора.
1. Он может банально уволиться в середине проекта.
2. Он может счесть себя богом, и начать творить самодурство в проекте.
3. Он может быть аутистом и психопатом, и вместо общепринятых в мире решений — начнёт делать свой собственный велосипед под каждую задачу.
Архитекторов в проекте должно быть как минимум двое, причём разных типов личности. Парное программирование, кстати, ещё никто не отменял.
тут ключевое слово — «отвечающий» :). Опять же, я всегда на человека посмотрю прежде, чем ему доверить архитектуру.
А вообще — надо было добавить «или группа разработчиков». Основная смысль не в уникальности, а в том, что кто-то должен за архитектуру отвечать.
А вообще — надо было добавить «или группа разработчиков». Основная смысль не в уникальности, а в том, что кто-то должен за архитектуру отвечать.
0. Он может быть обычным адекватным человеком и все будет отлично.
Смотреть нужно кого выбираешь.
Смотреть нужно кого выбираешь.
По-английски «пластилиновая» архитектура называется «Big ball of mud», что имхо более точное название :)
А ещё: большой проект нужно дробить
Мой алгоритм:
1. Понять заказчика. Что ему нужно, зачем, какие стоят задачи, что и как происходит сейчас. С этим никогда нельзя спешить, нужно все понять, и разговаривать столько, сколько нужно (диктофон здорово помогает — часто после прослушивания своего же разговора узнаю много нового %) ) — могут меняться требования к системе, редко меняются конечные задачи.
Простыми словами — редко меняется то, что нужно заказчику, но может поменяться то, чего он хочет.
Хороший кстати фильм, Константин, там тоже об этом ) Давать то, что нужно, а не то, что хотят %)
2. Поставить себя на место каждой роли пользователя/оператора/…. Если это автоматизация, всю рутину пройти самому, чтобы прочувствовать.
3. После п.1 и п.2 я знаю, что мне нужно (к этому моменту я для своей команды уже становлюсь «заказчиком», и проект воспринимаю как «для себя»)
3. Можно делать. Архитектура должна быть достаточной, не надо проектировать мосты там, где хватит переброшенного через брод бревна.
4. Надо чаще встречаться. И регулярно. Нет ничего страшного в добавлении новых функций, изменении в мелочах, нюансах и пр. Современные инструменты проектирования и разработки настолько хороши, что ключевое требование — понять заказчика в мелочах, после понимания остальное детали.
1. Понять заказчика. Что ему нужно, зачем, какие стоят задачи, что и как происходит сейчас. С этим никогда нельзя спешить, нужно все понять, и разговаривать столько, сколько нужно (диктофон здорово помогает — часто после прослушивания своего же разговора узнаю много нового %) ) — могут меняться требования к системе, редко меняются конечные задачи.
Простыми словами — редко меняется то, что нужно заказчику, но может поменяться то, чего он хочет.
Хороший кстати фильм, Константин, там тоже об этом ) Давать то, что нужно, а не то, что хотят %)
2. Поставить себя на место каждой роли пользователя/оператора/…. Если это автоматизация, всю рутину пройти самому, чтобы прочувствовать.
3. После п.1 и п.2 я знаю, что мне нужно (к этому моменту я для своей команды уже становлюсь «заказчиком», и проект воспринимаю как «для себя»)
3. Можно делать. Архитектура должна быть достаточной, не надо проектировать мосты там, где хватит переброшенного через брод бревна.
4. Надо чаще встречаться. И регулярно. Нет ничего страшного в добавлении новых функций, изменении в мелочах, нюансах и пр. Современные инструменты проектирования и разработки настолько хороши, что ключевое требование — понять заказчика в мелочах, после понимания остальное детали.
> И вот, в какой-то момент, появляется задача, которая влияет на несколько составных частей системы. Привычным движением мы лепим очередной комок… Но вдруг осознаём, что у нас перестала работать какая-то совершенно другая функция. Мы исправляем её, налепив очередной кусок, и получаем ошибки ещё в двух. И это – цепная реакция.
для таких случаев отлично подходит разработка в TDD-стиле… ну или хотя бы test-first. Нельзя поломать «сначала одну», а «потом другую» часть системы, поломка или есть — или ее нет.
для таких случаев отлично подходит разработка в TDD-стиле… ну или хотя бы test-first. Нельзя поломать «сначала одну», а «потом другую» часть системы, поломка или есть — или ее нет.
Олег, извините за прямоту, вы когда-нибудь занимались производством коммерческого ПО на заказ? Очень странные вы вещи говорите.
Причём тут TDD? Я могу переформулировать: исправив один баг, мы получили два свалившихся теста. Теперь всё в концепцию TDD укладывается. Проблема не в том, что багов не видно или тестовое покрытие слабое, а в неуправляемости кода и невозможности его нормально модифицировать, ничего не поломав.
Причём тут TDD? Я могу переформулировать: исправив один баг, мы получили два свалившихся теста. Теперь всё в концепцию TDD укладывается. Проблема не в том, что багов не видно или тестовое покрытие слабое, а в неуправляемости кода и невозможности его нормально модифицировать, ничего не поломав.
при том что мы мгновенно понимаем, что какая-то часть системы не работает. Задачу нельзя закрыть, пока все задокументированные сценарии не будут работать ОК. (за незадокументированные сценарии не платят, так что можно расслабиться).
представим другую ситуацию: у нас нет никаких тестов. Или у нас есть куча тестов, но они проверяют неизвестно что, так что можно считать что их нет. Это вполне частая ситуация. Согласно задаче, мы меняем или добавляем новый кусок к пластилиновому кому, и никто в мире не сможет сказать — сломалось ли что-то еще в системе или нет. «Живые» тестеры если и смогут найти нарушения в бизнес-логике, то через многие дни или месяцы. Возможно, к этому моменту проектом будут заниматься совсем другие люди, которые пару месяцев будут пытаться понять, а в чем вообще проблема. Возможно, баг не найдут даже после релиза. Согласитесь, это гораздо ужаснее пары проваленных тестов, которые мгновенно скажут, что задача еще не доделана.
представим другую ситуацию: у нас нет никаких тестов. Или у нас есть куча тестов, но они проверяют неизвестно что, так что можно считать что их нет. Это вполне частая ситуация. Согласно задаче, мы меняем или добавляем новый кусок к пластилиновому кому, и никто в мире не сможет сказать — сломалось ли что-то еще в системе или нет. «Живые» тестеры если и смогут найти нарушения в бизнес-логике, то через многие дни или месяцы. Возможно, к этому моменту проектом будут заниматься совсем другие люди, которые пару месяцев будут пытаться понять, а в чем вообще проблема. Возможно, баг не найдут даже после релиза. Согласитесь, это гораздо ужаснее пары проваленных тестов, которые мгновенно скажут, что задача еще не доделана.
Мы ушли в сторону. Я говорю о том, что пластилиновую архитектуру сложно поддерживать. Вы говорите, что без тестов её поддерживать ещё сложнее.
> Задачу нельзя закрыть, пока все задокументированные сценарии не будут работать ОК.
Именно поэтому, над закрытием каждой задачи вы будете биться днями. Если ваш проект из разряда «вечных» и мигрирующих от одних индусов к другим — я вам просто сочувствую. Тут, вероятно, ничего уже и не сделаешь. Легаси есть легаси. Росту от него профессионального — 0, силы выматывает чуть более, чем полностью и, вероятно, приносит деньги, но небольшие.
А вот если вы стартуете новый проект — ваша моральная обязанность не допустить пластилина.
> Задачу нельзя закрыть, пока все задокументированные сценарии не будут работать ОК.
Именно поэтому, над закрытием каждой задачи вы будете биться днями. Если ваш проект из разряда «вечных» и мигрирующих от одних индусов к другим — я вам просто сочувствую. Тут, вероятно, ничего уже и не сделаешь. Легаси есть легаси. Росту от него профессионального — 0, силы выматывает чуть более, чем полностью и, вероятно, приносит деньги, но небольшие.
А вот если вы стартуете новый проект — ваша моральная обязанность не допустить пластилина.
обещаю не допускать пластилина в новых проектах ;) ладно, по крайней мере — бездумного и бессмысленного пластилина.
видео в тему, «пластелин бессмысленный и беспощадный»:
www.youtube.com/watch?v=gsTEjAJxF3w
www.youtube.com/watch?v=gsTEjAJxF3w
> Легаси есть легаси. Росту от него профессионального — 0
Позволю себе не согласиться. Частный случай: есть легаси код и нужно из него сделать нормальный, время на «fat refactoring» в разумных пределах не ограничено. Если подобные задачи раньше решать не приходилось (грубо говоря, «лепил пластилин» или просто с самого начала опыта следовал «правильным» (зазубренным) методикам, принципам, паттернам — редкий случай, по-моему), то итеративно (в смысле не «перепишу всё заново», а пошагово улучшая) можно прийти к пониманию, а не тупого («авторитеты так говорят») использования тех же паттернов, можно увидеть откуда они получаются.
Позволю себе не согласиться. Частный случай: есть легаси код и нужно из него сделать нормальный, время на «fat refactoring» в разумных пределах не ограничено. Если подобные задачи раньше решать не приходилось (грубо говоря, «лепил пластилин» или просто с самого начала опыта следовал «правильным» (зазубренным) методикам, принципам, паттернам — редкий случай, по-моему), то итеративно (в смысле не «перепишу всё заново», а пошагово улучшая) можно прийти к пониманию, а не тупого («авторитеты так говорят») использования тех же паттернов, можно увидеть откуда они получаются.
Можно было выкинуть всё, кроме последнего абзаца :)
>> Думать перед тем, как писать код, думать в процессе его написания и думать даже после того, как код написан
Много слов. Ну так покажите идеальный код, возможно в приведенном вами коде будет чему поучиться. А так, статья похожа на переливание из пустого в порожнее.
Каждый себе рисует некий идеальный образ всего на свете. Вы ни чем не лучше.
Много слов. Ну так покажите идеальный код, возможно в приведенном вами коде будет чему поучиться. А так, статья похожа на переливание из пустого в порожнее.
Каждый себе рисует некий идеальный образ всего на свете. Вы ни чем не лучше.
Эта статья, если Вы, вдруг, не заметили, учит думать. И это не просто пустая болтовня. Вы думаете, я долго сидел и высасывал из пальца «о чём бы написать»? Нет. Я взял реальный пример из жизни, с которым неоднократно сталкивался. И я рассказал ровно то, что я говорю своей команде, чтобы они поняли всю неприглядность такого подхода.
Более того, чтобы развеять остатки сомнения, Скажу: я — практик и мало верю теориям и шарообразным коням. И этот подход я повсеместно применяю этот подход на практике и воспитал уже ни одного классного специалиста.
Что касается «идеального кода». Вы опять сводите к «коду». Код — это самый нижний уровень, это буквы и строчки. Читая чужой код, можно научиться хорошо копировать. Научиться принимать правильные архитектурные решения, подходящие для Вашей конкретной задачи, глядя на чужой код крайне сложно. И в любом случае для этого надо думать.
Кстати, заметьте: заявления различных людей типа «пишу плохо, но все остальные ещё хуже. И вообще, один умный дядька говорил. что писать плохо — это нормально» — показатель непрофессионализма и отсутствия желания расти.
Более того, чтобы развеять остатки сомнения, Скажу: я — практик и мало верю теориям и шарообразным коням. И этот подход я повсеместно применяю этот подход на практике и воспитал уже ни одного классного специалиста.
Что касается «идеального кода». Вы опять сводите к «коду». Код — это самый нижний уровень, это буквы и строчки. Читая чужой код, можно научиться хорошо копировать. Научиться принимать правильные архитектурные решения, подходящие для Вашей конкретной задачи, глядя на чужой код крайне сложно. И в любом случае для этого надо думать.
Кстати, заметьте: заявления различных людей типа «пишу плохо, но все остальные ещё хуже. И вообще, один умный дядька говорил. что писать плохо — это нормально» — показатель непрофессионализма и отсутствия желания расти.
Из личного опыта могу отметить, что проект не зарастает и не начинает разваливаться, если на самых первых этапах планирования в архитектуру закладываются большие возможности для роста и развития проекта, т.е. как бы создается каркас и фундамент для заведомо большого здания, которое будет выдерживать большую нагрузку. При этом стоит проводить так называемое дальнее планирование, учитывая рост нагрузки и посещаемости, примерный объем новых фич и кода в будущем.
Это как поиск некоторого баланса между полетом фантазии и жесткими рамками. Реализовывать ненужный на данный момент функционал ни в коем случае не стоит, но стоит учитывать возможность его появления в будущем.
Это как поиск некоторого баланса между полетом фантазии и жесткими рамками. Реализовывать ненужный на данный момент функционал ни в коем случае не стоит, но стоит учитывать возможность его появления в будущем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Пластилиновая» архитектура