OberonCore https://forum.oberoncore.ru/ |
|
Нужна ли "инженерия кодинга"? https://forum.oberoncore.ru/viewtopic.php?f=86&t=3838 |
Страница 1 из 1 |
Автор: | Илья Ермаков [ Суббота, 11 Февраль, 2012 10:17 ] |
Заголовок сообщения: | Нужна ли "инженерия кодинга"? |
Так получилось, что уже не раз люди, ратующие за "анализ сложных задач" и т.п., бросали мне упрёк, что я акцентирую внимание на "всякой ерунде, этого внимания не заслуживающего". На данном форуме это некогда делали и alexus, и Galkov, и другие. Поскольку непонимание до сих пор имеет место быть... Возникло желание разъяснить данный вопрос. 1) В тех рабочих группах, с которыми мне приходится работать, решаются достаточно сложные и нетиповые задачи. Поэтому глупо меня обвинять в том, что мне нужны "кодеры". Хотя, конечно, на парах я стремлюсь научить всякой "рутине" и только "низкоуровневым" творческим и аналитическим элементам, потому что реально всё остальное у заинтересованной части аудитории потом формирую отдельными проектами, часто связанными с реальными. Посторонние к учебному процессу люди обычно не понимают, что часов всегда дефицит. И банально нет возможности очень далеко залезать, потому что без "фундамента" (банального с точки зрения критиков) их тоже не оставишь. Хотя, признаю честно, я долго боялся активных форм обучения - и только сейчас, после того, как у нас в институте прошло повышение квалификации с приглашённым педагогом-психологом из Ростова, рискнул работать по активной схеме - с делением на команды, проблемными задачами - и потом только "догоняющей теорией". Пока идёт отлично. 2) Ну а теперь про "рутину". На мой взгляд, одна из нерешённых проблем в ИТ - внедрение "инженерного подхода" на уровень кодирования. Под этим я понимаю: - гарантированное получение результата (мы доверяем тому, что написали, даже до тестирования, зная, что оно правильное с точностью до опечаток и глупых ляпов, которые и должно будет "срезать" тестирование); - снижение многообразия в коде, его "обезличивание" (чтобы два обученных "инженерии кодинга" программиста выдавали практически одинаковый код); - снижение рисков в "велосипедостроении" (чтобы банальная необходимость написать какой-то поисковый или сортирующий цикл не вела к трудностям, ломанию мозга и повышению плотности ошибок. Как выразился Пётр Алмазов - "я хочу переезжать такие задачи трактором, практически не снижая скорости"). Именно этих качеств я хочу от любого члена своей команды. Чтобы его творческая сила была сконцентрирована как раз на анализе задач и проектировании. А не этой рутине. Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам. Ошибки и разрушение памяти неизбежно - выстроим аппаратные барьеры, и пусть там компонент чудит как хочет. Надёжность обеспечим уровнем выше, на всём множестве изолированных компонентов. Кстати, именно по такому принципу разрабатывется - и вполне успешно - софт в РКК "Энергия". В частности, для российского сегмента МКС. Недавно на одном отраслевом мероприятии они подробно рассказывали. Используется C++ и инфраструктура GNU, используются библиотеки типа boost, работает это всё на базе QNX и Винды. "Инженерный подход" имеется на уровне организации системы из изолированных компонентов, которые обмениваются данными по протоколам. Проблема кодинга и языка программирования "изолирована" в этих "резервациях". На вопрос: сравнивали ли С++ и Аду? - отвечали: да, конечно, но где нам брать программистов на Аде? И добавляли: "главное - правильная организация жизненного цикла ПО". И я полностью с ними здесь соглашусь. Но если ряд проблем можно решить ниже, ещё на уровне "программирования в малом", зачем тратить усилия на их парирование на организационном уровне? Чтобы парировать "любой бред" на уровне модулей, используют модульное тестирование. Нет, я не против его - но я хочу, чтобы на тестирование выходил уже практически правильный модуль. Это позволяет нам иметь хорошее качество БЕЗ модульного тестирования, и просто отличное - если потратить дополнительные усилия на него (в ответственным случаях). Снижение многообразия кода решено поверхностно - введением code-style, общих соглашений и т.п., направленных на сопровождаемость и отчуждаемость кода. Но в любой своей нетривиальной алгоритмической части код не "обезличен", там возникает кустарное решение, найденное хаотичным поиском конкретного программиста. Как раз несопровождаемое. И никакими инструкциями эту сопровождаемость для "велосипедов" не обеспечишь. Поэтому паническая их, "велосипедов", боязнь. Потому что при текущем положении дел они, действительно, несут большие риски. Но и подход - использование стандартных библиотек - это, по сути, ещё одна "изоляция" проблемы. Загнали проблему в "резервацию", трясёмся и надеемся, что уж в библиотеке-то за годы вылизывания, тестирования и использования она не возникнет. То, что под "крышкой" библиотеки, забыли, как страшный сон. Только бы опять не писать эти ужасные сложные циклы и потом не искать в них ошибки. Я, опять же, не против библиотек, я против того, что, когда выгодно и удобно написать конкретное решение, народ этого не умеет и панически боится. Конструктор не боится индивидуально для своей конструкции, если это обосновано, спроектировать и обсчитать нестандартную часть. Нестандартную арку. Или нестандартную передачу. Или... Т.е. мы имеем вместо конструкторов только сборщиков. Тут я замечу важный момент: грамотный конструктор, если ему придётся делать нестандартный элемент конструкции, должен сделать его не "наколеночно", а используя некоторые наработанные методы, "культуру" проектирование таких элементов. Он построит его так, что сомнений в правильном его устройстве не будет ни у кого. Т.е. даже нестандартные элементы делаются в некотором смысле "стандартно". Потому что, я думаю, многообразие полезных небольших элементов систем, в общем-то, исчерпываемо - их достаточно небольшое число классов, и дальше оно всё становится, при правильном подходе, подобным друг другу. Реальная нестандартность на малом уровне - исключение. Например, связанное с оптимизациями и проч. Вот все эти проблемы я и пытаюсь решить, уча, не "кодингу", а "инженерному подходу в кодинге". |
Автор: | TAU [ Суббота, 11 Февраль, 2012 11:49 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
Все правильно. И я согласен с высказанным. Кстати, не случайно возник же термин software engineering! |
Автор: | Илья Ермаков [ Суббота, 11 Февраль, 2012 12:57 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
Что я имел в виду выше под "нестандартными конструкторскими решениями"? В первую очередь вот что: В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле. Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом. Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч. |
Автор: | Владислав Жаринов [ Пятница, 17 Февраль, 2012 12:06 ] |
Заголовок сообщения: | Повторное использование "на предмете" и "в описании" |
Как синхронно, однако, мы мыслим... Одно из добавлений к графит-методу, которое делал во время отсутствия на форуме, как раз касается различия между повторным использованием "для содержания" и "для представления" - в Правиле 239 здесь. Как раз для этого набросал схемы, иллюстрирующие, видимо, и сказанное Вами насчёт "когда не надо упаковывать"... |
Автор: | Сергей Прохоренко [ Пятница, 17 Февраль, 2012 16:34 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
Илья Ермаков писал(а): Что я имел в виду выше под "нестандартными конструкторскими решениями"? В первую очередь вот что: В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле. Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом. Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч. На самом деле возможны и другие альтеранативы:
|
Автор: | Илья Ермаков [ Понедельник, 20 Февраль, 2012 11:33 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
В принципе, да. Но здесь нет связи между исходным образцом и всеми его местами применений. И, в принципе, это ПРАВИЛЬНО (если мы выпускали приборы на старых микросхемах - и вдруг появились новые, от этого в старых приборах они не обновятся). Но это решение другого уровня, как раз не языкового, а инструментального. |
Автор: | Владислав Жаринов [ Понедельник, 20 Февраль, 2012 13:37 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
...Зато "прошивки" можно обновить (для тех же микросхем)... Видимо, шаблоны - что-то из разряда графит-областей - сегодня одно наполнение, завтра - и/или другое... |
Автор: | Сергей Прохоренко [ Понедельник, 20 Февраль, 2012 16:11 ] |
Заголовок сообщения: | Re: Нужна ли "инженерия кодинга"? |
Владислав Жаринов писал(а): ...Зато "прошивки" можно обновить (для тех же микросхем)... Видимо, шаблоны - что-то из разряда графит-областей - сегодня одно наполнение, завтра - и/или другое... Сам по себе структурированный сниппет (заполняемый шаблон) стабилен, что обеспечивает простое и безошибочное применение в указанных Ильей Ермаковым случаях:
Однако частичные обновления возможны: структурированный сниппет (заполняемый шаблон) может содержать вызовы функций и процедур, реализацию которых можно обновлять. Например, рукоятка рубанка может стать более удобной. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |