Блог

Хардкоднутая дата в будущем - пофигизм?

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

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

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

Тесты заставляют писать код чище

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

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

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

Тесты нужно писать для того, чтобы они тестировали

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

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

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

Мы не хотим переходить на git - Как же это круто!

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

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

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

Вопрос на засыпку - Как спрятать элемент на форме

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

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

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

Слишком много методов - Признак плохого кода #4

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

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

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

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

Отсутствие тестов - Признак плохого кода #3

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

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

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

У классов нет свойств - Признак плохого кода #2

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

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

Если в классе можно все методы сделать статичными, и функционал не поменяется, то почему они не статичные? 

Оператор if - Признак плохого кода #1

Если у тебя в коде есть if оператор, который в зависимости от условия выполняет разные действия:

void func() {
	If (type == 1) {
		// логика функции #1
		 . . . 
		 . . . 
	}
	If (type == 2) {
		 // логика функции #2
		 . . . 
		 . . . 
	}
}

О блоге

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

Обратная связь

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

Пишите мне


Я в социальных сетях
Facebook Telegram Програмысли
Youtube Instagram Твитер