Что значит legacy перевод? как понять legacy? значение и смысл

Legacy — это… Что такое Legacy?

Что значит legacy перевод? Как понять legacy? Значение и смысл

  • legacy — leg·a·cy / le gə sē/ n pl cies [Medieval Latin legatio, from Latin legare to bequeath]: a gift of property by will; specif: a gift of personal property by will: bequest see also ademption compare devise conjoint leg …   Law dictionary
  • Legacy — or legacies may refer to:Buildings* Legacy Tower, a Skyscraper under construction in Chicago * Legacy Village, an outdoor shopping complex in Lyndhurst, OhioComics* Legacy (heroclix), the fourth DC Heroclix set produced by Wizkids * Legacy Virus …   Wikipedia
  • Legacy — Leg a*cy (l[e^]g [.a]*s[y^]), n.; pl. {Legacies} ( s[i^]z). [L. (assumed) legatia, for legatum, from legare to appoint by last will, to bequeath as a legacy, to depute: cf. OF. legat legacy. See {Legate}.] 1. A gift of property by will, esp. of… …   The Collaborative International Dictionary of English
  • Legacy — (englisch Erbe) bezeichnet: ein deutschsprachiges Musikmagazin, Legacy (Musikmagazin) in der Wirtschaftsinformatik eine historisch gewachsene Anwendung, siehe Legacy System Subaru Legacy, ein Mittelklasseauto einen amerikanischen Film aus dem… …   Deutsch Wikipedia
  • Legacy — (Сульмона,Италия) Категория отеля: Адрес: Vico Dell Ospedale 54, 67039 Сульмона, Италия …   Каталог отелей
  • Legacy —   [dt. »Vermächtnis«] die, ältere Datenbestände, die möglicherweise nicht mehr problemlos genutzt werden können, weil neue Programme, ein neues Betriebssystem oder ein neues Computersystem eingeführt wurden. Legacy wird auch generell als… …   Universal-Lexikon
  • legacy — late 14c., body of persons sent on a mission, from O.Fr. legatie legate s office, from M.L. legatia, from L. legatus ambassador, envoy, noun use of pp. of legare appoint by a last will, send as a legate (see LEGATE (Cf. legate)). Sense of… …   Etymology dictionary
  • legacy — [n] inheritance, heritage bequest, birthright, devise, endowment, estate, gift, heirloom, throwback, tradition; concepts 337,710 …   New thesaurus
  • legacy — ► NOUN (pl. legacies) 1) an amount of money or property left to someone in a will. 2) something handed down by a predecessor. ► ADJECTIVE ▪ (of computer hardware or software) that has been superseded but is difficult to replace because of its… …   English terms dictionary
  • legacy — [leg′ə sē] n. pl. legacies [ME legacie < OFr < ML legatia < L legatus: see LEGATE] 1. money or property left to someone by a will; bequest 2. anything handed down from, or as from, an ancestor ☆ 3. a student applying or admitted to a… …   English World dictionary
  • legacy — A disposition of personalty by will. A bequest. In a technical sense and strictly construed, legacy is a gift or bequest by will of personal property, whereas a devise is a testamentary disposition of real estate, but such distinction will not be …   Black's law dictionary

Источник: https://traffic_en_ru.academic.ru/3657/Legacy

Legacy-фобия

Коллеги, у меня для вас есть замечательная новость, мы получили чудесный проект, его несколько лет писали неизвестные нам разработчики, адрес которых мы вряд ли узнаем (чтобы «поделиться обратной связью»), писали очень давно и не известно под чем, и нам предстоит его поддерживать и развивать.

Проект сейчас находится на пике своей производительности и мы скоро упремся, любые неаккуратные изменения могут его положить, но мы будем его развивать. Ура! Согласитесь, странно звучит? Как бред больного на голову программиста.

Кто же любит legacy? Это же всегда говнокод (ведь только мы сами пишем идеально), в нем полно багов (а мы сами пишем без ошибок), ужасные решения (ведь только мы сами выбираем подходящую архитектуру), и почти всегда его сложно читать (ведь только мы сами пишем понятно и красиво).

Я знаком с этой страшилкой столько, сколько вообще знаком с областью разработки. Пугание legacy-кодом -­­ это универсальная страшилка для программистов, как для детей история про серого волчка, который придет и укусит за бочок.

Потому хотелось бы немного поломать стереотипы касательно legacy, пусть не всем, но хотя бы части разработчиков, и дать понимание того, насколько на самом деле интересен legacy и что его можно на самом деле не бояться, а даже любить. Сразу оговорюсь, что мы сейчас говорим про код, и только про него.

Не про красивые офисы, привлекательных HRов, крутых лидов и большой PR. Код. Допустим вы разработчик на PHP, и вам бы сказали «Приходи к нам на проект, мы уже пишем этот код на PHP несколько лет, у нас сотни мегабайт кода, почти никакого ООП и процедурное программирование».

Как-то сомнительно звучит в разрезе legacy? А если бы вам сказали «Приходи кодить vk?». Разница есть, и она значительна. Зайдем с другой стороны.

Вам бы сказали: «Слушай, у меня есть для тебя отличная возможность, мне нужно чтобы ты применил все паттерны которые тебе знакомы, можешь использовать любые фреймворки и технологии, можешь написать все с нуля, сделай мне просто домашний блог для моей собачки». Никакого legacy, полный простор мысли и свобода действий. Все можно сделать идеально красиво на модном node.js, прикрутить ajax и comet, поставить кеши на redis, добавить RT поиск с морфологией на elastic’e, но… зачем?

Банальность №1:
Интересный проект — это тот, который интересен разработчику в принципе. Вне языка, вне технологии, вне архитектуры. И это не имеет никакого отношения к legacy.

Вам знакомо чувство, когда думая над новым проектом, вы рисуете у себя в голове картинку того, как какие сущности должны с чем взаимодействовать, какие слои архитектуры надо сделать, где проявятся узкие места и что нужно сделать чтобы этого избежать? Этакий сказочный мир со своими обитателями и связями, который живет своей жизнью и который вы постепенно переводите в код, во что-то осязаемое, что начинает «существовать». Раскрою вам секрет — невозможно писать код, если ты не «художник». Но и художники не сразу могут написать красивые полотна. Они учатся более гармонично подбирать цвета, отображать перспективу, сочетать элементы и т.д. Программисты точно также учатся подбирать решения, видеть будущее проекта и делать все максимально удобным, поддерживаемым, эффективным, и в рамках доступных ресурсов. А если в процессе жизни картины к ней появляются новые требования ­− «А давайте сделаем что теперь вечер. А еще пусть по небу летит дракон. А еще на самом деле сейчас зима, а не лето. И пусть на заднем плане будет Дайнерис убивающая Джорджа Мартина» − в такие моменты сложно сохранить изначальный творческий, в чем-то прекрасный, замысел автора. Когда вы начинаете работать с новым проектом, по факту вы являетесь творцом, изобретателем. Прекрасное чувство. Когда же вы получаете legacy код, проект на поддержку, почему-то у большинства складывается образ, как будто они только что получили Авгиевы конюшни, притом это еще до того, как собственно заглянули в код. Достаточно просто подумать что это legacy. Какой бы не был проект, в его основе тоже лежит картина, может мазки на ней уже не так гармонично сочетаются, но картина была. И пока вы читаете legacy, вы, как исследователь, можете восстановить ее в своей голове, и мало того, вы, как профессионал, можете сделать ее действительно красивой. Грамотно добавить недостающих деталей, дорисовать то, что получилось очень красиво у предыдущих «мастеров», и получить новую картину, уже вашу, и только в ваших силах сделать ее еще лучше, чем она может быть даже была изначально.

Банальность №2:
«Legacy» не значит «некрасиво». Это шанс сделать еще красивее.

Многим знакома фраза «Дурак учится на своих ошибках, а умный на чужих». Если кто-то из вас все же практиковал TDD, то прекрасно знает, что невозможно, при всем профессионализме, всегда писать код без багов, даже с миллионом перестраховок. Это естественное явление.

Так вот если вы достаточно опытны и умеете, как настоящий детектив, исследователь и даже реконструктор, копаться в чужом коде, создавать его образ в своей голове, находить скрытые закономерности, то вы также сможете и извлечь из него немало полезного.

Какие-то странные решения, которые на самом деле были к месту, но вы вдруг задумаетесь, и поймете, что знаете и более оптимальное решение, просто потому что неоптимальное за вас уже написали, и вы увидели его в действии, и теперь то вы знаете, как сделать лучше.

Мы все знаем, что рефакторить можно бесконечно, но чтобы рефакторить, узнавать новое о коде, нужно, чтобы он уже что-то пожил, уже был написан, и тут как раз legacy подходит идеально. Хочу только заметить, что меня в этом поймут только те, кто любит находить новые подходы, кто любит думать не по шаблону.

Читайте также:  Что значит тату буйвол? выбор тату буйвол? значение и смысл

Встречаются разработчики, которые, скорее в силу своей неопытности, встречаясь со старыми проектами, готовы брать знамена и кричать «Да тут сплошной говнокод, все это на самом деле пишется по-другому на %my_favorite_framework%, он идеален, он решает все проблемы, все переписать!!!».

В legacy коде много чему можно научиться при должном подходе и навыках. Прежде всего тому, как видит код другой разработчик, и в чем его подход хорош, а в чем плох. Расширение своей картины мира всегда делает ее еще более полной, если не замыкаться на шаблонных решениях.

По факту, код большинства популярных фреймворков, библиотек и компонентов уже во многом стал legacy. И думаю вы вряд ли станете отрицать, что изучение этого кода никогда не даст вам чего-то нового, ценного для разработчика. Того, что не прочтешь ни в одной книге.

Банальность №3:
Legacy — это отличный учебник того, как надо, и как не надо делать.

Вы когда-нибудь читали книги, которые были очень сложны для вашего восприятия? Возьмите, к примеру, для сравнения стихи Данте, или рассказы Германа Гессе, или Айн Рэнд, или вообще хоть какой-нибудь кодекс РФ.

Знакомо ощущение, когда шестеренки мыслительного процесса начинают ломать друг об друга зубья уже на второй странице? Но разве это каким-либо образом принижает смысловую ценность произведения? Так вот чтение чужого кода порой может быть не менее зубодробительным. Конечно, уже давно придумали такое понятие, как CodeStyle.

Однако, почему-то у многих legacy ассоциируется с чем-то, что очень сложно прочитать, что написано в нарушение всех правил очень давно. На самом же деле тот, кто писал этот код, просто следовал «тем» правилам, и научиться читать код в любом стиле не так уж и сложно.

Банальность №4:
Legacy не так сложно читать, даже если нарушен CodeStyle. К тому же, основные современные IDE уже научились на достойном уровне поддерживать автоформатирование кода.

Как-то давно, на фрилансе, один знакомый заказчик попросил доработать простенький проект на одном известном фреймворке. Ему его изготовил один фрилансер, буквально недавно, но он исчез после получения оплаты, а нужно поправить мелочь.

Каково же было мое удивление, когда я обнаружил копипаст запуска простого контроллера с одним view-файлом, в котором и был расположен весь(!) код проекта. Человек сделал проект «на модном фреймворке», но как(!) сделал.

Если бы этот код отлежался годик-другой, и достался кому-то на поддержку, то он бы с ужасом в глазах сказал бы «Да что это за legacy?!». Но для меня этому коду не было и «недели отроду». Это был обычный, банальный говнокод. Сейчас же я работаю на проекте, код которого развивается уже 12-ый год и будет расти дальше.

И знаете, несмотря на отдельные недостатки, даже очень старые куски смотрятся и читаются очень хорошо. Это legacy, хороший, добротный legacy, много раз доработанный, но все еще читаемый и поддерживаемый legacy.

Банальность №5:
«Legacy» не равно «говнокод».

Случалось ли с вами, что открывая проект за давностью нескольких лет, вы видите код и чувствуете легкое дежа-вю? Как будто из тумана постепенно начинают проявляться очертания чего-то до боли знакомого, почти родного.

И дабы развеять последние сомнения в ход идет blame и annotate, и тут все встает на свои места. Он. Он самый. И в голове начинают крутиться мысли вроде «Да как я такое мог написать?! Эххх, зеленый был. О, а вот это я круто сделал, простенько и со вкусом.

Так так, а вот это надо быстро поправить пока никто не увидел». Знакомо? Так вот многие почему-то думают что legacy это что-то, что бывает с кем-то другим.

Что вы либо никогда не будете смотреть на свой код через несколько месяцев/лет, либо даже не допускаете той мысли, что сейчас пишете что-то, что будет выглядеть как legacy (или уже выглядит так?). Тем не менее, это не так.

Банальность №6:
Вы тоже пишете Legacy.

Резюмируя все вышесказанное, хотелось бы сказать, что как таковой термин legacy не заслуживает чести быть «страшилкой». В нем есть свои замечательные стороны, и лишь неопытность разработчиков, притом не только тех, кто написал код, а порой и тех, кто собирается с ним работать, создает ему такую славу.

Много legacy кода прошло через мои руки, и с большинством из него мне действительно было приятно работать. Разбираться как он работает, пытаться понять замысел автора, находить более подходящие решения или наоборот убеждаться в том, что решение автора хоть и не было очевидным, но оказывалось весьма эффективным.

Дорабатывать уже то, что работает, чем пользуются, делать это лучше — это отличный опыт. Нельзя научиться писать код хорошо, если писать его или всегда по шаблону, или всегда с нуля. Человек все познает в сравнении, и чем больше источников для сравнения, тем лучше вы пишете.

Успехов вам на просторах разработки и побольше хорошего, добротного Legacy-кода! Надеюсь, теперь для вас эта фраза воспринимается иначе, чем до начала статьи. Бонус ввиде списка книг, если еще не прочли:

Refactoring — Improving the Design of Existing Code

Источник: https://habrahabr.ru/post/236449/

legacy systems — это… Что такое legacy systems?

  • Systems Applications Products audit — is when a computer system from SAP undegoes an audit to check its security and data integrity. SAP is the acronym for Systems, Applications, Products. It is a system that provides users with a soft real time business application. It contains a… …   Wikipedia
  • Legacy costs — is a term formed by analogy with the computer industry s legacy systems. Legacy costs are those incured by an organization in prior years under different leadership or when the entity s priorities and resources were different. In business, while… …   Wikipedia
  • Legacy system — A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users needs, even though newer technology or more efficient methods of performing a task …   Wikipedia
  • legacy — ▪ I. legacy leg‧a‧cy 1 [ˈlegəsi] noun legacies PLURALFORM [countable] 1. a situation that exists as a result of things that happened at an earlier time: • Hotels are in oversupply, a legacy of the last building boom. 2 …   Financial and business terms
  • Legacy-System — Der Begriff Altsystem (engl. legacy system) bezeichnet in der Wirtschaftsinformatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist hierbei das englische Wort für Vermächtnis, Hinterlassenschaft,… …   Deutsch Wikipedia
  • Legacy Software — Der Begriff Altsystem (engl. legacy system) bezeichnet in der Wirtschaftsinformatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist hierbei das englische Wort für Vermächtnis, Hinterlassenschaft,… …   Deutsch Wikipedia
  • Legacy System — Der Begriff Altsystem (engl. legacy system) bezeichnet in der Wirtschaftsinformatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist hierbei das englische Wort für Vermächtnis, Hinterlassenschaft,… …   Deutsch Wikipedia
  • Legacy system — Der Begriff Altsystem (engl. legacy system) bezeichnet in der Wirtschaftsinformatik eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware. Legacy ist hierbei das englische Wort für Vermächtnis, Hinterlassenschaft,… …   Deutsch Wikipedia
  • legacy system —    A computer system, developed to solve a particular business need, which, due to the passage of time, has become obsolete.    Legacy systems do not conform to the technical standards or performance standards of up to date systems. There is… …   Dictionary of networking
  • Legacy Meridian Park Medical Center — Legacy Health System Geography Location Tualatin …   Wikipedia
  • Systems Engineering Laboratories — (also called SEL) was a manufacturer of minicomputers in Fort Lauderdale, Florida. It was one of the first 32 bit realtime computer system manufacturers. Realtime computers are used for process control and monitoring; to accommodate these… …   Wikipedia
Читайте также:  Что значит тату солнца? выбор тату солнца? смысл

Источник: http://computers_en_ru.enacademic.com/8575/legacy_systems

Legacy-код — это рак

Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они.

«Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.

1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ

Возможно, это спорный вывод, но я твердо уверен, нет места для legacy-кода в современных системах. Скажу несколько слов, прежде чем вы начнете точить свои вилы и зажжете факелы.

Я имею ввиду, что не должно быть ни малейшего повода поддерживать старый функционал, вы добавляете обновления задним числом к старой версии только потому, что некоторые люди все еще используют ее. Даже если этих людей большинство — не делайте так.

Для уточнения: исправление ошибок предыдущих версий до тех пор, пока их контракт на долгосрочную поддержку не закончится, да. Добавление нового функционала, который можно выпустить в версии X, в версии X-1, только для того, чтобы не обижать пользователей X-1 — абсолютно и 100% нет.

Аналогично, добавление X-1 кода в версию X только потому, что он может «пригодиться», должно быть признано недопустимым. Если вы по-прежнему берете с людей плату за X-1 и строите свои апгрейды поверх этого, то у вас очень плохой бизнес-план.

Хотя, кто я такой, чтобы нести подобную чушь? Я никогда не поддерживал большой проект с кучей заинтересованных сторон и саппортом, который развивается супермедленно и делает всех счастливыми.

Насколько долго он делается и как работает не важно, ведь потенциально он может работать в 100 раз безопасней и в 1000 раз быстрее, верно? Не совсем.

Моим самым большим ребенком был сайт крупного издателя со сложным бекендом на ZF1.

Если вы когда-нибудь делали проекты на ZF1, то знаете, этот фреймворк — вихрь из костылей и анти-паттернов.

Когда приложение начало показывать признаки ухудшения из-за увеличения трафика, я перестроил фронтенд наиболее интенсивно используемой части приложения полностью на работу через ajax и вызовы API.

Нагрузка резко упала и этим мы купили себе достаточно времени для переноса всех остальных частей приложения на Zend Framework 2. Тем, кто делал что-то подобное известно, что это все та же смесь из костылей и анти-паттернов, но чуть менее плотная.

Я пытаюсь сказать, что большие изменения и рефакторинг может произойти лишь в том случае, когда за ними стоят способные люди. Если все что вы делаете — это сплошные agile-митинги и мозговые штурмы, то никакое количество LTS контрактов не может помешать вам глупо выглядеть в течение пяти лет.

Даже если вы делаете бесплатную и/или open source работу, конечно же вы не должны ломать совместимость для X-1 пользователей. Делая им одолжение, развивая старые версии, при глобальном обновлении вы можете столкнуться с потенциальной потерей обратной совместимости. Просто усвойте одну вещь — они должны либо приспособиться, либо умереть.

Так все же почему мы должны изгнать legacy-код из современных систем?

Бесконечное LTS проклятие

Подписываясь под подходом «поддерживаем все так долго, как только можем», вы хоронитесь в бездонную яму, и, глядя на себя через несколько лет, когда вы окажитесь вынуждены поддерживать четыре различные версии вашего продукта, вы будете биться головой об стену из-за того, что не отказались от пользователей V1 и V2, если могли. В попытке сохранить аудиторию разработчики часто выходят за рамки своих возможностей и несправляются под гнетом тонн legacy-кода. По той же причине WordPress и оказался в своем нынешнем состоянии. Не позволяйте приковывать себя к старой версии.

Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят. Дайте им возможность перехода и двигайтесь дальше, если они способны, то догонят вас. Если же нет, то они того не стоят.

Поддерживая старые версии слишком долго, вы насылаете на себя WP-проклятье. Старые версии уязвимы, их поддержка требует все больше сил и усилий по исправлению багов. Потратьте лучше эти часы на создание новых версий и наймите разработчиков, которые будут помогать пользователям с переходом.

Вы отчуждаетесь и негативно влияете на продвинутых пользователей

В последний раз я сталкивался с отчаянным legacy-кодом я сталкивался, когда устанавливал CMS, что оказалось очень трудным занятием в среде Vagrant — не только из-за проблем с symlink, которые сейчас широко известны всем (даже создателю Vagrant), но и с тем, что многие оставляют устаревшие версии CMS, т.к. часть модулей/плагинов еще не выпустили свои обновления. Раз нет обновлений модулей, то к чему обновлять ядро? Зачем торопить события, если ты к ним не готов?

Оставляя legacy-код в новой версии, вы в конечном итоге получаете монстра Франкенштейна, который вроде как по-прежнему работает, но плохо, и новый код, имеющий потенциал, не может его развить из-за беспорядка в унаследованной кодовой базе.

Такой подход хоть и делает работу компаний-разработчиков, которые все еще застряли где-то в 90-х, проще, но в тоже время продвинутым пользователям становится сложнее работать с продуктом.

Решениями, принятыми для толпы, которая уже давно и безнадежно отстала от технологий, вы отчуждаете и негативно влияете на продвинутых пользователей, способных принести гораздо большие деньги.

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

То же самое касается и пользователей библиотек или систем управления контентом — тех, кто не заботится об устаревшей CMS, не волнует, что вы делаете в новых версиях, так что не парьтесь с черезмерной поддержкой старых версий больше, чем это нужно в реальности.

Неудачи иногда предвещают успех

Конечно, иногда это просто невозможно, и подобные исключения являются очень редким и ценным обучающим материалом. Один из любопытных случаев версионирования — 2й и 3й Python. Python — это удивительный язык, с ним вы можете сделать практически все что угодно.

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

Когда пришел Python 3, в него были введены некоторые фичи, ломающие совместимость и пользователи 2й версии уже не могли так просто перейти на него.

Большинство отговорок вроде «пока еще не хватает Py3 пакетов» и «у нас слишком много кода в Py2, чтобы переписать все это» получают от меня ответы — «портируйте то, что вам нужно» и «Бедные программисты, их заставляют писать код», соответственно. Согласен, тут было несколько аргументов, но и те, как правило, берут в пример проекты, которые были изначально неправильно спроектированы, что и вылилось в их абсурдно большой размер.

На самом деле сейчас противостояние Py2 против Py3 уже превратилось в разлом, по обеим сторонам которого стоят программисты.

Читайте также:  Кто такой игроман? почему игроман? как понять, игроман ли он?

Но многие не задумываются о том, что к тому времени как будет Python 4, люди, которые так яростно отказывались от перехода на версию 3+ будут по прежнему оставаться на Py2 и несовместимость станет еще больше. К тому моменту они могли бы уже освоить другой язык, а не противиться изменениям в текущем.

С другой стороны, те, кто «отважился» переступить через разлом и переписал свой код на 3+ без долгих колебаний, получат все новейшие возможности будущих версий с нулевыми трудозатратами.

Слом обратной совместимости достаточно эффективно отсек ленивых и подготовил Python для нового поколения разработчиков. На мой взгляд, это огромный успех. Программирование, как и многие другие сферы жизни, все еще основано на выживании наиболее приспособленных — и если вы не можете использовать новые технологии адекватно — уйдите с дороги, не мешайте тем, кто может.

Приложения vs Библиотеки/Пакеты

Также есть вопросы по поводу противостояния приложений и библиотек. Другими словами, если правило «не устаревать» применимо для приложений, например при получении нового релиза фреймворка, то должно ли оно распространяться и на библиотеки?

Да.

Библиотеки, получившие бамп X+1, должны четко следовать пути к прогрессу — с момента, когда ваша версия библиотеки стала публично доступна, поддерживайте только багфиксы последней.

Приложения, которые используют такие библиотеки, находятся в более сложной ситуации из-за их зависимости от API, которые, возможно, могут измениться. Разумный подходом будет ждать отзывов из комьюнити о стабильности, прежде чем начать переход.

В течении переходного периода, как старая, так и новая версии библиотеки/фреймворка могут оставаться в использовании, и после того, как все необходимые части будут модернизированы, старая версия должна быть удалена.

Ведь это не займет много времени, правда?

Не бывает достаточно большого приложения

«Но Бруно, некоторые приложения огромны и их переписывание займет несколько месяцев», скажете вы. «Переход с ZF1 на ZF2 — это год работы!», на что я отвечаю: чушь. Нет достаточно большого веб-приложения, апгрейд которого займет подобные сроки. Я пойду еще дальше и скажу, что на самом деле нет веб-приложений достаточно больших, которые могли бы сравниться по размерам с Symfony или Zend.

Конечно же, все что я говорил, не относится к какому-либо из этих фреймворков, они гиперкомплексные бегемоты из очень профессионального кода, но если вы следуете концепции разделения задач, инкапсулируете свои сервисы и APIфицируете ваше приложение, то вы можете писать фронт отдельно от бекенда, что, в свою очередь, освобождает вас от многих преград на пути к актуальному коду независимо от размера и/или популярности приложения — при условии, что у вас в команде есть программисты, а не теоретики. Неважно сколько структур и алгоритмов вы знаете — главное знать как их использовать, чтобы быть достаточно эффективным во время миграций.

Схема обновления

Как правильнее всего обновляться? Есть только один приемлимый вариант обновления программного обеспечения, которого должны придерживаться разработчики независимо от популярности их приложения/библиотеки:

  1. Создайте новую ветку для новой версии
  2. Пометьте старую версию/ветку как deprecated
  3. Публично заявите, сколько вы еще будете поддерживать старую версию
  4. Предупредите всех пользователей старой версии
  5. Внедряйте новые функции ТОЛЬКО в новой ветке, в старой — багфиксы
  6. Когда время жизни старой версии истечет, обрывайте все концы. Не исправляйте, не советуйте, вообще удалите упоминание о старой версии из документации. Убейте ее.

После прохождения данной процедуры вы никогда не получите в наследство неприятности.

Один из проектов, следущий этому пути — Guzzle. У него есть 3+ версия и 4+, для тех, кто хочет жить в ногу со временем и всегда быть на пике прогресса.

Вывод

Как веб-разработчик, я твердо уверен, legacy-код должен быть выброшен, когда речь заходит о новых фичах или мажорном обновлении версии.

Если у вас есть большой проект, которое использует код версий, вышедших два или более месяцев назад, то вы должны прекратить все действия с ним и переписать под свежую версию, особенно, если продукты, которыми вы пользуетесь, критически важны для бизнеса.

Нет в мире достаточно больших приложений, которым нужно более двух месяцев для полного перехода, а если и есть, то они должны быть переписаны с нуля — веб намного проще, чем вы всегда предполагали.

А что думаете вы? Следует ли legacy-код хранить неограниченное время? Определенное число версий? Возможно не все? Как вы относитесь к legacy-коду в сторонних проектах? Должен ли разработчик волноваться о проблемах с legacy в библиотеках, которыми он пользуется? Ошибся ли я в этой статье? Данным постом я хотел начать дискуссию об этом — в конце концов, мои взгляды на проблемы и переживания — лишь моя точка зрения. Дайте знать в комментариях ниже.

Источник: http://www.pvsm.ru/php-2/83773

Как переводятся названия моделей японских машин?

Некоторые названия моделей не нужно переводить — смысл того или иного слова давно стал понятен вне зависимости от языка, на котором оно написано. Так часто бывает со словами-транслитерациями. Также не нужно переводить названия-имена собственные.

Примерный список названий моделей японских машин, не требующих перевода, выглядит так:

Daihatsu Max

Honda Ballade

Mazda Capella

Mazda Millenia

Mazda Roadster

Mazda Savanna

Mazda Titan

Mitsubishi Bravo

Mitsubishi Carisma

Mitsubishi Colt

Mitsubishi Dingo

Mitsubishi Jeep

Mitsubishi Mirage

Nissan Atlas

Nissan Condor

Nissan Diesel

Nissan Expert

Nissan Figaro

Nissan Leopard

Nissan Mistral

Nissan Patrol

Nissan Pulsar

Nissan Serena

Nissan Silvia

Nissan Sports

Suzuki Samurai

Toyota Avalon

Toyota Cavalier

Toyota Comfort

Toyota Corona

Toyota Duet

Toyota Nadia

Toyota Progres

Toyota Publica

Toyota Sports

Toyota Sprinter

Ниже же следует список переводов названий моделей с разных языков. В некоторых случаях, возможно, производители могли вложить в название машины не тот смысл, что таится в нашем переводе; в любом случае — мы публикуем только перевод названия с того или иного языка.

Название модели Язык Перевод с языка
Daihatsu Applause англ. аплодисменты, рукоплескания, овация, одобрение, похвала
Daihatsu Bee англ. пчела
Daihatsu Cargo англ. машина, предназначенная для перевозки грузов
Daihatsu Charade англ. шарада
Daihatsu Charmant франц. прелестный
Daihatsu Cuore итал. сердце
Daihatsu Delta англ. дельта, треугольник
Daihatsu Fellow англ. приятель, товарищ, коллега, собрат, напарник
Daihatsu Midget II англ. карлик, лилипут, нечто очень маленькое, миниатюрное
Daihatsu Mira итал. цель
Daihatsu Move англ. двигаться, движение
Daihatsu Naked англ. неукрашенный, неприкрашенный, открытый, явный
Daihatsu Opti итал. выбранный
Daihatsu Rocky англ. крепкий, твердый, непоколебимый; неподатливый, суровый
Daihatsu Storia итал. история
Hino Ranger англ. «рейнджер», бродяга, странник, скиталец
Honda Accord англ. аккорд, созвучие
Honda Beat англ. удар, такт, ритм
Honda Capa итал. вмещаться; видимо, подразумевается «вместительный»
Honda City англ. город
Honda Civic англ. гражданский, штатский
Honda Civic Ferio исп. feria — ярмарка, праздник, ferio — «я не работаю»; видимо, подразумевается «выходной», отдых
Honda Civic Shuttle англ. shuttle — челнок, аппарат, курсирующий между двумя пунктами
Honda Concerto итал. концерт
Honda Cross Road англ. перекресток
Honda Domani итал. завтра
Honda Fit англ. пригодный, подходящий
Honda Horizon англ. горизонт
Honda Insight англ. проницательность, интуиция, понимание
Honda Inspire англ. вдохновлять, воодушевлять, внушать
Honda Integra итал. интегрировать
Honda Jazz англ. джаз
Honda Legend англ. легенда
Honda Life англ. жизнь
Honda Logo англ. сокращение от «логотип» либо «логограмма»
Honda Odyssey англ. одиссея
Honda Partner англ. партнер
Honda Prelude англ. прелюдия вступление, начало
Honda Quint англ. квинта, набор из пяти предметов
Honda Rafaga исп. молния
Honda Saber англ. сабля, шашка
Honda Stream англ. течение, направление, поток
Honda Street англ. улица
Honda Today англ. сегодня, сегодняшний день
Honda Torneo итал. турнир
Honda Vigor англ. возможно, сокращение от vigour — сила, мощь
Isuzu Bighorn англ. большой рог
Isuzu Como исп. как
Isuzu Elf англ. эльф
Isuzu Forward англ. вперед
Isuzu Gemini лат. близнецы
Isuzu Pa Nero итал. nero — черный
Isuzu Piazza итал. площадь
Isuzu Piazza Nero итал. черная площадь

Источник: http://in-drive.ru/6307-kak-perevodjatsja-nazvanija-modelejj-japonskikh.html

Ссылка на основную публикацию