Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Андрей Янпольский ([info]yanis)
@ 2004-12-23 00:34:00

Previous Entry  Add to memories!  Tell a Friend!  Next Entry
мифы о программировании
Два главных примера принципиально неправильно понятой большинством методологии, с результатами, часто полностью противоположными желаемому - это Объекто-Ориентированное Программирование и Стандарты Кодирования.

Набор благих намерений при переходе на "Объекто-Ориентированную Парадигму" выглядит всегда примерно одинаково:

  • Облегченная поддержка кода

  • Централизация общих компонентов

  • Меньшее количество ошибок в коде и меньшая кодобаза, облегченное тестирование


Употребляются часто слова reusability, decoupling, modularity и тп. количество модулей возрастает в разы и даже десятки раз, информативность кода качественно падает. Там где раньше была процедурка на С из 50 строчек с одним экспортированным символом, которой требовалось скажем 1000 байт в сегменте кода, 100 байт стека, 100 байт статических и 100 байт из кучи, появится иерархия классов в 500 строк которая будет экспортировать 10 символов, занимать 10 килобайт в сегменте кода, жрать в 10-20 раз больше ресурсов и работать в 10 раз медленнее.

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

Если а) система существенно велика - скажем больше миллиона строк кода б) процент компетентных программистов (на любом языке) ниже некоторой отметки (скажем 20%) в) процент очень сильных программистов, ниже допустим 10% с) процент очень слиьных программистов, которые глубоко знают новые технологии ниже 5% вероятность того, что все произойдет именно так, как я описал, выше 90%. То есть - поддержка и разработка софта станут дороже, цикл разработки длиннее, качество ниже.

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

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

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


(Читать комментарии)

Добавить комментарий:

Как:
(комментарий будет скрыт)
Identity URL: 
имя пользователя:    
Вы должны предварительно войти в LiveJournal.com
 
E-mail для ответов: 
Вы сможете оставлять комментарии, даже если не введете e-mail.
Но вы не сможете получать уведомления об ответах на ваши комментарии!
Внимание: на указанный адрес будет выслано подтверждение.
Имя пользователя:
Пароль:
Тема:
HTML нельзя использовать в теме сообщения
Сообщение: