--- title: "Недостатки «самописного» программного обеспечения" description: "Один из наших потенциальных Заказчиков задался вопросом - может ли он нанять программистов, и самост..." author: "crmkz" published: "2017-03-16T11:41:13+00:00" modified: "2017-03-16T11:42:01+00:00" locale: "ru" canonical_url: "https://yvision.kz/post/nedostatki-samopisnogo-programmnogo-obespecheniya-760315" markdown_url: "https://yvision.kz/post/nedostatki-samopisnogo-programmnogo-obespecheniya-760315/markdown" site_name: "Yvision.kz" --- # Недостатки «самописного» программного обеспечения > Один из наших потенциальных Заказчиков задался вопросом - может ли он нанять программистов, и самост... Один из наших потенциальных Заказчиков задался вопросом - может ли он нанять программистов, и самостоятельно написать CRM систему под свои задачи. Заказчик предположил, что в этом случае затраты на автоматизацию будут низкими, в виде заработной платы одного или двух программистов в течении нескольких месяцев. Разберем недостатки этой идеи, а именно две основные проблемы, возникающие в случае «самописного» программного обеспечения (ПО): - Проблемы с экспертизой, вкладываемой в функциональность такого ПО. - Проблемы с дальнейшим сопровождением такого ПО.   **Проблемы с экспертизой, вкладываемой в функциональность «самописного» ПО** В случае внедрения готового ПО, базовый функционал решения уже прошел испытание временем на сотнях или тысячах других проектов, и содержит в себе экспертизу, или наилучший опыт эксплуатации, из этих проектов. Эта экспертиза реализована во множестве деталей решения, начиная с разделов системы и взаимосвязи функций, заканчивая интерфейсом и размещением кнопок. Облик решения определен архитекторами, и специалистами по интерфейсу – профессионалами в своих областях. Именно они ставят задачи перед программистами, являющимися профессионалами совсем в другой области, в области алгоритмов и программных технологий. В случае «самописного» ПО, функциональность и интерфейс системы будут определяться по ходу проекта, и исходить из необходимости наименьших затрат человеко-часов для программистов. Функциональность такого решения впоследствии окажется не совсем удобной, или совсем не удобной, для пользователей.   **Проблемы с дальнейшим сопровождением «самописного» ПО** В случае «самописного» ПО, основным требованием к программистам будет являться минимальная стоимость – то есть написание программного кода в минимальные сроки, с минимальным числом задействованных специалистов. Результатом такой работы будет являться так называемый «[Код с запашком](https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4_%D1%81_%D0%B7%D0%B0%D0%BF%D0%B0%D1%88%D0%BA%D0%BE%D0%BC)», из которого вытекают следующие проблемы: - У Заказчика со временем обязательно возникнет необходимость внести изменения в какую-либо функцию ПО, но выяснится, что такие изменения невозможны, так как не заложены на уровне базовых принципов реализации этой функции, или требуется переработка больших участков кода. - Устранение выявляемых ошибок или сбоев в работе ПО, требует большого объема часов разработчика, из-за сложностей с выявлением источника ошибок, или работы по переписыванию больших участков кода. - Понять что-либо в «Коде с запашком» может только программист, написавший его, в течении ограниченного времени, прошедшего с момента написания. Другим разработчикам может быть проще написать это ПО заново, чем разобрать такой код, или потратить время на переработку кода в нормальный. См.статью «[Рефакторинг](https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3)».   **Нормальный программный код** Программный код, отвечающий здоровой практике программирования, будет лишен перечисленных выше проблем, и будет дешевым в дальнейшем сопровождении, но разработка такого кода требует программистов высокого уровня, и существенного объема часов кодирования. Разработка такого кода является дорогостоящим мероприятием: - Данные, интерфейс и логика должны быть разделены на три отдельных компонента: [модель, представление и контроллер](https://ru.wikipedia.org/wiki/Model-View-Controller). - Все сущности должны быть описаны с помощью [объектов](https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5). - Сам код должен быть написан с учетом [общепринятых правил](https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82_%D0%BE%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BA%D0%BE%D0%B4%D0%B0) по отступам, именам, и комментариям.   **Заключение договора на разработку ПО** В договоре на разработку «самописного» ПО трудно юридически сформулировать ответственность Исполнителя за качество программного кода, то есть за стоимость будущего сопровождения ПО. Возможно попытаться оценить уровень Исполнителя, ознакомившись с программным кодом в других проектах, выполненных ранее этим Исполнителем, и находящихся в эксплуатации. Для такой оценки портфеля проектов Исполнителя возможно: - Привлечь сторонних программистов для ознакомления с кодом. - Ознакомиться с работой ПО из этих проектов. - Попросить Исполнителя в присутствии Заказчика внести изменения в какую-либо функцию ПО. - Ознакомиться с документацией ПО (инструкция пользователя, справочное руководство, видеоуроки, и т.п.). - Получить обратную связь от пользователей ПО. --- Source: [https://yvision.kz/post/nedostatki-samopisnogo-programmnogo-obespecheniya-760315](https://yvision.kz/post/nedostatki-samopisnogo-programmnogo-obespecheniya-760315)