Блог

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

func foo (something) {
   if (something.isActive &&
      something.StartDate < DateTime.Now && 
     (something.EndDate == null ||  something.EndDate > DateTime.Now) &&
     User.CurrentUser == something.Creator && canEdit(something)) {
   }
}

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

Классическое имя ReadOnly. Почему Only? Почему нельзя просто назвать Read? В ОС Windows есть такой атрибут ReadOnly, который как бы переопределяет любые права на запись и говорит, что теперь из файла можно только читать. Теоретически это выглядит красиво, но начинаются проблемы, когда мы хотим кому-то дать права на запись. С одной стороны, вроде бы стоит Only флаг на чтение, а с другой стороны мы хотим дать запись. Странно и непонятно. Ну ладно, это ОС и UI. Я хоть и не согласен с этим именем, все уже смирились с этим. 

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

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

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

Сейчас у нас на работе везде используется 01.01.2050. В принципе, через 30 лет я уже точно буду на пенсии и исправить эту дате не так уж и сложно, если все будут использовать только ее и никто случайно (или намеренно) не станет использовать другую дату в будущем.

В SQL очень часто можно увидеть код типа: 

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

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

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

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

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

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

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

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

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

У нас снова команда ищет программистов, и я иногда начал проводить телефонные интервью, чтобы понять, стоит ли кандидата приглашать на тест. В прошлый раз я сам придумывал вопросы и у меня был список из 15 штук, а тут мне дали уже заранее подготовленный список по 5 разным темам - C#, JS, HTML/CSS, SQL и тестирование кода. 

Когда я открыл раздел HTML/CSS, то один из первых вопросов был - как спрятать что-либо на форме. Я подумал, что слишком простой вопрос и может я что-то не понимаю. Но следующим был - в чем разница между display и visibility. "Ну что за детские вопросы" подумал я.

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

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

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

Если говорить о контроллерах в Web программировании, то тут вполне очевидно, что на один класс контроллера может быть много методов, которые будут реагировать на запросы клиентов. 

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

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

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

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