Зачем на собеседованиях тупые алгоритмические задачки? Да-да, алгоримтические задачки из собеседований применяются в дальнейшей работе в чуть менее чем нуля случаях, но на собеседовании смысл в них вполне есть.
Это потому, что любая задача из типа «посчитать то, что кажется что хрен посчитаешь» начитается с листика и ручки и попытке посчитать всё вручную. Мозг ленив и пытается экономить ресурсы и от этого ищет закономерности. И вот тут уже проверяется насколько мозг пытлив и гибок для того, чтобы найти совсем неочевидные и непрямолинейные решения.
И тут есть несколько правил.
1. У задачи должно быть больше одного решения. Даже самый умный человек в мире не всегда приходит к решению за короткое время. А если решение всего одно, то ответ «решил/не решил» выдаёт очень много ложноотрицательных результатов. Ещё лучше, если задачу можно решить достаточно большим количеством способов, чтобы сформировать градиент качества решений. Чтобы хоть как-то можно было бы сравнить два разных решения.
2. Испытуемый не должен знать задачу или то, как её решать лучше. Тут очевидно, что если испытуемый знаком с задачей, то проверить гибкость ума не получится. В пуле задач лучше держать таких несколько и если задача знакома, то нужно брать другую.
3. Задача должна быть максимально абстрактна. Это менее очевидно, но тестовые задачи, сформулированные на языке рабочих задач начинают решаться не тестовым способом, а рабочим. «Перебрать юзеров, чтобы отсеять лишних» с помощью чистых алгоритмов пытливым и ленивым мозгом очень быстро решается парочкой запросов в базу данных, а вот «найти числа из последовательности, удовлетворяющие условию» уже достаточно абстрактна, чтобы рефлексы не тянулись к SQL.
4. Ничего другого, кроме пытливости ума такой тип задач проверить не в состоянии. Не надо искать подтекстов и проверять что-то ещё. Решения одной задачи не достаточно, чтобы определить насколько хорошо испытуемый пишет тесты, задаёт вопросы, называет переменные или что-то там ещё. Тем более если добавить к этому лёгкое ощущение экзамена или собеседования. Сейчас такие задачи стали чем-то вроде культа Карго и перешли совершенно в другую категорию собеседований. Проверяют скорость написания кода, оптимальность решения, чистоту кода и написание, простигосподи, тестов. Это настолько же тупо, как отсеивать козерогов и водолеев на основании совместимости гороскопов.
Одна из любимых моих задач на собеседовании — это задача с названием «Сумма двух». Алгоритмических решений у этой задачи я знаю штук пять, каждое из которых ещё можно и оптимизировать.
Дано: массив случайных натуральных чисел
Вопрос: может ли число
Ответ нужно только
Если захотите вдруг решить эту задачу — вот вам специальных гист, чтобы проверить решение.
Это потому, что любая задача из типа «посчитать то, что кажется что хрен посчитаешь» начитается с листика и ручки и попытке посчитать всё вручную. Мозг ленив и пытается экономить ресурсы и от этого ищет закономерности. И вот тут уже проверяется насколько мозг пытлив и гибок для того, чтобы найти совсем неочевидные и непрямолинейные решения.
И тут есть несколько правил.
1. У задачи должно быть больше одного решения. Даже самый умный человек в мире не всегда приходит к решению за короткое время. А если решение всего одно, то ответ «решил/не решил» выдаёт очень много ложноотрицательных результатов. Ещё лучше, если задачу можно решить достаточно большим количеством способов, чтобы сформировать градиент качества решений. Чтобы хоть как-то можно было бы сравнить два разных решения.
2. Испытуемый не должен знать задачу или то, как её решать лучше. Тут очевидно, что если испытуемый знаком с задачей, то проверить гибкость ума не получится. В пуле задач лучше держать таких несколько и если задача знакома, то нужно брать другую.
3. Задача должна быть максимально абстрактна. Это менее очевидно, но тестовые задачи, сформулированные на языке рабочих задач начинают решаться не тестовым способом, а рабочим. «Перебрать юзеров, чтобы отсеять лишних» с помощью чистых алгоритмов пытливым и ленивым мозгом очень быстро решается парочкой запросов в базу данных, а вот «найти числа из последовательности, удовлетворяющие условию» уже достаточно абстрактна, чтобы рефлексы не тянулись к SQL.
4. Ничего другого, кроме пытливости ума такой тип задач проверить не в состоянии. Не надо искать подтекстов и проверять что-то ещё. Решения одной задачи не достаточно, чтобы определить насколько хорошо испытуемый пишет тесты, задаёт вопросы, называет переменные или что-то там ещё. Тем более если добавить к этому лёгкое ощущение экзамена или собеседования. Сейчас такие задачи стали чем-то вроде культа Карго и перешли совершенно в другую категорию собеседований. Проверяют скорость написания кода, оптимальность решения, чистоту кода и написание, простигосподи, тестов. Это настолько же тупо, как отсеивать козерогов и водолеев на основании совместимости гороскопов.
Одна из любимых моих задач на собеседовании — это задача с названием «Сумма двух». Алгоритмических решений у этой задачи я знаю штук пять, каждое из которых ещё можно и оптимизировать.
Дано: массив случайных натуральных чисел
X в случайном порядке, среди которых могут быть дубликаты. И целое число C.Вопрос: может ли число
C быть сформировано суммой двух элементов массива? Другими словами, существуют ли такие i, j, что X[i] + X[j] == C?Ответ нужно только
true или false, сами числа знать не обязательно.Если захотите вдруг решить эту задачу — вот вам специальных гист, чтобы проверить решение.
По роду своей деятельности доводится много общаться с теми, кто принимает решения, всяких там CEO, COO, PO и прочих офицеров и порутчиков. Подавляющее большинство из них рассказывают о вынужденной удалёнке и как бы здорово было бы работать всем из офиса. Аргументов называют разных и много, но основных всего три.
1. Командный дух. Мол, сплотить команду, думать, как один и чувство локтя можно только на расстоянии вытянутой руки друг от друга.
2. Незаметный генератор идей. Чашечка кофе у кулера может порождать кучу всего такого, чего не удаться придумать, сидя каждый у себя в норках.
3. Производительность. Офис — место концентрации рабочего процесса и сосредоточиться в офисе намного проще, чем у себя дома с иксбоксом и орущими детьми под рукой.
Остальное всё, как правило вырождается в один из этих пунктов или зависит от них. Например, «контроллировать сотрудников проще в офисе» — совокупность первого и третьего пунктов, «не нужно тратить время на планирование разговоров, а просто подошёл и спросил» — совокупность второго и третьего. Ну, и так далее.
Самая главное заблуждение приверженцев офисной работы — это то, что работа бывает удалённой и офисной. По факту это деление в корне неверное. Работа бывает синхронной (это когда требуется ответа здесь и сейчас) и асинхронной (когда никто не нужен, чтобы делать свою работу). Если работу строить асинхронно, то становится совершенно плевать где сейчас находится коллега, за соседним стулом или на пляжах Шри-Ланки.
1. Командный дух. Мол, сплотить команду, думать, как один и чувство локтя можно только на расстоянии вытянутой руки друг от друга.
2. Незаметный генератор идей. Чашечка кофе у кулера может порождать кучу всего такого, чего не удаться придумать, сидя каждый у себя в норках.
3. Производительность. Офис — место концентрации рабочего процесса и сосредоточиться в офисе намного проще, чем у себя дома с иксбоксом и орущими детьми под рукой.
Остальное всё, как правило вырождается в один из этих пунктов или зависит от них. Например, «контроллировать сотрудников проще в офисе» — совокупность первого и третьего пунктов, «не нужно тратить время на планирование разговоров, а просто подошёл и спросил» — совокупность второго и третьего. Ну, и так далее.
Самая главное заблуждение приверженцев офисной работы — это то, что работа бывает удалённой и офисной. По факту это деление в корне неверное. Работа бывает синхронной (это когда требуется ответа здесь и сейчас) и асинхронной (когда никто не нужен, чтобы делать свою работу). Если работу строить асинхронно, то становится совершенно плевать где сейчас находится коллега, за соседним стулом или на пляжах Шри-Ланки.
👍2
Человечество до сих пор не знает что же такое интеллект. В смысле, конечно, интуитивно мы можем понять, что собака умнее червя, а дельфин умнее курицы. Даже придумали тесты, которые показательно отличают ум одного испытуемого от другого.
Понять от чего зависит интеллект мы не знаем. Казалось, что он зависит от размера мозга, но это не так. Думали, что на него влияет размер конкретного учатстка мозга или объем какого-то вещества внутри, но это тоже не подтвердилось. В общем, теории есть, но доказанных нету.
Но и с тем, что такое интеллект тоже вопросы. Самое удачное определение интеллекта говорит, что это способность адаптироваться к изменениям. Чем быстрее и лучше адаптируется индивид, тем интеллект лучше, больше или сильнее. Да, с измерениями его тоже проблемы.
В общем, говорить, что один человек умнее другого можно исключительно субъективно, никаких объективных критериев нет.
(лайк, если хочешь ещё об интеллекте)
Понять от чего зависит интеллект мы не знаем. Казалось, что он зависит от размера мозга, но это не так. Думали, что на него влияет размер конкретного учатстка мозга или объем какого-то вещества внутри, но это тоже не подтвердилось. В общем, теории есть, но доказанных нету.
Но и с тем, что такое интеллект тоже вопросы. Самое удачное определение интеллекта говорит, что это способность адаптироваться к изменениям. Чем быстрее и лучше адаптируется индивид, тем интеллект лучше, больше или сильнее. Да, с измерениями его тоже проблемы.
В общем, говорить, что один человек умнее другого можно исключительно субъективно, никаких объективных критериев нет.
(лайк, если хочешь ещё об интеллекте)
«Есть два подхода к программированию. Первый — сделать программу настолько простой, чтобы в ней очевидно не было ошибок. А второй — сделать её настолько сложной, чтобы в ней не было очевидных ошибок»
Отнюдь не каждую операцию, которую совершает человек, он совершает «на личном воображении». Большую часть операций человек (во всяком случае, взрослый) делает без участия воображения как нечто рутинное, привычное, регулируемое уже сложившимися ассоциациями. И механизм таких операций не отличается у животных. Это и называется обучением.
Но есть механизм обучения у людей, который отсутствует у животных. У животных новые ассоциации образуются в некотором смысле насильно, извне. Чтобы образовалась ассоциация, она должна быть мотивационно обоснована, связана с отрицательной или положительной эмоцией. Необходимо подкрепление. Иначе говоря, обучение происходит только «методом кнута и пряника».
Ассоциации могут образовываться у человека «просто так», без всякого подкрепления. Это так работает механизм управления ассоциированием, который постоянно требует себе пищи. Если ее нет, человеку становится скучно, а это отрицательная эмоция. Учителю нет надобности навязывать что-либо ребенку или человеку вообще, его задача лишь в том, чтобы дать пищу его воображению. Получая эту пищу, человек испытывает удовольствие. Таким образом, он всегда учится сам, изнутри. Это активный, творческий процесс. Благодаря этому человек приобрел собственного внутреннего учителя, который непрерывно учит его, щелкая внутренним кнутом и заманивая внутренним пряником.
Но есть механизм обучения у людей, который отсутствует у животных. У животных новые ассоциации образуются в некотором смысле насильно, извне. Чтобы образовалась ассоциация, она должна быть мотивационно обоснована, связана с отрицательной или положительной эмоцией. Необходимо подкрепление. Иначе говоря, обучение происходит только «методом кнута и пряника».
Ассоциации могут образовываться у человека «просто так», без всякого подкрепления. Это так работает механизм управления ассоциированием, который постоянно требует себе пищи. Если ее нет, человеку становится скучно, а это отрицательная эмоция. Учителю нет надобности навязывать что-либо ребенку или человеку вообще, его задача лишь в том, чтобы дать пищу его воображению. Получая эту пищу, человек испытывает удовольствие. Таким образом, он всегда учится сам, изнутри. Это активный, творческий процесс. Благодаря этому человек приобрел собственного внутреннего учителя, который непрерывно учит его, щелкая внутренним кнутом и заманивая внутренним пряником.
Мы живем в век технологий, когда любая амбициозная идея, которая хоть сколько-нибудь гипотетически возможна, априори считается реализуемой технически. У большинства даже не возникает сомнений в эмуляции этих самых магических способностей. Вера в компьютерных духов непоколебима.
Три-дэ колонки с автоопределением помещения, искусственный интеллект в телефоне который понимает естесственную речь, личные картины Ван Гога в инстаграме с помощью фотокамеры, читалка в телефоне, следящая за глазами пользователя. Список эмуляций магии можно перечислять бесконечно. Чудес не бывает, мы все еще заперты в тьюринг-полноте и выбраться пока возможности не видно. Это мы, люди, подстраиваем себя и свои нейронные сети под программы, а не программы подстраиваются под нас, ведь это значительно проще и нам и программам.
#перечитываяэкстраполяцию
Три-дэ колонки с автоопределением помещения, искусственный интеллект в телефоне который понимает естесственную речь, личные картины Ван Гога в инстаграме с помощью фотокамеры, читалка в телефоне, следящая за глазами пользователя. Список эмуляций магии можно перечислять бесконечно. Чудес не бывает, мы все еще заперты в тьюринг-полноте и выбраться пока возможности не видно. Это мы, люди, подстраиваем себя и свои нейронные сети под программы, а не программы подстраиваются под нас, ведь это значительно проще и нам и программам.
#перечитываяэкстраполяцию
Главной проблемой быстрого устаревания кода является принцип «Работает — не трогай». Казалось бы, как в той истории, Солнце всходит каждый раз на востоке и менять ничего не надо, но как ни парадоксально то, что не нужно менять, не работает.
Во-первых, то, чем пользуются, начинает работать под нагрузкой. Во-вторых, то, чем много пользуются, подвергается тщательному тестированию во всех возможных случаях и окружениях. Ещё полезный и используемый код постоянно нужно переиспользовать, а значит расширять его применение.
В итоге код, который работает, постоянно меняется, исправляется и дополняется. А тот код, который один раз написали и оно работает и кушать не просит — первый кандидат на удаление.
Во-первых, то, чем пользуются, начинает работать под нагрузкой. Во-вторых, то, чем много пользуются, подвергается тщательному тестированию во всех возможных случаях и окружениях. Ещё полезный и используемый код постоянно нужно переиспользовать, а значит расширять его применение.
В итоге код, который работает, постоянно меняется, исправляется и дополняется. А тот код, который один раз написали и оно работает и кушать не просит — первый кандидат на удаление.
Уже несколько раз сталкиваюсь с непониманием того, что считать своим кодом и своей ответственностью, а что считать сторонними бибилиотеками и чужой ответственностью. И на этот счёт есть очень хорошее правило минус первого этажа.
Команда разработки должна контроллировать весь код, который она пишет и код, от которого зависит их код.
Как пример, допустим, у вас в коде есть отложенный вызов процедур и фреймворк отложенных задач. Контроллировать надо, очевидно, свой код и код фреймворка. А вот проблемы редиса, на которых основывается фреймворк — уже не ваша проблема.
Само собой, это не значит, что не нужно решать проблемы минус второго этажа вашей архитектуры. Это значит, что решат придется чужую проблему.
В качестве внезапного вывода из этого и без того хорошего правила, могу предложить подумать над тем, насколько нужно абстрагироваться от библиотеки в зависимостях. Нужно писать декораторы, врапперы или писать ли тесты на случаи, которые входят в эти два этажа абстрагирования — текущий и минус первый.
Команда разработки должна контроллировать весь код, который она пишет и код, от которого зависит их код.
Как пример, допустим, у вас в коде есть отложенный вызов процедур и фреймворк отложенных задач. Контроллировать надо, очевидно, свой код и код фреймворка. А вот проблемы редиса, на которых основывается фреймворк — уже не ваша проблема.
Само собой, это не значит, что не нужно решать проблемы минус второго этажа вашей архитектуры. Это значит, что решат придется чужую проблему.
В качестве внезапного вывода из этого и без того хорошего правила, могу предложить подумать над тем, насколько нужно абстрагироваться от библиотеки в зависимостях. Нужно писать декораторы, врапперы или писать ли тесты на случаи, которые входят в эти два этажа абстрагирования — текущий и минус первый.
На днях пришлось общаться с сантехником по всяким сантехническим делам и он поделился со мной крупицей мудрости своей профессии.
Началось с того, что сантехнические новички, когда приходят в профессию, допускают одну и ту же ошибку, хоть и с разными причинами. Одни сантехджуны хотели сэкономить материал и проложить трубы более коротким путём. Другие ленились и пытались придумать способ сделать работу попроще. Ещё бывают те, кто пытается сделать всё настолько лучше, что становится слишком запутано и усложено. Короче, принимают ситуативные оптимальные решения.
А секрет в том, что оказывается трубы нужно прокладывать не там, где удобнее или лучше всего, а там, где эти трубы вероятнее всего будет ожидать слесарь с перфоратором. Это далеко не всегда самое лучшее решение и редко самое ленивое решение. Но вот тогда не настанет жопа и кипяток не польётся прямо из стены.
Началось с того, что сантехнические новички, когда приходят в профессию, допускают одну и ту же ошибку, хоть и с разными причинами. Одни сантехджуны хотели сэкономить материал и проложить трубы более коротким путём. Другие ленились и пытались придумать способ сделать работу попроще. Ещё бывают те, кто пытается сделать всё настолько лучше, что становится слишком запутано и усложено. Короче, принимают ситуативные оптимальные решения.
А секрет в том, что оказывается трубы нужно прокладывать не там, где удобнее или лучше всего, а там, где эти трубы вероятнее всего будет ожидать слесарь с перфоратором. Это далеко не всегда самое лучшее решение и редко самое ленивое решение. Но вот тогда не настанет жопа и кипяток не польётся прямо из стены.
Иногда очень полезно формулировать и повторять вещи, которые кажутся совершенно очевидными и естесственными. То, что для кого-то может показаться банальщиной, кому-то откроет новые возможности и даст аргументы делать правильные вещи. Например, автотестирование.
Недавно, в разговоре с коллегой обнаружилась устойчивая ассоциация, что тесты — это всегда дополнительное время на разработку. Мол, «мы пока тесты не пишем, потому что время нужно экономить. А вот, как время не надо будет экономить, вот тогда и напишем». Да, можно, конечно, начать убеждать, что такого времени не настанет никогда и что тесты — это неизбежное зло и просто накидывай 15% времени к оценке, но это в корне ошибочная риторика.
Тесты — это не дополнительно потраченное время, а экономия его. Ведь даже написаный правильно с первого раза код нужно проверить и это обычно делают несколькими способами: интерактивная коносль, точка дебага и принтами в лог. И вот все эти способы очень требовательны к повторному воспроизведению. Вот если бы существовал бы способ, чтобы проверку работающего кода можно было бы автоматизировать и не проверять одно и то же по-нескольку раз, да? Это бы начало экономить время уже на первой ошибке во время написания кода.
Тесты — это не пятое колесо в разработке, это не вынужденная мера. Это самый ленивый и быстрый способ писать код. Возможно, разработчик, который никогда не писал раньше тесты, первые пару недель будет бороться с фреймворком и много гуглить, но это так с любым новым инструментом же. Тут бесполезно требовать соблюдения каких-то там TDD-практик, и объяснять, что нужно «сначала тесты, потом код», нет. Нужно просто донести мысль о том, что тесты — это универсальный способ быстрее и эффективнее писать код.
Короче, ленитесь по-полной и автоматизируйте вообще всё, включая проверку того, что код работает.
Недавно, в разговоре с коллегой обнаружилась устойчивая ассоциация, что тесты — это всегда дополнительное время на разработку. Мол, «мы пока тесты не пишем, потому что время нужно экономить. А вот, как время не надо будет экономить, вот тогда и напишем». Да, можно, конечно, начать убеждать, что такого времени не настанет никогда и что тесты — это неизбежное зло и просто накидывай 15% времени к оценке, но это в корне ошибочная риторика.
Тесты — это не дополнительно потраченное время, а экономия его. Ведь даже написаный правильно с первого раза код нужно проверить и это обычно делают несколькими способами: интерактивная коносль, точка дебага и принтами в лог. И вот все эти способы очень требовательны к повторному воспроизведению. Вот если бы существовал бы способ, чтобы проверку работающего кода можно было бы автоматизировать и не проверять одно и то же по-нескольку раз, да? Это бы начало экономить время уже на первой ошибке во время написания кода.
Тесты — это не пятое колесо в разработке, это не вынужденная мера. Это самый ленивый и быстрый способ писать код. Возможно, разработчик, который никогда не писал раньше тесты, первые пару недель будет бороться с фреймворком и много гуглить, но это так с любым новым инструментом же. Тут бесполезно требовать соблюдения каких-то там TDD-практик, и объяснять, что нужно «сначала тесты, потом код», нет. Нужно просто донести мысль о том, что тесты — это универсальный способ быстрее и эффективнее писать код.
Короче, ленитесь по-полной и автоматизируйте вообще всё, включая проверку того, что код работает.
Я не вижу увеличившихся возможностей разработки пользовательского интерфейса, за которые мы заплатили увеличившейся сложностью разработки пользовательского интерфейса.
UI в целом такой же на стороне пользователя.
Единственное, теперь на нём мерзко мерцает blank state, когда сначала показывается пустая таблица, а потом она идёт за данными, и если всё не прям шустрое-шустрое, ты успеваешь увидеть ‘You have no teams’ или там ‘Data loading’.
Других фундаментальных прорывов пользовательского интерфейса, достигнутых при помощи доминирующей технологии разработки UI, по сравнению с тем, что мы делали эпохи назад на js.haml и jQuery я пока не разглядел. Мы делали не хуже, но это было понятно.
Единственные увеличившиеся возможности — это увеличившийся потенциал рынка труда джаваскрипт-разработчиков. Как с юристами, сука — если законы вдруг станут простыми и понятными, их рынок сожмётся.
Да, да, я/мы просто не умею это готовить. Старческое брюзжание.
#dimoneverything
UI в целом такой же на стороне пользователя.
Единственное, теперь на нём мерзко мерцает blank state, когда сначала показывается пустая таблица, а потом она идёт за данными, и если всё не прям шустрое-шустрое, ты успеваешь увидеть ‘You have no teams’ или там ‘Data loading’.
Других фундаментальных прорывов пользовательского интерфейса, достигнутых при помощи доминирующей технологии разработки UI, по сравнению с тем, что мы делали эпохи назад на js.haml и jQuery я пока не разглядел. Мы делали не хуже, но это было понятно.
Единственные увеличившиеся возможности — это увеличившийся потенциал рынка труда джаваскрипт-разработчиков. Как с юристами, сука — если законы вдруг станут простыми и понятными, их рынок сожмётся.
Да, да, я/мы просто не умею это готовить. Старческое брюзжание.
#dimoneverything
Так, ещё одна очевидная вещь. Переписка и общение внутри команды должно быть публичными. Внутри команды, само собой. Под явное табу попадают личные переписки в мессенджерах и личные p2p письма. И, судя по опыту, мысль эта крайне непопулярная. Почти все команды, которые удалось наблюдать, используют приватные сообщения, как основной способ общения с коллегами. Созвоны — в приватных чатах, переклички там же. Обсудить, договориться, спросить. Всё в приватных чатах. А плохо это вот почему:
1. Полная изоляция от процессов, происходящих в проекте. Приходится изобретать дополнительные способы синхронизироваться и постфактум узнавать о жопе буквально в соседнем файлике.
2. Конфликты имплементаций. Две, с первого взгляда, независимые задачи вполне могут захотеть поменять логику в одном и том же месте. Узнать об этом заранее без дополнительных пинков нет никаких шансов.
3. Отсутствие вовлечённости. Полная тишина в общедоступных каналах создаёт ложное чувство одиночества и отдаляет членов одной и той же команды друг от друга. Трэд с длительным обсуждением проблемы даёт понять, что у соседей по парте тоже бурлит жизнь и у них там тоже проблемы лопатами разгребают.
Для любителей исключений из правил, наверное, нужно добавить, что в личку таки иногда нужно писать, когда решается какой-то конфликт, обсуждаете зарплаты или, например, выбираете подарок коллеге.
Как итог. Всё, что может быть написано не в приватном сообщении, должно быть написано в публичных каналах. И используйте трэды, пожалуйста.
1. Полная изоляция от процессов, происходящих в проекте. Приходится изобретать дополнительные способы синхронизироваться и постфактум узнавать о жопе буквально в соседнем файлике.
2. Конфликты имплементаций. Две, с первого взгляда, независимые задачи вполне могут захотеть поменять логику в одном и том же месте. Узнать об этом заранее без дополнительных пинков нет никаких шансов.
3. Отсутствие вовлечённости. Полная тишина в общедоступных каналах создаёт ложное чувство одиночества и отдаляет членов одной и той же команды друг от друга. Трэд с длительным обсуждением проблемы даёт понять, что у соседей по парте тоже бурлит жизнь и у них там тоже проблемы лопатами разгребают.
Для любителей исключений из правил, наверное, нужно добавить, что в личку таки иногда нужно писать, когда решается какой-то конфликт, обсуждаете зарплаты или, например, выбираете подарок коллеге.
Как итог. Всё, что может быть написано не в приватном сообщении, должно быть написано в публичных каналах. И используйте трэды, пожалуйста.
В чате на днях разогрелась дискуссия на тему разницы между фреймворком и библиотекой. Началась она, как водится, совсем не с того, а с разницы между IDE и «редактором». В итоге, к консенсусу пришли, сформулировав некоторые правила, но я вспомнил о логическом парадоксе, который сформулировали больше двух тысяч лет назад. Я его проиллюстрирую на примере определения «текстового редактора с плагинами» и «IDE».
Давайте скажем, что IDE — это такой вот богатый и многофункциональный способ редактировать файлы и делать что-то ещё в довесок. А текстовый редактор умеет лишь редактировать файлы.
Если мы возьмём, какой-то редактор (скажем, vim) вообще без плагинов, то это очевидно будет просто текстовый редактор. Затем скажем, что если добавить к виму парочку любых плагинов, то он останется всё ещё текстовым редактором (но уже с плагинами). Если мы продолжим добавлять к нему плагины, то с каждым новым вим будет оставаться редактором, просто с ещё одним плагином. С другой стороны, найдётся такой набор плагинов (скорее всего огромный набор), когда вим по функциональности и возможностям не будет уступать своим братьям, которые точно называются IDE. Если мы удалим из такого полнофункционального вима плагин-два, то он не перестанет быть полноценным IDE, даже если такое повторим несколько раз.
Такой парадокс не работает с ортогональными понятиями и, само собой, предполагается, что любой редактор — это просто маленькая IDE и наоборот. Как-то так.
Давайте скажем, что IDE — это такой вот богатый и многофункциональный способ редактировать файлы и делать что-то ещё в довесок. А текстовый редактор умеет лишь редактировать файлы.
Если мы возьмём, какой-то редактор (скажем, vim) вообще без плагинов, то это очевидно будет просто текстовый редактор. Затем скажем, что если добавить к виму парочку любых плагинов, то он останется всё ещё текстовым редактором (но уже с плагинами). Если мы продолжим добавлять к нему плагины, то с каждым новым вим будет оставаться редактором, просто с ещё одним плагином. С другой стороны, найдётся такой набор плагинов (скорее всего огромный набор), когда вим по функциональности и возможностям не будет уступать своим братьям, которые точно называются IDE. Если мы удалим из такого полнофункционального вима плагин-два, то он не перестанет быть полноценным IDE, даже если такое повторим несколько раз.
Такой парадокс не работает с ортогональными понятиями и, само собой, предполагается, что любой редактор — это просто маленькая IDE и наоборот. Как-то так.
Из рабочей переписки.
«Жаль что те, кто могут управлять разработкой продукта, уже работают тестировщиками, верстальщиками и админами»
«Жаль что те, кто могут управлять разработкой продукта, уже работают тестировщиками, верстальщиками и админами»
Помните идиому с наточкой топора и вырубкой леса? Ну, в которой абстрактному разработчику некогда наточить топор, потому что лес рубить надо. Тут есть и обратная сторона этой проблемы — преждевременная наточка топора. Топор нужно точить, когда будет точно понятно, что затраты на заточку топора будут окупаться скоростью вырубки леса. А для этого нужно:
1. Знать скорость рубки леса тупым топором. Для этого нужно сделать задачу хотя бы один раз до оптимизаций. Городить библиотеку или отдельную абстракцию до того, как написан код в рамках текущих абстракций не стоит.
2. Понимать характеристики топора, чтобы знать что будет после наточки. Второй раз написанное инлайн решение, основанное в рамках текущей архитектуры, вполне даст понять что и куда можно вынести и рефакторить.
3. Знать когда в следующий раз нужно будет точить топор. Вылизывать код до идеального состояния не нужно никогда, а каждый раз, занимаясь рефакторингом, нужно заботиться лишь о прогрессе следующей задачи. Цель — укоротить время разработки этой однотипной задачи в следующий раз, скажем, в два раза.
Есть еще одна схожая популярная идиома, в которой лучше строить целый день самолет и за пять минут долететь, чем бежать целый день. Но топорная и самолетная идиома описывают разные вещи. Топорная говорит об однотипных задачах, а самолетная об рутинных процессах в рамках одной задачи.
#перечитываяэкстраполяцию
1. Знать скорость рубки леса тупым топором. Для этого нужно сделать задачу хотя бы один раз до оптимизаций. Городить библиотеку или отдельную абстракцию до того, как написан код в рамках текущих абстракций не стоит.
2. Понимать характеристики топора, чтобы знать что будет после наточки. Второй раз написанное инлайн решение, основанное в рамках текущей архитектуры, вполне даст понять что и куда можно вынести и рефакторить.
3. Знать когда в следующий раз нужно будет точить топор. Вылизывать код до идеального состояния не нужно никогда, а каждый раз, занимаясь рефакторингом, нужно заботиться лишь о прогрессе следующей задачи. Цель — укоротить время разработки этой однотипной задачи в следующий раз, скажем, в два раза.
Есть еще одна схожая популярная идиома, в которой лучше строить целый день самолет и за пять минут долететь, чем бежать целый день. Но топорная и самолетная идиома описывают разные вещи. Топорная говорит об однотипных задачах, а самолетная об рутинных процессах в рамках одной задачи.
#перечитываяэкстраполяцию
👍1
Продолжая вчерашнюю тему, в игре X-Com на высоких сложностях и без права на ошибку, самое главное — чтобы в твою сторону не стреляли вообще, потому что если будут стрелять, то иногда будут попадать.
Так вот, один из главных инструментов — это ранжирование целей по степени угрозы, и тут есть забавное. Чем больше у противника разнообразных способностей, тем ниже он для тебя стоит в списке угрожающих тебе целей. Например, если стоит сектоид, офицер и солдат, убить надо солдата, потому что солдат будет в тебя стрелять. Офицер наложит метку, повышающую шанс попасть по твоему бойцу, а сектоид что-нибудь сколдует — скажем, восстановит убитого тобой солдата в виде зомби. И таким образом ты переживёшь ход без стрельбы в твою сторону, нанеся в процессе какой-то урон противнику.
Возвращаясь к топору и программированию. Выходит, чем дольше ты точишь топор, тем дольше твой тикет в безопасности. И получается, что наиболее безопасны для работы парни, которые знают очень много разных способов заточки топора.
#dimoneverything
Так вот, один из главных инструментов — это ранжирование целей по степени угрозы, и тут есть забавное. Чем больше у противника разнообразных способностей, тем ниже он для тебя стоит в списке угрожающих тебе целей. Например, если стоит сектоид, офицер и солдат, убить надо солдата, потому что солдат будет в тебя стрелять. Офицер наложит метку, повышающую шанс попасть по твоему бойцу, а сектоид что-нибудь сколдует — скажем, восстановит убитого тобой солдата в виде зомби. И таким образом ты переживёшь ход без стрельбы в твою сторону, нанеся в процессе какой-то урон противнику.
Возвращаясь к топору и программированию. Выходит, чем дольше ты точишь топор, тем дольше твой тикет в безопасности. И получается, что наиболее безопасны для работы парни, которые знают очень много разных способов заточки топора.
#dimoneverything
Вы только представляете? Собирались лишить глаз только за то, что она робот! Это же не расизм, потому что у робота нет расы. И не феминизм, потому что у робота нет пола. Роботизм? Нам срочно надо отдельное слово какое-то для такого.
https://tjournal.ru/news/459178
https://tjournal.ru/news/459178
TJ
В Египте на десять дней задержали робота-художницу. Власти думали, что она шпионка — Новости на TJ
Пограничники хотели извлечь камеры из глаз Ай-Ды, с помощью которых она рисует.
По аналогии с термином «пуленепробиваемый дизайн», сформулируем «пуленепробиваемый код».
Ну вот, написали вы некую функциональность. Она была написана за один присест, поэтому выглядит очень лаконично и солидно, что прям хвастаться можно. Но буквально спустя дюжину изменений этот код не узнать — он ужасен и воняет. Каждое изменение привнесло в этот код какой-то дополнительный костыль, что-то такое инородное или какую-то дополнительную функциональность, которая лежит как бы сбоку, не задевая того, что было написано до этого. В результате на код страшно смотреть.
А бывает заморочились вначале и придумали такую архитектуру, в которой все последующие изменения идут как по маслу. Даже те, о которых и думать не думали. Да, заморочиться вначале нужно больше, но эффект не заставит себя ждать.
Это и есть пуленепробиваемый код.
Критериев и признаков такого кода много. Опустим такие банальные штуки, вроде «понятен при прочтении», «делает только одно действие» и тому подобное. Есть и вполне практичные штуки, описанные не в одной книге, на подобии «глобальные переменные это плохо» или «чистые функции это хорошо», о них тоже упомянем вскользь.
Самое главное что нужно помнить — код должен быть устойчивым к изменениям. Ну, в том смысле, что если код начнут менять или рефакторить, то это не будет увеличивать энтропию в кодовой базе. Иначе говоря, не добавит говна в проект.
#перечитываяэкстраполяцию
Ну вот, написали вы некую функциональность. Она была написана за один присест, поэтому выглядит очень лаконично и солидно, что прям хвастаться можно. Но буквально спустя дюжину изменений этот код не узнать — он ужасен и воняет. Каждое изменение привнесло в этот код какой-то дополнительный костыль, что-то такое инородное или какую-то дополнительную функциональность, которая лежит как бы сбоку, не задевая того, что было написано до этого. В результате на код страшно смотреть.
А бывает заморочились вначале и придумали такую архитектуру, в которой все последующие изменения идут как по маслу. Даже те, о которых и думать не думали. Да, заморочиться вначале нужно больше, но эффект не заставит себя ждать.
Это и есть пуленепробиваемый код.
Критериев и признаков такого кода много. Опустим такие банальные штуки, вроде «понятен при прочтении», «делает только одно действие» и тому подобное. Есть и вполне практичные штуки, описанные не в одной книге, на подобии «глобальные переменные это плохо» или «чистые функции это хорошо», о них тоже упомянем вскользь.
Самое главное что нужно помнить — код должен быть устойчивым к изменениям. Ну, в том смысле, что если код начнут менять или рефакторить, то это не будет увеличивать энтропию в кодовой базе. Иначе говоря, не добавит говна в проект.
#перечитываяэкстраполяцию
Уж не знаю как на счет прошлой заметки, с несьъедобными грибами, но эта ошибка наверняка была с последствиями.
Пора уже постоянную рубрику делать в Экстраполяции. Назовём её #продакшенхотфикс
Пора уже постоянную рубрику делать в Экстраполяции. Назовём её #продакшенхотфикс