Немного из мира сигналов. Которые по проводам бегают.

Если кто-то увлекается автомобилями и подписан на ютуб канал "ИЛЬДАР АВТО-ПОДБОР", те знают, что у него есть рубрика "оживление мертвеца". Её суть в двух словах : ребята выезжают на сложные "баги" в автомобилях и стараются найти их причину/пофиксать. Вы все понимаете, что более ли менее современный автомобиль состоит из сотен электронных систем/схем/блоков и так далее. И зачастую, по очень разным причинам это всё ломается и сбоит. Особенно со временем.

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

В данном ролике ребята оживляют BMW x5 e53, и используют осцилограф для дебага! Тут же и разъясняют как это всё работает. Оч крутой контент, имхо.

Советую к просмотру :) Таймкод проставлен, длительность просмотра ~5 минут.

https://youtu.be/06cWmc2Zpnk?t=1359

У Dev Jungles вышло очень крутое трёхчасовое видео в стиле "вопрос-ответ" по .net/C#. Имеет смысл смотреть всем дотнетчикам от middle+, много хардовых вопросов.

Было интересно, допустим, почему нельзя делать lock на string и в целом про интернированные строки, и например то, что

string s = "qwe"+"rty"+"uio";

будет на этапе компиляции развёрнуто в string.concat (есть нюансы, не всегда). Или по какой причине нельзя лочиться на структуры. + типичные области применения TCP vs UDP. В общем, много интересных моментов.

Единственное что, заметил, что перепутан ответ на вопрос про "Аутентификацию/Авторизацию/Идентификацию" - первое и второе нужно местами поменять в ответе. Авторизация - роли, Аутентификация - проверка логина/пароля.

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

#csharp #библиотека_знаний

https://www.youtube.com/watch?v=M32SEu0hY7w

Как бы вы реализовали форму логина и пароля/регистрации на сайте крупного заказчика?

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

Хорош этот вопрос потому что это задание можно сделать как "на коленке", так и "по всем канонам" - зависит от знаний конкретного дева и тз. А так же не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет.

Попробуйте потратить минут 5-10 на обдумывание как бы вы ответили на этот вопрос, а после - пункт-за пунктом открывайте чеклист ниже и проверьте себя. Красным флагом 🚩помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе :)

ps. Составлял сам и не претендую на полноту пунктов, поэтому если что пропустил, пишите в комментах 😉 Идёт по возрастанию сложности/экспертности для реализации. Каждый следующий пункт/уровень должен включать все пункты выше.

Опустим визуальную ui часть, допустим её предоставили. И так ... поехали!

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

Junior level

1) 🚩Нужно ли скрывать вводимый пароль на странице?
Это очевидно, но это и первый пункт! :) У input есть специальный аттрибут password для этого.

2) Должны ли вадидироваться поля для ввода на ui?
Как минимум на то, что поля не пустые - должно. Отправлять пустую формочку на сервер не комильфо, т.к. нагружает сервер почём зря 😉

3) Запрос идёт GET или POST'ом? Правильнее делать POST'ом.
Ничего вам не мешает сделать это любым другим методом, однако принято данные формы слать всегда POST'ом. Как минимум данные не шлются в URL, что может сыграть злую шутку при логировании. Плюс после POST запроса если у вас отвалится интернет соединение - браузер переспросит вас хотите ли вы заново отослать эту форму? - вы наверняка видели такую. Все GET запросы перепосылаются браузерами без подтверждения.

4) Сохраните ли вы в пароль при регистрации "как есть" в текстовом виде?
Если да - это очень плохо и непрофессионально. Пароли должны быть в идеале зашифрованы стойким алгоритмом по ключу, а в идеале хэшированы - без возможности их "восстановить" даже админами. И Base64 тут не подойдёт :) Не говоря уже о том, что если вашу базу сольют - у злоумышленника окажутся все пароли ваших пользователей.

5) Нужно ли проверять вводимые данные не только на UI стороне, но и на сервере? Двойная работа?
Главное правило веб разработчика - не доверяй клиенту (браузеру) - все данные/поля могут быть отосланы или подменены другими средствами, вам нужно обязательно делать полный цикл проверки на сервере.

6) Нужна ли валидация на сложность пароля или можно не париться?
Заставлять пользователя придумать пароль в соответствии с правилами - маст хэв. Но тут важна грань, т.к. знаю реальный пример, когда правила пароля настолько сложные, что пользователи потом хранят эти пароли в текстовых файлах на рабочих столах, т.к. запомнить их нереально. А это еще хуже :) Получается, заботились о безопасности, а по факту родили новый вектор атаки

Middle level

1) Соединение защищено по https?
Если нет, то у меня для вас плохие новости - ваш логин и пароль может быть легко перехвачен между браузером и сервером. Публичными вайфаями, на уровне провайдера или даже на уровне уязвимого роутера, которым вы пользуетесь. Весь сайт в теории может быть по http (лучше бы нет), но форма логина и регистрации - только https. Но даже в таком случае - токен аутентификации сможет быть перехвачен (но не логин и пароль). Весь сайт обязан быть https.

2) 🚩Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Конечно нет, это может говорить хакеру о том, что пароли хранятся в plain text и уже какой-то пользователь точно существует с таким паролем. Вы должны выдавать МИНИМУМ информации всего, что касается безопасности. Есть шуточная версия в виде сообщения "такой пароль уже используется пользователем %username%". Шутки шутками, но возможно где-то и написали.
На aws к слову максимальный уровень - после ввода логина, сразу же запрашивают пароль И второй фактор, т.е. злоумышленни даже может узнать что именно не подошло.

3) Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - логин. Пароль - нельзя. Был уже ни один и не два инцидента, когда у крупных сервисов ломали системы логов и вытаскивали пароли, которые логировались в plain text (лог шёл всего реквеста).

4) Если хэшировать пароль, то как? Каким алгоритмом? Хорошо, если мидл назовёт парочку, допустим md5 или sha-1.
Вопрос чем они плохи - уже скорее сеньорский левел. Но для мидла и такой ответ ок. Так же плюсом в карму будет рассказ о том, что хэшировать нужно с солью. SALT - это что-то, что добавляется к паролю чтобы уменьшить риск его обратного преобразования в случае утечки данных. Многие популярные пароли уже находятся в базах (так называемые Rainbow tables и хеши к ним подобраны, поэтому реверснуть какой-нибудь md5 без соли - дело несложное.

Senior level

1) Каким еще способом нужно обезопасить форму? CSRF имеет смысл добавлять?
Это вопрос на самом деле в целом на понимание CSRF вида уязвимости, сеньор должен знать и понимать как это работает. Безусловно, запрос должен быть посылаться с CSRF токеном. Это гарантирует отправку формы тем же клиентом, что её и отобразил.

2) 🚩Что такое 2fa и нужна ли?
Вопрос для сеньора, но мидловский, т.к. 2fa уже прочно вошла в обиход. И будет плохим признаком, если вы ответите wtf. Для серьёзных сервисов - 2fa is a must, даёт серьёзный буст к возможности зайти в вашу учётку даже зная логин и пароль. 2fa - это "второй фактор" = токен - обычно, ваш телефон (апп или смс), но не ограничивается им. Могут быть usb флешки, блютуз девайсы, биометрические сканеры и тп.

3) Храните пароль в базе? Хешированным? Солёным?
Пароль должен быть захеширован, притом важен алгоритм. md5, sha-1 - уже не подходят в текущих реалиях. Используйте bcrypt, PBKDF2 или sha-256. Соль к паролю может быть одна для в всех - не худший вариант. Однако идеально, если соль состоит частично из данных самого пользователя. Плюсом будет, если упомянете о rainbow tables.

4) 🚩Сможете ли сами написать алгоритм для хранения пароля?
Правильный ответ тут - не нужно изобретать криптовелосипеды, если вы не бородатый математик! Слишком просто допустить критическую ошибку в алгоритме и снизить стойкость. Хорошо, если вы сможете привести пример несложного шифрования через XOR, но не более :)

Senior+ level

1) Что делать в случае коллизий паролей при хэшировании?
Избежать этого невозможно, однако шанс стремится к нулю. Но если уж вопрос задан - чем длиннее хэш, тем меньше шанс этой коллизии. Именно md5 и sha-1 не обеспечивают этой длины в сегодняшнем мире. Так же можно упомянуть про двойное хеширование и метод цепочек - внутрянку знать не обязательно, просто знать, что методы есть.

2) Если принято решение шифровать пароль, то какой тип шифрования выберете? Почему?
Вопрос на знание отличий симметричного vs ассиметричного типа. Вы должны понимать разницу. Ответ на самом деле - it depends, зависит от системы взаимодействия. Обычно, используют симметричное, т.к. ассиметричное подразумевает валидацию второй стороной, которой скорее всего не будет. Нужно так же дополнить, что шифрование не замена хэшированию и должно применяться только в крайних случаях в нашем кейсе.

3) В связи с пунктом два - одинаков ли по стойкости 128-битный ключ для симметричного и ассиметричного способа?
Нет, не одинаков. Природа ассиметричного шифрования подразумевает, что ключ должен быть намного длиннее. Эквивалент 128 битного симм. ключа = 2048 ассим. Хорошо бы еще рассказать про плюсы и минусы каждого из подходов.

4) Хорошая ли идея вынести авторизацию на openid?
Безусловно да, если на сайте множество поддоменов и сервисов - это позволит упростить коммуникацию разных бэкендов/сервисов, а так же фрагментирует точки отказа в случае их возникновения - если ляжет авторизация, всё остальное скорее всего будет работать независимо. Т.е. функция не размана по множеству бэкендов. Плюс это более скейлбл решение и добавляет изолированности этой важной функции. Если на авторизацию будет один из векторов атаки - это не затронет остальные компоненты системы. К слову это частая точка для ддоса, т.к. обычно грамотная аутентификация кушает и память и cpu и может легко положить всю систему, если она гвоздями прибита к основной группе сервисов. Хорошо бы еще упомянуть и про oauth 2.0 - это второй по популярности протокол.

5) Rate Limit?
Да, штука отличная. В случае брутфорса или же ддоса - позволит отсекать вредных клиентов и не аффектать "хороших". Все большие ребята следят за этим. Часто авторизацию прячут (как и весь сайт) за cloudflare, который берёт это на себя эту функцию.

Пожалуй, это основные моменты, которые известны мне. Если что-то пропустил или где-то не прав, вэлкам в комменты ;) Всем, кто дочитал - респектушка и похлопывание по плечу ^^ Раскидайте знакомым и проверьте их 😉

и правда кек

#habr

🔐 Что такое SSL/TLS и как он работает? И немного про асимметричное шифрование на пальцах.

Друг тут на днях провёл ликбез и расставил точки над i на эту тему (были определенные чёрные дыры в понимании), за что ему большое спасибо ^^ Делюсь закаточкой с вами.

SSL (secure sockets layer) - это криптографический протокол, обеспечивающий безопасное общение пользователя и сервера по небезопасной сети. Он работает между транспортным уровнем (TCP) и уровнем программы/клиента (http/ftp и тд).

Если на пальцах - TCP это такой "автобус", который везёт ваши данные от вокзала (сервера) до вашего дома (браузер) и назад. И всё бы неплохо, если бы не одно но - все вокруг могут видеть кто и куда едет в автобусе. Зеваки, камеры на дороге, полиция, государственные чины, воры и жулики - любой, кто находится на пути автобуса может просканировать весь автобус. Неприятно, правда же.

SSL - это силовое поле вокруг автобуса, через которое видно только куда "примерно" автобус едет и ... само силовое поле. Извне автобуса непонятно кто едет и едет ли вообще хоть кто-то. Не видно какие инструкции у водителя и к какой именно подстанции он подъедет на самом вокзале. Все мы иногда ездим по подстанциям, которые не хотелось бы афишировать, правда? 😉 Это наше личное дело - касается только нас и вокзала. Всем незнакомым личностям по пути следования знать детали совсем не обязательно. А часто - и опасно. Для нас.

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer) и является его улучшенной версией. От SSL уже почти отказались, но название прижилось, поэтому если вы сегодня слышите SSL - подразумевается скорее всего TLS.

Итак. Как же это работает?

В основе протокола лежат асимметричное шифрование (для аутентификации) и симметричное (для сохранения конфиденциальности). Первый тип шифрования более ресурсоемкий/медленный, поэтому его комбинация с симметричным алгоритмом помогает делать всё красиво быстро.

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

Какая тут проблема в контексте интернета? А проблема в том, что а как передать этот секретный ключ из дома на вокзал чтобы никто по пути не перехватил его? Ответ : Асимметричное шифрование. Именно оно и нужно нам чтобы обменяться ключами между вашим браузером и сервером так, чтобы злоумышленники по пути не перехватили его. Как это сделать? Тут и начинается магия. Магия математики.

Асимметричное шифрование использует два связанных ключа - публичный и приватный. Приватный - это секретик, который хранится на сервере. Публичный же может знать хоть весь мир.
Эта пара ключей обладает одним крутым математическим свойством: сообщение, зашифрованное публичным ключом, может быть расшифровано только приватным ключом.

Круто, не правда ли? Т.е. то, что шифруется публичным ключом - расшифровать может только сервер с приватным. Именно этот публичный ключ и "зашивается" в специальный сертификат сервера, который скачивается при попытке установления соединения вашим браузером.

#security #библиотека_знаний

Итак... давайте отправлять автобус на порнхаб вокзал! (немного упрощенный сценарий на основе RSA, детали и другие варианты можно будет найти по ссылке в конце) :

1)🏠 ............🚌->........................................... 🏣[🔑🎫]
Вы отправляете на вокзал пустой автобус, водителя которого просите привезти сертификат с публичным ключом вокзала.

2) 🏠 ...................................<-🚌[🎫]........... 🏣[🔑]
Вокзал присылает автобус к вам домой, в нём лежит сертификат вокзала.

3) 🕵️ [🎫] => ✅ 🏠🚌............................. 🏣[🔑]
Вы проверяете, чтобы сертификат был красивым и ровно от того вокзала, в который вы отправляли автобус. Так же проверяете лицензионную голограмму (корневой сертификат, выданный надёжным центром сертификации) и срок годности.

4) 🕵️🏠............[🔐] 🚌->............................ 🏣 [🔑]
Если с сертификатом всё ок, вы генерируете симметричный ключ на своей стороне и шифруете его публичным ключом из сертификата. Отправляете автобус с вашим секретом. Уже на этом этапе никто по пути следования не сможет узнать ваш секретный ключ (помните, да? расшифровать это может только владелец приватного ключа, а владеет им только вокзал)

5) [🔑]🏠..........<-🚌[🔐boobs🔐].......... 🏣 [🔑]
Вокзал расшифровывает своим приватным ключиком сообщение. А там - уже ваш секретный симметричный ключ.

Всё. Теперь у вокзала и у вас есть ключ, о котором никто не знает. Этим ключом и создаётся то самое "энергетическое поле" вокруг вашего автобуса. Дальше уже работает только быстрое симметричное шифрование. Красиво, не правда ли?

Вот тут и тут можно найти более техническое и детальное описание процесса handshake'а. Так же очень советую глянуть (5min) визуализацию и объяснение работы алгоритма Диффи-Хеллмана.

#security #библиотека_знаний

Это определенно должно быть интересное интервью. Всего пять часов свободного времени выделить нужно 😎

Бегом смотреть!

https://www.youtube.com/watch?v=0xtEdIy2j88

#айтиборода #интервью

Интересный вектор атаки на packages подметили в последнем подкасте #радиот.

В двух словах - хацкеры сканят пакаджи, грепают все те, которые были зарегистрированы/залиты с кастомных доменных емейлов и проверяют а не истёк ли домен. В случае, если истёк - регистрируют, создают там нужную почту и льют новую версию package'а с вредоносом.

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

Как заявил сам автор - получилось собрать около 1000 переменных окружения, ну а что все там хранят? Правильно, секреты, конн стринги и прочие креды.

Вообще, атака на емейлы такого рода стара как мир, пакеты - лишь один из сценариев. К слову, совсем недавно чей-то бот купил истёкший домен аргентинского Google. В тот раз домен быстренько изъяли назад, однако you know, если даже гугл забывает продлять, то что уже говорить про остальные компании.

Будьте аккуратны с кастомными доменами и не забывайте их продлять 😉

#security

Как живётся в США "айтишнику". Три года спустя.

Автор довольно в позитивном ключе и детально рассказывает о трёхлетних итогах своей релокации из РФ в США. Рекомендую тем, кто посматривает в ту сторону - статья, пожалуй, даст вам плюс пару баллов в копилку ваших мыслей.

Отдельно, конечно же советую читать комментарии (1200+), там много информации и рассуждений.

https://habr.com/ru/post/666914/

#habr #usa #relocate

Я считаю, это прекрасно :

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

https://habr.com/ru/company/hexlet/blog/670114/

#habr

Заходит как-то тестировщик в бар...
#радиот #юмор

Телеграм недавно выкатил премиум подписку.

Давно ждал, если честно, так как пользуюсь им уже лет 8 и весьма доволен функционалом/юзабилити. Несмотря на то, что "плюшки" премиума могли бы и поинтереснее быть, но не суть - лично я с удовольствием купил в знак поддержки. Цена - 4$ в месяц и считаю её честной за такой софт.

Из приятных фич :
- Войсы теперь можно прогнать через сервера гугла и увидеть "текст", не прослушивая само сообщение. Качество распознания вполне себе на уровне, единственное что - тайминг ожидания высоковат, но спишем это пока на нагрузку.
- Приоритетный канал скачивания медиа
- Отключение рекламы (ненавижу рекламу!). Не сказать, что я часто её вижу, но скорее всего появляться она начнёт чаще. Напомню, что показываться она будет тайм-ту-тайм только в больших пабликах.

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

Дуров написал в своём блоге, что для того чтобы проект себя начал окупать требуется около 2-3% платных пользователей и мне стало интересно как много людей уже подписалось. Публичных данных нет, но у меня есть доступ к одному чату на 1300 человек (IT-компания) +этот канал с 317-ю подписчиками (спасибо, что читаете!) и я решил чуть подзаморочиться и посчитать кол-во людей с премиумом.

На данный момент статистика такая :

1) В этом канале купили прем 6 человек, т.е. ~1.9%
2) В чате моей IT компании - 9, т.е. 0.7%

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

Интересно будет посмотреть на цифры через полгода, т.к. уверен, что не все даже и знают о такой возможности. Подписаться сейчас можно через официальный тг бот @PremiumBot.

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

1) Очень не хватает более умного управления уведомлениями. Я хочу иметь возможность отключать у некоторых каналов уведомления от слова совсем. Окей, пусть там горит счётчик кол-ва новых, но я не хочу, чтобы они показывались в главной иконке (сейчас горит серым). Есть воркэраунд в виде "добавить чат в архивные", но костыль костылём.

2) Очень не хватает возможности держать свои "favorite" стикеры рядом и выделить их в отдельный "пак". Есть "recently used", но там и кол-во ограничено и туда всё равно "залетают" левые. Приходится делать свой пак для этого, но управлять им немного запарно.

3) Кол-во символов на один пост в канале. Если сообщение больше определенного кол-ва символов - оно бьётся на несколько (вот как в этом посте). Если в p2p чатах в целом пофиг, то в каналах выглядит как костыль. Есть telegra.ph, который и задумывался для "больших текстов", но это снижает конверсию чтения (уверен на 99%), т.к. необходим дополнительный клик.

4) Что за глупость с невозможностью добавлять картинки в пост - не понимаю. Во-первых, нельзя добавить пикчу в уже опубликованный текст, во-вторых, это выглядит как "подпись" к картинке. Какой-то маленький юзабилити ужас.

5) Более умный встроенный редактор видео, где можно было бы "подблюрить" определенные тайминги, или вообще их вырезать. Сейчас можно только обрезать начало/конец.

6) Качество звонков хотелось бы довести до уровня какого-нибудь Hangout. Есть тут еще простор для улучшения.

7) Security. Отвязать аккаунт от номера телефона. Да, так они пытаются бороться с фейк-акками и уменьшить кол-во "мёртвых душ", но есть и другие способы. Как показала практика 2020-ого года в Беларуси, симка как второй фактор - опасная штука. Cloud password тут вроде как "спасает", однако есть случаи, когда и он не помогал.
Второй момент - отсутствие "второго дна" или "защищённого пространства", куда можно попасть только если ввести куда-то какой-то код. Допустим, я хочу подписаться на канал, но иметь возможность читать его только тогда, когда считаю это безопасным.
Третья фишка - это идентификатор пользователя в общих чатах. Изменением никнейма и имени тут не добиться анонимности. Клиент телеграма видит ваш "реальный id", и он не меняется между чатами. А жаль, ведь таким образом можно вычислять людей "на будущее", собирая информацию о том, что кто пишет, а потом "сопоставляя" списки, собирая их, допустим, с других устройств. Чем и пользовались белорусские силовики в 2020-ом.

8) Было бы круто как-то "сливать" каналы и чаты в одну ленту. Т.е. чтобы я мог все новости поместить не в папку, а смержить в один канал и там читать не переключаясь постоянно между ними.

9) Ужасно не хватает фишки "отметить непросмотренным". Миллион раз был кейс, когда случайно открываешь чат с человеком и у него сообщения отображаются как "просмотренные". И нет возможности откатить. Существует возможность "mark as unread" на контакте, чтобы не забыть потом это сделать, но сообщение всё равно уже помечено как "просмотренное", что создаёт дискомфорт.

10) Было бы круто видеть не только "edited" при редактировании, но и историю изменений конкретного сообщения.

11) Есть куда расти и поиску. Сейчас он объединяет в себя поиск вообще по всему. Хочешь найти каналы - мимо. Покажет первые 5 по совпадению, остальные отрежутся. Нельзя в поиск вбить никнейм и найти все его сообщения. Ну и регулярочки бы :)

12) Комментарии в каналах это какой-то отдельный ад для автора канала. Сейчас это реализуется через бота, а хотелось бы нативно.

13) Ну и последнее :) Очень не хватает тредов (древовидной структуры), как в слаке. Удобно до жути. Уверен, что должны впилить в ближайший год-два, это же напрашивается.

❓Ребят, есть пару вопросов к вам :

1) Чего по вашему мнению не хватает сейчас в ТГ? С удовольствием почитаю.

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

Ну и ... ДУРОВ, ВЕРНИ СТЕНУ!

Паттерны, SOLID, Архитектура, Тесты или Хуяк-Хуяк и в продакшен ?

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

Но ... Серёжа нравится клиентам! Делает быстро. Фиксы как-то накатываются. Серёже не нужно рефакторить и писать тесты. Зачем? "Подфуфлил" и готово!

"Понапридумывали всякой высокоуровневой чуши, сами с ней и возитесь" - думает Серёжа.

Серёжа плохой?

Правильный ответ : it depends

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

В статье еще закончилось не так всё грустно, т.к. команда пришла к выводу "ну работает Серёжа и работает, раз мы не можем переубедить заказчика. Главное чтобы нам потом туда не нырять в гидрокостюме".

На самом деле, это палка о двух концах.

С одной стороны : Все мы понимаем (надеюсь), что качество конечного продукта зависит от множество факторов. Сделать качественно = сделать ... как? Возьмём как конечный продукт, скажем - автомобиль. Да это слоёный рекурсивный пирог, где СТОЛЬКО аспектов продукта, что можно взвыть только лишь перечисляя их.

А на другом конце Серёжа, который склеил автомобиль из картона, приделал смешную крякалку-дудку вместо клаксона, посадил на две оси и даже приклеил на клей зелёные брызговики Sparco! Таких даже у настоящих автомобилей нет.

Так почему "Зависит"-то? Вроде всё очевидно. На мерседесе все хотят ездить, а вот на машине Серёжи - только сам Серёжа.

А давайте теперь представим, что по ТЗ у этой машины на самом деле было ... "слепить автомобиль для ... детского утренника!". Да дети счастливы будут! Можно залезть внутрь, представить себя водителем и даже "подудеть клаксоном". А то, что она уже к вечеру развалится, брызговики отклеятся, а дудка выйдет из строя - уже и не так важно, дети уже дома будут - рассказывать родителям на каком крутом бугатти они катались. Заказчик доволен. Серёжа тоже. А вот вторая команда - нет, ведь дедлайн уже вышел, а они только-только прикинули стратегию постройки цеха для покраски ручки водительской двери.

Надеюсь, аналогия ясна :) Всё зависит от ... ТЗ и ... кучи факторов.

Во-первых, зачастую бизнесу нужно сегодня. Ибо завтра уже конкурент сожрёт или ниша закроется. А как только на ноги встанет - можно уже и команду нанять и переписать выкинуть старое. MVP (Minimal Valuable Product) - в конкурентной среде реально рабочий инструмент. И там не до архитектур, там бы просто "удочку закинуть". Посадочные страницы думаете зачем существуют? Ага. Сначала - proof of concept, а после уже напильничком-напильничком.

У меня в городе есть прекрасный пример - у лучшей шашлычной в городе сайт лет пять был ... JPEG картинкой. С ассортиментом, ценами и адресом. Всё. Ребята развились и ... заказали уже нормальный сайт. Уот так уот.

Во-вторых, вот даже по себе сужу - сколько код ни вылизывай, всё равно есть куда делать лучше. А надо ли? Это ведь та самая обратная сторона палки. Да поживёт эта админка на jquery, зачем там react? И что, что монолитом и падает раз в два дня? Ей пользуются два человека раз в месяц. Хоть функции у нее и критические для бизнеса - перезапустить сервер да жмякнуть пару раз кнопку (по таймауту просто валится по фазе луны) - пойдёт! Оно работает? Работает. Бизнесу хорошо. Админке, к сожалению не очень, но кто её спрашивает.

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

Это я всё к тому, что не всё так однозначно. Миссия на марс и ПО для аппаратов лучевой терапии не потерпят кривых процессов и плохого кода с багами (хотя, иногда и терпят). А одностраничнику в целом-то ваши горизонтальные скейлинги и O(logn) при сортировке ... сто лет не нужны. Пишите красивый код там, где нет спешки и особых требований и не пишите его там, кому он никому не нужен. Имейте компетенции для запуска марсохода, но не тратьте время на оверинженеринг. Вы должны быть как Нео из Матрицы. Каждый день выбирать правильную таблетку. Быть одновременно и специалистом и Серёжей. Решайте проблемы бизнеса в первую очередь.

А статью прочитайте, дельное чтиво. Как и комменты.

Have a good day!
#habr