March 6th, 2017

404

собеседовательное

Либо я становлюсь упёртым олдфагом, либо что-то меняется в компетенции собеседуемых.

Раньше, ещё в те времена, когда я был офисным админом, на собеседовании эникеев для меня неким разумным критерием отсечения была способность различить доменного пользователя и локального, плюс способность объяснить как компьютер отправляет ip-пакет (route, arp, плюс коронный вопрос с подначкой "получается, что компьютер отправляет пакет, у которого в dest ip написано 8.8.8.8, а в dest mac - мак адрес маршрутизатора, вы уверены? - в этом месте ожидается, что человек запнётся, но использовав логику подтвердит утверждение).

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

Сейчас я собеседую будущего коллегу (!) и я вижу, что в чуть ли не в половине случаев этот вопрос вызывает боль и непонимание. Так же как и любой другой, "на основы". При этом человек может кидаться какими-то модными словами про docker, delivery pipeline и "автоматизация процессов".

Эти базовые вопросы, разумеется, не являются критичными - если человек реально хорошо знает устройство ceph, или потрошки сhef, то ему можно простить "дырку в сетях" (хотя как он умудрился?). Но если человек ни одной технологии не знает хотя бы на приемлимом уровне, то о чём может идти речь?

Есть если кто-то это читает и думает о профразвитии: возьмите свой любимый инструмент и задайте себе вопрос: а как он это делает? Без режима "напиться из пожарного крана" - возьмите хотя бы одну технологию и поковыряйте её поглубже.
404

О рефакторинге

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

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

Долгий рисунок - это практически только устранение ошибок и ничего кроме.

И подход к программированию такой же. В режиме "наброска" можно попытаться ухватить главное (и тут разница между хорошим художником и плохим - хороший ухватит главное, а плохой натыкает деталек не туда и не так, а главного меж ними не ухватит). Так что в программировании большой программы большая часть работы - рефакторинг, иначе код превращается в мешанину из линий. Соответственно, после рефакторинга программа делает то же, что и делала, но "точнее" - зрителю (ака программисту) понятно, что тут изображено. Если не понятно - надо чистить и перерисовывать. При этом важно помнить, что перерисовывать - это не рисовать с нуля, нельзя просто стереть кусок и нарисовать его заново с нуля. Перед тем, как стирать уродливое надо быть уверенным, что нарисуешь лучше. То есть надо среди этих линий найти те, которые повторишь более аккуратно.


Пожалуй, рисование даёт для программирования больше, чем я думал...

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