А мы делаем precommit-review не потому что коммит может сломать. Просто хочется делать ревью пока все помнят контекст и не обкладывать этот процесс всякими автоматизирующими инструментами. Все прозрачно, хочешь закоммитить, зовешь ревьюера, он ревьюит. Это гарантирует, что точно отревьюят пока автор помнит, что он там писал-то :)
На самом деле было уже MVC, но еще невнятное. А мы как-то не видим смысла переводить на MVC, запаривались, чтобы говнокода не было, в вебе серверный код максимально тупой, просто делает перевызовы к классам, а всякими событиями и своими WebControlами мы пользуемся ограниченно и вдумчиво
Если я все верно понял, то нет. Сломается компиляция, по ошибкам компиляции вы придете к тестам, которые по-прежнему предполагают наличие этой функции в классе A, если вы соблюдаете принцип SRP из SOLID, то таких тестов не много, потому что функция должна делать толко одно дело, вы понимаете, что надо все перезамкнуть на класс B и вообще никто не свалится после того, как начнет компилироваться. Другой вопрос, что если вы соблюдаете SRP то непонятно какого черта вы функцию в какой-то другой класс потащили? :) Хотя конечно может пролезла в код гомосятина, класс раньше делал 2 дела, вы решили дать классу одну отвественность и исправить эту досадную оплошность.
Вопросы задавать конечно можно, отвечаем с удовольствием :)
1. У нас около 8 разработчиков, менеджер разработки, который тоже пишет код и верстальщик, который сильно участвует в программировании client-side. Изначально все разработчики были опытными и их было двое. Потом еще пара опытных присоединилась. За последнее время появилось трое вчерашних или сегодняшних студентов. Тесты человек может начать изменять прямо сразу, а все остальное зависит от его бэкграунда (например, писал ли он до этого веб-приложения, программировал ли на .NET) Первое время новичок конечно сидит в паре в режиме read-only почти независимо от его уровня, привыкает к нашим подходам и стилю кодирования. А потом многие уже начинали фиксить баги и забирать клавиатуру у напарника. Мы стараемся не создавать каких-то собственных монструозных фрэймворков, это снижает порог вхождения. Максимальный срок, который проходил до полного погружения — 3 месяца
2. У нас более 400 экранов. Каждый экран это разметка и довольно много javascript, плюс вызов нескольких классов с серверной бизнес-логикой. Еще сервис справочников, для того, чтобы подсказывать юзеру адрес при вводе, сервис печати, всякие роботы, которые отсылают отчеты в налоговую или в пенсионный фонд. Размер довольно велик, фунционально я думаю у нас больше фич, чем, например, у вконтакте. Хотя может я там не всем пользуюсь :) Насчет ядра и владения кодом. У нас нет чего-то, что можно быо бы назвать ядром. И у нас нет разработчиков ядра. Любой разработчик пишет server-side и client-side и сервис потрогать может. Пары все время разбиваются и меняются. У нас нет областей отвественности, но есть люди которые лучше представляют разные участки системы. Порой создается ситуация узкой специализации, мы с ней сразу же начинаем настойчиво бороться. Самое главное, что мы не делим людей на аристократов, которые пишут некое ядро и плебеев, которые делают печатные формы. Тимлидер тоже делает печатные формы, а новичок в паре с кем-то, вполне своими руками может внести изменения в какой-то важный класс.
3. Нет, не используем. Мы для этого используем code review. Злой reviewer стирает плохой код безжалостно и демонстрирует хороший :)
4. Если вы пишете в режиме tdd у вас ведь не может быть непокрытого тестами кода, верно? :) На практике конечно 100% покрытие невозможно, например нельзя до конца честно оттестировать корректно ли мы делаем pdf или excel документ. У нас классы бизнес-логики покрыты тестами очень хорошо, тесты их и породили. А взаимодейтвие мы тестируем функциональными тестами, там наверное покрытие вообще не померять, набор вариантов ввода в форму очевидно очень велик, мы тестируем принципиальные моменты и нюансы. Что пишет ТимСити завтра посмотрю :)
Можно и подискутировать :) Мое мнение по первому пункту такое — так делать вполне нормально (тестировать логику интеграционно), но tdd так не получится. Зато в качестве бонуса получатся более полные примеры использования классов
1. Имеем в виду unit. Модульные тесты это же буквально unit :) Взаимодействие классов может быть в тесте (например экземпляр класса для создания, хочет, чтобы в конструктор передали еще пару классов), мы передаем так называемые Mockи обычно.
2. Asp.Net WebForms
Ну это если нет никаких вариантов. Например дистанционной регистрации ООО нет, что тут поделаешь (: А тут-то можно подождать электронного формата, вполне реально, что он скоро выйдет
ORM — Linq 2 SQL. Можем сказать, что это очень легкий ORM, который легко использовать. Мы стараемся работать с базой в не реляционном стиле, нормальными формами там и не пахнет. Первая версия системы была на файлах. Сейчас все в таблицах, но мы можем скакануть на какую-нибудь Кассандру в любой момент, если пользователи начнут нас настолько любить, что текущие технологии перестанут вывозить нагрузку.
DI контейнер был Windsor в начале, давно уже пользуемся RoboContainer, это опен-сорс разработка Павла Егорова — разработчика Контура. Очень хорошая вещь, сама делает много предположений, то, что очевидно без конфигурирования, не приходится конфигурировать никогда
Ресурсы у МоегоДела изначально были несопоставимы с Контуром, я слышал, что Максим даже машину продавал, чтобы были деньги на разработку. Да и сейчас несопоставимы
Мне очень нравится фраза, которую я прочитал в книге «Прорыв в духе времени»: Гугл относится несерьезно ко всему кроме поиска. Я держу сотрудников в Эльбе не за то, что они ходят в кедах и имеют чувство юмора, а потому что они по настоящему крутые. Любой человек, который видел наши интерфейсы может сам сделать вывод о профессионализме и внимании к деталям. А МоеДело молодцы, не обладая изначально серьезными ресурсами, уже который год работают, делают всякие успехи, нас вот шевелят, может конечно не вполне корректно :) Я счастлив, что у нас есть конкуренты, это очень хорошо и правильно, а выбор сделают пользователи, их лозунгами не привлечь, ни Эльбе, ни МоемуДелу, только работать, других вариантов нет.
1. У нас около 8 разработчиков, менеджер разработки, который тоже пишет код и верстальщик, который сильно участвует в программировании client-side. Изначально все разработчики были опытными и их было двое. Потом еще пара опытных присоединилась. За последнее время появилось трое вчерашних или сегодняшних студентов. Тесты человек может начать изменять прямо сразу, а все остальное зависит от его бэкграунда (например, писал ли он до этого веб-приложения, программировал ли на .NET) Первое время новичок конечно сидит в паре в режиме read-only почти независимо от его уровня, привыкает к нашим подходам и стилю кодирования. А потом многие уже начинали фиксить баги и забирать клавиатуру у напарника. Мы стараемся не создавать каких-то собственных монструозных фрэймворков, это снижает порог вхождения. Максимальный срок, который проходил до полного погружения — 3 месяца
2. У нас более 400 экранов. Каждый экран это разметка и довольно много javascript, плюс вызов нескольких классов с серверной бизнес-логикой. Еще сервис справочников, для того, чтобы подсказывать юзеру адрес при вводе, сервис печати, всякие роботы, которые отсылают отчеты в налоговую или в пенсионный фонд. Размер довольно велик, фунционально я думаю у нас больше фич, чем, например, у вконтакте. Хотя может я там не всем пользуюсь :) Насчет ядра и владения кодом. У нас нет чего-то, что можно быо бы назвать ядром. И у нас нет разработчиков ядра. Любой разработчик пишет server-side и client-side и сервис потрогать может. Пары все время разбиваются и меняются. У нас нет областей отвественности, но есть люди которые лучше представляют разные участки системы. Порой создается ситуация узкой специализации, мы с ней сразу же начинаем настойчиво бороться. Самое главное, что мы не делим людей на аристократов, которые пишут некое ядро и плебеев, которые делают печатные формы. Тимлидер тоже делает печатные формы, а новичок в паре с кем-то, вполне своими руками может внести изменения в какой-то важный класс.
3. Нет, не используем. Мы для этого используем code review. Злой reviewer стирает плохой код безжалостно и демонстрирует хороший :)
4. Если вы пишете в режиме tdd у вас ведь не может быть непокрытого тестами кода, верно? :) На практике конечно 100% покрытие невозможно, например нельзя до конца честно оттестировать корректно ли мы делаем pdf или excel документ. У нас классы бизнес-логики покрыты тестами очень хорошо, тесты их и породили. А взаимодейтвие мы тестируем функциональными тестами, там наверное покрытие вообще не померять, набор вариантов ввода в форму очевидно очень велик, мы тестируем принципиальные моменты и нюансы. Что пишет ТимСити завтра посмотрю :)
2. Asp.Net WebForms
DI контейнер был Windsor в начале, давно уже пользуемся RoboContainer, это опен-сорс разработка Павла Егорова — разработчика Контура. Очень хорошая вещь, сама делает много предположений, то, что очевидно без конфигурирования, не приходится конфигурировать никогда