Вы сейчас пытаетесь сказать, что когда команда работает над проектом, каждому из них знать ТЗ и архитектуру проекта — не нужно? И новичка не нужно никак вводить в курс дела, чтобы он как раз и не был главным героем «угадай, куда я это засунул» и не найдя, не засовывал в новое место?
Но это всё вторично. Как, если не декоратором (CommentsService с методом create(text) — то же самое, только в профиль)?
Уверен. Мы же не пишем код с ИИ, чтобы он сам помнил о ТЗ. Это моя задача, как разработчика.
В данном конкретном месте, зная что необходимо дублировать в ФБ, я использую стратегию создания комментария, заодно дублирующую его в ФБ. В другом месте, если это необходимо — тоже буду. Там, где не нужно — не буду. Проблема то в чём?
По-моему довольно логичный ход. Когда я пишу код создания комментария, я знаю что мне нужно продублировать его в ФБ. В данном случае как раз Observer, использование которого многим показалось бы логичным, как раз и усложняет код. А вот декоратор как раз явно показывает намерения разработчика кода.
Естественно говнокод починить будет невозможно. Но что-то мне подсказывает, что в описанных в статье проектах время разработки слишком мало, чтобы объём говнокода достиг критической массы.
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
Часто работают всего 1 день во время выставки, а потом выкидываются
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
Если просекут IP, ясен-красен мгновенно вычислят конкретную машину и дальше хоть ставь её на паузу, делай снимок оперативки\диска и ковыряй сколько хочешь. А дальше зависит от того, как хорошо старались ТПБ защититься от проникновения снаружи и шифровали ли диски.
Лично я пользовал эти девайсы:
Gamin-Asus M10
ASUS MyPal A636 (и по-моему ещё P750)
Производителем они позиционируются как в т.ч. автомобильные гаджеты, поэтому в комплекте была держалка на лобовое стекло, в которую и втыкалось питание от прикуривателя. А сам девайс уже заряжался от держалки! Удобство просто неописуемое
А зачем так и планировалось? Заходя в топик, я думал вы хотите показать преимущества функционального подхода и вариант «как надо», а вы в очередной раз показали «как не надо».
Но это всё вторично. Как, если не декоратором (CommentsService с методом create(text) — то же самое, только в профиль)?
В данном конкретном месте, зная что необходимо дублировать в ФБ, я использую стратегию создания комментария, заодно дублирующую его в ФБ. В другом месте, если это необходимо — тоже буду. Там, где не нужно — не буду. Проблема то в чём?
Оказалось? Оказалось?? Да я Steam под Linux уже сколько лет жду! И каждые 5 минут жму F5 в браузере на их уютном бложике!
Нет, я не спорю что в идеале нужно делать красиво, качественно и с самого начала, вне зависимости от целей проекта. Но вы так легко и непринуждённо надавали советов, что хочется сразу же найти первоначальных авторов моих текущих проектов, разрабатывающихся с середины 2000х годов и спросить у них, а почему же мне приходится разгребать столько говнокода!
В таком контексте нет смысла рассуждать о прототипах и их выкидывании — в целом, совершенно пофиг на внутреннее качество результата.
Но таки пункт 4 из вашего алгоритма всё-равно и есть шаг под названием «выкинуть прототип».
Там, где софт будет жить долго и нудно, прототип нужен чтобы максимально быстро опробовать основные технические идеи, а затем сделать их по-уму. Может быть, конечно, есть люди, которые умеют с первого раза налабать архитектуру большого проекта так, что её потом легко поддерживать. Но лично я так не могу. И когда после работы над прототипом команда осознаёт более детально предметную область и плюсы\минусы выбранных технических решений, у неё открываются глаза на то, КАК на самом деле нужно было делать и дальше — сабж. Ну, в суровых реалиях отсутствия лишних денег\времени — можно ограничиться глубоким рефакторингом и закрыванием глаз на мелочи
Gamin-Asus M10
ASUS MyPal A636 (и по-моему ещё P750)
Производителем они позиционируются как в т.ч. автомобильные гаджеты, поэтому в комплекте была держалка на лобовое стекло, в которую и втыкалось питание от прикуривателя. А сам девайс уже заряжался от держалки! Удобство просто неописуемое