Pull to refresh

Comments 10

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

При тестировании возникают те же проблемы технического долга, что и в процессе разработки

При тестировании возникают проблемы экономического и ментального долга, которые выдаются за технические

Спасибо! Одна из лучших статей на тему технического долга. Прочитал с большим интересом. Буду показывать ее всем, как образец. Очень подробно и наглядно разобраны основные противоречия и возможные компромиссы при реальных процессах разработки и поддержки ИТ. Обязательна к прочтению всем бизнесменам желающим что-нибудь "замутить" на почве ИТ. Ровно как и наоборот - для романтически настроенных программистов, пытающихся окунуться в коммерческую разработку.

Для быстрых решений, которые потом сложно поддерживать есть даже специальный термин: «костыль».

В душе, когда мы создаём "костыль", мы искренне верим (по крайней мере я), что в ближайшее время вы его поправим и снимем гипс, но идёт время, появляется ещё костыль, первый уходит на задний план, и в итоге имеем то, что имеем. Сложно бывает избавиться от них.

Неожиданно оказалось очень хорошая внятная статья! Спасибо!

Хороший костыль может стать несущей конструкцией новой системы. Сколько раз уже такое было!

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

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

Но в целом статья хорошая, это уже, наверное, я придираюсь :)

Ну, мы сделали потоковую отдачу файла в zip-формате, не смотря на то, что zip потоковой архивации группы файлов никогда не предполагал. Для этого пришлось скопировать и творчески переработать библиотеку архивации в zip. Готового решения под это тогда не было.

zip не существовал в потоковом формате, потому что для архивирования потока давно существует gzip (.gz), а для записи группы файлов в поток - tar

архитектор (строительство) Кристофер Александр

Он Александер

Sign up to leave a comment.

Articles