- PVSM.RU - https://www.pvsm.ru -
На Хабре (да и в реальной IT жизни) встречаeтся много вопросов вида:
Ключевой вопрос во всех примерах ниже: что вы разрабатываете: товар или сервис? Как ни странно, но как только вы ответите на этот вопрос о товарах и сервисах, все сомнения о необходимости тестов, абстракций и т.д. отпадут сами собой.
В них есть принципиальная разница: товар обладает законченностью, его можно продать, а потом забыть о его существовании. В случае сервиса, покупатель и продавец общаются долго (по аналогии с подпиской, которая является этим самым сервисом).
Примеры продуктов:
Примеры сервисов:
Идея проста: если вы рассматриваете свою программу как товар (то есть ваша связь с ней прервется после первого релиза), то нет никакого смысла тратить лишнее время ни на тесты, ни на рефакторинги, ни на соответствие стилям кодирования. Ведь если вы потратите своё время и сделаете "на отлично", то ваш продукт просто удорожает. А в дальнейшем эти абстракции будут просто вам не нужны (ведь вы-то прекратите работать над программой).
Однако если вы оказываете сервис для пользователей (например, делаете аналог Facebook), то у вас будут задачи обновления зависимостей, у вас будут задачи добавления/удаления функций, а потому тесты всё-таки будут, ибо они снизят риски в долгосрочной перспективе. Более того, вам потребуется выделять абстракции, как минимум для того, чтобы в будущем встраивать новую логику. Итого, если вы рассматриваете свою разработку как сервис, то вам необходимо обновлять зависимости, писать тесты, выделять абстракции и делать немало другой работы по уходу от legacy и минимизации рисков ошибки в будущем.
В контексте этой статьи можно очень легко вывести формулу того, как можно очень просто из практически любого разрабатываемого ПО сделать legacy, причем следуя этой формуле успеха достигает сам разработчик этой самой программы, без чьей либо помощи. Формула проста: чтобы получить legacy софт, вам необходимо относится к разработке сервисного ПО так, как будто вы делаете товар.
Или другими словами: если вы видите, что участвуете в разработке сервиса (то есть вы надолго в этом проекте, вы будете еще несколько лет добавлять новые функции в проект, адаптировать его к новым реалиям), однако есть желание сделать из проекта истинное legacy (то есть программу, в которую невероятно сложно вносить изменения, которая неспособна работать на более новой ОС/железе и т.д.), то просто начните относиться к проекту как к товару. Просто рассматривайте каждый релиз, как последний. Чаще употребляйте слова "ну всё, продали версию". Как можно активнее делайте маленькие костыли и хаки, вместо переработки кода. И напоследок: побольше ручного труда (забудьте про TeamCity/Jenkins), и никогда не пишите документаций, спецификаций и разных комментариев в коде.
Довольно интересно, что если буквально чуть-чуть изменить отношение к ПО, то оно само будет становится страшным legacy, причем сделанным своими руками.
Как ни странно, однако для того, чтобы не получить ужасное ПО на руках, необходимо всего лишь задавать себе вопрос раз в месяц/квартал: а продукт, который я делаю, является товаром или сервисом? И запомнить/записать этот ответ хотя бы на некоторое время. В дальнейшем любые вопросы о тестах, рефакторинге, документации и пр. будут отпадать сами собой.
Примеры:
Несмотря на то, что аутсорсер технически является IT компанией (более того, основная часть послужного состава — это люди, относящиеся к IT), самые важные шаги в проекте:
То есть все остальные действия сотрудников компании крутятся только вокруг этих пунктов. И именно эти две вещи прямо влияют на то, что же на самом разрабатывает аутсорсер — товар или сервис.
Например, для государственных заказов зачастую разрабатываются товары. И ни разу не сервисы (хотя и такое тоже бывает). А потому, в таких проектах нет никакого резона делать документацию, ускорять работу программы (то есть делать заказчика довольными). А значит получаем правило: если вы разрабатываете, тестируете или настраиваете ПО в фирме аутсорсере, который забудет про контракт после подписания акта, то нет никакого смысла даже задумываться о тестах, документации, выделении абстракций и пр.. Более того, если вы будете советовать менеджеру среднего звена "сделать софт лучше", то он абсолютно не поймет, зачем вы в принципе задумываетесь о таком. Ведь компания мало того, что не получит никакой прибыли от рефакторингов, она зачастую может понести вполне реальные убытки то того, что разработчик тратит время не пойми на что.
Более того, если компания-аутсорсер делает подобный софт на заказ, то у неё зачастую нет никакого стимула делать программы безопасными (ведь в будущем всегда можно просто наехать на блогера [4], как это делали в 90е, верно? а все убытки так или иначе понесет заказчик)
Прочитав статью, невольно рождается мысль: ведь все эти идеи до боли просты. Почему же тогда у нас получается legacy софт? Почему у одной компании/команды продукты легки в поддержке, а у других программы тормозят, а разработчики тратят кучу времени на поддержку?
Один (из многих) ответов — это отношение самих людей в командах к программам как к товару, или же как сервису. Причем здесь важно понимать, что в данном контексте, команда — это все люди, которые имели отношение к разработке софта, то есть и тестировщики, и разработчики, и аналитики, и менеджмент. Суммарная позиция всех людей и дает позицию команды. И она может быть как и "мы продаем товар", так и "мы делаем сервис".
Примеры конфликта, когда команда разрабатывает сервис, однако относится к нему, как к товару:
Примеры обратного конфликта, когда команда на самом деле создает товар, однако относится к нему как к сервису:
На хабре зачастую есть немало споров по части того, какой язык программирования лучше. Или же какая технология лучше. Как ни странно, немало из них возникает из-за того, что у сторон разное понимание того, чем является программа — товаром или сервисом.
Если у вас одноразовая задача (например, перекопировать файлы из пункта А в пункт Б с некоторыми условиями и минимальными преобразованиями), то довольно глупо будет выбирать технологии, рассчитанные на долгую поддержку, дающие длинную обратную совместимость. Для таких задач Go/Python будет идеальным решением.
И наоборот — если в вашу задачу входит длительное оказание сервиса (с частыми обновлениями безопасности и т.д.), то на первое место выходят такие плюсы платформы, как обратная совместимость, легкость обновления, простота патчинга и т.д. Вам уже становится абсолютно неважно, легко или сложно написать Hello World на выбранном языке, так как такие программы будут создаваться раз в несколько лет.
В заключении — как использовать то, что программа может являться как товаром, так и сервисом.
Автор: Игорь Манушин
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/289720
Ссылки в тексте:
[1] Spring Boot 2: https://spring.io/projects/spring-boot
[2] будет неподдерживаемой уже через год: https://spring.io/blog/2018/07/30/spring-boot-1-x-eol-aug-1st-2019
[3] необходимо будет обновиться: https://medium.com/criciumadev/its-time-migrating-to-java-11-5eb3868354f9
[4] можно просто наехать на блогера: https://habr.com/post/417161/
[5] job security: https://en.wikipedia.org/wiki/Job_security
[6] через пару месяцев — за 11ю: http://www.java-countdown.xyz/
[7] Источник: https://habr.com/post/261001/?utm_source=habrahabr&utm_medium=rss&utm_campaign=261001
Нажмите здесь для печати.