Dushyant Sabharwal. В статье приведены некоторые советы для начинающих и, возможно, некоторых опытных программистов, которые могут помочь значительно повысить свой профессионализм и изменить отношение к работе. Некоторые из них могут показаться банальными, но новички, возможно, смогут найти что-то полезное для себя.
Пишите больше кода
Если вы хотите улучшить свои навыки в каком-либо занятии, нужно больше практиковаться — обходных путей, к сожалению, не существует. Не важно сколько статей по программированию в день вы читаете или сколько раз в день вы перечитываете документацию — вы не добьётесь результатов, не работая собственными руками. Паттерны проектирования, кажущиеся сложными в применении многим новичкам, начнут автоматически вылетать у вас из под пальцев, когда вы потренируетесь применять их в различных контекстах.
Пишите тесты
Когда я начал активно тестировать свой код, я был удивлён своей неподготовленности к написанию качественных тестов. Написание тестов научит вас по-новому смотреть на свой код, потому что, придумывая способы сломать свой код, вы, скорее всего, глубже осознаете структуру и логику работы своего кода, обнаружите собственные некоторые ошибки (ещё до выполнения тестов, во время их написания) и заметите, что, возможно, стоит вынести некоторые части вашего кода во вспомогательные функции или сделать некоторые функции более обобщёнными — в некоторых случаях вы даже будете вынуждены сделать это, обнаружив, что ваш код невозможно протестировать.
Давайте рассмотрим пример:
function postData(data) {
boolean valid = true;
// проверяем наличие данных
if (data === undefined) {
valid = false;
}
// проверяем формат электронной почты
if (!regex(data['email']) {
valid = false;
}
// проверяем длину пароля
if (data['password'].length < 8) {
valid = false;
}
if (valid) {
http
.post(`example.com/user/create`, data)
.then((response) => {
//добавляем информацию в список
this.users.append(response.userid);
})
.catch((error) => {
// выводим информацию об ошибке
});
} else {
showValidationError();
}
}
Метод
postData выполняет несколько функций сразу: проверка корректности данных, добавление информации в список пользователей в случае прохождения данными проверки, обработка ошибок. Написать модульный тест для postData может быть довольно сложной и неприятной задачей. Лучше будет разбить этот код на несколько методов и протестировать каждый по отдельности, например:function postData(data) {
return http
.post(`example.com/user/create`, data);
}
function validate(data) {
// проверяем наличие данных
if (data === undefined) {
return false;
}
// проверяем формат электронной почты
if (!regex(data['email']) {
return false;
}
// проверяем длину пароля
if (data['password'].length >= 8) {
return false;
}
return true;
}
function appendUsers(userId) {
this.users.append(response.userid);
}
function main() {
if (validate(data)) {
postData(data)
.then(data => appendToList(data.userId))
.catch(error => handleError(error))
} else {
showValidationError();
}
}
Уже сейчас вы можете увидеть, что написание тестов приводит к повышению качества кода — вам пришлось разбить вашу длинную функцию на несколько более коротких, выполняющих меньшее количество действий, которые легко можно протестировать по отдельности.
Будьте честны
Не врите о своих знаниях. Делая вид, что разбираетесь в каком-либо API, вы не сможете принести реальной пользы команде, но зато сможете подвести людей, если вам доверят выполнение задачи или просто опозориться, сказав что-то невпопад во время обсуждения.
Участвуйте в open-source проектах
Участвуя в open-source проектах, вы можете столкнуться с ситуациями, которые никогда бы не произошли на вашей обычной работе. Таким образом вы можете расширить свои горизонты. Вы можете больше узнать о работе в распределённых командах. непрерывной интеграции и других средствах разработки, активно используемых в крупных open-source проектах. Как известно, open-source значительно влияет на мир информационных технологий в целом и на разработчиков в частности.
Помогайте людям
Помогая другим людям с чем-то, в чём вы хорошо разбираетесь, повышает вашу ценность и репутацию в коллективе, а также позволяет вам закрепить свои знания и, иногда, обнаружить пробелы в них. Вызываясь на помощь с задачами, в которых вы разбираетесь не на все 100%, зачастую может помочь вам научиться чему-то новому.
Начните собственный проект
Собственные проекты являются отличным способом изучения новых фреймворков и технологий, с которыми вы не сталкиваетесь на работе. При работе над собственным проектом Вы являетесь product manager-ом, разработчиком и проектироващиком — представьте только, какое количество важных решений вам придётся принимать самостоятельно! Возможно, однажды на своей работе вы успешно предложите внедрить новую технологию или фреймворк, изученные вами во время работы над собственным проектом!
Умерьте своё эго
Не позволяйте своему эго и своей рабочей должности вставать на пути между вами и обучением/улучшением навыков. Каждый день думайте о том, кем вы станете, вместо того, кто вы есть сейчас. Всегда будьте открыты новым способам решения задач в которых, по вашему мнению, вы и так разбираетесь. Если это будет не так, вы рискуете упустить более эффективный, чем используемый вами, алгоритм или более подходящее архитектурное решение.
Думайте о причинах существования программных средств
Перед тем, как начать активно пользоваться новым фреймворком, паттерном или API, попытайтесь понять причину (и основную цель) его существования. Попробуйте получить представление о причинах создания средства, которым собираетесь воспользоваться.
var app = new Vue({
el: '#app',
data: {
message: 'Hello Vue!'
}
})
Выше приведён пример кода, который вы можете встретить на сайте с документацией vue.js. Даже глядя на этот простой пример, я думаю о следующих вещах:
- Почему для создания компонента используется ключевое слово
new? Почему они не используют паттерн «фабрика» для создания объектов? - Похоже, что свойство
elпринимает значениеidэлемента, но почему оно использует#? Означает ли это, что я могу добавить другие селекторы элементов, такие как аттрибуты и классы? dataвыглядит как обобщённое имя свойства для объектаvue. Что именно она представляет собой?
Я не говорю, что вы должны быть настолько внимательными ко всему коду, который вы встречаете в своей жизни, но вырабатывание этой привычки поможет вам лучше понимать суть используемых приспособлений.
Не ленитесь
Лень может помешать вам продемонстрировать свои навыки или сделать вещи, которые кажутся вам важными. Например, если вы считаете, что рефакторинг может повысить производительность кода, — сделайте это! Добавьте комментарии, чтобы сохранить время других разработчиков. Задокументируйте написанный вами API. Время, вложенное вами в свой код, является сохранённым временем других разработчиков, которые будут работать с вашим кодом.
Решайте алгоритмические задачи
Решение задач на программирование (имеются в виду алгоритмические, возможно, олимпиадные задачи) заставляет вас задумываться о вещах, на которые вы не всегда обращаете внимание в повседневной работе. Я говорю об асимптотических оценках кода по времени и памяти. Некоторые люди утверждают, что таких задач бесполезно, так как всё уже сделано за вас и вам нужно просто работать с API.
Я не согласен с этой точкой зрения. Это не только помогает вам более критически смотреть на код, но также позволяет вам с уверенностью предлагать решения по улучшению производительности кода. Ещё одним плюсом является то, что знания, приобретённые вами в процессе решения алгоритмических задач, вполне могут пригодиться вам на собеседовании.
К сайтам, содержащим такие задачи, относятся: hackerrank, leetcode, codingame и другие.
Хвалите людей
Если вам понравился коммит, сделанный вашим коллегой, напишите ему об этом. Поставьте плюсик ответу на stackoverflow, оказавшемуся полезным для вас. Проголосуйте на medium за статью, которая дала вам полезные знания. Поставьте звёздочку заинтересовавшему вас проекту на github. Поощрение других людей помогает им, а затем и вам, развивать в себе лучшие качества.
Не отказывайтесь от задач какого-либо типа
Если вы видите проблему в API и представляете, с чем она связана, не стоит говорить: «Я — фронтендер. Это не моя проблема». На мой взгляд, такое отношение к проблемам является неправильным. Основные принципы программирования, такие как DRY, использование абстракций в случаях, когда классы реализуют смешанную функциональность, обработка исключений по всем возможным ветвям исполнения кода и т.д. применимы практически на любом уровне (фронтэнд, бэкэнд), где возникают задачи для программистов. Держа в голове эти принципы, вы, возможно, будете справляться с задачами, которые на первый взгляд кажутся «не вашей головной болью», так как вы работаете с другим кодом.
Заключение
Как я уже говорил, чтение этой статьи может помочь вам узнать о новых для себя вещах, способных сделать вас более квалифицированным программистом, и требующих усилий и дисциплины. Если вы нашли здесь идеи, кажущиеся вам полезными — не затягивайте, попробуйте реализовать их уже сейчас!
Комментарии (289)
EvilArcher
11.07.2018 14:49-1Все это замечательно, когда оторвано от бизнес-задач.
Каким бы советам вы не следовали, главное помнить, что любой наемный работник, в первую очередь, должен уметь приносить пользу компании, в которой работает. В связи с этим, я бы сформулировал другие советы «как стать полезным сотрудником», которые пригодятся не только программистам:
1) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
2) Изучайте бизнес-процессы компании.
3) Рационализируйте. Предлагайте идеи руководству по улучшению, не ждите, когда вам принесут ТЗ на блюдечке с золотой каемочкой.
4) Берите задачи чуть выше вашего уровня (знаний). Так вы сможете развиваться.
Так вы станете полезным, а значит востребованным и хорошо оплачиваемым. Программирование это всего лишь инструмент. Если вы не знаете как заработать с помощью него деньги для компании, то вы бесполезный балласт.suharik
11.07.2018 15:05+11) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
Ага. Товарищ один, занимавшийся разработкой модуля для хирургического отделения некоей больницы внял такому совету и начал изучать хирургию. Скальпели купил, маску, перчатки там всякие… И в 40 лет бросил профессию программиста, став хирургом.saluev
11.07.2018 15:25Очень круто, между прочим. Его междисциплинарный опыт может позволить ему увидеть места для инноваций там, где их никто раньше не видел.
zoonman
12.07.2018 07:55+1Такие сказки только в России возможны. В нормальной стране его бы к пациенту только лет через 10 подпустили бы после получения соответствующего образования, сдачи экзаменов и получения необходимой практики. В общем годам к 50 стал бы хирургом.
Whuthering
12.07.2018 08:23Мне кажется это был сарказм. По аналогии с многочисленными «историями» в обратную сторону, когда хирург, пройдя пару онлайн-курсов по веб-разработке, сразу же становится востребованным фронтенд-разработчиком.
JobberNet
12.07.2018 09:40Судя по статье pikabu.ru/story/ob_obuchenii_khirurgov_5060175 потребовалось бы существенно больше десяти лет.
Whuthering
11.07.2018 17:05Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
А потом смените работу и выясните, что эти знания никому не нужны. Например, если в вашем городе только один хороший банк со своим отделом разработки, только одна компания, делающая софт для телекома, и т.д.arilou_camper
12.07.2018 02:01+2Или не изучайте, и будете как в том анекдоте — «могу копать, могу не копать»
kiwokr
12.07.2018 09:48Лишних знаний не бывает. И работать не зная предметную область и бизнес процессы компании это просто бред.
Neikist
12.07.2018 09:52Имхо, конечно какое то понимание нужно, но по моему мнению не то что на конкретную предметную область, на конкретные технологии завязываться не очень.
Femistoklov
12.07.2018 03:31+21) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
А если, к примеру, мне неинтересен телеком, всякие сети и передачи данных кажутся скучными? И финансы с бухгалтерией терпеть не могу.Free_ze
12.07.2018 12:13Так и речь не шла про увлечения и интересы. Если в комплекте идет плохая усидчивость и мотивация, то есть риск стать там малополезным парнем. Такое случается и, наверное, стоило бы подумать о другом рабочем месте с более интересной прикладной областью.
Ведь ощущение пользы от своего труда (облегчение работы других людей, сэкономленные ресурсы компании или удовлетворение клиентов) — это само по себе неплохая мотивация, как мне кажется. Но как понять боль людей, о которой ты не имеешь даже поверхностного представления?0xd34df00d
12.07.2018 19:07Хехе. Никогда не понимал этой мотивации. Решить интересную сложную задачу — это да. Даже если у неё нулевая практическая применимость.
Free_ze
12.07.2018 21:23Взаимно) В чем радость решения абстрактной в вакууме задачи? Для меня это звучит как рекорды гиннеса про толкание апельсинов носом.
peresada
11.07.2018 14:59Старайтесь быть добрее
Когда в следующий раз встретите бездомного алкоголика, который идет на Вас с угрожающим видом, предложите ему помощь, отмойте его, обрейте, усыновите, купите ему квартиру, найдите ему жену, пожертвуйте собой ради его будущего.
__________
Вот как-то так читаются подобные статьи. Лучше потратить время на какую-нибудь классическую утопиюimmaculate
12.07.2018 03:34Нет, не значит. Помочь человеку не значит дать ему денег или квартиру. Иногда даже ударить человека — значит помочь ему (например, когда дают пощечину, человеку, находящемуся в шоке).
Быть добрым и по-настоящему помогать людям — это очень сложная задача, отнюдь не раздавать деньги и ресурсы каждому встречному.
JobberNet
12.07.2018 06:37+1Иногда даже ударить человека — значит помочь ему
… то есть, гопник помогает лоху понять, что он лох и ссыкло.immaculate
12.07.2018 06:46-1Я в скобках написал пример того, когда ударить человека — помочь ему. Нет однозначного способа помочь каждому, такого как: дать каждому денег, или ударить каждого.
Помочь — значит вникнуть в ситуацию конкретного человека и дать ему именно ту помощь, в которой он нуждается.
Здесь нет одного решения, которое годится для всех. Одному человеку нужно дать совет, другому дать денег, третьего утешить, четвертому дать книгу, пятому что-то другое.
И стараться быть добрым не значит, что надо помогать каждому встречному. От такой помощи нередко даже вред может быть, недаром говорят, что добрыми намерениями дорога сами знаете куда вымощена. Без мудрости помочь другому человеку не навредив себе или ему невозможно.
musuk
11.07.2018 15:34Главное забыли:
Не женитесь
Не заводите детей
Не имейте других хобби
А то не будет времени на тесты, опенсурс и прочее.Neikist
11.07.2018 15:42Насчет других хобби могу поспорить. Например я совмещаю велосипед со слушанием подкастов. Иностранные можно учить с расчетом на переезд, ну и в конце концов иногда нужен отдых, так что можно завести что нибудь расслабляющее для этих целей.
Piratz
12.07.2018 10:40То есть насчёт «Не женитесь, Не заводите детей» вы согласны ?)
Neikist
12.07.2018 10:42Лично я вижу это логичным, поскольку и без этого на разное самообразование часов 20 в неделю хорошо если удается выкроить, а уж если заводить семью, или общаться с друзьями чаще чем раз в месяц-два — вообще представить не могу как как то развиваться.
Germanets
12.07.2018 15:55Ну я на счёт «не женитесь» не соглашусь, многим женившимся готовить приходится примерно в 2 раза реже, и заниматься всякими подобными вещами по дому… А уж если учитывать особенности менталитета и воспитания, то есть шансы вообще найти вариант, при котором готовить\стирать\работать по дому больше не придётся)
Может, конечно, всё наоборот получиться, но это опять же вопрос выбора и может быть немножко везения..)
UPD: увидел уже подобную ветку обсуждения от другого комментария…
jeConf
11.07.2018 16:20+1«Не женитесь» я бы вычеркнул.
Иначе кто будет содержать программиста в то время когда он «тесты, опенсурс и прочее», а при этом на всех доступных работах хотят чтобы всё заработало вчера.Whuthering
11.07.2018 17:41+1… иначе кто будет выносить программисту мозги «опять сидишь в комп уткнулся», когда он «тесты, опенсурс и прочее»…
reiser
12.07.2018 13:19Приготовить простую и вкусную еду занимает не так много времени, ну либо можно в кафе работать :)
0xd34df00d
12.07.2018 01:06Подтверждаю, очень важные пункты, без них к успеху не придёшь.
Я вот завёл хобби в виде всякой математики, теперь меньше времени на опенсорс и программирование :(
AlekseyCPP
11.07.2018 17:34Это не для России, честное пионерское :)
Ну какой опен- сорс? У нас тестов не делают, а архитектурные вопросы решаюся добавлением глобальных флагов (я уже не говорю об изучении чего-то нового). Компании всеми силами стараются минимизировать расходы на программистов, потому что считается что они и так получают неприлично много. Последнее происходит из- за знания программистами английского языка и как следствие- возможности продавать себя на западном рынке (а значит рынок IT в России должен конкурировать с глобальным).Neikist
11.07.2018 17:39Фух, а то я читая хабр уже начал дикий комплекс неполноценности зарабатывать, так как уже возникает ощущение что наша компания одна такая на всю страну осталась. Теперь знаю что их по крайней мере две (если мы конечно не из одной)))
Whuthering
11.07.2018 17:42+1Честно скажу, меня всегда интересовало, что же держит людей в таких компаниях. Особенно учитывая, что альтернатив на рынке труда просто море.
Neikist
11.07.2018 17:52В моем случае то что я программирование изучать начал примерно за год до окончания вуза, на момент окончания почти не знал английский, да и программирование тоже + возможность выбирать только в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд, но потребуется еще и сильно фундамент подтянуть, плюс стек сменить (текущий выбирал из того что было доступно на момент начала карьеры).
А, ну еще общая тупость мешает конечно же.shmatuan
12.07.2018 11:31в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд,
Почему не удалёнка или фриланс? Вакансий хватает, так что вариант далеко не «только один» -_-Neikist
12.07.2018 11:40Думал, но как я и говорил, хочу стек сменить, а на удаленку, как правило, нанимают уже состоявшихся специалистов на конкретном стеке, ну либо нанимают на небольшие проекты или задачи на несколько месяцев, не больше.
Да и про общую тупость упоминал уже которая не позволит с сотнями других удаленщиков конкурировать. Вон, только в марте прочитал «Грокаем алгоритмы», а уже не только не могу вспомнить решение задач методом динамического программирования, даже не помню список всех рассматриваемых в книге тем. А ведь книга то простая и совсем базовые вещи описывает.
Areso
12.07.2018 12:30Можно сначала сменить город, а там уже действовать по ситуации)
Сам вот переехал, не жалею, климат только бесит. Всем остальным, кто сомневается переезжать или нет, советую переезжать.
firk
11.07.2018 18:00+6Статья — просто куча шаблонов, часть из которых придуманы как раз теми, кто указан в заголовке. Часть из этих советов просто спорны (например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным), часть — хорошие, но не имеют отношения к теме статьи (например «будьте честны»), часть — вообще не в тему и потенциально вредные (например «умерьте своё эго», более того у этого совета заголовок не соответствует содержанию).
Neikist
11.07.2018 18:02например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным
С этим пунктом не согласен. Код может писаться в целях обучения или развлечения. Тогда ему совершенно нет необходимости реализовывать полезный функционал.
zoonman
12.07.2018 08:00Да типичные советы индусов. Выключите мозг и зазубривайте шаблоны до автоматизма, а затем пишите тонны спагетти.
А результат один — текстовый редактор в браузере, который умирает на файле в 100 кб.
vp_arth
12.07.2018 00:15+1Даже если все функции валидации сегодня у вас синхронные, стоит предусмотреть в интерфейсе возможность добавить асинхронную валидацию в будущем:
validate(data)
.then(postdata)
.then(append..)
.
m0Ray
12.07.2018 00:58Когда я начал активно тестировать свой код, я был удивлён своей неподготовленности к написанию качественных тестов.
Когда я начал сдавать свой желудочный сок, я был удивлён своей неподготовленностью к сдаче качественного желудочного сока.
ЕВПОЧЯ.
ДТКВТ: «Второе нашествие марсиан».
Вы удивитесь, но я могу писать рабочий код, не «покрывая его тестами». Я просто вижу, как он работает, моделирую его в сознании. Это требует усилий, разумеется. Но заменять это на тупые автотесты? НетЪ!
Ваши карманные калькуляторы отучили вас считать в уме. Это больше не искусство, это тупое ремесло.0xd34df00d
12.07.2018 01:08+2Восхищаюсь вашим умом, способным сохранять ментальную картину кода на многие месяцы, и вашими коммуникативными навыками, способными эту ментальную картину передать следующему владельцу написанного вами кода.
А как вы к строгой типизации относитесь, кстати? Или лучше всё в строку, а тайпчекер не нужон?m0Ray
12.07.2018 01:17+1Вот тут я немножко уязвим: другому человеку ментальную картину кода/проекта я передать не в состоянии. Хотя чужую, наверное, пойму, хоть и не с единичной вероятностью.
Что поделать, это текущие ограничения физических тел homo erectus'ов не позволяют прямой обмен мыслеобразами. Эволюция это исправит когда-нибудь.
Типизация у меня в коде зачастую строгая. Даже когда кодю на Python, соблюдаю. Внутри сознания, разумеется.
i86com
12.07.2018 03:38+1Тут вся трагедия в том, что этот список ассертов в конце юнита люди (по историческим причинам) называют тестами, из-за чего у них возникают лишние ассоциации к тому, зачем и почему это делается. Ну, мол, «тесты нужны, чтобы протестировать. Не будешь же ты непротестированный код выдавать».
Так вот для нормального тестирования нужны тестировщики (в мелких проектах эту функцию легко выполняет сам программист или принимающий работу).
А тесты же нужны в основном для того, чтобы автоматически выявлять ситуации, когда «тут починил, а там в 3 местах отвалилось». То есть в больших, развесистых проектах, с большой командой разноуровневых программистов или если цена ошибки очень велика (биржа, например). Чтобы можно было быстро, просто и без оглядки редактировать код под текущие нужды.
Поэтому нет смысла писать людям про необходимость тестов и создавать из этого культ карго, когда тесты нужно писать «потому, что в Интеле пишут» или «потому, что best practices». В тех проектах, где тесты нужны, их необходимость становится очевидна всем участникам.m0Ray
12.07.2018 09:16-2«тут починил, а там в 3 местах отвалилось»
Я с трудом себе могу представить такую ситуацию. Кто в здравом уме допустит криворуких программистов к коммерческому коду? Немыслимо…JobberNet
12.07.2018 09:32+3Аутсорсинг?
Фреймворки?
Когда во фреймворке была ошибка — код в этих трёх местах был написан с поправками на наличие ошибки во фреймворке, так что исправление ошибки во фреймворке, привело к тому, что код учитывающий наличие ошибок — теперь сам работает ошибочно.
Легаси?
Просто заплатки на заплатках лепившиеся в спешке.m0Ray
12.07.2018 09:41Ну, работал я на аутсорсинге. Писал код, претензий у заказчиков не было.
Любимые фреймворки — Drupal, Symfony, jQuery (на фронтенде). Ошибка во фреймворке — issue разработчику. Код, «учитывающий наличие ошибок» — это что? «Грязные хаки» так называемые? Такого в моём коде не бывает.
Даже «лепившееся в спешке» у меня выглядит прилично, а затем перерабатывается.
Я так и не понимаю, зачем писать говнокод в файлы, если можно проработать кучу вариантов кода в голове, и только потом изливать это в виде текста программы.
aikixd
12.07.2018 10:18Если задача достаточно сложная, последствия могут быть непредсказуемыми. У нас виртуальная машина, сломать там что-то совсем не сложно. Тем более что весь объем спецификации загрузить в голову невозможно даже теоретически.
m0Ray
12.07.2018 11:36Для этого большая задача разбивается на более мелкие с унифицированным интерфейсом и загружается и решается последовательно (одним программистом) или параллельно (командой). Главное — правильно разделить и унифицировать. Это уже опыт, талант и «чуйка».
Программирование — творческая работа, щоб ви таки знали.
i86com
12.07.2018 11:03«тут починил, а там в 3 местах отвалилось»
Я с трудом себе могу представить такую ситуацию.
Да легко. Например, перевод системы на новую кодировку или имперскую систему счисления (ну, там, дюймы, фунты, фаренгейты, MM-DD-YY). Пока в Вилларибо натужно вспоминают все те места, где это может что-то поменять, в Виллабаджо уже по тестам сразу видят, где что не так.m0Ray
12.07.2018 11:34«Реши другую проблему так, чтобы большинство предыдущих вообще потеряли смысл».
Unicode, std::chrono — я люблю вас.0xd34df00d
12.07.2018 19:09Так это надо, значится, типы любить, а не пихать всё в int, string и void*.
akera
12.07.2018 09:24+2Поэтому нет смысла писать людям про необходимость тестов и создавать из этого культ карго, когда тесты нужно писать «потому, что в Интеле пишут» или «потому, что best practices». В тех проектах, где тесты нужны, их необходимость становится очевидна всем участникам.
Не лучше ли тогда сразу развивать в себе это полезное качество, чтобы иметь в любую возможность плавно влиться в такие проекты? Для конкретного разработчика это, как мне кажется, сулит бОльшие перспективы.
Вообще, как начинающий разработчик, я часто в подобных дискуссиях задаюсь вопросом: в чём заключаются явные преимущества неписания юнит-тестов перед их написанием? Потому что в пользу обратного говорит очень много фактов. Если речь, конечно, не заходит о совсем тривиальных элементах кода.
Так вот для нормального тестирования нужны тестировщики.
«Нормальное» тестирование — слишком расплывчатое понятие, непонятно, как его интерпретировать. Очевидно, по общепринятым классификациям тестирования ПО для некоторых его видов требуются и отдельные тестировщики, и целые их команды, и наборы технических средств для автоматизации. Но с позиции непосредственно разработчика переносить ответственность за работоспособность своих модулей на кого-то ещё — неправильный подход.i86com
12.07.2018 10:37в чём заключаются явные преимущества неписания юнит-тестов перед их написанием?
Экономия сил и времени. Так-то по-хорошему, любой код можно оборачивать тестами, писать к нему документацию на двух языках и оптимизировать мелочи типа «что быстрее в микросекундах — for или while». Но если из-за этого задание на вечер превращается в работу на неделю (особенно если код временный, одноразовый или для собственных нужд) — это, чаще всего, лишнее.
Если работаете за фиксированную оплату по результату или пишете для себя — ради бога. А если повремёнка — то вы уже просто прожигаете чужие деньги и тратите время (которого обычно и на быстрый-то код не хватает).
Но с позиции непосредственно разработчика переносить ответственность за работоспособность своих модулей на кого-то ещё — неправильный подход.
Это не ответственность за работоспособность. Тестировщиков никто не обвинит в том, что они нашли баг и не заставят его чинить.
Это просто разделение труда — человек, который умеет эффективно писать код продакшен-уровня это редкость и их всегда не хватает. Пусть лучше занимаются самой продуктивной своей деятельностью, а не тем, что можно поручить остальным.
Также часто это всплывает при работе с нечёткими и постоянно меняющимися требованиями к результату (то есть в реальной жизни бизнеса). Пусть лучше заказчик сам оттестирует или даст оттестировать своим сотрудникам (будущим пользователям), потому что там не столько вопрос работоспособности, сколько вопрос соответствия ожиданиям. А это юнит-тесты не покрывают.Whuthering
12.07.2018 11:54А если повремёнка — то вы уже просто прожигаете чужие деньги и тратите время
То есть деньги и время, затраченные на ручной поиск и разгребание регрессий в будущем вы не учитываете?i86com
12.07.2018 12:19Это я отвечал про проекты, где тестов не нужно, но очень хочется. Например для тренировки.
Там где нужно, я выше упоминал, вопроса не возникает, нужно ли.Avvero
12.07.2018 12:30Интересно, что это за проекты, где не были бы полезны тесты
m0Ray
12.07.2018 12:43Лучше назовите проекты, где они полезны.
Вот всякая бухгалтерия с кучей однотипный форм и операций — согласен. И возни с тестированием каждой много, и операции простые.
Только вот при слове «бухгалтерия» меня тошнит. Наелся при разработке биллинга. Не берусь за подобное мозгоклюйство в принципе. Нехай зануды без воображения однообразные формы клепают, а я — программист, я решаю задачи.Avvero
12.07.2018 12:48Для бэкенда они просто обязательны.
m0Ray
12.07.2018 12:52Сколько писал бэкендов — ни разу не понадобились.
Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.
Сложные, логические — для них тест писать дольше, чем сам продукт. Я не вижу смысла тратить на это время.Avvero
12.07.2018 13:03>Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.
Хорошо, когда ваш бэкенд тестируется «прямо в браузере вручную набранным URL-ом.». А вот мой не тестируется так, он у меня, например, торчит http концом наружу и ждет запросов в свой api. Мне придется дергать кучу запросов руками и проверять толстенные json ответы?
А бывает, когда бекенд сервис вообще не имеет http конца, а только ESB слушает и отвечает.
А бывает, когда бекенд сервис интегрирован с другим сервисом через хитрый протокол и руками ничего вызвать из «браузера» нельзя
Бывает, что нужно проверить нагрузку, а я не могу открыть в своем браузере 10к вкладок с «вручную набранным URL-ом»m0Ray
12.07.2018 13:09А у меня вообще через MQTT некоторые бжкенды работают, и что? JSON вполне человекочитаем.
Нагрузочное тестирование сюда не надо приплетать. Это из другой оперы. Мы о скриптиках, которые подёргают API и найдут тупые ошибки.Avvero
12.07.2018 13:10о скриптиках, которые подёргают API и найдут тупые ошибки
Вы такие скрипты пишете?m0Ray
12.07.2018 13:15Нет. Я могу это сделать руками, если нужно.
Avvero
12.07.2018 13:22(пошел посмотреть)
У меня есть сервис… раскладывания кошек по коробкам в зависимости от породы кошки, цвета шерсти и 5-и других параметров.
Тест для 300 case'ов работы сервиса распределения занимает 3 минуты. 1 case — это уникальный набор параметров кошки отправленный http запросов в сервис.
Руками это проверять оооооочень долгоm0Ray
12.07.2018 13:25Параметры по отдельности проверить не вариант? Их всего пять.
Если неправильно работает один параметр — это видно сразу.
Если вы умудрились сделать так, что у вас программа работает в зависимости от сочетания параметров и фазы Луны — ну извините.Avvero
12.07.2018 13:29Фаза луны не при чем. Но разные комбинации параметров дают разный результат. И таких комбинаций/результатов много, как я описал.
Руками проверить нужно каждый случай, потому что все работать должно на бою правильно иначе потеря тысяч денегm0Ray
12.07.2018 13:35Разумеется, разный. Но каждый параметр определяет свой набор результатов. Если анализ каждого параметра сделан верно — результат будет правильным. Я не понимаю, зачем тестировать весь набор.
Впрочем, если у вас есть «тысячи денег» и время, чтобы такую проверку реализовать и гонять каждый раз — вай нот? У меня — нет.Avvero
12.07.2018 13:42Если анализ каждого параметра сделан верно — результат будет правильным
Если. А как вы этом убедиться? Нужно проверять
если у вас есть «тысячи денег» и время, чтобы такую проверку реализовать
Я выше привел пример, 300 случаев, каждый нужно проверить. Тестом — 3 минуты, руками — часыm0Ray
12.07.2018 13:49Нужно убедиться, что анализ каждого параметра прописан верно. Это можно узнать, посмотрев на код и покрутив его в голове. Их всего 5.
Если у вас 300 вариантов — то каждый должен быть прописан в коде? Это что-то ненормальное и очень большой объём. Надо посмотреть на задачу с другой стороны и решить её как-то иначе. Например, посмотреть в сторону таблиц или хэшей.
Я в аналогичном случае просто передавал анализатору PNG-изображение, в котором он по координатам получал 4 параметра и делал с ними предписанное. В изображении «косяки» можно обнаружить чисто визуально.Avvero
12.07.2018 13:59Параметров 8 (порода кошки, цвета шерсти и 5-и других параметров), а для каждого свои варианты значений.
И распределение нельзя как-то высчитать, оно соответствует описанной бизнесом логики.
И да, схемы распределения конечно же хитрые — сегодня черных метровых кошек с зелеными глазами в коробку #21, а завтра в #22
При этом нужно учитывать, что написал я распределение, тесты, все ок и далее идут задачи на изменение схемы и, благодаря наличию тестов, я могу править только нужные кейсы и не переживать за другие части сервиса — там тесты тоже есть. Поэтому оценка задача на правку схемы такой мизерная.
А при отсутствии тестов все эти 300 случаев руками перепроверятьm0Ray
12.07.2018 14:22Океюшки, вы описали случай, где тесты реально нужны. Как я и говорил — такие случаи есть, но это не значит, что их надо лепить везде где ни попадя.
Но я бы подумал над тем, как решить задачу иначе.
У меня, если стрелки попадают по мишени, а она не срабатывает или срабатывает нечётко — это видно сразу. Моя система автоматически подстраивается к разным параметрам окружения, а некоторые другие не меняются практически никогда, они вычислены или подобраны на оптимум.
И так я стараюсь делать всё. Получается слишком сложно — разделяем задачи и оставляем минимум места ошибкам.
0xd34df00d
12.07.2018 19:12Мне очень нравится писать компиляторы через тесты. Продираешься через спеку языка, реализуешь ещё один кусок — добавляешь тест.
Меняешь логику, преобразования AST, кодогенератор, всё такое — чинишь тесты и потом радуешься, что они снова зелёные.
Просто рефакторишь код, чинишь всю ругань ghc — а тесты уже зелёные. Приятно сразу!
i86com
12.07.2018 13:31Интересно, что это за проекты, где не были бы полезны тесты
Я в предыдущих комментах перечислял.
По критериям:
— проекты, где нет развесистой логики;
— проекты, где нет необходимости в долгой поддержке кода и/или большой команде программистов;
— где невелика цена ошибки, но при этом крайне важна скорость выхода;
— проекты, в которых основное тестирование может выполнить только заказчик и пользователи/тестировщики (т.е. самое главное автоматизировать не получится).
Примеры таких проектов:
— прототипы;
— игры (почти все, за исключением AAA-класса и игр с реальными деньгами);
— интерфейсы, основная функция которых — отображать данные с уже существующих API;
— прикладные программы, которые нужны временно или одноразово;
— практически все проекты от бизнеса, в которых ТЗ пишется умными словами, но на нормальный язык его можно перевести как «Сделайте такое же, как вон там, но другое. Насколько другое — пока не придумали. Увидим — скажем, что поправить.»;
Опять же, в тех проектах, где тесты нужны, это всегда очевидно. Если нет, значит, это неэффективная трата времени.
А иначе можно дойти и до того, чтобы команды в консоли с тестами писать.m0Ray
12.07.2018 13:36А иначе можно дойти и до того, чтобы команды в консоли с тестами писать.
Тащемта я так и делаю.
А ещё printf().i86com
12.07.2018 13:41Перефразирую — команды в linux-консоли с тестами к ним же.
m0Ray
12.07.2018 13:49Именно.
i86com
12.07.2018 14:32То есть если вам нужно, например, пару раз переименовать все файлы в папке из
*_rus_*.csv
в
*_eng_*.csv
, вы пишете консольную команду, и затем после этого (или перед этим) в той же команде создаёте n тестовых файлов с разными названиями и расширениями и проверяете, всё ли правильно переименовывается? Сомневаюсь.m0Ray
12.07.2018 14:42Ну сомневайтесь. А я для этого просто создам каталог «на поиграться» и проверю, если случай действительно сложный. Если там будет задействован rm, я ещё и chroot сделаю.
0xd34df00d
12.07.2018 19:14Если это действительно важно, я такой скрипт пишу на хаскеле. Логику переименования пишу в отдельной чистой функции, в repl её вызываю с тестовыми данными, а потом к ней пишу IO-обвязку из трёх строк, в котоой ошибиться невозможно.
ProgMiner
12.07.2018 07:12+1Считал, что могу писать нормальный код без юнит тестов, пока не начал писать юнит тесты.
m0Ray
12.07.2018 09:12-1Начал писать юнит тесты, не понял, зачем это мне нужно, бросил писать юнит тесты.
Whuthering
12.07.2018 09:17+2Может быть, стоило попробоваться поучаствовать в проектах хоть немного сложнее хеллоу-ворлда?
m0Ray
12.07.2018 09:35Комплекс TTC, или, например, система маршрутизации и биллинга и для IP-телефонии (написанная практически в одну харю) — сложнее хеллоу-ворлда, как думаете?
IRainman
12.07.2018 09:59+2написанная практически в одну харю
Вот в этом разница, если была бы команда без тестов было бы совсем грустно.m0Ray
12.07.2018 10:01-3Команда за год написала такое, что я за два вечера переписал и послал нахер такую команду.
Avvero
12.07.2018 10:55+1Мы обычно наоборот, а потом все еще тестами покроем
m0Ray
12.07.2018 11:05И фирма разорится, потому что код всё равно не будет работать как надо, требовать нового железа (в моём случае были Cisco AS53xx), платных средств разработки, и команда разработчиков будет много кушать.
Проходили. К сожалению, реальность такова, что один-два-три нормальных программиста, способных держать задачу (или свою часть оной) в уме, гораздо продуктивнее команды неумех, вызубрившей «паттерны», «TDD», всякие там новомодные способы трахать мозги себе и окружающим (agile или что ещё там) и прочее.
Работать надо, и надо знать своё дело. Иначе получается не работа, а ИБД без видимого результата.Whuthering
12.07.2018 11:18вызубрившей «паттерны», «TDD», всякие там новомодные способы трахать мозги себе
Особенно смешно, учитывая, что все это было придумано и успешно используется в деле как раз-таки программистами, для более удобного, эффективного и надежного процесса разработки. Может быть все-таки проблема не в окружающих, а в вас?m0Ray
12.07.2018 11:29Нет, проблема в тех, кто считает себя программистом, не имея к этому способностей и таланта. Вот они для себя это придумали и как-то так это работает [биллгейтс.жпг].
Напоминает: «он стал поэтом, потому что для математики у него не хватало воображения». Мне вроде всего хватает, в костылях нужды не испытываю.Whuthering
12.07.2018 11:35проблема в тех, кто считает себя программистом, не имея к этому способностей и таланта.
а вот уже и началась телепатия и выводы, не основанные ни на чем.
Мне вроде всего хватает, в костылях нужды не испытываю.
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.m0Ray
12.07.2018 11:38Намекаете на «мартышку и очки»? Так я не слаб глазами (образно, физически-то скоро ослепну). Мой код работает.
aikixd
12.07.2018 11:37+1Паттерн это способ коммуникации, а не инструмент. Нельзя взять паттерны и собрать их в архитектуру. Но если вы пришли к решению и оказалось что у него есть название, то вам проще донести информацию другому разработчику. Так-же бесполезно учить паттерны заранее, вы все равно их не поймете. Однако прочитав о паттерне который вы уже придумали, вы без проблем запомните его название и варианты реализации.
Лично у меня был пример. Несколько лет назад прочитал про паттерн "Команда". Спустя пару лет, когда он мне понадобился, я ничего о нем не помнил. К счастью название не забыл. Зашел на вики, пошуршал, ничего не понял. Может написано плохо, может я тупой. Взял маркер, доску, придумал свою реализацию, закодил, протестил, все работает. Вернулся к статье и тогда внезапно все стало понятно.
Суть в том, что паттерны не живут в вакууме. Для них нужны причины, у них есть свои проблемы и узкие места в рамках своего окружения. И в отрыве от окружения они бесполезны.
Вот фабрика. Вроде всем понятно зачем она нужна, но в отрыве от задачи ничего не понятно. Зачем городить огород, если можно просто создать объект?
m0Ray
12.07.2018 11:42-1«Зачем думать, если можно взять паттерн?»
А если паттерн не очень подходит к задаче? А если архитектор некомпетентен?
Если я скажу: «нужно исключить возможность создания копии объекта», вы поймёте, что я говорю? И любой, даже не знающий паттернов поймёт. Потому, что я знаю, о чём говорю, и объясняю доступно.
Если я скажу: «ну, тут просто сделайте синглтон» — повысится вероятность того, что я получу на выходе НЁХ, не соответствующую задаче. Зато слово умное сказал, паттерны знаю, ога.aikixd
12.07.2018 11:49+1Все сводится ко времени которое вы готовы потратить на общение. Если для описания решения (это в том числе и имена символов в коде, который потом кто-то будет читать) половина времени уходит на описания паттернов (есть паттерны которые реально долго описывать), то это контрпродуктивно.
m0Ray
12.07.2018 12:04Если задачу объясняют мне, неважно, мыслю я зазубренными паттернами, как овощ или, как человек, образами-«голограммами». То же самое неважно, если задачу объясняю я.
Я, как правило, ставлю задачу: что этот код должен делать и как я к нему должен обращаться. Потом сам же решаю или передаю другим людям. Главное — сформулировать задачу. Недаром говорят, что это половина решения.
Объяснять задачу надо максимально просто и доходчиво. Без «умных» слов желательно. Можно с матюками.
«Эта процедура должна найти на изображении красную точку с ограничением по яркости и размеру. Она будет запускаться в многопоточном окружении.»
«Требуется передать ряд изображений на многопоточную обработку вон той процедуре, после чего собрать результаты обработки обратно в правильной последовательности».
«Нужно проанализировать ряд результатов и найти внезапно появившуюся красную точку, определить принадлежность её координат зоне, определяемой битовой картой, при нахождении вызвать событие.»
«При таком-то событии следует передать сообщение по сети, протокол такой-то, параметры должны включать координаты, время и изображение.»
Реальные задачи, между прочим. Доска с беспыльным мелом рулит (ненавижу фломастеры).aikixd
12.07.2018 14:29«Эта процедура должна найти на изображении красную точку с ограничением по яркости и размеру. Она будет запускаться в многопоточном окружении.»
«Требуется передать ряд изображений на многопоточную обработку вон той процедуре, после чего собрать результаты обработки обратно в правильной последовательности».
«Нужно проанализировать ряд результатов и найти внезапно появившуюся красную точку, определить принадлежность её координат зоне, определяемой битовой картой, при нахождении вызвать событие.»
«При таком-то событии следует передать сообщение по сети, протокол такой-то, параметры должны включать координаты, время и изображение.»Это все задачи, тут ни слова об исполнении.
вызвать событие
События, кстати, паттерн.
m0Ray
12.07.2018 14:40Вот именно, я ставлю задачи. Как их решать — должен знать исполнитель.
Берём первую. Исполнитель начинает задавать вопросы.
В: В каком виде изображение?
О: Байтовый массив, представляющий JPEG-rкодированное изображение.
В: openCV можно?
О: Нужно.
Всё. Исполнитель понял, что ему, скорее всего, передадут shared_ptr из стандарта C++11, декодировать изображение надо при помощи cv::imdecode(), преобразовать цветовое пространство, свериться с моделью цветового пространства и т.д., понеслась работа. Это если исполнитель владеет темой.
По счастью, тут исполнитель я и всё это в принципе знаю. А на практике, конечно, пронеслась куча итераций сначала в голове, потом в реальном коде.
Паттерн? Окей. Но слово «событие» вам понятно и без знания паттернов, не так ли?
Whuthering
12.07.2018 11:52+1«Зачем думать, если можно взять паттерн?»
Вам выше автор комментария написал, что бессмысленно бездумно брать паттерны (да и никто так не делает), а вы приводите реплику ровно с обратным смыслом.
А если паттерн не очень подходит к задаче?
То ничего не мешает подумать и модифицировать его, чтобы подходил.
Если я скажу: «нужно исключить возможность создания копии объекта», вы поймёте, что я говорю?
То это будет так:
Obj(const Obj&) = delete;
Это вообще не похоже на синглтон и не реализует его функционал. Так что вы привели отличный контр-пример к своей же теории.m0Ray
12.07.2018 12:06Наоборот, я привёл пример того, что задача отлично решается без паттернов. Надо уметь её формализовать и изложить даже самому себе, тогда она решается гораздо проще.
Avvero
12.07.2018 12:28способных держать задачу (или свою часть оной) в уме, гораздо продуктивнее
Не понятно, что тут продуктивного
А если он в отпуск ушел? Был уволен? Ни документации, ни тестов, ни фига… все унес в своей большой и умной голове.
Потом компания тратит деньги — время нового программиста, который вычитывает тонны кода и пытается уместить у себя в голове. А потом еще тратит на регрессионное тестирование сервиса.
При наличии тестов все проще, если что-то сломал, то это видно сразу — упали тестыm0Ray
12.07.2018 12:32Вот это — слабое место. Человек смертен, а хуже всего — что он внезапно смертен.
Я это осознаю и максимально облегчаю работу последователям. А если проект начнёт приносить деньги — возьму падавана.
Так делается у людей тащемта.Avvero
12.07.2018 12:33И как вы ее облегчаете?
m0Ray
12.07.2018 12:37Хорошо структурированный и откомментированный код, записки о ходе мыслей, архитектуре и планах.
Вряд ли увеличение объёма кода тестами было бы облегчением, если вы об этом.Avvero
12.07.2018 12:45+1Скажем иначе. Если код не покрыт тестами, то оценка временных затрат на доработку этого кода и тестирование будет значительно выше, т.е. будет стоить дороже.
m0Ray
12.07.2018 12:49Не согласен. Человеку помимо основного кода придётся разбирать и дописывать тесты, а значит, разбираться ешё и в системе тестов.
А нормальному программисту, как я постулирую, тесты в основном без надобности. Есть пограничные моменты, где они необходимы, но они не так часты.Avvero
12.07.2018 12:53А как вы поймете, что ваша правка ничего не сломала?
m0Ray
12.07.2018 12:56Если она что-то сломает, это сразу вылезет. Как я говорил, исключение — сложные системы с множеством форм, которые ручками не протыкать за нормальное время.
Я таких не делаю. У меня нынче всё по-военному: затвор, приклад, спуск. Всё смазано и вычищено. Не дать дураку выстрелить себе в ногу. Работа такая.Avvero
12.07.2018 13:06ручками не протыкать за нормальное время
А это какое время? Час, два?m0Ray
12.07.2018 13:10Пять минут. Если интерфейс программы за это время не обойти полностью — с ней что-то не так. Или она для бухгалтера.
Avvero
12.07.2018 13:11А если нет интерфейса? Тоже что-то не так?
m0Ray
12.07.2018 13:14Тогда она не нужна. Сообщить программе задачу и получить от ней результат — это интерфейс, как бы он ни выглядел. Программа, которая не делает ничего, не нужна.
Avvero
12.07.2018 13:15Я наверное не так понял, вы же имели ввиду графический интерфейс?
m0Ray
12.07.2018 13:16Любой. API, к примеру.
Avvero
12.07.2018 13:24Значит я не так понял.
А 5 минут это вместе с подготовкой данных для запроса? Ну например мне нужно разными json запросами сервис вызыватьm0Ray
12.07.2018 13:29Как правило, данные готовятся один раз. Накидал пару-тройку запросов, сунул их в браузер или командную строку — и погнал. Оттестил — закрыл окно. На крайняк есть история, что в командной строке, что в браузере.
ankh1989
12.07.2018 14:15Это только в совсем простых случаях работает. Вот вы делаете браузер например: надо отрендерить html, css, js. Вам кто то даёт ссылку на сайт где разметку подозрительно перекосило — в других браузерах всё нормально. Допустим вы догадались в чём дело и пофискили баг. Как вы узнаете, что ничего другого не сломалось?
m0Ray
12.07.2018 14:24Открою страницу в нескольких браузерах (у меня их 4 штуки до сих пор стоит — да, да, и фронтенд тоже не мне), подвигаю размер окна. Если не сломалось при этом — значит, если и сломалось что-то, то это мизерный процент случаев, на который можно не обращать внимания.
То же самое с вашими тестами — сколько ни пишите, 100% никогда не покроете.ankh1989
12.07.2018 14:34Всё верно, ломается оно допустим в 5% случаев на некоторых сайтах с корпоративной формой авторизации где кривой html нахаченный индусами за еду. У вас даже не будет доступа к этим сайтам. Вы зафигачили багфикс в продакшн, а через неделю 4 компании которые платят вам за браузер говорят, что у них на работе стала часто глючить авторизация — раньше такого не было, поэтому либо платим неустойку либо фиским это в течении 3х дней как сказано в договоре. Были бы тесты, мы бы сразу заметили, что вот такая комбинация css пропертей вызывает глюки, но тестов нет. Что делать будем?
m0Ray
12.07.2018 14:45Не будет доступа — это заранее оговорено в договоре?
Оговорено — сразу нахрен таких поциэнтов.
Я должен знать, с чем работаю.ankh1989
12.07.2018 14:50Ну а что если баг возникает только когда вице президент компании вводит свой пароль на внутреннем сайте авторизации? Он должен вам дать свой пароль, чтобы вы подебажили html разметку? На деле у вас не будет даже такой роскоши как 100% воспроизводимый баг — вам просто скажут, что примерно в таких ситуациях глючит примерно так. Это вы должны будете разбираться что именно не работает.
m0Ray
12.07.2018 14:55«Плавающий баг» — признак говнокода. Переработай говнокод — баг исчезнет. Так говорит мой опыт.
ankh1989
12.07.2018 15:01Баг не плавающий. Он возникает в конкретных условиях: конкретный html, css, js. Но получить именно эти html и т.п. вы не можете по описанной выше причине.
m0Ray
12.07.2018 15:03Хорошо, вы нашли ещё один из немногих случаев, где тест поможет.
Сколько вы их выкопаете ещё? Из множества всех возможных?ankh1989
12.07.2018 15:07Ого, это браузер один из немногих случаев? Да и как вам тест поможет если вы их не пишете?
m0Ray
12.07.2018 15:17А у меня всё работает.
Для того, чтобы написать тест к моему коду, который отловит что-то кроме перепутанного знака, потребуется написать код, по сложности и объёму превосходящий то, что я написал. Я не вижу в этом смысла, когда то, что есть, работает.
И да, как предлагаете писать тесты для микроконтроллеров? Создавать программируемое искусственное окружение, имитирующее звуки, удары, освещение?
У меня нет на это времени. Мне проще пару раз постучать по автомату гаечным ключом, передёрнуть затвор и выстрелить. При финальном тестировании — выстрелить десять раз, а то и дать ребятишкам поразвлекаться, записывая логи.ankh1989
12.07.2018 15:31Работает оно по двум причинам: либо ваш код прост как доска, либо его никто толком не проверял (мало юзеров и т.д.). Помню, что в такой уверенности я пребывал когда будучи студентом подрабатывал программёром: когда мой говнокод столкнулся с кучей реальных юзеров и они начали репортить какие то хитрые баги, я просветлился и понял зачем нужны юнит тесты.
Возможно я вас удивлю, но количество кода в тестах часто превышает в несколько раз количество основного кода. Часто одна строчка изменений в основной либе сопровождается 5 тысячами строчек новых тестов. Нафига это нужно? Чтобы надежность была не 74%, а 99.99974%. Если вы фигачите формочки для десятка юзеров, то это конечно не нужно, но как только юзеров становится этак миллиард, ваш подход уже не прокатит.
Для микроконтроллёров и тем более процессоров тесты вообще параноидальные: там тестируется даже очевидное по 100 раз. Потому что исправить софт можно обновлением по сети, а вот исправить баг в процессорах (как это было недавно у Интела) так не получится. Собственно поэтому вы работаете не в Интеле, а стучите гаечным ключом.m0Ray
12.07.2018 15:36Именно! Я специально делаю код простым как доска, плоским как блин, и понятным как хрен! Если это не получается — я разделяю его на несколько простых, плоских и понятных частей, каждая из которых по отдельности сломаться не может — просто нечему. Потому всё и работает.
Если бы я работал в Интеле, процессоры не были бы такими, как сейчас. Они были бы больше похожи на модные некогда «транспьютеры»: куча небольших простых блоков.
Whuthering
12.07.2018 17:23Для МК тесты пишутся почти так же, как и для «больших» систем. Вы стреляете, стучите и светите не в сам микроконтроллер, а в соответствующий сенсор. В МК оно приходит в виде дискретного сигнала, частоты, битов АЦП, массива данных из I2P/SPI, и т.д.
И вот уже то, как контроллер работает и ведет себя этими данными, и тестируются. А сами тестовые данные или «пишутся» заранее, или генерируются синтетически (по-хорошему и то и то, в зависимости от данных, конечно).m0Ray
12.07.2018 17:28Как это поможет проимитировать криво наклеенную звукозащиту или хреновую, «дребезжащую» пайку?
Whuthering
12.07.2018 17:34А с чего это у вас тесты программного кода должны диагностировать аппаратные неисправности внешней обвязки?
Их задача в данном случае — сказать, что ошибка появилась не в коде обработки сигнала после очередного мержа, а нужно брать в руки мильтиметр и осциллограф и проверять источник этого самого сигнала.m0Ray
12.07.2018 17:35А вдруг уровень превысит или импульсы появятся где не положено?
Whuthering
12.07.2018 17:50Так в случае с «простым» тестированием для чистоты эксперимента еще нужно стараться, чтобы уровень был точно такой же, как и в прошлый раз, и импульсы снова появились в точности «не там». А когда у вас имитируется не реальный сигнал, а его цифровой двойник — у вас неограниченный простор для комбинации самых разных вариантов, которые вы даже не сможете или не подумаете специально воспроизвести «в живую» в лаборатории, но которые могут случиться в реальной жизни.
m0Ray
12.07.2018 17:51Про стоимость и сложность тестовой установки я уже говорил.
А не проще ли хорошо писать код, прямо клеить звукоизол и правильно паять, м?Whuthering
12.07.2018 17:54Проще. Но гарантировать постоянную стопроцентную правильность кода, пайки и монтажа, когда это делает даже квалифицированный и сосредоточенный человек, невозможно, увы. Как вы сами сказали, от ошибок не застрахован никто, важно вовремя их найти и свести к минимуму.
Whuthering
12.07.2018 18:00Хотя нет, не проще. Если было бы проще, то все бы так делали.
m0Ray
12.07.2018 18:06Конечно. Знать своё дело и уметь делать его хорошо, быть честным и всё такое — всё это редкость.
Потому проще наплодить костылей, правил, законов, регламентов, приставить к каждому по полицаю…
Но можно просто не работать с дураками и жуликами. Это сложнее, но это наш путь.Whuthering
12.07.2018 21:26Есть очень хорошая старая песня «Битва с дураками» от Машины Времени, которая полностью актуальна до сих пор. Послушайте, возможно натолкнет на размышления.
m0Ray
12.07.2018 18:03Устал объяснять. Скажу прямо. Дайте денег на разработчиков и тестовые установки. У нас их нет.
Я из ничего сделал что-то готовое к работе. Если бы я полагался на автотесты, разработка заняла бы гораздо больше времени.
А я умею и так, без костылей.
F0iL
12.07.2018 17:37Подозреваю, что «проимитировать» проблемы с внешними источниками помогут заранее «записанные» или сгенеренные паттерны проблем с внешними источниками.
m0Ray
12.07.2018 17:42Всё это по сложности намного превысит саму разработку. Это какое баблище придётся в это вбухать?
Когда-нибудь да. Но сегодня у меня, к примеру, одна из задач — вымутить какой-нибудь еды на 43 рубля.F0iL
12.07.2018 17:46+1Не вижу разницы, честно говоря, разницу в затратах между «выстрелить»/«отклеить»/«подергать» во время ручного теста, или для того чтобы записать сигнал с АЦП/сделать дамп обмена по шине, использовать это потом для тестов.
m0Ray
12.07.2018 17:50Так чем я эти сигналы буду на контроллер подавать? Тут тестовое оборудование надо, и что-то мне подсказывает, что оно ни фига не дешёвое. Или колхозить тестовый стенд самостоятельно. Извините, ни времени, ни денег на это у меня сейчас нет.
F0iL
12.07.2018 17:52+1Вы же сами говорили, что программы надо разделять на простые блоки. Блок, тупо получающий данные с АЦП или с порта (по сути дела копирующий массив из одного адреса памяти в другой) — это одна часть, блок, обрабатывающий эти данные — вторая. Если мы тестируем обработку сигнала и какие-то алгоритмы, работу которых этот сигнал должен вызвать, то вместо первого блока мы подсовываем фейковый блок с таким же интерфейсом, который и выдает нужные нам данные.
m0Ray
12.07.2018 18:00Повторяю главные аргумент против этого. Создание тестового окружения для программы или железки во многократно сложнее и дороже создания самой программы или железки.
Если бы у меня были миллионы долларов, я бы нанял контору, которая мне всё это разработала бы. Мне по фигу было бы, используют ли он TDD, agile и паттерны. Мне важен результат.
Но мне приходится всё делать самому и ограниченными средствами. И я, чёрт побери, умею делать конфетку почти из ничего. Если бы я начал с «100% покрытия автотестами», система не была бы сейчас и наполовину готова. А у нас уже в феврале были предсерийные образцы. Учитывая, что ранние наработки были у нас похищены (физически), думаю, не надо объяснять, почему я не пишу тесты и не делаю тестовые стенды.
Потому что я могу работать без них. Мне не нужны костыли, особенно сейчас, когда надо бежать, а не ковылять.F0iL
12.07.2018 18:09Не знаю, что у вас за специфические задачи, но когда я решал похожую проблему (контроллер, обрабатывающий информацию с десятка вторичных преобразователей и других контроллеров по разным протоколам плюс ADC и DI модули ввода), то написание кода, позволяющего захватить обмен за какое-то время и использовать его потом, плюс модификация полученных дампов для некоторых случаев, которые на стенде «наиграть» не так-то просто (учитывая, что одна из железок стоила несколько лямов и физически стояла за пару сотен километров), заняло гораздо меньше времени, чем разработка того функционала, что надо было протестировать — по сути дела, оно собралось из того, что уже было сделано плюс некая обвязка. И больше не было нужды щелкать релешками на стенде, крутить подстроечники и гонять наладчика с ноутбуком в поле за тридевять земель.
m0Ray
12.07.2018 18:17Аналоговые сигналы чем захватывать и воспроизводить? Звуковуху не предлагать, не катит.
В контроллере килобайт памяти. Отладки нет. Да, я знаю, что бывает JTAG, но нет.
Для отладки кода на openCV я накидал утилитку, работающую с вебкой. Потом перенёс код и подобранные коэффициенты на рабочую версию. Всё работает.
И так далее.F0iL
12.07.2018 20:48Зачем звуковуху-то? У вас уже есть сенсор, который этот самый сигнал преобразует в код АЦП. Захватывать ровно тем же, чем и при обычной работе. Как-то же этот сигнал после цепочки преобразований в контроллер попадает в процессе эксплуатации — следовательно, не будет трудностей.
Воспроизводится все «виртуально» записью значения из массива по смещению на вход функции или в заранее определенное место в памяти.m0Ray
13.07.2018 04:38Сенсор даёт сигнал с размахом 3В. Сигнал поступает сразу на ногу контроллера, на которую смультиплексирован АЦП.
То есть вы предлагаете запилить отдельный контроллер, который запишет сигнал в память (ОЗУ контроллера 64 байта), каким-то хреном передаст его в более умное место (UART на борту нет, ПЗУ 1 килобайт) для хранения… И ещё один контроллер, который в нужное время его воспроизведёт криво-косо при помощи ШИМ… И всё это только на один сигнал?
Граждане, таким извратом мне сейчас заниматься некогда и даже контроллеров лишних у меня сейчас нет, покупать надо.
Будет до фига времени и денег — запилю, устрою линию контроля качества и всё такое. Но не сейчас. Сейчас надо быстро бежать. И тут поможет только умение писать код с минимумом глюков и нормально собирать устройства.F0iL
13.07.2018 14:35Сигнал поступает сразу на ногу контроллера, на которую смультиплексирован АЦП.
Зачем? Объясните, почему вы все время для чисто программных вещей хотите добавить еще горсть контроллеров и внешней обвязки? Вы тестируете программный код, который работает с цифровым сигналом. Следовательно, все это отлично делается в софте, а не в железе.
Берем и вотт с этого самого АЦП с этой самой ноги и пишем паттерны для всего того что нужно.
Да, если у вас 64 байта ОЗУ — это печаль.
На атмегах, STM8, STM32 и разных там ПЛК проблемы такой нет (это из того, что я работал). Опять же, можно не писать в свою память, а сразу стримить по USART на подключенный ПК — там чтобы это записать хватит программки из десяти строчек. Куски прошивки, которые отвечают за логику, а не за работу с железом, если код действительно разбит на модули и написан не через задницу, без усилий обособленно билдятся для нативного запуска на ПК, где все тесты гоняются даже не задействуя контроллер. Сделать все описанное можно меньше чем за день (если, как я уже сказал, изначально все сделано по уму), а времени в будущем сэкономит вагон.
Whuthering
12.07.2018 21:26Прототипы — это другая история. Там быстрый старт иногда вообще важнее всего.
А часто бывают противоположные ситуации — когда проект долгосрочный, и его развитие и поддержка тянется и будет тянуться не один десяток лет. Там проблема не «сделать конфетку из ничего», проблема не «сделать тратя минимум ресурсов», и даже не «сделать быстрее». Там проблема «сделать так, чтобы оно стабильно работало, поддерживалось и расширялось еще и еще, и не приносило при этом жопную боль тем, кому с этим придется работать». Вот там ваш write-only код уже ну никак не приемлем.
Ну и с костылями аналогия не очень уместна. Вам предлагают автомобиль, а вы отвечаете «да не, мне и пешком норм». Да, когда надо дойти до соседнего ларька, пешком может оказаться даже быстрее, и учиться водить не надо, а вот если нужно в соседний город, то все уже становится не так просто.m0Ray
13.07.2018 04:43У меня код не write-only, он хорошо читаем и поддерживаем.
Нет, вы предлагаете не автомобиль. Вы предлагаете мотоколяску для инвалидов. Извините, но у меня пока ноги ещё работают. До соседнего города я доеду на велосипеде, возможно, с электроприводом.
А автомобиль я себе позволить не могу. Просто ну вот никак. Если для поездки в соседний город я буду сидеть и копить на автомобиль — я туда не доеду никогда.
Nexus7
12.07.2018 09:24Основное назначение тестов — возможность рефакторинга и расширения кода. Плюс они документируют API и дают примеры его использования. Как говорил классик: «код, не покрытый тестами не существует». Тесты — это инвестиции в будущее проекта и возможность спать спокойно по ночам.
m0Ray
12.07.2018 09:29-3Мне не нужны тесты, чтобы рефакторить код. Примеры использования API я могу дать в readme.txt. И сплю я спокойно — мой код работает.
Дело в том, что код сначала рождается и тестируется у меня в сознании, лишь потом переносится на язык программирования и в файлы.
И я не понимаю, как программист может работать иным образом.F0iL
12.07.2018 09:36+1Вы можете у себя в голове удержать хотя бы миллион строк кода со всеми их нюансами и точностью до мелочей, и каждый раз при внесении изменений тестировать их все в своем сознании?
m0Ray
12.07.2018 09:43-1Зачем держать в голове миллион строк кода, если держать надо модель, как оно работает? Мелочи легко проверить прямым наблюдением кода, да и компилятор/парсер мелочи вроде синтаксиса проверит.
F0iL
12.07.2018 09:52+1Проект Chromium. В связи со спецификой и сложности задач и требований к производительности, есть свой сборщик мусора и свои библиотеки коллекций, а также многое другое. 8 миллионов строк кода. Около 50 компаний участвует в разработке плюс около тысячи индивидуальных контрибьюторов.
Вы предлагает разработчикам при внесении изменений, например, в подсистему управления памяти, каждый раз «в голове» или «прямыми наблюдениями» кода вручную проверять, как изменения отразились на _всех_ десятках тысяч классов, в том числе с крайне разнообразными и далеко не самыми очевидными сценариями использования этого функционала?m0Ray
12.07.2018 09:59-2Если у людей в голове нет модели того, как работает их код — это очень плохо. Они не понимают, что делают.
И это всё, что я могу сказать на эту тему.
Изменения в системе управления памятью не должны затрагивать API. Если затрагивают — это надо документировать, а другие разработчики, соответственно, вносить изменения в свой участок кода. Я не понимаю, в чём тут проблема.Whuthering
12.07.2018 10:02+4А мне вот теперь всё понятно. Вы слабо представляете, о чем вообще говорите.
m0Ray
12.07.2018 10:05Тем не менее мой код работает. Не скажу, что он полностью избавлен от багов, но покажите мне баг в моём коде «в диком виде» — и я его исправлю. Потому что я знаю, где его искать.
Whuthering
12.07.2018 10:07+3но покажите мне баг в моём коде «в диком виде» — и я его исправлю
Так любой дурак сможет.
Когда разработчика заботит качество его софта и экспириенс пользователя, баги должны исправляться без показывания на них со стороны людьми.m0Ray
12.07.2018 10:09-2Для этого код можно предварительно дать поюзать доверенным людям — тестировщикам, альфа/бета-тестерам и т.п.
Whuthering
12.07.2018 10:50А зачем я должен при каждом изменении тратить ресурсы тестировщиков на выполнение одних и тех же проверок, если я могу вместо этого использовать автоматический скрипт?
m0Ray
12.07.2018 11:06А что вы можете автоматизировать скриптом? CRUD-операции?
Whuthering
12.07.2018 11:14Да очень много чего. От низкоуровневых (атомарные методы и обособленные классы) до высокоуровневых (интеграционных, в каком-то случае это может быть CRUD, как вы хотите) проверок, вплоть до пользовательского интерфейса.
m0Ray
12.07.2018 11:25Знаете, я делал «роботов», имитирующих пользователя (SlimerJS там и прочее). Но это были отдельные продукты.
Писать автоматику, по сложности превосходящую тестируемый код — контрпродуктивно. Простенькие операции я и сам мышкой натыкаю, не заржавею.Whuthering
12.07.2018 11:33В большинстве случаев в этой автоматике как раз-таки никакой магии и сложности нет.
Тут вопрос в другом. Для проектов из разряда «кустарщина», либо распильно-откатных вещей, либо команд, состоящих из студентов и индусов смысла в этом может и не быть.
Если же цена рабочего времени разработчиков/тестировщиков, которое тратится при каждом обновлении или релизе выше, чем цена однократной автоматизации — это уже выгодно. Если цена ошибки на продакшене, которую пропустят программисты/тестировщики, схалявив на предыдущем пункте, выше, чем цена однократной автоматизации — это снова выгодно. Про сумму этих цен мы даже говорить не будем.m0Ray
12.07.2018 11:43То есть TDD — это средство получить мало-мальски работающий продукт при некомпетентных разработчиках. Океюшки, так и запишем.
Whuthering
12.07.2018 11:47Да никто и не говорит, что ошибок не бывает.
Иными словами, вы расписываетесь в том, что вы некомпетентный разработчик? Забавно.m0Ray
12.07.2018 11:50Неверно. Я знаю о том, что могу допускать ошибки и действую так, чтобы минимизировать их вероятность.
Плюс оптимизирую код.
Некомпетентный этого не делает. «Тест прокатил — ну и ладно».Whuthering
12.07.2018 11:59ействую так, чтобы минимизировать их вероятность.
Одно другому не мешает.
Плюс оптимизирую код.
аналогично
Некомпетентный этого не делает.
Эти подоходы не исключают, а дополняют друг друга.
«Тест прокатил — ну и ладно».
Тут примерно как с демократией — плохая система, но все остальные еще хуже. Так и здесь. Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно — то лучше «Тест прокатил — ну и ладно» еще ничего не придумали.m0Ray
12.07.2018 12:08«Давайте делать плохо, потому что лучше мы не можем и не сможем никогда, всё тлен».
Неа. Я не согласен.Whuthering
12.07.2018 12:55Тогда предложите рабочее и экономически эффективное решение описанной ситации:
Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно
m0Ray
12.07.2018 12:57«Решить другую проблему так, чтобы предыдущие потеряли смысл».
Если система слишком сложна — она неправильная.Whuthering
12.07.2018 13:01Это экономически неэффективный вариант. Переписывание системы требует в несколько раз больших ресурсов (учитывая уже вложенные в нее человеко-года), чем автоматизация тестирования.
m0Ray
12.07.2018 13:03«Давайте оставим плохую систему, потому что хорошую мы себе позволить не можем».
Да ну вас. Всё на бабло перемеряете.
Я занимаюсь искусством.
IRainman
12.07.2018 10:13+2Модель это общие принципы того как система реализована, мозг действительно хорошо приспособлен для хранения и анализа моделей поскольку сохраняет их «нативно», в виде голограмм.
В это же время реализация это реализация и сохранить все детали реализации мозг принципиально не в силах. Модель редко учитывает что либо кроме API и это архитектурная модель проекта, куска проекта или какого то механизма. API могут не меняться, но абсолютно всегда и везде существует вероятность ошибки и эта вероятность растёт именно внутри реализации ибо там гораздо больше кода. Кроме того лучше закладывать на то, что реализация всегда содержит ошибки, а после изменения у кого то использующего код через API могут сломаться костыли к используемым API и это тоже надо увидеть сразу, чтобы это не вызвало проблем у пользователей.
Вообще суть тестов в автоматизации. Статический анализ нужен для тех же целей — это автоматизация процесса разработки и поиска ошибок или криво написанного.m0Ray
12.07.2018 10:19-2Да никто и не говорит, что ошибок не бывает. Но есть средства понизить вероятность ошибки до минимума и улучшить средства для её обнаружения, если вдруг что-то стало работать не так.
«Костыли для API» — ужас, кошмар, недопустимо!
Автоматизация — это хорошо. Но простых ошибок избежать легко, а сложные автоматика не найдёт. Или эта автоматика должна быть сложнее продукта. Смысл теряется тогда. Хороший программист быстро найдёт причину и без такой автоматики.Whuthering
12.07.2018 10:27Но простых ошибок избежать легко, а сложные автоматика не найдёт.
Что вы понимаете под простыми и сложными ошибками?m0Ray
12.07.2018 10:51+ и -, = и == — это простые.
Сложные — это с многопоточностью, deadlock-и, race condition, проблемы с очередями и т.д.Neikist
12.07.2018 10:57А к чему вы относите ошибки в бизнес логике?
m0Ray
12.07.2018 11:07Логические ошибки тоже бывают, как правило, они весьма просты.
Neikist
12.07.2018 11:12+1Как правило такие ошибки максимально сложны, поскольку их часто не то что программисты не видят с ходу, но и бизнес аналитики, знающие предметную область очень хорошо. Например какая нибудь «проблема копеек» при расчете себестоимости по партиям товаров по средней, в результате которой оказывается что в определенных, нечастых, случаях на остатках может быть 0 товаров, а себестоимость списана не полностью. Хотя это на самом деле как раз простая и многим известная проблема, а бывают такие дебри…
m0Ray
12.07.2018 11:19Бригадные наряды, к примеру, я кодил. Это когда бригада собирается произвольно, выполняет наряд, а потом надо никого не обидеть копейкой. При этом приходилось использовать ужас под названием BTrieve и проприетарный язык программирования. Не напугали.
Проблему можно разложить на простые блоки, применить проверенные подходы и так далее. Тут весь вопрос в том, чтобы уложить задачу в уме, покрутить, помоделировать, «переспать» с ней — и решение вскоре находится. А потом его можно и изложить на нужном ЯП.
Whuthering
12.07.2018 11:14Феноменальная наивность.
m0Ray
12.07.2018 11:19Нет, многолетний опыт.
Whuthering
12.07.2018 11:20+1А, то есть вы почти не сталкивались со сложными логическими ошибками, но при этом постоянно упоминаете свой многолетний опыт. Ясно, понятно.
m0Ray
12.07.2018 11:21Сталкивался. Как правило, ошибки были тупые. Если разделить многоэтажный if на несколько более простых, ошибка становилась очевидна.
Это вопрос ещё и культуры кода.
0xd34df00d
12.07.2018 19:24
IRainman
12.07.2018 10:49+1«Костыли для API» — ужас, кошмар, недопустимо!
В реальном мире это есть и чем больше проект тем вот такого больше и это, обычно, таки можно исправить, но за время приближающееся к бесконечности. Ещё существует Legacy и обратная совместимость и там без костылей иногда вообще никак. К сожалению, под определение «хороший программист» в этом контексте попадает только ИИ, мозг по принципу своего устройства не может не совершать ошибок вообще никогда, а ещё не может иметь безгранично расширяемые вычислительные ресурсы и память, такое может только ИИ.m0Ray
12.07.2018 10:56В реальном мире есть разработчики API. Если они тупы и неповоротливы и не могут за реальное время исправить баг или хотя бы предложить работающий API — меняем разработчиков. Nothing personal, как говорится. Код должен быть «чотким», как «пацан», извините за подзаборную аналогию. Нет «чоткости» — «дитынах».
ИИ — тупик. Он не может и никогда не сможет создавать новое. Иллюзия «китайской комнаты», ЕВПОЧЯ.
Вот как анализатор типа PVS Studio — ещё можно.
F0iL
12.07.2018 10:17+1Внешний API здесь непричем. Я вношу изменения в реализацию того, что стоит за этим API.
Я могу иметь в голове четкую модель того, как работает мой код, но при этом не иметь подобной модели в отношении миллионов других строк кода, которые прямо или косвенно используют ту часть, в которую я вношу изменения.
Одного только первого пункта явно недостаточно для тщательной проверки получившегося результата, как минимум потому, что не получится сгенерировать в голове абсолютно все граничные случаи для всех кейсов использования в оставшихся миллионов строк кода. В случае с тестами же, их сгенерируют как раз авторы этих самых сторонних модулей, потому что они, в свою очередь, имеют в голове четкую модель своего кода, и знают, как он должен и не должен работать. Поэтому любая косвенная регрессия будет выявлена вообще без каких-либо временных и трудовых затрат.m0Ray
12.07.2018 10:20Если API работает так, как документирован — какое мне дело до внутренней реализации?
Если нет — я вам напишу issue.
В чём проблема, не понимаю.F0iL
12.07.2018 10:26В том-то и разница. Я что-то сломал, API перестало работать в каких-то случаях как надо, вы должны это заметить, собрать данные и завести на меня Issue.
Это 1) ваши трудозатраты по моей вине 2) время между появлением бага и его обнаружением.
И это в том случае, если вы вообще заметите, что после какого-то обновления API в каких-то очень специфичных перестало работать правильно. А можете вообще и не заметить, если случай очень редкий и очень специфичный, и потом эта ошибка сыграет гораздо хуже и больнее.
Тесты все эти проблемы полностью решают.m0Ray
12.07.2018 11:00Работы мы не боимся. Видим, что в данном модуле код не менялся, а баг там — садимся, разбираемся, делаем выводы, пишем issue, а в продакшене мы новую версию ещё не накатили. Нормальная рабочая ситуация.
А если я не заметил поломки — тут два варианта. Либо я не использую этот API, либо и мой код сломан (не проверяет данные и т.п.)F0iL
12.07.2018 11:09А если я не заметил поломки — тут два варианта.
То есть вы при каждом (не исключено что очень частом) обновлении какого-то стороннего (по отношению к лично вашему коду) компонента сами вручную полностью проверяете, не сломались ли чего из-за этого у вас?
Работы мы не боимся.
Видимо, у вас мало работы и много свободного времени.m0Ray
12.07.2018 11:14Если у меня что-то сломалось — это заметно сразу. Если не сразу — этот функционал используется редко и не критичен.
Свободного времени у меня мало, работаю чуть ли не круглосуточно.
Правда, сейчас большую часть работы составляет разработка и пайка электроники, но прошивки микроконтроллеров и одноплатников, GUI и облачные сервисы — это я всё делаю сам. На разных языках причём, от ассемблера до PHP и python. И прикиньте, всё работает.ankh1989
12.07.2018 13:29«этот функционал используется редко и не критичен» — угу, не критичен. А у компании соглашение о service availability 99.995% с штрафом $1M в день за нарушение этого пункта. И вот вы пофиксили какой то мелкий баг, зафигачили в продакшн, конечно потестировав важные сценарии, а тут вдруг выясняется через 6 часов, что uptime упал до 99.2% и совершенно не понятно из за чего — тестов то нет, а разных сценариев миллиона полтора и все их не проверить. И что вы будете делать в таком случае?
Avvero
12.07.2018 13:31Мне кажется, что у m0Ray другие бизнес задачи, когда код можно так протестировать
Как правило, данные готовятся один раз. Накидал пару-тройку запросов, сунул их в браузер или командную строку — и погнал. Оттестил — закрыл окно. На крайняк есть история, что в командной строке, что в браузере.
m0Ray
12.07.2018 13:38Вы знаете, я программист, а не «тыжпрограммист», у которого в обязанностях прописана личная ответственность за uptime сервака. Я решаю задачи. Uptime — это к эксплуатационщикам.
ankh1989
12.07.2018 13:40А кто написал говнокод который уронил uptime?
m0Ray
12.07.2018 13:53А вы говнокод перед выкатываением в продакшн не обкатываете на локалхосте/деве/бете?
ankh1989
12.07.2018 14:09Цитирую вас же: «Если у меня что-то сломалось — это заметно сразу. Если не сразу — этот функционал используется редко и не критичен.» — протестировали в бете, ничего подозрительного не нашли — вроде работает как раньше (никаких тестов нет, так? поэтому только вручную). Раз работает как раньше, то фигачим в продакшн. А там uptime упал на 0.01%. И что теперь?
m0Ray
12.07.2018 14:17Падение uptime на сотую долю процента видно только в вашем мониторинге, его можно не торопясь найти и отдебажить.
ankh1989
12.07.2018 14:26Эмм… как например? У вас 100 тысяч серверов и в среднем на 10 из них обычно возникают подозрительные лаги. Вы даже видите это в логах но не можете предсказать какой из них начнёт глючить и потому не можете заранее прицепить отладчик, а если глюк произошёл (скажем дропнулось соединение), то цеплять отладчик смысла уже нет. Обновление нужной dll-ки на этих серверах занимает месяц, поэтому добавлять логи в реальном режиме не получится — да и вообще это продакшн. Допустим, что если бы были тесты, мы бы узнали, что всё дело в хитром integer overflow в одной редкой функции которая конвертирует время из UTC в какой то другой формат — но мы это не знаем. Что делаем?
m0Ray
12.07.2018 18:26Цепляем отладчик и пишем его логи, пока не сглючит.
Только вот я отладчиком тоже не пользуюсь. У меня просто практически везде заложен вывод дебага в консоль. Просто перезапускаем программу с нужным ключиком, потом анализируем вывод. Если надо что-то детализировать — добавляем пару строчек в нужных местах.
Представьте, это работает.ankh1989
12.07.2018 20:38Так работает оно потому что это уровень песочницы. Как вы будете перезапускать 100к серверов с «ключиком»? Они все будут писать логи? А если логов, как это обычно бывает, недостаточно, чтобы понять в чём проблема — будете добавлять логи с итерацией в 1 месяц (обновление серверов в проде)?
m0Ray
13.07.2018 04:45Повторяю: у вас что, локалхоста/дева/альфы/беты нет? На них, вызвав искусственную нагрузку, можно отловить всё что хочешь, с итерацией в 10 секунд.
Neikist
12.07.2018 09:51+2Бросьте, с такими людьми спорить бесполезно, проверено. Они свято уверены в собственной непогрешимости, а также непогрешимости всех остальных кто пишет код того же проекта, и тех чьими библиотеками и фреймворками пользуются. А также видимо имеют много времени.
F0iL
12.07.2018 09:52+1Больше похоже просто на троллинг, увы.
m0Ray
12.07.2018 09:56Увы, но нет.
В моём коде всегда куча закомментированных средств диагностики, но ни одного автотеста. Я реально не вижу в них смысла.Whuthering
12.07.2018 10:00закомментированных средств диагностики
а как же compile-time defines? dependency injection? mixins?
Хотя да, извините, о чем это я.
m0Ray
12.07.2018 09:54О, нет, ошибается всякий. Вот и вы ошиблись в оценке моего modus operandi.
Только код можно писать так, что он либо работает, либо нет. И место, где «не работает», легко находится. Ошибся сам — исправил. Ошибся другой — подозвал, ткнул пальцем (написал issue).Neikist
12.07.2018 09:59+3Только код можно писать так, что он либо работает, либо нет. И место, где «не работает», легко находится.
В общем как я и сказал — спорить бесполезно.
Nexus7
12.07.2018 16:58+1Когда-то я легко писал на ассемблере с листа, держа в уме все регистры процессора и распределение памяти, помня команды управления контроллерами. Но потом деревья выросли, были прочитаны книжки Кента Бека, появились проекты и команды больше двух человек.
Если вы один, тесты вам могут быть и не нужны, но когда проект состоит из десятков модулей, сервисов и серверов с набором разнообразных протоколов, когда приходится взаимодействовать с внешними сервисами и иметь пользовательский интерфейс, когда это всё делается десятками людей — то без многослойного покрытия тестами не обойтись.
Мне наоборот странно видеть, что программист работает без тестов, для их написания создано множество разных фреймворков на разных уровнях тестирования, сильно облегчающих жизнь. «мне не нужны тесты» — лишь отмазка, показывающая отношение к своей работе и коллегам.
PS. Почитал ответы ниже, дальше можно не продолжать, удачи вам в поддержке ментальных моделей.
PPS. Строительная каска в офисе для того, кто сломал тесты — очень хороший мотивирующий фактор для запуска модульных тестов перед коммитом ;)m0Ray
12.07.2018 17:33Но у меня так и есть — десятки модулей, сервисов, разные протоколы, и прочее… Я очень люблю свою работу, но считаю, что ей не сожет заниматься только лишь каждый. (С) Костыли в виде тестов и всяких там методик разработки — это для тех, кто работает через силу, не понимает половины того, что делает и т.п.
Когда живёшь, дышишь этим, плаваешь как рыба в воде и наслаждаешься — ты с большим удивлением смотришь на людей, которые могут передвигаться только на мотоколяске. Да, коляска быстрая, удобная, в ней куча интересных рычажков… Но зачем?
Да, иногда надо. Но не всем и не всегда.Avvero
12.07.2018 17:41+2Костыли в виде тестов
Вы же сами тут неоднократно писали, что тестируете, но рукамиm0Ray
12.07.2018 17:44Окей, в виде «100% покрытия автотестами».
Просто писать нормальный код с минимальным количеством ошибок, и тестировать только самые потенциально проблемные места — не судьбец. Надо нахерачить в два раза больше кода, чем есть в проекте, только для того, чтоб защититься от криворуких программистов.Avvero
12.07.2018 17:58Не понятно только почему это нужно делать руками, когда написать автотест — дело несложное и проверка им быстрее ручной
Заголовок спойлераНу вот пример теста
@Unroll def "For command #command task type will be #type"() { expect: TaskFactory.createInstance(null, command).type.toString() == type where: command | type "info" | "INFO" "Info" | "INFO" "list" | "LIST" "List" | "LIST" "last" | "LAST" "again" | "AGAIN" "clear" | "CLEAR" "cancel" | "CUSTOM" "Cancel" | "CUSTOM" "Cancel <context offer=\"12312312\"/>" | "CANCEL" "deploy" | "CUSTOM" "foo" | "CUSTOM" }
Простой и очень наглядный, написать его просто, добавлять новые кейсы еще проще.
А вот зарефакторишь метод или перепишешь и все это руками перепроверять? Ну такоеm0Ray
12.07.2018 18:08Это вообще на каком языке?
И как этим пользоваться?
Мне теперь новый язык/фреймворк для этого учить? Некогда. Руками быстрее.Avvero
12.07.2018 18:16Ну мы же тут в целом рассуждаем или только применительно к стеку ваших технологий? Этот тест написан на spock framework. Привел я его как пример тестов, которые просто писать и просто понимать.
m0Ray
12.07.2018 18:19Вот честно, я мало что понял. Синтаксис похож на питоновский, но это явно не программа. Что куда девается — хз. Надо читать про фреймворк и забивать голову ещё этим.
Зачем чинить то, что не сломано — ну не понимаю.Avvero
12.07.2018 18:35+1При чем тут сломано? Вы же тестируете? Да, как выяснилось. Но руками. Я тестирую тестами — это быстрее
m0Ray
12.07.2018 18:39Тесты надо написать. Для этого изучить целый фреймворк. Тесты, я так понимаю, длятся долго, уж никак не меньше компиляции.
Ваша проблема в том, что вы тестируете всё, даже то, где вероятность ошибки при правильном подходе к написанию кода околонулевая.
Я же тестирую руками, но выборочно. И не пишу тесты, и не держу в голове лишних языков и фреймворков. И у меня таки быстрее.
Глядя на всю эту современную модную возню вокруг кода, я удивляюсь: а сам код уже когда можно будет писать?
Не могу я так работать.Avvero
12.07.2018 18:49А перед тестирование руками вы приложение поднимаете же? Ну а я тест запускаю. Это в любом случае дольше компиляции.
Я привел выше пример теста который проверяет 12 случаев и отрабатывает за меньше секунды. Вы за такое 12 случаев проверите руками? Вряд ли.
при правильном подходе к написанию кода околонулевая
А вы проверяете зачем тогда? У вас подход не достаточно правильный?m0Ray
12.07.2018 18:59А мне не надо проверять 12 случаев. Мне надо проверить один — тот, что я изменил. Программы я стараюсь писать так, чтобы не было такого: «здесь изменил, там упало».
Но главное в том, что при написании программы я «прогоняю» её в уме. Читаю и выполняю, читаю и выполняю, мысленно подсовывая разные данные.
Проверяю — потому что от ошибок я не застрахован. Чаще, конечно, синтаксические бывают, но они ловятся ещё до компиляции.
Многопоточность иногда головную боль доставляет. А в python так вообще с ней беда. Совсем без проверки никуда. И перед выкаткой «в бой» проверяем уже всё. Но это много времени не занимает.Avvero
12.07.2018 19:22+1Вы изменили код метода или у вас отдельные методы под каждый случай?
Программы я стараюсь писать так, чтобы не было такого: «здесь изменил, там упало».Проверяю — потому что от ошибок я не застрахован.
Ну проверяете-то каждый раз? Значит стараний описанных выше недостаточно или они на что направлены?m0Ray
13.07.2018 04:48Без проверки — никак. Другое дело, что проверять каждый раз всё не имеет смысла. Никак не могу донести до вас эту простую мысль. Ковровые бомбардировки — это хорошо, но дорого. Можно обойтись меньшими затратами, если есть высокоточные крылатые ракеты. Да, они сложнее, чем фугас с простым взрывателем, но эффективнее. Не умеете работать с ракетами — ну что ж вам остаётся, бомбите всё.
Avvero
13.07.2018 05:10Как же нет смысла? Как можно быть уверенным, что правка метода что-то не сломает левой?
но дорого
совсем нет, очень дешево, «никак не могу донести до вас эту простую мысль»
0xd34df00d
12.07.2018 19:32+1Не всегда долго и уж точно не всегда дольше. В одном из моих проектов тесты длятся меньше секунды из repl'а, тогда как релизная компиляция проекта — пару минут. А их там под тысячу было.
0xd34df00d
12.07.2018 19:31Не, я всё понимаю, но тест вместо статического тайпчекера — это даже как-то смешно.
И вызывает вопросы, ну да ладно.
ankh1989
12.07.2018 13:01+1Попробуйте решить 10 задач на leetcode из группы hard. Там к каждой задаче есть сотня тестов и вы можете их запустить и проверить ошиблись вы где то или нет. Как решать можете посмотреть в секции discuss. Если вы сможете сделать хоть одно решение сразу без ошибок — я буду впечатлён, если три подряд — придётся признать, что вы гений. Для сравнения, мне требуется обычно десяток попыток пока все тесты не пройдут — мне трудно удержать в голове всю картину и не наделать ошибок. При этом за мой говнокод платят где то $30K в месяц.
m0Ray
12.07.2018 13:05Зачем решать задачи, которые уже решены, да ещё и не по одному разу? Это не интересно.
Платят? Гордитесь до пенсии. Если доживёте.ankh1989
12.07.2018 13:10Чтобы проверить свою способность решать задачи и сравнить себя с другими. P.S. Не понял про пенсию.
m0Ray
12.07.2018 13:12Моя способность решать задачи и так проверяется на работе. Писькомерство мне чуждо, не хочу тратить на это своё время, работать надо.
Про пенсию — вы, наверное, не из Мордора?ankh1989
12.07.2018 14:03Идея в том, чтобы доказать себе, что писать код без ошибок вы не можете. Вот например простая задачка на регулярки: leetcode.com/problems/regular-expression-matching/description Там нужно применить регулярку вида «ab.cd*» — то есть из спец символов только точка и *. Вполне практичная вещь: можно представить себе сервис который хранит логи (терабайты логов) и юзеры могут зайти на его веб интерфейс, набрать вот такую простую регулярку и получить логи которые подходят. Конечно же вы не хотите, чтобы ваш сервис наглухо завис из за неудачной регулярки — поэтому код должен быть быстрым. На вид задачка решается за 10 минут, а вам наверно и вовсе пары минут хватит. Вряд ли у вас нету пары минут, правда?
m0Ray
12.07.2018 14:26Сколько мне за это заплатят?
ankh1989
12.07.2018 14:28Могу вам перечислить 0.1 BTC (это чуть больше $600). Довольно неплохо за 10 минут работы?
m0Ray
12.07.2018 14:32Это не 10 минут. И даже не день. Это вам кажется, может быть, что задача проста. Но с кондачка она не решается, это я вижу сразу.
Некоторым тоже казалось, что сделать ТТС — как два байта переслать, лазер вон из указки выковыряем, а написать на openCV распознавалку так вообще любой студент сможет. Как бы не так.
Извините, но неинтересно. И дело даже не в том, что мало. Сложно — не значит интересно.ankh1989
12.07.2018 14:37600 баксов даже за два дня вроде весьма некисло? И ниже вы писали, что за вечер переделывали сложные системы которые криворукие кодеры писали годами. А тут жалкая регулярка которая сгодится разве что для вопроса на собеседовании с 20 минутами на ответ.
m0Ray
12.07.2018 14:54Ошибаетесь. Регулярка — это меньшая проблема. Гораздо большая — чтоб не вешался сервер. Тут я вижу ещё как минимум две сущности — фильтр-анализатор, который распознает рекурсию и прочие нехорошие вещи, да менеджер процессов, который будет убивать наиболее жрущие и пухнущие процессы регулярок с соответствующим уведомлением пользователя. Это не скриптик для собеседования, а серьёзная такая задачка.
Но у меня свои задачи есть, не менее сложные, и с них я сейчас переключаться не хочу.
Я переделывал не всю систему, а ту часть, которую писали на языке TCL и которая исполнялась на Cisco AS5300. Эти скрипты некоторые уникумы писали год. Я переделал за пару дней, когда они сказали, что «вот этого» они ну совсем не могут сделать. И не только сделал, но и выгреб кучу говнокода. При этом практически не отрываясь от основной работы — тогда бухи требовали каких-то мерзких и скучных отчётов для импорта в 1С.
Николi знову!ankh1989
12.07.2018 14:59Не надо ляля. У нас есть простая регулярка и строка — надо выдать 1 или 0. Это стандартный вопрос на интервью, 20 минут на ответ. Вам я даже готов компенсировать ваши усилия в размере 0.1 BTC, что весьма дофига. Можете прям тут функцию написать. Сигнатура пусть будет bool test(char* pattern, char* text); Ограничения: пусть обе строки не больше 100 ASCII символов.
m0Ray
12.07.2018 15:01Чем не устраивает preg_match()?
ankh1989
12.07.2018 15:04Потому что мы пишем код на C — сервис такой. Плюс регулярка у нас урезанная и мы хотим этим воспользоваться, чтобы получить максимальную производительность. Всякие preg_match они для общего случая.
m0Ray
12.07.2018 15:12В C это regex.h, regcomp()/regexec(). Есть ещё libPCRE. Возьмите исходники (благо они открыты) и уберите лишнее ради производительности. Не множьте сущности, от этого глюки плодятся.
Зачем решать задачи, которые уже решены и даже протестированы?ankh1989
12.07.2018 15:20Я сомневаюсь, что вы можете решить эту простую задачу без тестов. Вы очень упорно сопротивляетесь. Тут два варианта: либо у вас нет на это 30 минут (зато есть время чатиться на хабре), либо вам не нужны 600 баксов за эти 30 минут (и тогда вы наверно нам пишите из личного самолёта). Фигня в том, что практически никто не сможет решить эту задачу сходу без тестирования — обязательно будет несколько багов. По этой причине когда на собеседовании в крупную компанию задают такие вопросы, ожидают, что вы не только напишите код на доске, но и приведёте список тестов, протестируете (в уме) и исправите все баги. Именно для этого и нужны тесты в реальном мире. Утверждать, что «я могу кодить без тестов» всего лишь невежество, а не опыт. Следующий уровень невежества это «мне не нужна телеметрия — мой код и так хорошо и надёжен ведь у меня столько тестов.»
m0Ray
12.07.2018 15:28Я просто чувствую, что вы мне готовите какой-то подвох. Задача непростая, и если я потрачу на неё 30 минут времени, она явно будет решена неправильно. А больше времени тратить мне не хочется.
Общение в комментах тут у меня идет параллельно с другими задачами, вы и так меня изрядно отвлекаете, пытаясь скормить задачку с подвохом.
А личный самолёт… Если наш проект таки взлетит (а для этого явно придётся покинуть Мордор), то… у меня его не будет. Я, как бывший студент аэрокосмического ВУЗа, посещавший аэродром, на километр не подойду к коммерческой авиации. Жить ещё хочу. Получится плохо и недолго, но это лучше, чем шваркнуться об землю или сгореть в воздухе.ankh1989
12.07.2018 15:35Подвоха нет. Это стандартная задача для собеседования на 20-30 минут для студентов которые ищут первую работу: проверяется умение написать простой алгоритм и проверить его тестами. Если работа не первая и кандидат претендует на сеньора, ему нужно не только написать этот код, но и рассказать как он будет работать на практике — вся эта многопоточность и т.д. Но если вы не можете написать даже таую функцию, то про многопоточность можно не рассказывать.
F0iL
12.07.2018 17:39Если наш проект таки взлетит (а для этого явно придётся покинуть Мордор), то… у меня его не будет. Я, как бывший студент аэрокосмического ВУЗа, посещавший аэродром, на километр не подойду к коммерческой авиации.
А можете подробнее рассказать, почему?
Я вот, как бывший студент авиационного вуза, студент военной кафедры с ВУС авиатехника (занятия на аэродроме тоже были, и не раз), и разработчик, несколько лет работавший в фирме, которая пишет софт для авиации (в т.ч. который идет на борт и участвует в воздушном движении) и производивший ПНР в аэропорту, наоборот, после всего изученного и увиденного стал бояться летать гораздо меньше, потому что знаю, как оно работает, и что сделано (как технически, так и административно) для того, чтобы оно работало как надо.m0Ray
12.07.2018 17:47Ага. А самолёты продолжают падать. А те, что не падают — дребезжат во время полётов.
Потому что главное — не состояние техники, не жизни и безопасность людей, а бабло. О людях заботятся только с одной точки зрения — как бы не попасть на штрафы и компенсации. А уж в этой стране вообще лучше не подходить — топливо разольют, потом прикурят.
Нафиг-нафиг.
0xd34df00d
12.07.2018 19:36Это всё не нужно, если вы делаете NFA simulation. Если регулярки делать через DFA, да, там легко получить экспоненту, а вот через NFA сильно сложнее, оно полиномиально по длине входа и регулярки (лень выводить точную асимптотику сейчас, сорян).
Ну и это всё вдвойне не нужно, если вы сами пишете реализацию.
f0rk
12.07.2018 19:27Ага, видел я код и продукты этого гения. Понятия не имею, что он там у себя в сознании моделирует, но программировать не умеет совсем.
JobberNet
12.07.2018 06:15Хвалите
За что? же, не боясь греха, Кукушка хвалит Петуха? За то, что хвалит он Кукушку. © КрыловAlekseyCPP
12.07.2018 09:17+1
Вот кого хвалишь, того и сделают начальником, а ты вечно будешь в дураках. У нас 2/3 программистов работает в офисе заказчика (на постоянке), и у такого заказчика уровень IT- развития равен 0. Они ровно ничего не понимают в этих вопросах и ориентируются на сплетни в курилках и подобные похвальбы от коллег по цеху. А в продуктовых фирмах начальники тоже часто плохо понимают глубины программирования и в таком случае пустить пыль в глаза также проще паренной репы (например, во франчайзи 1с руководителями нанимают не программистов, а людей с улицы).
SenorLeoncio
12.07.2018 09:25+1«Кем бы вы ни были, помните мудрый совет: „Ни одного дня без написанной строчки“. Трудитесь! Что такое талант? Трижды и четырежды труд. Любите труд, и пусть вам всегда будет жаль с ним расставаться. Счастливой дороги!»
Из автобиографической повести Константина Паустовского (где-то в районе 1908-го, что-ли, года) — напутствие диркетора лицея выпускникам.
stalkers
12.07.2018 11:42+17 советов, как сделать жизнь лучше
Бесполезный совет.
Совет, требующий больших затрат времени.
Очевидный совет.
Совет, требующий больших денежных затрат.
Совет, требующий чрезвычайно особенных условий.
Рекомендация выполнять советы регулярно.
Совет, который написали для того, чтобы получилось всего 7 советов.
/* фото девушки в наушниках на пробежке */
Этот пост изменит вашу жизнь!
//////////////
и откуда вы, б…ь, такие лезете…
mbait
12.07.2018 12:45А где эта чёткая, ровная, словно меч самурая остарая грань, которая делит программистов на постредственных и… непосредственных? По-мойму, автор неправильно применил свой же совет «умерить эго».
urticazoku
12.07.2018 12:51Вот тут дружно критикуют m0Ray, а между прочим, TDD не работает. Или работает. Смотря кто как исследует).
Whuthering
12.07.2018 12:57Статья про то, что TDD не особо эффективнее в сравнении с TLD.
Однако, буква T там присутствует в любом случае. Про то, что тесты писать вообще не нужно, там ни слова.
Aguinore
13.07.2018 10:29То есть исследование не показало, что TDD не работает, правда?
Нет, пожалуй, не показало.
Что же оно показало?
Думаю, оно показало, что нельзя интерпретировать выводы исследований без прочтения исследований.
Тонко
miga
12.07.2018 23:46// проверяем формат электронной почты
if (!regex(data['email']) {
return false;
}
Бац — и вы плохой программист
aFanOfSwift
Вроде бы очевидные вещи, жалко только не все их понимают.
artskep
Понимать, скорее всего, понимают. Но не всегда теория совпадает с практикой (где-то ресурсов не хватает, где-то сроки горят, где-то попытки делать "правильно" могут привести к проблемам, а дома жена и дети и они хотят кушать)
Это жизнь. Все ведь знают и понимают зачем правила дорожного движения, и их надо выполнять. Но каждый хоть раз их да нарушил.