Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.
Резонный вопрос: зачем вообще может понадобится переписывать программу, которая уже написана и нормально работает?
Рубрика «рефакторинг» - 7
Как победить дракона: переписываем вашу программу на Golang
2019-01-24 в 6:10, admin, рубрики: dapp, Go, golang, ruby, werf, Анализ и проектирование систем, архитектура, Блог компании Флант, ооп, переписывание, Программирование, Проектирование и рефакторинг, проектирование по, рефакторинг
Разработка команды запроса данных из базы — часть 4, завершающая
2019-01-18 в 15:37, admin, рубрики: javascript, tdd, гибкое проектирование, Проектирование и рефакторинг, рефакторингЭто продолжение истории, которая началась здесь, а продолжалась здесь и здесь.
В прошлой части я написал интеграционный тест, демонстрирующий процесс инициализации и выполнения полного набора обработчиков, извлекающих данные из базы. Но поскольку от написания этого теста, до его запуска, может пройти слишком длительное время, необходимое для кодирования не только обработчика, но и правил настройки для всех необходимых запросов к базе, то сегодня я решил реализовать его модульную версию, расчитанную на конфигурирование и запуск всего одного обработчика. Выглядит это тест вот как:Читать полностью »
Разработка команды запроса данных из базы — часть 2
2019-01-16 в 14:25, admin, рубрики: javascript, tdd, гибкое проектирование, Проектирование и рефакторинг, рефакторингВ предыдущей части я остановился на том, что разрабатываемая мной команда реализует поведение, которое можно описать вот таким тестом:
it('execute should return promise', () => {
request.configure(options);
request.execute().then((result) => {
expect(result.Id).toEqual(1);
expect(result.Name).toEqual('Jack');
});
});[] 5 простых правил удобного для восприятия кода
2019-01-15 в 11:07, admin, рубрики: C#, Анализ и проектирование систем, архитектура, мозг, Программирование, Промышленное программирование, рефакторинг, чистый кодУскользает понимание своего или чужого кода?
Не можете вникнуть в алгоритм?
Проводите кучу время в отладке, но найти место неверной инициализации не получается, а хочется получать удовольствие от кодирования?
Вспомните о приведенных ниже правилах и примените их!
В статье не рассматриваются базовые правила именования переменных и функций, синтаксические отступы и масштабная тема рефакторинга. Рассматриваются 5 простых правил по упрощению кода и снижению нагрузки на мозг в процессе разработки.
Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.
Упрощенный процесс восприятия состоит из следующих этапов:
- Поступающая через рецепторы данные соотносятся с предыдущим опытом.
- Если соотнесения нет – это шум. Шум быстро забывается. Если есть с чем соотнести, происходит опознавание фактов.
- Если факт важен — запоминаем, либо обобщаем, либо действуем, например говорим или набираем код.
- Для сокращения объема запоминаемой и анализируемой информации используется обобщение.
- После обобщения, информация вновь соотносится и анализируется (этап 1).
Как не надо писать шаблоны для bootstrap
2018-12-27 в 15:54, admin, рубрики: css, переиспользование кода, Проектирование и рефакторинг, рефакторингМало кто сейчас пишет дизайн сайта с нуля — зачем, если есть куча замечательных CSS фреймворков? Наиболее популярен среди них bootstrap. Тем не менее, всем хочется, чтобы сайт выглядел уникально, не так как у других — поэтому поверх часто втыкают(в меру возможностей) бесплатный или платный шаблон, либо свой UI кит.
О некоторых проблемах, которые(к сожалению) встречаются даже в платных шаблонах, не говоря уж о своих решениях, я и хочу поговорить. Текст ниже не претендует на уникальность, и вряд ли будет интересен опытным разработчикам, но может оказаться полезным для начинающих фронтендеров, верстальщиков и веб разработчиков широкого профиля. Итак, если вам всё ещё интересно, добро пожаловать!
Читать полностью »
Как выруливать с legacy code, когда проект нужно было на вчера
2018-11-29 в 15:36, admin, рубрики: legacy code, php, Программирование, Проектирование и рефакторинг, рефакторингПривет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.
Разбираемся с проектом
Для того, чтобы передать насколько аккуратной, продуманной и кропотливой, должна быть работа с легаси, приведу аналогию с карточным домиком.
Именно так выглядит устаревший код. Если мы решим убрать или заменить хотя бы одну карту из этой постройки, мы рискуем завалить весь дом и сровнять его остатки с землей.
Примерно так же “ведет” себя легаси. Поэтому работа программиста, который взялся за задачу модернизировать и “вдохнуть вторую жизнь” в проект, должна быть в некой степени ювелирной. Большинство программистов пытаются избегать и вообще “спрыгнуть с темы” технического долга. Даже составил хит-парад самых распространенных цитат, которые приходилось слышать от программистов, оказавшихся в условиях legacy:
Читать полностью »
Общая игровая логика на клиенте и сервере
2018-11-12 в 10:40, admin, рубрики: ecs, entity component system, unity3d, Блог компании Pixonic, геймдев, игровая логика, игры, код, кодогенерация, конференции, проектирование, Проектирование и рефакторинг, разработка, разработка игр, рефакторингНа Pixonic DevGAMM Talks выступал еще наш DTO Антон Григорьев. Мы в компании уже говорили, что работаем над новым PvP-шутером и Антон поделился некоторыми нюансами архитектуры этого проекта. Он рассказал, как построить разработку, чтобы изменения в игровой логике клиента появлялись на сервере автоматически (и наоборот), и можно ли не писать код, но при этом минимизировать трафик. Ниже — запись и расшифровка доклада.
Принцип KISS в разработке
2018-10-29 в 12:30, admin, рубрики: Блог компании Pixonic, геймдев, игры, код, конференции, проектирование, Проектирование и рефакторинг, разработка, разработка игр, рефакторинг, управление, управление разработкой, философияСледующий доклад с Pixonic DevGAMM Talks, который мы расшифровали, немного философский — это выступление Константина Гладышева. Он Lead Game Programmer в 1C Game Studios и рассказывал о принципе управления сложностью разработки в контексте всего продукта, а не отдельных фичей. И на примерах показал, почему главное в разработке — это определить, чего делать не надо. Про другие доклады можно почитать по ссылкам в конце статьи.
Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса
2018-09-17 в 7:00, admin, рубрики: Блог компании Яндекс, бюджетные смартфоны, Клиентская оптимизация, новый рынок, оперативная память, оптимизация приложений, разработка мобильных приложений, Разработка под android, рефакторингНовые направления развития уже знакомой платформы — это всегда интересно. С одной стороны, вы расширяете клиентскую базу, с другой — не вкладываетесь в создание софта с нуля, а используете существующие наработки. Но если направление действительно новое, со своей спецификой, то совсем малой кровью обойтись не удастся. На очередной встрече сообщества Mosdroid в нашем офисе разработчик Артур Василов рассказал об адаптации приложения «Яндекс» под систему Android Go.
В среднем, если вы не пишете калькулятор, будильник и прочее, то либо вы очень классный, большой молодец и все сделали хорошо, либо ваше приложение занимает 150–170 мегабайт.
Товар или сервис
2018-08-19 в 17:23, admin, рубрики: legacy, автоматические тесты, баги, качественный софт, программа, Программирование, продукт, Проектирование и рефакторинг, разработка, рефакторинг, сервис, тестирование, управление, Управление продуктом, управление проектами, Управление проектом, управление разработкойНа Хабре (да и в реальной IT жизни) встречаeтся много вопросов вида:
- Надо ли обновлять систему (или зависимости в приложении), если и так всё работает?
- Нужны ли вообще тесты (автотесты) в приложении (вы ведь на них потратите своё время и деньги заказчика)?
- Если ли смысл в паттернах и выделении абстракций (ведь подобное размазывает код, приводит к снижению производительности и т.д.)?
Ключевой вопрос во всех примерах ниже: что вы разрабатываете: товар или сервис? Как ни странно, но как только вы ответите на этот вопрос о товарах и сервисах, все сомнения о необходимости тестов, абстракций и т.д. отпадут сами собой.