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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would use static's in a lot of methods/classes as it was more concise. When I started writing tests that practice changed very quickly.

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

Waterfall development in general, and in specific, the practice of writing complete and comprehensive functional and design specifications that are somehow expected to be canonical and then expecting an implementation of those to be correct and acceptable. I've seen it replaced with Scrum, and good riddance to it, I say. The simple fact is that the changing nature of customer needs and desires makes any fixed specification effectively useless; the only way to really properly approach the problem is with an iterative approach. Not that Scrum is a silver bullet, of course; I've seen it misused and abused many, many times. But it beats waterfall.

Hungarian notation (both Forms and Systems). I used to prefix everything. strSomeString or txtFoo. Теперь я использую someString и textBoxFoo. Это гораздо более читабельно и легче для кого-то нового. В качестве дополнительного бонуса сохранить его единообразие тривиально - используйте camelCase для элемента управления и добавьте полезное / описательное имя. У Forms Hungarian есть недостаток, заключающийся в том, что они не всегда последовательны, а Systems Hungarian не особо помогает. Объединение всех переменных вместе не так уж и полезно, особенно с современными IDE.

Single return points.

I once preferred a single return point for each method, because with that I could ensure that any cleanup needed by the routine was not overlooked.

Since then, I've moved to much smaller routines - so the likelihood of overlooking cleanup is reduced and in fact the need for cleanup is reduced - and find that early returns reduce the apparent complexity (the nesting level) of the code. Artifacts of the single return point - keeping "result" variables around, keeping flag variables, conditional clauses for not-already-done situations - make the code appear much more complex than it actually is, make it harder to read and maintain. Early exits, and smaller methods, are the way to go.

• Trying to code things perfectly on the first try.
• Trying to create perfect OO model before coding.
• Designing everything for flexibility and future improvements.

In one word overengineering.

The use of caffine. It once kept me awake and in a glorious programming mood, where the code flew from my fingers with feverous fluidity. Now it does nothing, and if I don't have it I get a headache.

The overuse / abuse of #region directives. It's just a little thing, but in C#, I previously would use #region directives all over the place, to organize my classes. For example, I'd group all class properties together in a region.

Now I look back at old code and mostly just get annoyed by them. I don't think it really makes things clearer most of the time, and sometimes they just plain slow you down. So I have now changed my mind and feel that well laid out classes are mostly cleaner without region directives.

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

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

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

Никаких сбоев.

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

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

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

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

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

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

Wrapping existing Data Access components, like the Enterprise Library, with a custom layer of helper methods.

• It doesn't make anybody's life easier
• Its more code that can have bugs in it
• A lot of people know how to use the EntLib data access components. No one but the local team knows how to use the in house data access solution

Obsessive testing. I used to be a rabid proponent of test-first development. For some projects it makes a lot of sense, but I've come to realize that it is not only unfeasible, but rather detrimental to many projects to slavishly adhere to a doctrine of writing unit tests for every single piece of functionality.

Really, slavishly adhering to anything can be detrimental.

Designing more than I coded. After a while, it turns into analysis paralysis.

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

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

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

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

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