Comments 88
Адовые хардварные баги и костыли.
UFO just landed and posted this here
50% воздержавшихся это интересно)
2 и 3 пункты сильно взаимосвязаны.
Как насчет Варианта «Заказчик»? )
Я воздержался, потому что нет пункта «Адовая бюрократия и шатание из пустого в порожнее у крупного клиента»
Тег в тему. Scrum'ы очень хорошо эту боль облегчают.
я бы еще добавил «Безумное руководство»
БР: — Вот это надо сделать срочно, сегодня.
Р: — Ок, 2, 3 часа.
БР: —Делай.
через 30мин.
БР: — бросай все вот эта надо просто…
Р: — но,
БР: — делай это.
Р: — Ок, 2часа
БР: —Делай.
через 30мин
БР: — ну что готово?
Р: — нет
и т.д.
БР: — Вот б… нечего не делаете
БР: — Вот это надо сделать срочно, сегодня.
Р: — Ок, 2, 3 часа.
БР: —Делай.
через 30мин.
БР: — бросай все вот эта надо просто…
Р: — но,
БР: — делай это.
Р: — Ок, 2часа
БР: —Делай.
через 30мин
БР: — ну что готово?
Р: — нет
и т.д.
БР: — Вот б… нечего не делаете
С некоторым БР можно использовать принцип ПВО (подожди — возможно, отменят).
UFO just landed and posted this here
Зачем работать на такой работе?
Обязательства?
Работа интересная. Подумываю.
Ну просто, для меня хорошая работа это совокупность четырех параметров:
1. Стек технологий, которые я люблю
2. Интересные задачи
3. Адекватная оплата труда
4. Адекватный коллектив, в том числе (и на первом месте) адекватное начальство
Если выбить любой из этих параметров (особенно, конечно, первые два), то сразу становится как то не так и тянет поменять место работы,
учитывая что рынок испытывает дефицит, найти полностью подходящую работу сейчас не так уж сложно.
1. Стек технологий, которые я люблю
2. Интересные задачи
3. Адекватная оплата труда
4. Адекватный коллектив, в том числе (и на первом месте) адекватное начальство
Если выбить любой из этих параметров (особенно, конечно, первые два), то сразу становится как то не так и тянет поменять место работы,
учитывая что рынок испытывает дефицит, найти полностью подходящую работу сейчас не так уж сложно.
Не везде есть возможность смены работы на более подходящуюю.
Использую правило трех гвоздей. В результате треть работ отсеивается сразу, и достаточно серьезный процент пересматривается в течении дня так, что нужно кардинально другой функционал.
Михаил Жванецкий. Куда толкать.
Адовые требования заказчиков, которые в пух и прах рассыпают стройную архитектуру проекта и привносят в него кучу костылей, заставляют писать для этих костылей неподдерживаемый говнокод и исключают из проекта понятие «Стабильность» как класс.
Agile вам в помощь
Вы Notepad чтоли разрабатываете в качестве CRP-решения?
Обычно такое происходит, если неправильная архитектура заложена.
На конкретном примере. Есть стройное crud web-приложение, формочек эдак под 800. Вполне себе работоспособное. У заказчика появилась идея сделать автозаполнение на форме создания/редактирования записей почти для каждого из полей, с зависимостью от других полей, с интерактивщиной на JS. Каждый запрос на заполнение каждого поля затрагивает по 3-4 таблицы БД. Да, это реализовать не сложно. Но: сроки исполнения — позавчера, код должен выйти плоский — но очень объёмный и сложный из-за зависимостей, кое-где перекрёстных, кое где зацикливающихся. Вот тут и начинабются костыли.Мы постарались такой код вынести в отдельное место, но переплетение с основными ветками исходников всё равно остаются.
Обычно это происходит, если заказчик ИТ продукта (а не автоматизации производства стройматериалов), не разбирается в ИТ на должном уровне и не слушает советов тех кто разбирается.
Я понял, что у меня замечательная работа =)
Костыли! Самая большая проблема.
— Сейчас сделаем так, потом переделаем. Нет времени делать правильно.
— Ой-ой-ой, мы забыли, что у нас там сделано так, а во всех других местах иначе.
В результате всё на подпорках, и вроде работает, но чуть тряхнуло — и всё посыпалось.
Ну и враги R&D — админы.
— Сейчас сделаем так, потом переделаем. Нет времени делать правильно.
— Ой-ой-ой, мы забыли, что у нас там сделано так, а во всех других местах иначе.
В результате всё на подпорках, и вроде работает, но чуть тряхнуло — и всё посыпалось.
Ну и враги R&D — админы.
С некоторых пор забиваю на все админские ограничения и наказы — потому как они часто лишь мешаются, а реальной пользы не приносят. А если начинается головомойка вроде «не исполняешь админских поручений» — привожу контр-аргумент: «если я буду их исполнять и ждать пока админы соизволят на сервере настроить то что мне необходимо — я не выполню и десятой части проекта». Как правило руководству всё же важнее чтобы выполнялись поставленные задачи и только потом — соблюдение требований внутреннего распорядка.
Дело не в наказах. Дело в том, что админы могут или поменять что-то у себя (проксю, виртуалки выключить, грохнуть сеть) и вся наша инфраструктура перестает работать. И закупки оборудования идут через них.
Я это понимаю, про то и говорю. Поэтому например у себя отвоевал пару виртуалок, на которые не пускаю админов и слава богу поселил их на мало интересном админам сервере.
Есть ещё такая проблема: если что-то нужно развернуть на сервере, то по должностным обязанностям это должен сделать админ. но мне лично нафиг не нужно во первых ждать пока админ сподобится развернуть мне к примеру redmine, всё равно потом придётся всё перенастраивать заново под свои задачи.
Есть ещё такая проблема: если что-то нужно развернуть на сервере, то по должностным обязанностям это должен сделать админ. но мне лично нафиг не нужно во первых ждать пока админ сподобится развернуть мне к примеру redmine, всё равно потом придётся всё перенастраивать заново под свои задачи.
Отвечу из лагеря админов. Вот перечень того, что просят:
Это первое что всплывает в памяти, можно еще набросать пару десятков не логичных требований, гробящих всю безопасность компании на корню, вносящих задержки в работу и т.п. А так да, у плохого танцора админ виноват.
- Дай права на дирректорию проекта 777 иначе он не работает
- А давай проект будет запускаться от root
- Зачем ему отдельный пользователь, пусть на все 100500 проектов будет один, а мы в это время будем между ними куски перемещать
- Фаирвол, да кому мы нужны нас ломать?
Это первое что всплывает в памяти, можно еще набросать пару десятков не логичных требований, гробящих всю безопасность компании на корню, вносящих задержки в работу и т.п. А так да, у плохого танцора админ виноват.
1. Когда заказчик упорно отказывается обсуждать детали проекта, а в самом конце заявляет
«Нет! То что вы сделали — не правильно, я хотел все по другому!»
2. Когда заказчик навязывает свое видение «правильной» архитектуры проекта, и отказывается выслушивать доводы опытных исполнителей.
«Нет! То что вы сделали — не правильно, я хотел все по другому!»
2. Когда заказчик навязывает свое видение «правильной» архитектуры проекта, и отказывается выслушивать доводы опытных исполнителей.
2, 3, 4.
Ответил: «Адов говнокод и костыли».
Именно этим я и занимаюсь в моем проекте…
Именно этим я и занимаюсь в моем проекте…
У нас из-за постоянного регресса закрыли проект, в который вкачали 10 миллионов долларов. Никто не писал юнит тесты, в итоге полная жопа, дошло до того что коммиты в транк были только после ревью двумя девелоперами. Покрывать тестами говнокод без рефакторинга уже было не в возможно. С регрессией так и не справились. Бизнес сказал идити вы нах козлы и закрыл проект. Вот такие пироги.
Кароче TDD был необходим с самого начала.
Кароче TDD был необходим с самого начала.
Не вам упрек, а так — наблюдение в целом.
Рефакторить тоже надо было, а не ждать отмажки от заказчиков-лидов-манагеров-мамочки. Наверняка ведь время было. Другое дело, что ленивые все как черти и по собственно инициативе никто ничего делать не хочет. А потом, даже когда такой человек находится, его всей командой синьоров отговаривают.
В нашей профессии не хватает смелости.
Рефакторить тоже надо было, а не ждать отмажки от заказчиков-лидов-манагеров-мамочки. Наверняка ведь время было. Другое дело, что ленивые все как черти и по собственно инициативе никто ничего делать не хочет. А потом, даже когда такой человек находится, его всей командой синьоров отговаривают.
В нашей профессии не хватает смелости.
А почему никто не писал юнит-тесты?
Слишком много всего в каждой итерации надо было делать. Многие в начале тесты считали мелочью на которую не обращали внимание (тесты были, но очень мало конечно всего покрывали). Да и команда тестеров вручную все тестировала, без авто-тестов. Когда спохватились, было поздно, ни TDD ни Selenium, ни Sonar ни чего не помогло. Бесконечная регрессия загубила проект.
ха, у нас на проекте есть «синьоры», которые уверяют, что юнит-тесты говно и DDD говно и «все — говно и вот так всегда». Но и их код с точки зрения SOLID и DDD даже не стоит начинать критиковать. Это просто забор детского сада из костылей и\или спагетти и кучей зависимостей. Рефакторить его проблематично, а поддерживать или расширять почти невозможно.
А всё потому что книжкам умным они не верят («да в книжках и не такое напишут»), про техники узнают из обзорных статей, до конца в теории разобраться и начать применять её так и не сумели, а вот шишек заработали и теперь всё хают, напоминая девочек на уроке физики.
Доходило до того, что один такой чел утверждал, что бизнес процессы описывать не надо, требования не нужны, а код на 200 тыс. строк можно написать просто получая задания от клиента и не иметь при этом проблем.
А всё потому что книжкам умным они не верят («да в книжках и не такое напишут»), про техники узнают из обзорных статей, до конца в теории разобраться и начать применять её так и не сумели, а вот шишек заработали и теперь всё хают, напоминая девочек на уроке физики.
Доходило до того, что один такой чел утверждал, что бизнес процессы описывать не надо, требования не нужны, а код на 200 тыс. строк можно написать просто получая задания от клиента и не иметь при этом проблем.
Вы знаете, я могу сказать аналогично. Бизнес-процессы действительно описывать не надо, требования не нужны. Все потому, что эти процессы будет описывать человек, который будет наблюдать со своей колокольни, потом пропустит через фильтр своего ограниченного мышления, и на выходе выдаст требования, которые устареют как минимум на пол года. Потом это все будет реализовано, и никому совершенно не нужно.
Странная позиция: или ноль юнит-тестов, или полное TDD. Может, правда где-то посередине?
Менеджеры которые постоянно переносят установку фич. Бывает накопиться штук 5-10 разных в разных ветках, а потом приходится долго и упорно их сливать… Или что еще хуже, выдергивать отдельный функционал для использования в другой ветке.
Третий раз читаю название поста как «Какая проблема на вашем проекте приносит вам самую большую попаболь»… :(
Я один тут такой?
Я один тут такой?
Хм, я даже растерялся немного, так как не могу придумать ни одну причину, которая бы мне доставляла боль… Что я делаю не так?
UFO just landed and posted this here
У нашего проекта основная беда — это настройки, раскиданные по .config — файлу, в том числе по секции . Из-за этого крайне затруднительно выпускать новые версии, которые были бы совместимы с настройками старого формата.
Дошли до того, что секцию castle перестали отдавать кастлу, вместо чего теперь выдергиваем из нее нужные настройки сами.
Дошли до того, что секцию castle перестали отдавать кастлу, вместо чего теперь выдергиваем из нее нужные настройки сами.
Отсутствие нормального электронного документооборота.
Прокрастинация.
прикручивание верстки — не хватает такого пункта
А где же пункт — адские проблемы с тестированием? Сначала одни «забыли» в спешке про юнит-тесты, потом другие «сэкономили» на тестерах и проект проверяли все-подряд, затем отчеты «тестеров» в аське, скайпе, почте и оупенсорс баг-трекере стали жутко пересекаться, ссылаться друг на друга, теряться и обрастать слухами…
Как результат — потерянное время, нервы, сорваные несколько раз сроки и натянутые отношения всей команды вплоть до момента релиза. И в той или иной мере это бывает везде, где считают «да ну, потестить продукт может и сам заказчик, или сват-брат по дороге на работу».
Как результат — потерянное время, нервы, сорваные несколько раз сроки и натянутые отношения всей команды вплоть до момента релиза. И в той или иной мере это бывает везде, где считают «да ну, потестить продукт может и сам заказчик, или сват-брат по дороге на работу».
Голосую за вариант «яидиот и не понимаю, почему каждый второй класс — это или фабрика, или инжектор»
Регресс, т.к. не понимаю, каким образом возможно сделать автотесты для пользоветельских интерфейсов…
Сделать тулзу, которая записывает действия пользователя в программе, а потом воспроизводит. У нас в проекте на андроиде предлагалось такое сделать.
Предполагалось — то есть не сделали? А потом поддерживать эту тулзу, «перезаписывать» действия, если какая-то кнопка переехала на 20 пикселей вправо? Вот у нас флеш-игры (социалки), как тестить, кроме как руками — не представляю. Учитывая, что элементы интерфейсов меняются _постоянно_, переставляются, перерисовываются, удаляются, заменяются и, конечно же, меняется сама логика + интерфейсы — это же сильно «субъективно», «очеловеченно» + очень много таких штук, где нужно подождать, например 2 минуты, прежде чем проверить фичу, а в чуть другой ситуации — 2.5 минуты. Регрессионных багов много, но в нашем случае по-моему это следствие исключительно безответственного кода, когда правят баги не задумываясь что при этом могут зацепить еще что-то, когда починив баг в одном месте, не проверяют есть ли еще аналогичные проблемные места, когда (!) элементарно не проверяют результат своей работы (!), когда пихают костыли просто из лени, и прочее, и прочее. И имхо если грамотно и ответственно подходить к тестированию, то можно и без автоматизации нормально жить.
Не предполагалось, а предлагалось. Лично я от этого отказался, потому как мне крайне неинтересно делать тулзу для тестинга. Может кто-нибудь другой сейчас это делает.
Необязательно записывать событие нажатия по координатам — можно искать компонент управления и как-то его дергать.
По поводу изменения интерфейса, конечно, согласен, не знаю как бы мы с этим справились — но тулза была бы полезная для всяких проверок типа загрузки контента и правильной реакции приложения на действия в некоторых случаях.
Необязательно записывать событие нажатия по координатам — можно искать компонент управления и как-то его дергать.
По поводу изменения интерфейса, конечно, согласен, не знаю как бы мы с этим справились — но тулза была бы полезная для всяких проверок типа загрузки контента и правильной реакции приложения на действия в некоторых случаях.
Никто, кстати, не подскажет, как он оформляет костыли? Мы вот думаем, как бы вынести их, чтобы в основном коде не мешались.
UFO just landed and posted this here
Говнотесты, которые проверяют имплементацию, а не поведение. Каждый рефакторинг влечет переписывание кучи тестов.
а еще при отсутствии четкого ТЗ заказчик может решить, что он хочет совсем не то, что уже почти готово. Вот тогда-то и начнутся костыли там, где изначально было все в норме. А финальный результат будет шептать «убей меня...»
В общем, это можно отнести к менеджменту.
В общем, это можно отнести к менеджменту.
Адовые клиенты с адовыми идеями, которые мне приходится реализовывать.
Sign up to leave a comment.
Какая проблема на вашем проекте приносит вам самую большую боль