Комментарии 12
В статье речь пойдет об одной из основных причин гибели проекта после ухода программиста
Именно так у вас у основного Билайна завелся максимально тупой кот в приложении?
А может наоборот, это программист[ы] валят когда видят надвигающуюся задницу?
Главное - вовремя остановиться в обобщениях
Как понять, когда это "вовремя" случается? Если выпишете фабрику фабрик, уже поздно :)
На самом деле это часто проблема заказчика.
Сперва делаем ролевую модель, а потом костыли чтобы стажер мог сам себе ставить апрувы.
Сегодня делаем А, завтра к нему нужно приделать Б, а через пол года убрать А и на его место сделать В, но чтобы когда надо можно было включить А, при этом частично А работает как В.
Самая частая проблема что заказчик посреди строительства атомного реактора говорит делаем ТЭЦ на угле, когда вы смогли переделать АЭС в ТЭЦ он говорит что теперь мы делаем модный такомак.
он говорит что теперь мы делаем модный такомак.
Вот именно, что "такомак". Хотя нужен был Токамак.
Расскажу историю одного из своих проектов. Сначала был подключен сервис. Множество классов и методов имели имена этого сервиса. Затем от него отказались в пользу иного сервиса. У нового сервиса новые подходы, поэтому надо новые классы, методы. Но нужна и совместимость и использование громадного количества данных полученных и обработанных с помощью старого сервиса. Написали прослойки. Затем появилась необходимость использовать параллельно ещё один сервис. Множество переписывание и рефакторинга. И, наконец, мы сами создали свой сервис совместимый со вторым сервисом, но не полностью ибо тот имел недостатки. Сущности первого сервиса кое-как назвали master, хотя таблицы в бд и поля не все поменяли ибо это требует колоссального тестирования, а бизнес идёт вперёд. Короче, представляю удивление будущего прогера, который будет после меня, "почему этот клас называется X, а суть Y, при этом реализует Z? Я, естественно, максимально все пытаюсь отрефакторить, но это тонны кода за 10 не моих лет проекта
Но, действительно, статья не отвечает на вопрос из заголовка...
Срок жизни проекта в любом случае ограничен. Мой первый большой проект прожил без меня 5 лет. Я занимался его поддержкой только, и за эти 5 лет ничего в него не было добавлено, это был не web проект а ERP для торговой компании ещё во времена отсутствия сервиса разработки под 1С. Потом какие-то ушлые 1с-ники решили срубить деньжат на этой конторе и убедили их переделать все на 1С. Ничего принципиально нового они не сделали, даже не смогли мою функциональность повторить, но денег взяли и немало. В конечном итоге я подумал что это к лучшему, Я тогда сменил область деятельности на разработку электроники и в общем стал более свободным. Ну а в сегодняшней компании пришлось наоборот, вспомнить все, что когда-то делал, но уже в области разработки программ для интеллектуального железа, ибо программист, который 10 лет пилил на С# там одну программу ушёл, и в общем контора решила с нуля сделать новую систему для настройки и пооизводства, ибо старая была сделана вообще без БД, на основе xml файла, который мог содержать тысячи строк для каждого прибора и с выпуском новых прошивок его надо было корректировать. В общем вы понимаете, что значит корректировать xml в несколько тысяч строк. Я сделал это на основе БД в двух вариантах, северной и локальной. SQL lite для локальной лёг очень хорошо. Быстрая и лёгкая БД. Корректировка и основная работа с северной БД, в локальную только импорт. Отдельный квест был перенос десятков далеко не однотипных xml в серверную БД. Можно написать целую статью. Это было далеко не тривиально, ибо надо было оставить все связи в таблицах как в xml. Атрибутов для переноса было очень много, скрипт sql в виде хранимой процедуры получился очень нехилый. В общем все получилось, и прибор после переноса xml в бд сразу начинал работать и показывать свои сотни регистров правильно. Программист-разработчик прошивки может сейчас сам редактировать меню прибора, добавлять регистры и даже делать вычисляемые регистры. Клиентская часть была переписано с С# на Labview и это повысило стабильность системы значительно.
В основе трудовых отношений лежит трудовой кодекс РФ. То что пытаются обойти законы, налоги, поработить, ввели ITIL, тикеты, каждый утыкается в свой тикет и получает за выполненные тикеты - это рабство. За исключением, что хозяин конторы Ваш отец. Если это чужой дядя - ни кто с вами нянчится не будет. По российским законам нельзя уволить беременную женщину, только в случае ликвидации компании. Сейчас идет феминизация общества и геноцид мужского населения, и ни один человек не выйдет и не скажет - это что за неравенство? А парня который взял ипонету и кормит семью - его можно уволить? А сотрудника который не смог быстро переориентироваться на новые задачи, или ему специально подсунули тикеты которые он решить не может - его можно вышвырнуть получается? Получайте второе высшее образование - юридическое, из интернета не надо читать законы и гуглить что такое трудовой кодекс, социальное государство и все прочее - это бесполезно. Право и социологию бесполезно гуглить, надо идти учиться хотя бы на заочку. Если коротко: некоторые проекты угасают после ухода программиста из компании - что свидетельствует о профессионализме человека который работал, он был увлечен работой и переживал не только за конечный результат, но за свои социальные гарантии. В идеале - когда Вас попрут - желательно раззорить всю контору, еще лучше создать свой бизнес и увести всех клиентов.
Почему некоторые проекты угасают после ухода программиста из компании