Pull to refresh

Comments 41

UFO just landed and posted this here
Хороший топик, читал с интересом. Долго втыкал в вашу доску… только так и не понял, откуда взялась цифра 49.

Улыбнула хренька для шняги (:
Потом 49 меняется на 50 и все вокруг этого кружка стирается и рисуется заново?
Да, именно так. На практике не всегда стирается все (если что-то не успели сделать, нет смысла стирать и переоценивать заново)
41 была за 14 недель до момента снимка :)
Тоже об этом подумал. Но тогда это должен был быть идеал.
Гыгы, «как я перестал бояться и полюбил бомбу». Отличны фильм, кстати.
Раз уж «контур» пишет про «эльбу» — реквестирую формы уведомления налоговой и прочих всяких фондов об открытии счета!:)
Налоговая пока не поддерживает такие уведомления, но может быть скоро утвердят. Пока это процедурно невозможно
Да я про банальную форму С-09-1
Это же бумажка, если я не ошибаюсь. Это точно может быть в электронном виде?
Пока это бумажка, разумеется. Утверждена приказом ФНС России от 09.06.2011 № ММВ-7-6/362.
В том же приказе содержится пункт
3. Управлению информатизации (В.Г. Колесников), ФГУП ГНИВЦ ФНС России (Р.В.Филимошин) обеспечить разработку и сопровождение программного обеспечения, реализующего представление сообщений, предусмотренных пунктами 2 и 3 статьи 23 Налогового кодекса Российской Федерации, в электронном виде.

В любом случае у вас в Эльбе и документоводе полно бумажек!
Ну это если нет никаких вариантов. Например дистанционной регистрации ООО нет, что тут поделаешь (: А тут-то можно подождать электронного формата, вполне реально, что он скоро выйдет
Вот кстати дистанционная регистрация ООО есть, через gosuslugi.ru :)
Правда представляю какую панику попытка такой регистрации вызовет в налоговой.
Интересная статья, спасибо.
Если не секрет, можно ещё немного про технические детали:
Какие ORM используете, что можете сказать про них?
IoC/DI контейнеры?
ORM — Linq 2 SQL. Можем сказать, что это очень легкий ORM, который легко использовать. Мы стараемся работать с базой в не реляционном стиле, нормальными формами там и не пахнет. Первая версия системы была на файлах. Сейчас все в таблицах, но мы можем скакануть на какую-нибудь Кассандру в любой момент, если пользователи начнут нас настолько любить, что текущие технологии перестанут вывозить нагрузку.
DI контейнер был Windsor в начале, давно уже пользуемся RoboContainer, это опен-сорс разработка Павла Егорова — разработчика Контура. Очень хорошая вещь, сама делает много предположений, то, что очевидно без конфигурирования, не приходится конфигурировать никогда
Спасибо! Очень интересно. А можно немного вопросов задать?
Для начала о составе команды
Что у вас за ребята? Вы берете опытных разработчиков или недавних студентов? Сколько времени нужно человеку, чтобы прийти и начать что-то изменять?

О разделяемом владении кодом
Какой у вас размер системы? Неужели получается в большой системе добиться разделяемого владения?
Я имею ввиду не формального а реального. Чтобы любые два разработчика (например со стажем 4 и 6 месяцев), взяли и внесли доработку в ядровую часть системы?
Или по факту на каждую функциональность системы есть специалист который РЕАЛЬНО и вносит изменение в формально всеобщий разделяемый код?

Используете ли какие-либо инструменты для мониторинга качества кода?
Стилистика (StyleCop)? Возможности рефаекторинга (FxCop и студийные ворнинги)? Метрики кода? Какие-нибудь системы для анализа слабой связанности (студийные или сторонние)?
Если да, то как это происходит? Есть какой-то день или на каждый комит?
Или тестов, считаете, достаточно?

О покрытии кода
Ммм. Когда говорят о 100% покрытия кода, или даже о 80% у меня всегда острый приступ недоверия. Было время и я предполагал что только 100% покрытия спасут Россию и все время скорбил о недостижимости этой цифры. Потом послушал мнение Джоеля и успокоился.
Неужели такое возможно? Какое у вас реальное покрытие всего проекта? Не какого-то отдельного модуля а именно всего? Что вам пишет TeamCity?

Вопросы задавать конечно можно, отвечаем с удовольствием :)
1. У нас около 8 разработчиков, менеджер разработки, который тоже пишет код и верстальщик, который сильно участвует в программировании client-side. Изначально все разработчики были опытными и их было двое. Потом еще пара опытных присоединилась. За последнее время появилось трое вчерашних или сегодняшних студентов. Тесты человек может начать изменять прямо сразу, а все остальное зависит от его бэкграунда (например, писал ли он до этого веб-приложения, программировал ли на .NET) Первое время новичок конечно сидит в паре в режиме read-only почти независимо от его уровня, привыкает к нашим подходам и стилю кодирования. А потом многие уже начинали фиксить баги и забирать клавиатуру у напарника. Мы стараемся не создавать каких-то собственных монструозных фрэймворков, это снижает порог вхождения. Максимальный срок, который проходил до полного погружения — 3 месяца
2. У нас более 400 экранов. Каждый экран это разметка и довольно много javascript, плюс вызов нескольких классов с серверной бизнес-логикой. Еще сервис справочников, для того, чтобы подсказывать юзеру адрес при вводе, сервис печати, всякие роботы, которые отсылают отчеты в налоговую или в пенсионный фонд. Размер довольно велик, фунционально я думаю у нас больше фич, чем, например, у вконтакте. Хотя может я там не всем пользуюсь :) Насчет ядра и владения кодом. У нас нет чего-то, что можно быо бы назвать ядром. И у нас нет разработчиков ядра. Любой разработчик пишет server-side и client-side и сервис потрогать может. Пары все время разбиваются и меняются. У нас нет областей отвественности, но есть люди которые лучше представляют разные участки системы. Порой создается ситуация узкой специализации, мы с ней сразу же начинаем настойчиво бороться. Самое главное, что мы не делим людей на аристократов, которые пишут некое ядро и плебеев, которые делают печатные формы. Тимлидер тоже делает печатные формы, а новичок в паре с кем-то, вполне своими руками может внести изменения в какой-то важный класс.
3. Нет, не используем. Мы для этого используем code review. Злой reviewer стирает плохой код безжалостно и демонстрирует хороший :)
4. Если вы пишете в режиме tdd у вас ведь не может быть непокрытого тестами кода, верно? :) На практике конечно 100% покрытие невозможно, например нельзя до конца честно оттестировать корректно ли мы делаем pdf или excel документ. У нас классы бизнес-логики покрыты тестами очень хорошо, тесты их и породили. А взаимодейтвие мы тестируем функциональными тестами, там наверное покрытие вообще не померять, набор вариантов ввода в форму очевидно очень велик, мы тестируем принципиальные моменты и нюансы. Что пишет ТимСити завтра посмотрю :)
Еще у нас есть iphone-разработчик, но он в наши игры не сильно играет :)
В первом пункте про тесты вы пишете «модульные тесты». Вы имеете в виду юнит-тесты (тестирование каждого класса в изоляции от других классов) или именно модульные тесты (мелко-интеграционные, включающие взаимодействие двух-трех-нескольких классов)?
У нас тут просто жаркие дискуссии по этому поводу :)

Ну и в догонку про технологии — у вас Asp.net MVC? Что майкрософтовская технология — понятно, а какая именно — не очень :)
1. Имеем в виду unit. Модульные тесты это же буквально unit :) Взаимодействие классов может быть в тесте (например экземпляр класса для создания, хочет, чтобы в конструктор передали еще пару классов), мы передаем так называемые Mockи обычно.
2. Asp.Net WebForms
>2. Asp.Net WebForms

Суровые ребята! Хотя понятно, что когда начинали Asp.Net MVC могло еще не быть.
У нас огромный, десятилетний проект (просто залежи говнокода :) постепенно, шаг за шагом переводится на MVC.
На самом деле было уже MVC, но еще невнятное. А мы как-то не видим смысла переводить на MVC, запаривались, чтобы говнокода не было, в вебе серверный код максимально тупой, просто делает перевызовы к классам, а всякими событиями и своими WebControlами мы пользуемся ограниченно и вдумчиво
Честно-говоря, после использования MVC 3 с Razor (ну и jQuery конечно), WebForms вспоминаются как ад. В MVC контроллерах тоже логики минимум, но сама концепция — посто сказка!
А нам хорошо, нам даже не надо вспоминать ад — мы в нём :))) Хотя местами концепция WebForms во многом нам помогла и определила направление развития клиент-сайд части. Если интересны подробности, могу вкратце рассказать, хотя это вполне возможно может потянуть на отдельный пост.
Да, расскажите пожалуйста.

В нашем случае ад усугубился свежеиспеченным жопоголовым архитектом, который на одной из конференций внезапно услышал модное слово «MVP», а переубедить руководство не следовать этому бреду мне не удалось.
Вот тут настал настоящий пипец!

К счастью сейчас тот архитект слил, наняли двоих умных и опытных ребят и все пошло как по маслу.
Благодаря вынесению большей части логики на клиент + использованию Repository Pattern делает кодебехайнды довольно компактными, поэтому ада нет (по крайней мере на новых страницах), туда всего лишь надо заинжектить нужные репозитории и потом в нужном месте присунуть вызов к репозиторию через DataBind синтаксис (мы пришли к выводу, что круто иметь один глобавльный DataBind(), хотя у нас этого не получается сделать, так как есть куча старых мест, где с датабиндами всякое колдунство).
Т.к. на клиенте очень много логики надо уметь удобно с этим работать, поэтому мы почти не пишем low level JS кода, а строим абстракции над страницами (почти как в функциональных тестах). Работа строится так: создаём страницу, накидываем на неё контролов (UserControlы или WebControlы), которые помимо своей вёрстки пишут рядышком JS, который регистрирует контрол (экземпляр JS «класса») в глобальном дереве контролов (которое может быть какой угодно глубины, за счёт наличия композитных контролов, типа лайтбоксов, которые могут содержать другие контролы). JS «классы» контролов пишутся в соответствии с MVC, сложные контроллеры покрываются тестами. В итоге, чтобы подвеситься на change какого-нибудь инпута MyInput (именно такая айдишку мы даём в ASP коде, просто пишем <x:InnInput id=«MyInput» runat=«server» /> и больше ничего) достаточно в конструкторе JS «класса» страницы написать this.controls.MyInput.change(somecallback).

Вкратце как-то так
Я потому и уточнил, что под «модулем» может подразумеваться и класс, и, допустим, библиотека :) С тех. терминологией в русском языке не все утряслось еще.

За ответ спасибо, хотя по первому пункту и было бы любопытно подискутировать, но будет совсем оффтопик :)
Можно и подискутировать :) Мое мнение по первому пункту такое — так делать вполне нормально (тестировать логику интеграционно), но tdd так не получится. Зато в качестве бонуса получатся более полные примеры использования классов
получится «почти-тдд» :) Написать тест сначала для маленькой подсистемы проблем обычно нет. Они выполняются подольше — это минус, да.

А у вас хрупкими тесты не получаются? То есть если какая-нибудь функция перешла из одного класса в соседний, это не влечет массовый тестоповал? :)
Если я все верно понял, то нет. Сломается компиляция, по ошибкам компиляции вы придете к тестам, которые по-прежнему предполагают наличие этой функции в классе A, если вы соблюдаете принцип SRP из SOLID, то таких тестов не много, потому что функция должна делать толко одно дело, вы понимаете, что надо все перезамкнуть на класс B и вообще никто не свалится после того, как начнет компилироваться. Другой вопрос, что если вы соблюдаете SRP то непонятно какого черта вы функцию в какой-то другой класс потащили? :) Хотя конечно может пролезла в код гомосятина, класс раньше делал 2 дела, вы решили дать классу одну отвественность и исправить эту досадную оплошность.
Молодцы.
У нас всё так же, только мы используем модель feature branches.
Это позволяет в любое время иметь stable сборку и избавляет от необходимости некоторых мелочей типа упомянутой вами pre-commit code review (коммит в принципе ничего не ломает и его ревьюят позже).
А мы делаем precommit-review не потому что коммит может сломать. Просто хочется делать ревью пока все помнят контекст и не обкладывать этот процесс всякими автоматизирующими инструментами. Все прозрачно, хочешь закоммитить, зовешь ревьюера, он ревьюит. Это гарантирует, что точно отревьюят пока автор помнит, что он там писал-то :)
Ааа, вот в чем дело. У нас просто сильная декомпозиция задач, коммиты частые, и звать ревьюера на каждый — чудовищно отвлекать его от работы. Поэтому контекстом является вся feature в целом, перед merge.
Тем не менее, вы реально молодцы, с удовольствием пообщался бы в оффлайне.
Евгений не пишет код с тех пор как мы перешли на dvcs, поэтому информация немного неактуальная :D Сейчас у нас такая же идеология как и у вас (feature branches), но ревьюим мы чаще, чем один раз перед вливанием, потому что порой фичи низшего уровня декомпозиции иногда бывают слишком объёмными и ревью такой фичи может занять день, что очень печалит и выматывает.
Sign up to leave a comment.