Pull to refresh

Comments 88

UFO just landed and posted this here
Получается что всем мешает то, что кроме них есть еще кто-то, кто учавствует в проекте.
Не обязательно. Нередко и самому приходится ставить костыли, которыми уже в момент написания сам и недоволен.
Нееее. Мы кодим-кодим, сто раз проговорим с менеджерами чего они хотят. А потом спустя неделю, появится маааленькое пожелание, которое будет идти в разрез с логикой работы и начнутся костыли.
Со словами «давайте отделаемся малой кровью»
UFO just landed and posted this here
Тут же не все в IT компаниях, или программисты. Я — админ, например, в обычной фирме.
Ага, я дизайнер / девелопер, но все равно ничего из перечисленного тут бы не подошло, нужен свой вариант ответа.

Для меня самый тяжелый момент это отсутствие мотивации — если ее потерял, все, считай пропало. Грустно, что деньги в какой-то момент тоже теряют свою мотивирующую способность.
Не у всех есть проблемы с проектом
Кстати, да. Но я не воздержался, чтобы статистика учла и тот проект, с которым, слава Б-гу, уже не приходится иметь дел.
Нет варианта: «Проект не приносит денег» :)
Судя по уровню проблем (описаны достаточно мелкие), в опросе не хватает ещё 160 пунктов.
UFO just landed and posted this here
Если нет времени на продумывание архитектуры — то всё будет печально. Это конечно тоже отсутствие мозгов, но не у программиста. С другой стороны, иногда выйти с говеным (внутри!) продуктом и захватить позиции, а потом переписать всё — тоже ведь стратегия.
UFO just landed and posted this here
Я воздержался, потому что нет пункта «Адовая бюрократия и шатание из пустого в порожнее у крупного клиента»
я бы еще добавил «Безумное руководство»
БР: — Вот это надо сделать срочно, сегодня.
Р: — Ок, 2, 3 часа.
БР: —Делай.
через 30мин.
БР: — бросай все вот эта надо просто…
Р: — но,
БР: — делай это.
Р: — Ок, 2часа
БР: —Делай.
через 30мин
БР: — ну что готово?
Р: — нет
и т.д.
БР: — Вот б… нечего не делаете
С некоторым БР можно использовать принцип ПВО (подожди — возможно, отменят).
UFO just landed and posted this here
Зачем работать на такой работе?
Работа интересная. Подумываю.
Ну просто, для меня хорошая работа это совокупность четырех параметров:
1. Стек технологий, которые я люблю
2. Интересные задачи
3. Адекватная оплата труда
4. Адекватный коллектив, в том числе (и на первом месте) адекватное начальство

Если выбить любой из этих параметров (особенно, конечно, первые два), то сразу становится как то не так и тянет поменять место работы,
учитывая что рынок испытывает дефицит, найти полностью подходящую работу сейчас не так уж сложно.

В моем случаи выполняется 1, 2 пункты, остальные частично. В провинциях не всегда коту масленица :) Из моей практики 4 пункт, если он с приставкой «не» делает все остальные пункты. Что и происходит.(печалька)
Не везде есть возможность смены работы на более подходящуюю.
Использую правило трех гвоздей. В результате треть работ отсеивается сразу, и достаточно серьезный процент пересматривается в течении дня так, что нужно кардинально другой функционал.
Адовые требования заказчиков, которые в пух и прах рассыпают стройную архитектуру проекта и привносят в него кучу костылей, заставляют писать для этих костылей неподдерживаемый говнокод и исключают из проекта понятие «Стабильность» как класс.
Минусующие — не ленитесь аргументировать.
Вы Notepad чтоли разрабатываете в качестве CRP-решения?
Обычно такое происходит, если неправильная архитектура заложена.
На конкретном примере. Есть стройное crud web-приложение, формочек эдак под 800. Вполне себе работоспособное. У заказчика появилась идея сделать автозаполнение на форме создания/редактирования записей почти для каждого из полей, с зависимостью от других полей, с интерактивщиной на JS. Каждый запрос на заполнение каждого поля затрагивает по 3-4 таблицы БД. Да, это реализовать не сложно. Но: сроки исполнения — позавчера, код должен выйти плоский — но очень объёмный и сложный из-за зависимостей, кое-где перекрёстных, кое где зацикливающихся. Вот тут и начинабются костыли.Мы постарались такой код вынести в отдельное место, но переплетение с основными ветками исходников всё равно остаются.
Ну тут тогда проблема в том, что времени мало не только на разработку архитектуры (=== плохая архитектура), но и на само кодирование.
Нельзя впихнуть невпихуемое.
Обычно это происходит, если заказчик ИТ продукта (а не автоматизации производства стройматериалов), не разбирается в ИТ на должном уровне и не слушает советов тех кто разбирается.
Обычно это происходит, если разработчик ИТ продукта, разбираеться только в ИТ на должном уровне и не хочет слышать тех, кто разбирается в автоматизации производства стройматериалов.
Я в моём комментарии говорил про тот случай, когда как раз не происходит автоматизация производстве стройматериалов, а происходит создание ИТ продукта (например поисковая система или социальная сеть).
Я понял, что у меня замечательная работа =)
Костыли! Самая большая проблема.
— Сейчас сделаем так, потом переделаем. Нет времени делать правильно.
— Ой-ой-ой, мы забыли, что у нас там сделано так, а во всех других местах иначе.
В результате всё на подпорках, и вроде работает, но чуть тряхнуло — и всё посыпалось.
Ну и враги R&D — админы.
С некоторых пор забиваю на все админские ограничения и наказы — потому как они часто лишь мешаются, а реальной пользы не приносят. А если начинается головомойка вроде «не исполняешь админских поручений» — привожу контр-аргумент: «если я буду их исполнять и ждать пока админы соизволят на сервере настроить то что мне необходимо — я не выполню и десятой части проекта». Как правило руководству всё же важнее чтобы выполнялись поставленные задачи и только потом — соблюдение требований внутреннего распорядка.
Дело не в наказах. Дело в том, что админы могут или поменять что-то у себя (проксю, виртуалки выключить, грохнуть сеть) и вся наша инфраструктура перестает работать. И закупки оборудования идут через них.
Я это понимаю, про то и говорю. Поэтому например у себя отвоевал пару виртуалок, на которые не пускаю админов и слава богу поселил их на мало интересном админам сервере.
Есть ещё такая проблема: если что-то нужно развернуть на сервере, то по должностным обязанностям это должен сделать админ. но мне лично нафиг не нужно во первых ждать пока админ сподобится развернуть мне к примеру redmine, всё равно потом придётся всё перенастраивать заново под свои задачи.
Отвечу из лагеря админов. Вот перечень того, что просят:
  • Дай права на дирректорию проекта 777 иначе он не работает
  • А давай проект будет запускаться от root
  • Зачем ему отдельный пользователь, пусть на все 100500 проектов будет один, а мы в это время будем между ними куски перемещать
  • Фаирвол, да кому мы нужны нас ломать?

Это первое что всплывает в памяти, можно еще набросать пару десятков не логичных требований, гробящих всю безопасность компании на корню, вносящих задержки в работу и т.п. А так да, у плохого танцора админ виноват.

1. Когда заказчик упорно отказывается обсуждать детали проекта, а в самом конце заявляет
«Нет! То что вы сделали — не правильно, я хотел все по другому!»

2. Когда заказчик навязывает свое видение «правильной» архитектуры проекта, и отказывается выслушивать доводы опытных исполнителей.
Разработка это движение от «ничего не работает» к состоянию «все не работает» =)
Ответил: «Адов говнокод и костыли».
Именно этим я и занимаюсь в моем проекте…
«именно этим» — это пишешь говнокод и делаешь костыли?
У нас из-за постоянного регресса закрыли проект, в который вкачали 10 миллионов долларов. Никто не писал юнит тесты, в итоге полная жопа, дошло до того что коммиты в транк были только после ревью двумя девелоперами. Покрывать тестами говнокод без рефакторинга уже было не в возможно. С регрессией так и не справились. Бизнес сказал идити вы нах козлы и закрыл проект. Вот такие пироги.

Кароче TDD был необходим с самого начала.
Не вам упрек, а так — наблюдение в целом.

Рефакторить тоже надо было, а не ждать отмажки от заказчиков-лидов-манагеров-мамочки. Наверняка ведь время было. Другое дело, что ленивые все как черти и по собственно инициативе никто ничего делать не хочет. А потом, даже когда такой человек находится, его всей командой синьоров отговаривают.

В нашей профессии не хватает смелости.
А почему никто не писал юнит-тесты?
Слишком много всего в каждой итерации надо было делать. Многие в начале тесты считали мелочью на которую не обращали внимание (тесты были, но очень мало конечно всего покрывали). Да и команда тестеров вручную все тестировала, без авто-тестов. Когда спохватились, было поздно, ни TDD ни Selenium, ни Sonar ни чего не помогло. Бесконечная регрессия загубила проект.
ха, у нас на проекте есть «синьоры», которые уверяют, что юнит-тесты говно и DDD говно и «все — говно и вот так всегда». Но и их код с точки зрения SOLID и DDD даже не стоит начинать критиковать. Это просто забор детского сада из костылей и\или спагетти и кучей зависимостей. Рефакторить его проблематично, а поддерживать или расширять почти невозможно.
А всё потому что книжкам умным они не верят («да в книжках и не такое напишут»), про техники узнают из обзорных статей, до конца в теории разобраться и начать применять её так и не сумели, а вот шишек заработали и теперь всё хают, напоминая девочек на уроке физики.
Доходило до того, что один такой чел утверждал, что бизнес процессы описывать не надо, требования не нужны, а код на 200 тыс. строк можно написать просто получая задания от клиента и не иметь при этом проблем.

Вы знаете, я могу сказать аналогично. Бизнес-процессы действительно описывать не надо, требования не нужны. Все потому, что эти процессы будет описывать человек, который будет наблюдать со своей колокольни, потом пропустит через фильтр своего ограниченного мышления, и на выходе выдаст требования, которые устареют как минимум на пол года. Потом это все будет реализовано, и никому совершенно не нужно.
Странная позиция: или ноль юнит-тестов, или полное TDD. Может, правда где-то посередине?
Есть мнение, что нельзя быть немножко беременной. И есть мнение, что к TDD это тоже относится.
Да, тесты можно писать без TDD. А ещё бывают не unit тесты, а другие приёмы тестирования.
Менеджеры которые постоянно переносят установку фич. Бывает накопиться штук 5-10 разных в разных ветках, а потом приходится долго и упорно их сливать… Или что еще хуже, выдергивать отдельный функционал для использования в другой ветке.
Третий раз читаю название поста как «Какая проблема на вашем проекте приносит вам самую большую попаболь»… :(
Я один тут такой?
Хм, я даже растерялся немного, так как не могу придумать ни одну причину, которая бы мне доставляла боль… Что я делаю не так?
Может быть, проект еще не вышел в полностью боевую фазу?
Всегда есть ощущение безоблачности, пока не раскочегарится нагрузка или пользователи начнут весь день работать в программе.
Да вроде как 5 лет уже работает. И не один…
Ну тогда вы просто классный инженер :)
Да вроде обычный… не самый выдающийся даже… Просто я люблю оптимизировать
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.

Articles