Какая практика программирования, которая вам когда-то нравилась, вы изменили? [закрыто]

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

Пример практики, которую я когда-то использовал довольно часто, но в последние годы изменился, - это использование шаблона объекта Singleton .

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

Мои вопросы к сообществу в духе самосовершенствования:

• Какие шаблоны или практики программирования вы недавно пересмотрели и теперь стараетесь избегать?
• Чем вы решили их заменить?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Единичные точки возврата.

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

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

• Пытаться идеально кодировать с первой попытки.
• Попытка создать идеальную объектно-ориентированную модель перед написанием кода.
• Все проектируется с учетом гибкости и будущих улучшений.

Одним словом сверхинженерия .

Венгерская нотация (как формы, так и системы). Раньше я все ставил префиксом. strSomeString или txtFoo. Теперь я использую someString и textBoxFoo. Это гораздо более читабельно и легче для кого-то нового. В качестве дополнительного бонуса сохранить его единообразие тривиально - используйте camelCase для элемента управления и добавьте полезное / описательное имя. У Forms Hungarian есть недостаток, заключающийся в том, что они не всегда последовательны, а Systems Hungarian не особо помогает. Объединение всех ваших переменных вместе не так уж и полезно, особенно с современными IDE.

«Идеальная» архитектура

Я придумал эту архитектуру пару лет назад. Я продвинулся технически так далеко, как мог, чтобы были 100% слабосвязанные слои, широкое использование делегатов и легкие объекты. Это был технический рай.

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

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

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

Комментируем код. Раньше я думал, что код драгоценен, и что вы не можете просто удалить те прекрасные драгоценные камни, которые вы создали. Теперь я удаляю любой закомментированный код, с которым я сталкиваюсь, если только там нет TODO или NOTE, потому что оставлять его слишком опасно. Я встречал старые классы с огромными закомментированными частями, и меня действительно смущало, почему они были: были ли они недавно закомментированы? это изменение среды разработки? почему он делает этот несвязанный блок?

Серьезно подумайте о том, чтобы не комментировать код, а просто удалить его. Если он вам нужен, он все еще находится в системе контроля версий. ЯГНИ.

Чрезмерное использование / злоупотребление директивами #region. Это просто мелочь, но раньше в C # я бы повсюду использовал директивы #region для организации своих классов. Например, я бы сгруппировал все свойства класса вместе в регионе.

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

Каскадная разработка в целом и, в частности, практика написания полных и исчерпывающих функциональных и проектных спецификаций, которые каким-то образом должны быть каноническими, а затем ожидание их правильной и приемлемой реализации. Я видел, как его заменили скрамом, и я сказал, что избавился от него. Простой факт заключается в том, что изменяющаяся природа потребностей и желаний клиентов делает любую фиксированную спецификацию практически бесполезной; единственный способ действительно правильно подойти к проблеме - это итеративный подход. Не то чтобы Scrum, конечно, серебряная пуля; Я много раз видел, как им злоупотребляли и злоупотребляли. Но он лучше водопада.

Никогда не рушится.

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

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

Мой любимый шаблон "не сбои" таков:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

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

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

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

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

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

Действительно, рабское соблюдение чего-либо может нанести вред.

Это мелочь, но: Заботясь о том, где идут фигурные скобки (в той же строке или в следующей?), Предлагает максимальную длину строки кода, соглашения об именах для переменных и другие элементы стиля. Я обнаружил, что все, кажется, заботятся об этом больше, чем я, поэтому я просто плыву в потоке тех, с кем работаю в настоящее время.

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

(Обратите внимание, что это не то же самое, что отсутствие согласованного стиля. Я думаю, что согласованный стиль в кодовой базе очень важен для удобочитаемости.)

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

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

На самом деле я просто создал огромное пространство имен с множеством плохо организованных функций.

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

Проектирую больше, чем кодировал. Через некоторое время это переходит в аналитический паралич.

Использование DataSet для выполнения бизнес-логики. Это слишком сильно привязывает код к базе данных, также DataSet обычно создается из SQL, что делает вещи еще более хрупкими. Если SQL или база данных изменяются, они имеют тенденцию просачиваться ко всему, чего касается DataSet.

Выполнение любой бизнес-логики внутри конструктора объекта. Наследование и возможность создавать перегруженные конструкторы, как правило, затрудняют обслуживание.

Сокращение переменной / метода / таблицы / ... Имена

Раньше я делал это все время, даже когда работал с языками без принудительных ограничений на длину имен (ну, наверное, 255 или что-то в этом роде). Одним из побочных эффектов было множество комментариев, разбросанных по всему коду, объясняющих (нестандартные) сокращения. И, конечно, если имена по какой-то причине изменились ...

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

Обертывание существующих компонентов доступа к данным, таких как Enterprise Library, настраиваемым уровнем вспомогательных методов.

• Это никому не облегчает жизнь
• Это еще код, в котором могут быть ошибки
• Многие люди знают, как использовать компоненты доступа к данным EntLib. Никто, кроме местной команды, не знает, как использовать собственное решение для доступа к данным.

Я впервые услышал об объектно-ориентированном программировании, когда читал о Smalltalk в 1984 году, но у меня не было доступа к oo-языку, пока я не использовал компилятор cfront C ++ в 1992 году. Я наконец-то смог использовать Smalltalk в 1995 году. Я с нетерпением ожидал oo технологии, и поддержал идею, что это спасет разработку программного обеспечения.

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

На самом деле мне интересно поработать в Clojure, когда у меня будет время, которое не предоставляет возможностей oo, хотя может использовать объекты Java, если я правильно понимаю. Я не готов сказать что-нибудь вроде oo мертв, но лично я не тот фанат, которым был раньше.

В C # используется _notationдля закрытых членов. Теперь я думаю, что это некрасиво.

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

Я перестал придерживаться рекомендованного университетом метода проектирования до внедрения. Работа в хаотической и сложной системе заставила меня изменить отношение.

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

Код не будет выглядеть так, как вы сначала думали. Бывает каждый раз :)

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

Я бы использовал статические во многих методах / классах, поскольку они были более краткими. Когда я начал писать тесты, эта практика очень быстро изменилась.

Проверенные исключения

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

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

Что-нибудь стоящее было закодировано только на одном конкретном языке. В моем случае я считал, что C - лучший язык на свете, и у меня никогда не было причин кодировать что-либо на каком-либо другом языке ... никогда.

С тех пор я начал ценить много разных языков и их преимущества / функциональность. Если я хочу написать что-то маленькое - быстро - я бы использовал Python. Если я хочу работать над большим проектом, я буду писать код на C ++ или C #. Если я хочу развить опухоль мозга, я буду писать код на Perl .

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

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

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

Инициализация всех членов класса.

Раньше я явно инициализировал каждый член класса чем-нибудь, обычно NULL. Я понял, что это:

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

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

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