Добрый вечер, коллеги. Ровно месяц назад мы получили контракт на перевод книги "Modern Java" от издательства Manning, которая должна стать одной из наших самых заметных новинок в будущем году. Проблема «Modern» и «Legacy» в Java настолько остра, что необходимость такой книги довольно назрела. Масштабы бедствия и способы решения возникающих проблем в Java 9 кратко описаны в статье Уэйна Ситрина (Wayne Citrin), перевод которой мы и хотим вам сегодня предложить.
Читать полностью »
Рубрика «legacy» - 3
Руководство по Java 9 для тех, кому приходится работать с legacy-кодом
2018-07-20 в 15:05, admin, рубрики: java, java 9, Jigsaw, legacy, Блог компании Издательский дом «Питер», книги, контроль версий, ооп, Программирование, Проектирование и рефакторингКак выживать в изменяющемся мире разработки
2018-06-13 в 13:30, admin, рубрики: CTO, legacy, Карьера в IT-индустрии, Программирование, разработка, Разработка веб-сайтов, управление разработкой, устаревание, фронтендС коллегами зашел разговор о постоянном самосовершенствовании программиста в личное время. Нужно всё время бежать, чтобы просто оставаться на месте. Сам-то я это дело люблю, и, несмотря на наличие троих детей, успеваю пощупать новые концепции. Но множество людей просто устало от такой беготни, и их можно понять.
Взять к примеру, мир фронтенда. Со знанием JavaScript пятилетней давности сейчас хорошую работу не найдешь. Сейчас RequireJS + Grunt не прокатят, надо знать React, Webpack, современный ES или TypeScript и т.д. Причем в следующем году многое уже снова устареет.
При этом не всегда на работе можно получить новые знания, потому что зачастую там тонны легаси (если долго пилится какой-то продукт — это неизбежно), которые никто переписывать "по модному" не даст.
Что же делать? Делать pet projects по ночам? Или пытаться сменить направление развития на более стабильное во времени?
Особенно часто этот вопрос встает у программистов с детьми. Как оставаться актуальным на рынке в долгой перспективе, не тратя на это всё личное время?
DevConf: из шаурмы в Symfony или миграция legacy
2018-04-27 в 13:00, admin, рубрики: devconf, legacy, php, symfony, Блог компании DevConf, Проектирование и рефакторинг, Разработка веб-сайтовПод занавес прошлогоднего DevConf Артем Дегтярь и Павел Степанец рассказали как они мигрировали ERP-систему написанную на «голом» PHP5.3, работающую на винде, в Symfony + PHP7, и построили на его основе облачный сервис в сфере b2b. Видео доступно по ссылке доклада. А я представлю текстовый, немного сжатый, вариант.
Мы работали над большой системой, которая позволяла создавать заявки и менять статусы, плюс биллинг, учет ТМЦ и много всего. Сегодня мы расскажем как рефакторили эту систему, мигрировали ее в Symfony. Первоначально система была написана на чистом PHP, и имела много «особенностей». Например, этот пятиуровневый тернарник на слайде весьма оригинально работал с датой, пришедшей от юзера. Читать полностью »
Как прикрутить нормальный поиск к устаревшему SQL-бэкенду
2017-10-25 в 9:04, admin, рубрики: elastic, elasticsearch, java, joker, joker2016, joker2016spb, legacy, nosql, sql, text search, Блог компании JUG.ru GroupКак совместить миры SQL и NoSQL? В этой статье будет несколько живых примеров интеграции продвинутого поискового движка Elasticsearch в устаревшие приложения, работающие с RestX, Hibernate и Postgresql/MySQL.
Расскажет об этом Дэвид Пилато (David Pilato) — эксперт компании Elastic (это те ребята, что сделали Elasticsearch, Kibana, Beats, and Logstash — то есть, Elastic Stack). У Дэвида есть огромный опыт проведения докладов о продуктах Elastic (конференции Devoxx в Англии, Бельгии и Франции, всевозможные JUG, Web5, Agile France, Mix-IT, Javazone, доклады для конкретных компаний, и так далее). Иначе говоря, излагает Дэвид весьма понятно и доходчиво, а его доклады заменяют тренинги за сотни нефти.
В основе этой публикации — доклад Дэвида на конференции Joker 2016, которая прошла в Санкт-Петербурге в минувшем октябре. Тем не менее, обсуждаемые темы за прошедший год никак не потеряли актуальности.
Статья доступна в двух вариантах: видеозапись доклада и полная текстовая расшифровка (жмите кнопку «читать дальше» ⇩). В текстовом варианте все необходимые данные представлены в виде скриншотов, так что вы ничего не потеряете.
Как перешагнуть через legacy и начать использовать статический анализ кода
2017-08-31 в 6:58, admin, рубрики: legacy, legacy code, pvs-studio, sonarqube, static code analysis, Visual Studio, Блог компании PVS-Studio, Компиляторы, Разработка под Linux, разработка под windows, статический анализ кода
Проблемы legacy-кода знакомы подавляющему большинству разработчиков программного обеспечения. Процесс превращения кода в legacy неизбежен, ведь прогресс в программировании не стоит на месте. Проекты либо «умирают» навсегда, либо требуют постоянной поддержки и написания новых функций. Таким образом, в любом проекте на любом языке программирования legacy-код возникает и доставляет разные неудобства при дальнейшей разработке. На примере PVS-Studio, в этой статье я расскажу, как сразу начать использовать статический анализатор кода в своём проекте.
Читать полностью »
Команда PHP-фреймворка Yii выпустила версию 1.1.19. Получить её можно либо через Composer, либо архивом со страницы.
Данная версия является релизом ветки Yii 1.1, которая достигла EOL и получает только исправления безопасности и поддержки PHP 7.
Релизы, такие как этот, позволяют обновить PHP на серверах с Yii 1.1 и, тем самым, обновиться на поддерживаемые командой PHP-версии.
Yii 1.1.19 совместим с PHP 7.1, патчи безопасности на который будут выходить до 1 декабря 2019.
StringBuffer, и как тяжело избавиться от наследия старого кода
2017-06-02 в 7:07, admin, рубрики: java, legacy, stringbuffer, stringbuilder, жизнь-больВсем привет.
Эта статья — вольный перевод поста StringBuffer, and how hard it is to get rid of legacy code. Как-то очень он мне запал в душу, поэтому решил перевести. Поехали.
В 2006-м, в 5-й java появился StringBuilder
. Более легковесная и разумная альтернатива StringBuffer
. Вот, что говорит официальная документация по StringBuffer
:
Этот класс дополнен аналогичным классом предназначенным для использования в одном потоке — StringBuilder. В общем случае нужно отдавать предпочтение классу StringBuilder, так как он поддерживает все те же операции, что и этот (StringBuffer), но быстрее, так как не выполняет никаких синхронизаций.
Иметь synchronized
в StringBuffer
вообще никогда не было хорошей идеей. Основная проблема в том, что одной операции никогда не достаточно. Одиночная конкатенация .append(x)
бесполезная без других операций, таких как .append(y)
и .toString()
. В то время, когда каждый конкретный метод потокобезопасный, вы не можете сделать несколько вызовов без конкуренции между потоками. Ваша единственная опция — внешняя синхронизация.
Так, что? Получается, 10 лет спустя уже никто не использует StringBuffer!? Ну, по крайней мере, точно не для нового функционала!?
Сколько объектов создает этот код?
Как я уже писал раньше, виртуальная машина создает много объектов на старте или при загрузке основных библиотек. Гораздо больше, чем Вы могли бы представить, задавая вопрос выше:
public class Main {
public static void main(String... args) {
System.out.println("Hello " + "world");
}
}
Oracle JVM 8-й версии создает приблизительно 10_000 объектов для выполнения этой программы.
Сколько же это создается StringBuffers?
Псевдо-инкапсуляция легаси include-ов когда нет времени рефакторить
2016-12-01 в 13:57, admin, рубрики: adapter, flyweight, legacy, php, refactoring, ненормальное программирование, ооп, Программирование, Проектирование и рефакторингСегодня хочу рассмотреть миграцию кода из далекого прошлого в современный фреймворк.
Наиболее частая ситуация, которую я могу привести в пример — str_repeat('очень-', 20) старый код, не знающий даже классов, планируется перенести или частично использовать в современном фреймворке, но переписывать тысячи строк и десятки зависимостей нет времени. Такое бывает, когда заказчик вдруг решает существенно модернизировать или развивать проект, который 10+ лет работал без изменений, а сапортил его один парттайм-олдскул-программист изредка перезагружая пару-тройку сервисов и восстанавливая пароли.
Читать полностью »
«Керосинка» против «Патриотов»: как американские военные программисты научились правильно округлять
2016-10-18 в 10:35, admin, рубрики: legacy, баг, Блог компании PVS-Studio, отладка, программные ошибки, Промышленное программирование, статический анализатор, Тестирование IT-систем, юнит-тестирование11 февраля 1991 года Patriot Project Office получил израильские данные о дефекте в ракетной системе Patriot. Они нашли, что если система работает 8 часов, она начинает мазать на 20%. Они прикинули, что после 20 часов работы система начинает промахиваться настолько, что перестанет быть способной захватывать, отслеживать и поражать баллистические ракеты. Американские военные не приняли во внимание всю важность открытия, заявив, что система предназначена для портативных и краткосрочных защитных операций и что никто никогда не будет использовать систему больше 8 часов.
16 февраля был выпущен Bug Fix, но чтобы его внедрить во все единицы боевой техники, требовалось время, ибо война.
21 февраля военные выпускают указание, что система не должна работать «долго». Военные не уточнили сколько длится «долго».
25 февраля в Дахране (Саудовская Аравия) в казарму в гости к американцам прилетела баллистичекая ракета "керосинка" (она же Р-17, она же Scud). 28 убито 96 ранено, потому что ЗРК «Патриот» промахнулся из-за программной ошибки.
26 февраля Bug Fix был доставлен в Дахран.
На хабре есть много статей, как сделать хорошо. Есть много статей, как делать не стоит.
Но что, если у вас есть проект, который работает, приносит бизнесу деньги, но из программистов, что-то в нем понять, не способен почти никто. Каждое изменение делается на страх и риск сыграть в русскую рулетку.
Хорошо, когда у вас есть годик или два для подготовки нового проекта с нуля (был у меня и такой опыт). Но если владелец не готов вкладываться в то, что вы будете что-то делать параллельно с нуля, пока старый движок во всю загибается. Попытки даже заговорить, о том, чтобы написать все по новой, встречают моментальный отказ. Но можно попробовать маленькими шажками, делать новый движок, который постепенно бы начал забирать на себя всю большую и большую роль в работе проекта. Собственно об опыте осуществить такую замену, я бы и хотел вам рассказать.
Читать полностью »