Соотношение реального кода к вспомогательному коду

Question

Я считаю, что только около 30% моего кода фактически решает проблемы, остальное занимают ведение журнала, тесты, проверка параметров, исключения, обработка ошибок и так далее. Находите ли вы это в своем коде, и есть ли IDE / Editor, позволяющий скрыть неинтересный код?

OTOH Существуют ли языки, которые делают код поддержки более управляемым и меньшим по размеру?

Редактировать - я думаю, что мы все понимаем разницу между бизнес-логикой и другим кодом. Я не говорю, что регистрация и т.д. не важны. Дело в том, что когда я пишу код, я либо реализую бизнес-логику, либо я стараюсь, чтобы все не сломалось. Для меня это два разных способа мышления, развиваются ли другие так, и есть ли IDE, поддерживающая этот способ развития?

Answer 1

Поддержка кода так же важна, как и «реальный код». Качество вашего продукта определяется как поддержкой кода, так и всего остального.

Рассмотрим автомобиль. С точки зрения простого перемещения из пункта А в пункт Б, для этого требуется не более чем тележка: рама, сиденье, двигатель, несколько шин. Но современные автомобили имеют гораздо больше, чем просто основы. Высокоэффективные двигатели с использованием электронной системы газораспределения. Автоматические коробки передач. Ковшеобразные сиденья. Отопление и кондиционер. Реечный рулевой механизм. Силовые тормоза. Антиблокировочная система тормозов. Тихие, комфортабельные каюты защищены от непогоды. Подушки безопасности. Смять зоны и другие передовые функции безопасности. И т. Д. И т. Д.

Детали и исполнение важны, даже в программном обеспечении. Если вы обнаружите, что ваш «поддерживающий код» больше похож на клуджи и хаки, то пришло время переосмыслить ваш фундаментальный подход. Но, в конечном счете, качество и отделка определяют качество конечного продукта так же, как и все остальное.

Редактировать: Вопросы, которые вы должны себе задать:

Ваш "поддерживающий код" :

• Трубопровод зонтика, приклеенный к столбу или металлической и стеклянной раме кабины?
• Кусок трубы, привязанный к передней части автомобиля, или энергопоглощающий бампер, встроенный в зону деформации?
• Крюк на веревке, привязанной к раме, или 4-колесные антиблокировочные тормоза?
• Пара защитных очков и толстый слой или ветровое стекло и система отопления?

Ответы на эти вопросы, вероятно, будут влиять на то, насколько вы заботитесь о своем «вспомогательном коде».

Редактировать: Ответ на комментарий Дэйва Турви:

Я бы рекомендовал перечитать исходный вопрос, один из приведенных примеров «кода поддержки» - «обработка ошибок». Задумайтесь об этом на мгновение. Представьте это в контексте, скажем, автомобиля, микроволновой печи или даже операционной системы. Должна ли обработка ошибок быть отнесена к гражданству второго сорта, потому что она выполняет функцию поддержки в некотором абстрактном смысле? В автомобиле функции безопасности являются частью фундаментальной конструкции автомобиля и составляют существенную часть стоимости автомобиля. Функции безопасности и «обработка ошибок» микроволновой печи (в том числе встроенного программного обеспечения микроволновой печи) также являются важной частью ее ценности. Микроволновая печь, которая была неправильно экранирована, могла бы хорошо готовить пищу при правильных обстоятельствах, но это представляло бы опасность для оператора.

Неявный набор функций каждого инструмента (программного или иного) включает в себя этот список:

• Надёжность
• Юзабилити
• Производительность

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

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

Answer 2

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

• A язык с первоклассными функциями поможет вам модульно модифицировать ваш код, так что ведение журнала, синхронизация и т. Д. Могут быть реализованы один раз, а затем объединены со многими другими модулями. Это также поможет вам написать модульные тесты. Хорошие способы освоить эти приемы - прочитать статью Почему функциональное программирование имеет значение и узнать об инструменте QuickCheck . (Нет, я не дурак для Джона Хьюза, но он делает замечательную работу.)

• Если вы не можете использовать язык программирования с мощными возможностями для модульности и повторного использования, или если вы не хотите, методика грамотного программирования Дона Кнута поможет вам организовать свой код так, чтобы вы могли разделить части так, как вы хотите, и обращать внимание только на то, что вы хотите, когда вы хотите. Инструмент грамотного программирования Noweb поддерживает любой язык, который может быть написан в ASCII, а также комбинации этих языков.

Answer 3

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

Вы должны включить видимые пользователю функции или у вас нет жизнеспособного продукта или работы. Как только это будет сделано частично, ваш оставшийся бюджет времени будет разделен между действиями с видимой отдачей от усилий и невидимой (но положительной!) Отдачей от усилий, такими как регистрация исключений, управление памятью и т. Д.

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

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

Я не завидую 90% моего кода, который является канализацией доступа к данным, потому что он весь тестируемый, сгенерированный и очень дешевый по сравнению с 10% рукописного кода, специфичного для домена.

Answer 4

Аспектно-ориентированное программирование частично решает эту проблему. Это позволяет вам вводить код в существующий исходный / байт-код. Таким образом, вы можете заставить задачу, такую ​​как ведение журнала, появляться в своем собственном модуле, а не вплетаться в бизнес-логику.

Answer 5

Как будто вы хотите отправиться в путешествие на вершину Пика Пик. Вы можете взять Winnebago, внедорожник или мотоцикл, или покататься на велосипеде.

Некоторые способы являются более или менее дорогими, более быстрыми и т. Д. Иногда вы заканчиваете тем, что берете с собой много вещей, которых не существует исключительно для достижения вертикального прогресса; приятно иметь пиво в холодильнике. Но стоит помнить, что вы несете ответственность за все, что идет с вами на вершину.

Answer 6

Реальный код, на который вы ссылаетесь, обычно называется «Бизнес-логика».

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

Остальное по большей части основано на языке. Чем более продвинутый язык, тем лучше его способность в некоторой степени избегать написания кода поддержки. Кроме того, хорошо разработанная система разработки может помочь вам избежать написания большого количества кода (конструктор экрана Visual Basic, Ruby on Rails, ...), но эти абстракции могут сломаться и заставить вас писать столько же кода, сколько и всего остального, если Вы используете его для разработки целей за пределами предполагаемых типов приложений. (VB и Ruby не сильно помогают, если вы вычисляете простые числа)

Помимо языка / платформы, у вас есть рефакторинг - искусство устранения всего вспомогательного кода, который вы можете (а также избыточности в вашей бизнес-логике), чтобы поддерживать вашу кодовую базу чистой и маленькой.

Занимаясь продвинутым рефакторингом, вы, вероятно, в конечном итоге будете писать инструменты для себя.

Иногда абстрагирование данных из вашего кода в какой-либо структурированный файл может исключить огромные кучи вспомогательного кода и перенести остальное в «бизнес-логику», потому что теперь анализ этих данных и их настройка являются частью «бизнеса» ваша программа делает.

Это хороший компромисс, потому что этот тип бизнес-логики имеет тенденцию быть более читабельным и легче анализировать. Другое преимущество этого вида абстракции состоит в том, что вся ваша «Конфигурация» теперь выполняется в данных, что делает ее проблемой кого-то другого.

В качестве примера такого типа инструментов: сам Rails! Он берет на себя большую часть шаблона веб-разработки и выделяет его из кода в библиотеки, управляемые данными и упрощенным кодом (Ruby стирает грань между кодом и данными - их файлы данных фактически возвращаются к заданному в коде Ruby! )

Answer 7

Если бы моя IDE могла скрыть «не интересный код», я бы обязательно отключил эту функцию. Бьюсь об заклад, ты бы не хотел, чтобы это произошло:

Конечно, есть языки, которые минимизируют объем поддерживаемого кода, но я не думаю, что вы могли бы переключиться с Java на, скажем, JavaScript просто потому, что в JavaScript вам не нужно объявлять каждое исключение ... Я думаю, что это довольно необходимо иметь ваш поддерживающий код, где он находится.

О, и вы могли бы формально указать и математически проверить вашу программу, тогда вам не нужно будет слишком сильно поддерживать ваш код; D

Answer 8

Вы могли бы просто сделать статический класс в сборке утилит, которая проверяет ваши параметры и вещи. Например, в Spring Framework (где я и получил идею) у него есть класс Assert, и он позволяет очень быстро убедиться, что строковые параметры не пусты или что параметры объекта не равны NULL. Он очищает проверочный код и уменьшает дубликат кода, который является выигрышным.

Answer 9

У меня есть несколько коллег, которые однажды, когда клиент пережевывал запоздалый и перегруженный ошибками проект, хвастались заказчику, что они написали в 5 раз больше тестового кода, чем операционного кода.

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

Answer 10

Я использую директиву #region в Visual Studio, чтобы свернуть блоки кода, которые не являются основной задачей, например модульные тесты. С log4net операторы журналирования имеют только одну строку. Я не нашел подходов к сокращению кода проверки параметров, хотя похоже, что в C # 4 есть какая-то структура контракта, которая поможет там.