Итак. Получилось так, что я подзабил на затею с каналом. Навалились повседневные дела, работа. Переехал в Петербург, сменил работу. И недавно коллега убедил меня вернуться к каналу. Но формат будет несколько другим. Без сложных и длинных заметок. Выводы, сделанные мной из книг, что читаю сейчас. Статьи, которые показались интересными. Возможно, разбор проблем, с которыми сталкиваюсь в работе.
Дисклеймер. Я все еще не претендую на авторитет. Все написанное в канале личное мнение одного не очень умного человека.
Дисклеймер. Я все еще не претендую на авторитет. Все написанное в канале личное мнение одного не очень умного человека.
Сейчас читаю "Программист-фанатик".
За первую треть книжки больше всего тронула такая мысль.
Следует посчитать, сколько ты стоишь своему работодателю. Не только зарплата. Аренда офиса, амортизация компьютера, печеньки в офисе, да что угодно. А потом подумать, сколько денег ты приносишь ему взамен.
И думать об этом каждый день, когда программируешь программирование. Сколько ты стоил сегодня? А сколько принес компании? Если первое больше второго — значит нужно работать иначе.
Это заставило меня изменить подход к коду. Я хочу чтобы построенные мной приложения были красивыми. Но разве красота приносит деньги заказчику? Нет. Простота поддержки и модификации, скорость работы, отказоустойчивость. Вот что должно быть важно разработчику.
#программист_фанатик
За первую треть книжки больше всего тронула такая мысль.
Следует посчитать, сколько ты стоишь своему работодателю. Не только зарплата. Аренда офиса, амортизация компьютера, печеньки в офисе, да что угодно. А потом подумать, сколько денег ты приносишь ему взамен.
И думать об этом каждый день, когда программируешь программирование. Сколько ты стоил сегодня? А сколько принес компании? Если первое больше второго — значит нужно работать иначе.
Это заставило меня изменить подход к коду. Я хочу чтобы построенные мной приложения были красивыми. Но разве красота приносит деньги заказчику? Нет. Простота поддержки и модификации, скорость работы, отказоустойчивость. Вот что должно быть важно разработчику.
#программист_фанатик
Как посчитать сколько денег ты приносишь не понимая специфики бизнеса?
А никак. Но программист (хороший программист) должен разбираться в бизнесе на который он работает.
Подход "я просто превращаю таски в код" — больной. Нужно приносить пользу, решать задачи бизнеса. Для этого нужно его понимать.
Тогда и посчитать сколько приносишь денег получиться.
#программист_фанатик
А никак. Но программист (хороший программист) должен разбираться в бизнесе на который он работает.
Подход "я просто превращаю таски в код" — больной. Нужно приносить пользу, решать задачи бизнеса. Для этого нужно его понимать.
Тогда и посчитать сколько приносишь денег получиться.
#программист_фанатик
"Нет"
Эта мысль встретилась не только в "Программисте-фанатике", но и в "Идеальном программмсте".
Нужно уметь отказывать начальству.
Это повышает ценность согласия.
Если приходит босс и требует странного, невозможного или глупого, следует сказать ему "нет". Нельзя брать обязательства которые невозможно выполнить или которые повредят продукту.
Программист, который всегда говорит "да" либо очень умён, либо постоянно врёт. Чаще все же врёт. Нужно быть честным. Соглашаться взять на себя обязательства только если уверен, что их можно выполнить в установленный срок.
Компании нанимают специалистов, чтобы получить их знания. Часто разработчик знает лучше, что нужно использовать в конкретной ситуации. И потому иногда на идею босса нужно ответить "нет" и объяснить ему, почему он не прав.
Тонкая грань. Нужно не переусердствовать. Исполнительность важна!
#программист_фанатик #идеальный_программист
Эта мысль встретилась не только в "Программисте-фанатике", но и в "Идеальном программмсте".
Нужно уметь отказывать начальству.
Это повышает ценность согласия.
Если приходит босс и требует странного, невозможного или глупого, следует сказать ему "нет". Нельзя брать обязательства которые невозможно выполнить или которые повредят продукту.
Программист, который всегда говорит "да" либо очень умён, либо постоянно врёт. Чаще все же врёт. Нужно быть честным. Соглашаться взять на себя обязательства только если уверен, что их можно выполнить в установленный срок.
Компании нанимают специалистов, чтобы получить их знания. Часто разработчик знает лучше, что нужно использовать в конкретной ситуации. И потому иногда на идею босса нужно ответить "нет" и объяснить ему, почему он не прав.
Тонкая грань. Нужно не переусердствовать. Исполнительность важна!
#программист_фанатик #идеальный_программист
Основная идея книги — нужно быть выдающимся программистом.
Одна из важных составляющих — никогда не стыдиться сделанной работы. Даже если ты ведёшь проект отвратительного легаси, нужно сделать усилие, потратить свое время, но сделать в нем что-то, чем можно гордиться.
В проекте все собирается ручным трудом программистов? Значит нужно настроить автоматизированные сборки, зафигачить все это на CI и гордиться этим.
В проекте совсем нет тестов? Значит нужно стать евангелистом тестирования и покрыть тестами все, до чего можно дотянуться.
Зависимости проекта не обновляли с 1970 года? Значит нужно пойти и перевести все компоненты на современные технологии и обеспечить работоспособность.
Нельзя делать работу, которой будешь стыдиться.
#программист_фанатик
Одна из важных составляющих — никогда не стыдиться сделанной работы. Даже если ты ведёшь проект отвратительного легаси, нужно сделать усилие, потратить свое время, но сделать в нем что-то, чем можно гордиться.
В проекте все собирается ручным трудом программистов? Значит нужно настроить автоматизированные сборки, зафигачить все это на CI и гордиться этим.
В проекте совсем нет тестов? Значит нужно стать евангелистом тестирования и покрыть тестами все, до чего можно дотянуться.
Зависимости проекта не обновляли с 1970 года? Значит нужно пойти и перевести все компоненты на современные технологии и обеспечить работоспособность.
Нельзя делать работу, которой будешь стыдиться.
#программист_фанатик
В "Идеальном программисте" дядя Боб рассказывает о концепции "ката". Упражнения для разработчиков, которые позволяют натренировать пальцы на решения простых повседневных задач.
Хороший ресурс с набором таких упражнений по JS — http://es6katas.org/
#идеальный_программист #js
Хороший ресурс с набором таких упражнений по JS — http://es6katas.org/
#идеальный_программист #js
Часто сталкиваюсь с тем, что свеже-обращенные разработчики считают Redux какой-то магией и отказываются понимать, как он работает. Убежден, что единственный способ понять что-то — сделать это руками.
Отличная статья по теме:
“Изучаем Redux на примере создания мини-Redux” @NTolochny https://medium.com/devschacht/jakob-lind-learn-redux-by-coding-a-mini-redux-d1a58e830514
#js
Отличная статья по теме:
“Изучаем Redux на примере создания мини-Redux” @NTolochny https://medium.com/devschacht/jakob-lind-learn-redux-by-coding-a-mini-redux-d1a58e830514
#js
Medium
Изучаем Redux на примере создания мини-Redux
Перевод статьи Jakob Lind: Learn Redux by coding a Mini-Redux
Самое крутое что случилось с CSS за последние годы — флекс боксы и кастом пропертис.
Простое и короткое введение в CSS-переменные (они же — кастом пропертис):
“Изучите CSS-переменные за 5 минут” https://medium.com/devschacht/%D0%B8%D0%B7%D1%83%D1%87%D0%B8%D1%82%D0%B5-css-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B7%D0%B0-5-%D0%BC%D0%B8%D0%BD%D1%83%D1%82-3a5dc6193857
#css
Простое и короткое введение в CSS-переменные (они же — кастом пропертис):
“Изучите CSS-переменные за 5 минут” https://medium.com/devschacht/%D0%B8%D0%B7%D1%83%D1%87%D0%B8%D1%82%D0%B5-css-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B7%D0%B0-5-%D0%BC%D0%B8%D0%BD%D1%83%D1%82-3a5dc6193857
#css
Medium
Изучите CSS-переменные за 5 минут
Перевод статьи Per Harald Borgen: Learn CSS Variables in 5 minutes.
Наверно, самые большие проблемы в первые месяцы работы разработчики испытывают с гитом.
Не нужно бояться гита! Это простой и надёжный инструмент. Две тематические статьи. Первая — обзорная, вторая — что делать, если "все сломалось".
+ Git снизу вверх: https://habr.com/post/344962/
+ Git: распространненные ошибки и способы их исправления: https://habr.com/post/423015/
#git
Не нужно бояться гита! Это простой и надёжный инструмент. Две тематические статьи. Первая — обзорная, вторая — что делать, если "все сломалось".
+ Git снизу вверх: https://habr.com/post/344962/
+ Git: распространненные ошибки и способы их исправления: https://habr.com/post/423015/
#git
Хабр
Git снизу вверх
У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто,...
Круто быть разработчиком. Не фронтендером, бекендером или верстальщиком.
Не важно в какой области разработки лежит проблема бизнеса — ее нужно решить.
И многие проблемы бизнеса связаны с доставкой приложения до клиента, масштабированием. Последние годы они решаются с помощью докера.
Любому разработчику будет полезно понимать, что это, как этим пользоваться и зачем оно нужно. Ниже тематическая статья.
“Docker для начинающего разработчика” https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d
#docker
Не важно в какой области разработки лежит проблема бизнеса — ее нужно решить.
И многие проблемы бизнеса связаны с доставкой приложения до клиента, масштабированием. Последние годы они решаются с помощью докера.
Любому разработчику будет полезно понимать, что это, как этим пользоваться и зачем оно нужно. Ниже тематическая статья.
“Docker для начинающего разработчика” https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d
#docker
Medium
Docker для начинающего разработчика
Docker стремительно ворвался в мир контейнеров и за пару лет из надстройки над LXC развился в систему запуска, окрестрирования…
Начал читать "Предметро-ориентированное проектирование" Эванса.
Основная сложность программ сосредоточена в предметной области, а не в коде. Следует строить архитектуру приложения на основе модели предметной области.
#ddd
Основная сложность программ сосредоточена в предметной области, а не в коде. Следует строить архитектуру приложения на основе модели предметной области.
#ddd
Для построения надёжных приложений важно разрабатывать их итеративно и в тесном взаимодействии со специалистами предметной области (представителями бизнеса).
#ddd
#ddd
Модель должна строиться во взаимодействии разработчиков и представителей бизнеса. Нужно сесть и определить, что должна делать программа. В процессе следует вырабатывать общий язык, на котором будут формулироваться все штуки связанные с приложением.
Два важных момента:
+ Взаимодействие технических специалистов и представителей бизнеса.
+ Общий язык.
#ddd
Два важных момента:
+ Взаимодействие технических специалистов и представителей бизнеса.
+ Общий язык.
#ddd
Общий язык должен быть повсюду. Термины, их взаимосвязи. Он должен быть отражены в документации, коде, переписке и устном общении.
Если в коде мы называем управляющего магазином "Управляющий", значит такой же термин мы будем использовать обсуждая с заказчиком систему.
Этот язык не следует насаживать. Нужно вырабатывать его совместно. При этом, он может эволюционировать. И тогда нужно приводить все к новым терминам. Затраты не переименования класса — мелочь по сравнению с непониманием, возникающим из-за разных терминов.
#ddd
Если в коде мы называем управляющего магазином "Управляющий", значит такой же термин мы будем использовать обсуждая с заказчиком систему.
Этот язык не следует насаживать. Нужно вырабатывать его совместно. При этом, он может эволюционировать. И тогда нужно приводить все к новым терминам. Затраты не переименования класса — мелочь по сравнению с непониманием, возникающим из-за разных терминов.
#ddd
Тесты — это не просто полезно или важно. Это необходимо. Без тестов большие системы перестают быть управляемыми.
“Тесты, которые должен писать разработчик” @ArturBasak https://medium.com/@arturbasak/%D1%82%D0%B5%D1%81%D1%82%D1%8B-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5-%D0%B4%D0%BE%D0%BB%D0%B6%D0%B5%D0%BD-%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA-a04cab35f45b
#tests
“Тесты, которые должен писать разработчик” @ArturBasak https://medium.com/@arturbasak/%D1%82%D0%B5%D1%81%D1%82%D1%8B-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5-%D0%B4%D0%BE%D0%BB%D0%B6%D0%B5%D0%BD-%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA-a04cab35f45b
#tests
Medium
Тесты, которые должен писать разработчик
“После каждого исправления ошибки нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше”
Нельзя отрывать модель от реализации. Придумали модель, но в коде она не используется? Значит она ничего не стоит.
Те, что думают над моделью должны писать код. Те, кто пишет код, должны думать над моделью.
Нельзя допускать до кода человека, не погруженного в предметную область.
#ddd
Те, что думают над моделью должны писать код. Те, кто пишет код, должны думать над моделью.
Нельзя допускать до кода человека, не погруженного в предметную область.
#ddd