Какая практика программирования, которую вы когда-то любили, с тех пор передумала?

Ответ 1

//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.

Ответ 2

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

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

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

Ответ 3

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

Одним словом overengineering.

Ответ 4

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

Ответ 5

"Совершенная" архитектура

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Никогда не сбой.

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

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

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

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;
}

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

Аббревиатура переменной /method/table/... Имена

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

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

Ответ 19

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

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

Ответ 20

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

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

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

Ответ 21

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

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

Ответ 22

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

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

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

Ответ 23

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

Ответ 24

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

Ответ 25

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

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

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

Ответ 26

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

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

Ответ 27

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

Ответ 28

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

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

Ответ 29

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

Я использовал для явного инициализации каждого члена класса что-то, обычно NULL. Я понял, что это:

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

Ответ 30

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

Вкратце, я использую "мини-рамки" для более быстрого и эффективного создания программного обеспечения. Эти мини-рамки экономят много времени, и если все сделано правильно, вы можете сделать приложение супер простым для поддержания в будущем. Plug 'n Игра для победы!