All streams
Search
Write a publication
Pull to refresh
5
0.1
Григорий Бочаров @FlyingDutchman2

Senior Developer

Send message
Люди, претендующие на сениор-позицию могут всерьез сказать, что не помнят, как объявить пустой dict в Python.

Я вот претендую на позицию Senior и тоже многих таких базовых вещей не помню.


Например, я не помню, как написать заголовок цикла for в C# (или C). Помню только, что он состоит из трех частей — объявление переменной цикла, инкремент переменной и условие окончания цикла.


Логично, что объявление переменной должно идти первым, но вот остальные две части — что там первое, инкремент или условие окончания цикла — этого я никогда не помнил. Приходится постоянно в Help заглядывать.


Или вот внешнее cоединение в SQL. Если у нас left outer join, то с какой стороны у нас добавляются пустые записи, слева или справа? Хоть убей, не помню. Хотя и использую это соединение уже лет 25.


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


Правда, пустой dict в Python могу объявить. И в C# тоже. Но вот проинициализировать несколькими элементами — уже нужно где-то посмотреть.


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


Видимо, это особенности моего опыта. За последние 35 лет приходилось писать как минимум на 20 различных языках программирования. Если все это постоянно держать в голове, то можно свихнуться.


Помню собеседование несколько лет назад в одной компании в Брюсселе. Перед собеседованием дали мне пачку заданий по C# по написанию кода на бумажке. Первое задание — написать определение класса. Я с этим не справился, потому что классы я всегда создаю в Visual Studio — нажал кнопку и готово. А наизусть не помню, что там пишется. Второе задание — написать код для определения Event. С ним я тоже не справился, потому что последний раз делал это лет за пять до интервью и успел все забыть. После этого я бросил делать эти задачки.


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


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


И когда мне нужно было, к примеру, узнать, сколько будет 6*9 — я умножал в уме 6 на 10 и потом отнимал 6.


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


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


Но при всем при этом работу свою я делаю хорошо. А часто просто отлично.


Такие дела.

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


Эдсгер Дейкстра

CRUD программировать тоже надо с умом. Допустим, что база данных у нас на SQL Server, а Front-End, который с ней работает, написан на C#. Для программирования CRUD-функциональности можно для каждой CRUD-операции создать хранимую процедуру в базе данных и вызывать эти процедуры в C#-коде.


Сейчас, конечно, в связи с широким распространением ORM типа Entity Framework или Hibernate так уже не делают. Но 15 лет назад такая манера имплементации CRUD была типичной.


Допустим, что у нас в базе данных 100 таблиц. Для каждой таблицы нужно вручную написать 4 хранимых процедуры + код на C# для вызова этих хранимых процедур.


Допустим, что для создания кода для одной хранимой процедуры нужно полчаса (а может быть и больше, если вместе с тестированием). Тогда для написания всего кода нужно 200 часов. Джуниору наверняка еще больше времени понадобится. Допустим, что ему понадобится примерно 340 часов (2 месяца работы).


Как эту задачу будет решать Senior? Можно написать программу, которая читает структуру таблиц базы данных и на основе этой информации генерирует как код хранимых процедур, так и C#-код для их вызова. Для написания такого кодогенератора нужно потратить где-то неделю времени.


Собственно, я так и поступил в одном проекте в 2005 году.


То есть получаем неделю работы вместо двух месяцев.


Далее, при изменении структуры БД Junior будет опять вручную имплементировать все изменения, а Senior просто запустит свой кодогенератор и сгенерирует весь код. При этом вручную написанный код надо еще тестировать, а сгенерированный нет.


Сейчас у меня ушло бы на это еще меньше времени. У меня сейчас есть мной написанная программа на C#, которая считывает все метаданные из базы данных SQL Server (структуру таблиц и т.д.). На ее основе такой генератор кода можно написать за 1-2 дня (что я и делал для другой задачи в прошлом году).


Итого получается, что даже на простых задачах типа CRUD производительность Senior в 20 раз выше производительности Junior.

Хотя это и не имеет отношения к теме, но вспомнилось: был я несколько лет назад на юге Голландии в славном городе Маастрихт. Проходил вечером у церкви XIII века в центре города, в торговом районе. Дверь церкви была открыта и там горел свет. Я подумал, что там какая-то выставка, и подошел ближе. Однако оказалось, что в церкви находится книжной магазин: https://media.insiders.nl/maa/files/image/94f92d4dbf7db6d6257cfbf49b97414c3f04840a.jpg И название у него: Книготорговля 'У доминиканцев'

Нет. Но задачу фасетного поиска решает хорошо.

Такого рода происшествия, как это — большая редкость для Голландии.

Какой ужас! И как это Голландия умудрилась попасть в первую двадцатку наиболее развитых стран?

Я когда-то реализовал фасетный поиск при разработке каталога товаров для веб-магазина в реляционной базе данных, на основе паттерна EAV (Entity — Attribute — Value).


Краткое описание реализации для SQL Server можно посмотреть здесь: https://rsdn.org/forum/db/3566910.1 https://www.sql.ru/forum/789723/internet-magazin#9534088


Структура полностью нормализованная, никаких полей типа JSON, XML или BLOB.


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


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


Эта структура использовалась для реализации десятков (а может и сотен) веб-магазинов, в том числе с большим числом товаров (несколько десятков тысяч) и высоконагруженных (сотни запросов в секунду). С производительностью было все в порядке.

Для Голландии это не копейки, а очень хорошая зарплата.

Точно, я и не заметил :-)

Но неопытным его тоже не назовешь. Оустерхаут — разработчик скриптового языка Tcl. Может, на самом деле не 3 года, а 30? К моменту написания книги ему было 63 года.

В 2019 году я познакомился с молодым венгром, который перебрался в Голландию в поисках лучшей жизни. Ему 22 года, работал массажистом в отеле в Будапеште. По его словам, средняя зарплата в Венгрии составляет 500 евро.


Ругал президента Орбана и его политику. Говорил, что в Венгрии застой и стагнация, не видно никаких перспектив.


В Голландии соглашается на любую работу и пытается любой ценой здесь закрепиться.


Здесь, работая официально, он получал минимальную голландскую зарплату (для его возраста около 10 евро в час). Работая по-черному, получал 15 евро в час чистыми.

На голландских автобанах нет луж. Ну, скажем, почти нет. Возможно, я не прав на все 100%. С 2001 года я проехал по дорогам Голландии почти 400000 км. Я по ним ездил в дождливую погоду на скорости до 150 км/ч.


Описанная мной проблема возникает с грузовиками на любой скорости. Чтобы быть точным, они обычно едут по автобану со скоростью 90-100 км/ч.

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


К примеру, совершенно типичная ситуация на дорогах Голландии в дождливую погоду, при обгоне грузовика на скорости где-то 130 км/ч:


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


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


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


А вот еще один образчик современного автомобильного дизайна. Сообщение из голландских новостей: https://www.hartvannederland.nl/nieuws/2018/mannen-in-snikhete-geldwagen-opgesloten-in-breda/


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


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

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

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

А вы правильно прочитали то что я написал? Безос говорит, что нельзя выбирать 2 из 3х и нужно работать и долго, и с умом, и напрягаясь.

По поводу корпоративных ценностей Amazon:


Bezos told shareholders that employees at other companies "can work long, hard, or smart, but at Amazon.com, you can't choose two out of three."


(взято отсюда: https://www.businessinsider.in/jeff-bezos-once-said-that-in-job-interviews-he-told-candidates-there-are-3-ways-to-work-and-at-amazon-you-have-to-do-all-3/articleshow/65343632.cms )


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

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


Я в таких случаях использую таблицы решений (decision tables). Это наглядный метод табличного описания алгоритмов, который описываются большим количеством логических операторов if и switch.


Я ними познакомился в 2000 году во время работы над проектом, который реализовывался по методологии Хэтли-Пирбхаи. С тех пор я регулярно использую их как для написания нового кода, так и для анализа существующего кода.


Это очень давно известная методика. Хорошее описание можно найти в книге издательства "Мир" 1976 года: Э.Хамби "Программирование таблиц решений".


Методология Хэтли-Пирбхаи, одной из составных частей которых является использование таблиц решений, описана в книге Hatley & Pirbhai "Strategies for Real Time System Specification" https://www.amazon.co.uk/gp/product/0932633110 Есть более свежее издание: https://www.amazon.co.uk/gp/product/0932633412

Маленькое замечание: в русскоязычной литературе фамилию создателя языка Фортран принято писать "Бэкус", а не "Бакус".

Information

Rating
3,910-th
Location
Arnhem, Gelderland, Нидерланды
Registered
Activity