Коротко про то, что больше всего беспокоит в современном мире разработки и почему нужно доказывать, учиться, тестировать и не лениться.
Я разработчик, но код давненько не писал
Нихрена ты не разработчик.
Если вы считаете, что написание кода — это опциональное требование для хорошего разработчика, то, пожалуйста, сойдите с этой планеты. Существует много возможностей, чтобы жить дальше, но перестать писать код. Можно перейти в менеджмент, можно в управление персоналом мигрировать, можно апнуться до высокой должности, а можно просто уйти в монастырь. Но при любом из этих раскладов вы перестаёте быть разработчиком, если больше не пишете код.
Почему? Во-первых: код — это не велосипед, если не практикуешься, то забываешь. Во-вторых: разработчикам очень обидно, когда "какой-то менеджер", пытается выдать себя за своего (да, в общем-то, это для любой профессии справедливо). В третьих: это вредно для ЧСВ; если вы перешли в другую область/отрасль, то отращивайте себе скилл с харизмой заново, а не тащите ссылки на былые успехи (см. последний грех).
Из примеров.
- Был как-то на собеседовании в Американской конторе. Там на одном из этапов господин, представившийся как CEO, начал спрашивать лютую дичь о Ruby по бумажке (в смысле по заготовленным шаблонам в гуглодоке). На вопросы о том пишет ли он сам код и зачем такое непотребство спрашивать у соискателей он тактично перевёл разговор и попросил сосредоточиться на задачах.
- Есть знакомый ресурсный менеджер, который психологом работает на досуге. Так вот этот господин до их пор код пописывает в свободное время и иной раз может сильно удивить кандидата любопытными познаниями в, казалось бы, нехарактерной для него области. Вроде не не программист, но все его принимают за своего.
Я же запускал тесты, зачем тестировать руками приложение?
Полагаться только на результаты тестов (даже если среди них интеграционные end-to-end прокликивалки) — это тяжкий грех. Как минимум раз за время разработки любой фичи нужно взять и руками прокликать весь цикл этой самой фичи. Во-первых, вы будете чуть лучше разбираться в платформе и в том, как её видит юзер, а не как она устроена внутри. А во-вторых, вы идёте по новому сценарию и здравому смыслу и можете обнаружить что-нибудь очевидное вам, но незаметное для автотестов. В любом случае, автотесты — это дополнение к ручной проверке самим разработчиком, не замена таковой.
Сразу же скажу про особенности. Я не говорю про полноценное ручное тестирование силами разработчика, для этого есть специально обученные QA-ребята. Я о необходимости запуска локального проекта и о минимальной проверке любых изменений именно там. А уж потом в автотестах, на деве, стейдже, препроде и проде.
Таки да, тут должны быть холивары про сложности многих проектов и их "невозможность" запустить локально. Лично я в такие эпические проекты не верю. А вот в лень и жадкость — верю. Посему давайте коротко пройдёмся во возможным проблемам запуска проекта локально.
- Маленький независиый проект — нет препятствий патриотам!
- Много внешних интеграций. Значит у вас есть песочницы для каждой из них. Либо у вас есть заглушки или локальные эмуляторы внешних сервисов. Либо у вас есть большие проблемы, которые скоро выстрелят.
- Много микросервисов. Суть да дело это предыдущий пункт. С той лишь разницей, что расширяются возможности по локальной эмуляции. Например, набор из докеров с реальными микросервисами вместо заглушек.
- Нужно много данных для работы проекта. Но очень редко нужен весь многотерабайтный массив данных для разработки. А если всё-таки нужен, то для этого делают несколько инстансов для разработчиков. Например, 2-3 огромных инстанса на команду из 10-15 разработчиков. Таки да, не шибко удобно и дорого для бизнеса, но иначе вы заплатите ещё больше за разработку на продакшене, которая будет производиться вне зависимости от хотелок высшего руководства.
- Монструозный монолит, который работает на определённом железе и только в правильной фазе луны. Если так, то, скорее всего, вы в кровавом энтерпрайзе и здравый смысл там не работает.
Я уже знаю достаточно и могу больше не учиться
Если коротко: "кто не развивается, тот деградирует".
В теоретических науках имеют место случаи, когда можно узнать базу и на ней остановиться. Там всё более-менее стабильно, доказано и неизменно. Физические законы, к счастью, каждую пятилетку не меняют. Так что, если не лезть на передний край науки, то можно жить и даже работу работать. Вот, например, интегралы по контуру: Фейнман их решал в Лос-Аламосе после Второй Мировой и сейчас их решают примерно теми же аналитическими методами.
А вот с разработкой и программированием так не прокатит. Единого неизменного божественного языка программирования пока не нашли (концепция из Лавины интересна, но пока не открыта). Скорость изменения технологий от пары десятков лет в случае операционных систем и БД до пары месяцев в случае JavaScript'а. И если не развиваться, то за год-другой можно изрядно потерять уровень, а за пятилетку просто обресетиться в ноль.
Дабы не сильно холиварить о скорости изменения технологий приведу пару примеров. Есть книжка Кернигана и Пайка 1992 года розлива. По ней можно неплохо освоить Unix и не сильно удивиться изменениям, случившимся 15 лет спустя. Можно взять книжку Тома Кайта про Oracle 8, который вышел в районе 2000 года и не сильно удивиться различиям, случившимся в версии 18c. А вот любую книжку по JS пятилетней давности можно смело пустить на растопку.
Я достаточно крут и могу это не доказывать
По-моему, это самое тяжкое и самое распространённое.
К сожалению или к счастью, доказывать свои навыки, проф.пригодность и вменяемость нужно всю жизнь. Когда вы перестаёте это делать, то можете обнаружить, что вы либо на пенсии, либо у вас деменция, либо вы просто сгорели. В любом случае, вам к специалисту.
Частота доказательств разная. В случае друзей и родственников доказывать нужно не так уж часто. А в случае незнакомых людей — на регулярной основе и по полной программе. Места, где потребно доказательство, очень разнообразны: на собеседованиях, на конференциях, новым коллегам, новым возлюбленным… даже в магазине, если покупка немного сложнее табуретки.
Если вы считаете, что рассказ о своём опыте без подтверждения навыков — это нормально и достаточно, то посетите соседнюю планету. Как по мне, это называется пижонством и зазнайством.
По части примеров в этой области туго, ибо большинство из них негативны и, думаю, читатель сам вспомнит что-нибудь подходящее из своего опыта. А с позитивными ещё сложнее, так как они не замечаются и просто выливаются в конструктивный диалог. Посему, уповаю на жизненный опыт читателя и, надеюсь, каждый подберёт достойный пример.
Комментарии (27)
fireSparrow
05.08.2019 09:39+2Во-первых: код — это не велосипед,
Ну, смотря какой код. Бывает такой, что из велосипедов состоит чуть более, чем полностью.exehoo
05.08.2019 10:29Вы уполовинили цитату.
Во-первых: код — это не велосипед, если не практикуешься, то забываешь.
Не надо так.
Автор пишет не про «изобретать велосипед», а про «если научился кататься на велосипеде, то уже не забудешь»
MasteR_GeliOS
05.08.2019 10:01+1Очень все категорично. И работает в достаточно узких рамках «проектов которых я считаю „нормальными“, а остальных как будто не существует». Но здравые зерна в тексте есть
0x1000000
05.08.2019 10:02+6У статьи очень неприятный нравоучительный тон. Обвинения в зазнайстве в таком контексте выглядят, как минимум, странно.
NorthDragon
05.08.2019 10:19+2> Я же запускал тесты, зачем тестировать руками приложение?
Видимо, ты имеешь в виду только свою отрасль, а именно, web-приложения.
В случае разработки проектов другого плана: СУБД, бизнес-процессы, общие библиотеки — тесты+code review должны быть критерием корректности изменений.
Mikluho
05.08.2019 10:43Слишком всё категорично…
Я разработчик, но код давненько не писал
Я как то год код не писал. Всё, на что это повлияло — скорость вхождения в рабочий процесс на новой работе. Но никто не засомневался в том, что я разработчик.
Я же запускал тесты, зачем тестировать руками приложение?
Многие вещи тестировать руками разработчика — слишком дорогое удовольствие. А иногда и вовсе не имеет смысла.
Я уже знаю достаточно и могу больше не учиться
Это тоже не универсальное утверждение. Иногда учить — лишь отвлекать ценного разработчика от его профессиональной компетенции.
Я достаточно крут и могу это не доказывать
Вот иногда очень нужно просто сказать некоторым спорщикам именно это — я достаточно крут, потому сделай как я говорю и потом посмотрим на результат.
lair
05.08.2019 11:13+2К сожалению или к счастью, доказывать свои навыки, проф.пригодность и вменяемость нужно всю жизнь.
С моей точки зрения, люди, которые постоянно доказывают, что они крутые, ничем не лучше тех, кто этого не доказывает. Потому что представления о том, как надо доказывать, у каждого свои, а некоторым потом приходится жить с результатами таких доказательств.
harry2019
05.08.2019 11:17Да, всё так. Спасибо! Наконец кто-то озвучил мои мысли.
Про покрытие тестами я говорил своим не раз. Фекалии, покрытые тестами, остаются фекалиями, покрытыми тестами. Да, всё зелено. Супер грин. А потом 85 багов, на которые никто не удосужился выделить время. Зато всё покрыто тестами.lair
05.08.2019 11:25+1… я так понимаю, ситуация "я запустил и минуту потыкал руками" что-то изменит по вашему мнению?
Free_ze
05.08.2019 11:28+1любую книжку по JS 5-илетней давности можно смело пустить на растопку.
А как насчет десятилетней?)
dss_kalika
05.08.2019 13:22+1Дабы не сильно холиварить о скорости изменения технологий приведу пару примеров. Есть книжка Кернигана и Пайка 1992 года розлива. По ней можно неплохо освоить Unix и не сильно удивиться изменениям, случившимся 15 лет спустя. Можно взять книжку Тома Кайта про Oracle 8, который вышел в районе 2000 года и не сильно удивиться различиям, случившимся в версии 18c. А вот любую книжку по JS 5-илетней давности можно смело пустить на растопку.
т.е. вы пишете, что надо постоянно развиваться и тут же приводите 3 примера, 2 из которых не сильно менялись за последние 10 лет? )
Как то… непоследовательно, что ли )
Loriowar Автор
05.08.2019 14:22На самом деле, из веб-стека я кроме сетей, осей и БД не знаю ничего долгоиграющего. То есть язык, как основа разработки, за пятилетку меняется значительно. А любой фреймворк поверх языка и подавно изменчив за такой срок. Мысль была про это.
Free_ze
05.08.2019 15:27Языки, кстати, даже JS, неплохо дружат с обратной совместимость. Новые фишки крайне редко обнуляют базовые возможности. Особенно, если новое — это щедро пересыпанное сахаром старое.
dss_kalika
05.08.2019 16:11+2А этого мало? )
Вебстек лишь часть айти-индустрии и столь радикально заявлять о постоянных изменениях в статье без явного указания что это касается только веба как то опрометчиво и наивно. Говорит о недостатке ширины кругозора )
Ну это так, небольшое недовольство общей тенденцией хабра к вебразработке.
ЗЫ:delphi изменился сильно за это время? C#? C? и фреймворки к ним?
Ну так, чисто косметически. про Т-SQL я вообще молчу.
Быстро меняющиеся стандарты языка, фреймворки и прочее не подходят для больших, серьёзных и долгих проектов, просто по причине того, что им нужен стабильный и реализующий то что им надо стек, а не зоопарк технологий, который устареет через пол года. =)
ncr
05.08.2019 20:36Нихрена ты не разработчик
сойдите с этой планеты
можно просто уйти в монастырь
если не практикуешься, то забываешь
разработчикам очень обидно
отращивайте себе скилл с харизмой заново
не тащите ссылки на былые успехи
В тексте чувствуется знатная попаболь.
Дайте погадаю. У «настоящего разработчика» случился факап, пришел «какой-то менеджер» (совсем не настоящий же!!11), показал мастер-класс и теперь перед коллегами неудобно?
Разработчик — это, прежде всего, склад ума и понимание CS в целом, а не уверенное жонглирование очередным JS-фреймворком, имя которым легион.
Код — не велосипед, да (хотя у кого как). Знания — велосипед.
Если человек знает фундаментальные принципы разработки, структур данных, оценки сложности алгоритмов и т.п. — это уже не пропьёшь, он освоит любой язык за два дня, даже если писал последний раз в 80-х.
Scf
Вот это неправильно. Доказывается очень просто — что можно прокликать вручную, то можно автоматизировать. Вручную можно прокликать 2-3 тесткейса, автотесты могут прокликивать сотни тесткейсов. Для проблем со сломанной версткой есть скриншоты и попиксельное сравнение с эталонной картинкой.
harry2019
автотестами можно покрыть всё. безусловно. при одном условии. если на это деньги есть на проекте, а если нет, то это исключительно ответственность разработчика за свой код и больше не чья.
lair
Очень плохо работать на проекте, где качество — это "исключительно ответственность разработчика за свой код и больше не чья".
(pet projects не считаем, понятное дело)
Guitariz
работать на чьем то pet project — это не очень)
aknew
Было у нас на одном проекте попиксельное сравнение — не взлетело. Для него надо либо жестко фиксировать версию операционки и размер экрана (а так не интересно, да и не особо-то и полезно), либо же делать эталонные скрины для каждого разрешения и версии (в том числе минорной, а это очень затратно по времени) иначе оно будет падать на какое-нибудь немного по другому обрисовывающееся сглаживание шрифта. Проще уж тогда просто делать кучу скринов всех экранов и состояний и потом их просматривать
Scf
вы использовали живые браузеры, не headless?
aknew
Не браузеры, живые айпады (я мобильный разработчик), но не думаю что применительно к попиксельному сравнению это так уж важно