Комментарии 14
Эх, если бы reuse-компоненты так легко создавались, как этого хочется :(
Очень интересно, спасибо! А экономическую выгоду от поддержки reuseable frameworks в Вашей компании Вы пытались оценить? И влияет ли как-то наличие у вас таких фреймворков на условия лицензирования и ценообразования на уровне контракта с клиентом?
Экономическую выгоду посчитать очень тяжело, поскольку все проекты уникальны и для честной оценки надо делать 2 похожих проекта с применением нашего фреймворка и без. Для конкретного проекта можно примерно оценить стоимость работ «с нуля» и вычесть реальную стоимость. По моим оценкам один из проектов стоил дешевле примерно на 30% благодаря технологии. Для типичных проектов этот процент больше, а для проектов в которых количество специфичных решений весьма велико, разумеется, процент выигрыша будет небольшим. Наиболее важный аспект как для заказчика, так и для нас — это возможность за 2-3 недели подготовить работающий прототип приложения и продемонстрировать его, а также гарантировать качество работ, поскольку основные компоненты были проверены в других внедрённых проектах. Что же касается лицензирования и ценообразования — технология позволяет делать уступки клиентам, если иначе договориться не получается.
Есть мнение, что увеличение кол-ва ступеней, может привести к ошибке, которая разрушит всю вашу пирамиду.
Вам не кажется, что в некоторых вещах вы усложняете процесс?
Какое кол-во программистов у вас работает? Боюсь при определенной массе, некоторые будут «класть» на такой подход.
Плюс:
• Прикладные программисты не будут совать нос в технологический код и задавать глупые вопросы по этому поводу
Минусы:
• Сложность отладки для прикладных разработчиков
• Возможная нестабильность работы во время разработки
Угу… просто смотреть на мусор в Exception и думать «кто дурак» или просто идти и выносить мозг тем кто до этого это написал и произвел обусфакцию.
Видимо это очень большой плюс…
Вам не кажется, что в некоторых вещах вы усложняете процесс?
Какое кол-во программистов у вас работает? Боюсь при определенной массе, некоторые будут «класть» на такой подход.
Плюс:
• Прикладные программисты не будут совать нос в технологический код и задавать глупые вопросы по этому поводу
Минусы:
• Сложность отладки для прикладных разработчиков
• Возможная нестабильность работы во время разработки
Угу… просто смотреть на мусор в Exception и думать «кто дурак» или просто идти и выносить мозг тем кто до этого это написал и произвел обусфакцию.
Видимо это очень большой плюс…
Увеличение ступеней — это, разумеется, может привести к нехорошим последствиям при определённом стечении обстоятельств. Чтобы этого не происходило вырабатываются определённые механизмы как технического, так и организационного свойства. У нас около 50ти программистов (из них 6 технологов). Если технология развивается и хорошо поддерживается, то ни у одного прикладного программиста не возникнет мысли сделать как-то по-своему в обход общих практик просто потому, что проще и надёжнее взять готовое решение. Появление велосипедов в прикладных проектах говорит о недостаточно качественной работе технологического отдела.
По поводу заглядывания в технологический код. Я лично ничего против этого не имею, но лишь до той степени, когда начинают появляться реплики наподобие «я бы сделал это в 1000 раз лучше». Конструктивная критика и советы всегда принимаются. Тут следует учесть, что ввиду своей универсальной природы и многообразия вариантов, технологический слой довольно сложен. Если прикладной программист начинает тратить время на чтение этого кода, то для компании — это не очень хорошо, поскольку зарплата платится ему за другую работу. Отлаживать технологический код — сравнимо с отладкой кода .NET Framework. Это возможно, но принесёт ли это счастье? Я находил ошибки в .NET, в результате приходилось ставить «костыли» у себя. В случае с технологическим слоем — всегда есть возможность подойти к технологам и попросить их разобраться в ситуации.
И ещё один комментарий по поводу обфускации — не все наши проекты подвергаются этому процессу. Это нужно только при угрозе, что наш прототип будет передан заказчиком третьим лицам на доработку и с нами не будет заключен контракт.
По поводу заглядывания в технологический код. Я лично ничего против этого не имею, но лишь до той степени, когда начинают появляться реплики наподобие «я бы сделал это в 1000 раз лучше». Конструктивная критика и советы всегда принимаются. Тут следует учесть, что ввиду своей универсальной природы и многообразия вариантов, технологический слой довольно сложен. Если прикладной программист начинает тратить время на чтение этого кода, то для компании — это не очень хорошо, поскольку зарплата платится ему за другую работу. Отлаживать технологический код — сравнимо с отладкой кода .NET Framework. Это возможно, но принесёт ли это счастье? Я находил ошибки в .NET, в результате приходилось ставить «костыли» у себя. В случае с технологическим слоем — всегда есть возможность подойти к технологам и попросить их разобраться в ситуации.
И ещё один комментарий по поводу обфускации — не все наши проекты подвергаются этому процессу. Это нужно только при угрозе, что наш прототип будет передан заказчиком третьим лицам на доработку и с нами не будет заключен контракт.
Ясно… о заглядывании… конечно есть такая штука, которая ущемляет эго программиста, но основное это возможность получить нормальный Exception и понять «кто дурак». Из личного опыта, мне пофиг на код контролов/библиотек, пока не свалится в Exception. Далее или VS покажет или… контрол/библиотека уйдет в мусор, ибо невозможность дебагинга уже зло.
Здорово. Интересно бы задать пару вопросов.
А можно сперва поинтересоваться, в какой команде вы работаете? Жутко интересно, а в статье не нашел.
И еще, Вы пишете «мы (технологи)». Правильно ли я понял, что технологи, это разработчики, занимающиеся технологическим слоем?
А можно сперва поинтересоваться, в какой команде вы работаете? Жутко интересно, а в статье не нашел.
И еще, Вы пишете «мы (технологи)». Правильно ли я понял, что технологи, это разработчики, занимающиеся технологическим слоем?
Я готов ответить на вопросы (как тут в комментах, так и в личных сообщениях).
По поводу команды: да, Вы правильно понимаете, наша небольшая команда технологов занимается разработкой технологического слоя. Чтобы дать представление о всей компании, приведу пример одной из прикладных систем, разработанных на нашей технологии: web2edu.ru
По поводу команды: да, Вы правильно понимаете, наша небольшая команда технологов занимается разработкой технологического слоя. Чтобы дать представление о всей компании, приведу пример одной из прикладных систем, разработанных на нашей технологии: web2edu.ru
Ага. Вы из группы компаний ИВС.
Посмотрел онлайн-демо, симпатично. Разве что немного напрягает, что тормозит при изменении значений в полях формы (фильтра?) и перегружает всю страницу целиком. При этом перегружает ИНОГДА! :)
Впрочем, статья не об этом :) Вопросы по статье:
Как вы ведете документацию? Что обычно пишет разработчик по завершении задачи? Если не секрет, можно пример статьи какой-нибудь технологической фичи? Жутко любопытно.
Как пишете тесты? Сперва тест, потом код, или наоборот. В какой момент появляются новые тесты? Разработчик сам пишет тест к каждой новой фиче или на тесты ставятся отдельные задачи?
Какое соотношение технологических разработчиков и прикладных?
Посмотрел онлайн-демо, симпатично. Разве что немного напрягает, что тормозит при изменении значений в полях формы (фильтра?) и перегружает всю страницу целиком. При этом перегружает ИНОГДА! :)
Впрочем, статья не об этом :) Вопросы по статье:
Как вы ведете документацию? Что обычно пишет разработчик по завершении задачи? Если не секрет, можно пример статьи какой-нибудь технологической фичи? Жутко любопытно.
Как пишете тесты? Сперва тест, потом код, или наоборот. В какой момент появляются новые тесты? Разработчик сам пишет тест к каждой новой фиче или на тесты ставятся отдельные задачи?
Какое соотношение технологических разработчиков и прикладных?
Разработчик описывает реализованные фичи во внутренней вики. Ответы на вопросы прикладных программистов также пишем туда. Уровни описания были указаны выше.
Пример статьи (для прикладных программистов):
Тесты у нас пишутся, как правило, после кода. Отдельные разработчики иногда делают наоборот — это не возбраняется. В связи с тем, что часть кода была написана довольно давно и без тестов, при изменении функциональности или исправлении ошибок разработчик добавляет тесты для проверки и того старого кода. Цели взять и покрыть за один раз тестами всё на 100% у нас нет — идём постепенно. Отдельных задач на тестирование не ставится — участники команды достаточно сознательные чтобы писать тесты самостоятельно.
В данный момент соотношение технологов к прикладным разработчикам у нас примерно 1 к 5-6.
Пример статьи (для прикладных программистов):
Тесты у нас пишутся, как правило, после кода. Отдельные разработчики иногда делают наоборот — это не возбраняется. В связи с тем, что часть кода была написана довольно давно и без тестов, при изменении функциональности или исправлении ошибок разработчик добавляет тесты для проверки и того старого кода. Цели взять и покрыть за один раз тестами всё на 100% у нас нет — идём постепенно. Отдельных задач на тестирование не ставится — участники команды достаточно сознательные чтобы писать тесты самостоятельно.
В данный момент соотношение технологов к прикладным разработчикам у нас примерно 1 к 5-6.
А, да, еще вопрос. Используете ли вы NuGet для работы с внешними сборками и с внутренними?
Поддержка распространения технологических сборок через NuGet у нас только в планах.
Привожу ссылку на картинку, поскольку в моём комментарии выше на ней ничего не видно.
Привожу ссылку на картинку, поскольку в моём комментарии выше на ней ничего не видно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт создания фреймворков