Фатальный недостаток.
Есть у программистов черта, отличающая их от представителей других видов деятельности. А именно жуткая неприязнь к работе, выполненной другими программистами. Я уверен, у любого из вас, как и у меня, имея дело с чужим кодом возникал непреодолимый соблазн удалить все и переписать заново. Для этого есть даже специальный термин - "Фатальный недостаток" (недостаток чужого кода в том, что он чужой).
Благодаря склонности разработчиков видеть "фатальные недостатки" в уже существующих проектах, программные системы часто переписываются "с нуля", что является распространенной в индустрии ошибкой, ведь не меняя подходов к разработке и условий, новый код никогда не будет лучше старого.
http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA
Есть у программистов черта, отличающая их от представителей других видов деятельности. А именно жуткая неприязнь к работе, выполненной другими программистами. Я уверен, у любого из вас, как и у меня, имея дело с чужим кодом возникал непреодолимый соблазн удалить все и переписать заново. Для этого есть даже специальный термин - "Фатальный недостаток" (недостаток чужого кода в том, что он чужой).
Благодаря склонности разработчиков видеть "фатальные недостатки" в уже существующих проектах, программные системы часто переписываются "с нуля", что является распространенной в индустрии ошибкой, ведь не меняя подходов к разработке и условий, новый код никогда не будет лучше старого.
http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA
Lurkmore
Фатальный недостаток
Фатальный недостаток — локальный мем айтишной тусовки. Вкратце означает, что кто-то от нежелания платить за авторские права, ЧСВ, зависти, скуки (или просто выгнали) решает сделать что-то своё, только с блекджеком и шлюхами. Как правило, в результате очередное…
Чему чебуречная "Советские времена" может научить разработчика?
То ли из-за фантомной ностальгии по временам, которых никогда не было, то ли из-за отсутствия добротных едален в центре Москвы повадились мы с коллегами посещать чебуречную "Советские времена". Кормят там сносно, да и чебуреки добротные. А если не обращать внимания на лики вождей и стены кумачового цвета, то и вообще можно отдать звание лучшего места для обеда за свои деньги.
Так вот в чебуречной этой довольно элегантно решена проблема нумерации заказываемых обедов. Первому человеку кассир на чеке пишет, например, номер 20, второму 21, третьему 22 и так далее. Иногда двум идущим подряд людям достаются одинаковые номера, но так как люди эти скорее всего из одной компании, при выдаче обеда они могут легко разобраться где чей.
Дело все в том, что кассир выбирает какой номер присвоить заказу просто взглянув на количество минут на электронных часах! Так как человек в процессе выбора блюда, оплаты тратит около минуты, коллизии случаются относительно редко и не столь критичны, люди могут легко получить информацию о готовности обеда, а главное не написано ни единой строки кода!
И вот вроде бы все прекрасно, система работает, на разработку и внедрение не потратили ни рубля, не хороший ли это пример для проектировщика программных систем? Ну разве что для тех случаев, когда код писать не хочется (не успевается), а показать что-либо нужно. А вообще, конечно, принцип единой ответственности придумали не просто так, и часами должны пользоваться для получения времени, а для заказов нужен отдельный каунтер.
То ли из-за фантомной ностальгии по временам, которых никогда не было, то ли из-за отсутствия добротных едален в центре Москвы повадились мы с коллегами посещать чебуречную "Советские времена". Кормят там сносно, да и чебуреки добротные. А если не обращать внимания на лики вождей и стены кумачового цвета, то и вообще можно отдать звание лучшего места для обеда за свои деньги.
Так вот в чебуречной этой довольно элегантно решена проблема нумерации заказываемых обедов. Первому человеку кассир на чеке пишет, например, номер 20, второму 21, третьему 22 и так далее. Иногда двум идущим подряд людям достаются одинаковые номера, но так как люди эти скорее всего из одной компании, при выдаче обеда они могут легко разобраться где чей.
Дело все в том, что кассир выбирает какой номер присвоить заказу просто взглянув на количество минут на электронных часах! Так как человек в процессе выбора блюда, оплаты тратит около минуты, коллизии случаются относительно редко и не столь критичны, люди могут легко получить информацию о готовности обеда, а главное не написано ни единой строки кода!
И вот вроде бы все прекрасно, система работает, на разработку и внедрение не потратили ни рубля, не хороший ли это пример для проектировщика программных систем? Ну разве что для тех случаев, когда код писать не хочется (не успевается), а показать что-либо нужно. А вообще, конечно, принцип единой ответственности придумали не просто так, и часами должны пользоваться для получения времени, а для заказов нужен отдельный каунтер.
О чем спорят программисты?
Мир разработки программного обеспечения многополярен. В нашем распоряжении сотни языков программирования, десятки виртуальных машин, фреймворков и библиотек для решения всевозможных задач, несколько методологий и ворох операционных систем. Все это вызывает огромное количество пересудов между адептами тех или иных технологий, что ведёт к сильной технологикоцентричности большинства споров разработчиков. Их можно понять, ведь на изучение очередного фреймворка нужно потратить иной раз огромное количество часов собственной жизни, что не может не приводить к некоторой привязанности, но не стоит забывать, что действительно важные аспекты разработки это чистая архитектура, грамотное проектирование и расстановка четких границ между компонентами, а споры должны отвечать лишь на вопрос: помогают ли ваши средства добиться этих целей?
Также нужно уметь иногда отвлекаться от программирования и сидя в пятницу вечером в баре в компании друзей выбирать для споров более приятные темы, вроде актерского мастерства пассии Бергмана в каждом из его фильмов или, например, вкусовые качества тайваньских улунов по сравнению с южнофундзянскими.
Мир разработки программного обеспечения многополярен. В нашем распоряжении сотни языков программирования, десятки виртуальных машин, фреймворков и библиотек для решения всевозможных задач, несколько методологий и ворох операционных систем. Все это вызывает огромное количество пересудов между адептами тех или иных технологий, что ведёт к сильной технологикоцентричности большинства споров разработчиков. Их можно понять, ведь на изучение очередного фреймворка нужно потратить иной раз огромное количество часов собственной жизни, что не может не приводить к некоторой привязанности, но не стоит забывать, что действительно важные аспекты разработки это чистая архитектура, грамотное проектирование и расстановка четких границ между компонентами, а споры должны отвечать лишь на вопрос: помогают ли ваши средства добиться этих целей?
Также нужно уметь иногда отвлекаться от программирования и сидя в пятницу вечером в баре в компании друзей выбирать для споров более приятные темы, вроде актерского мастерства пассии Бергмана в каждом из его фильмов или, например, вкусовые качества тайваньских улунов по сравнению с южнофундзянскими.
О чем кричит ваша архитектура?
Посмотрите на структуру вашего проекта. О чем кричит организация модулей и пакетов? В подавляющем большинстве будет что-то такое:
- контроллеры!
- сервисы!
- репозитории!
- я проект на Spring! (Node, Django, Grails нужное вставить)
А должно быть так:
- я система банковских транзакции!
- я социальная сеть!
- я почтовый сервис!
Заставьте вашу архитектуру кричать о своем предназначении.
Посмотрите на структуру вашего проекта. О чем кричит организация модулей и пакетов? В подавляющем большинстве будет что-то такое:
- контроллеры!
- сервисы!
- репозитории!
- я проект на Spring! (Node, Django, Grails нужное вставить)
А должно быть так:
- я система банковских транзакции!
- я социальная сеть!
- я почтовый сервис!
Заставьте вашу архитектуру кричать о своем предназначении.
Clean architecture by Uncle Bob
Только что дочитал "Clean architecture" Роберта Мартина. Абсолютный мастрид для любого разработчика (после "Clean code" естественно). Книга о самом важном в разработке, о том, что превращает ее из обыкновенного кодирования в область тонкого искусства, об уменьшении сложности, расстановке зависимостей и границ, о том, зачем нужны микросервисы и как не жениться на фреймворке
Только что дочитал "Clean architecture" Роберта Мартина. Абсолютный мастрид для любого разработчика (после "Clean code" естественно). Книга о самом важном в разработке, о том, что превращает ее из обыкновенного кодирования в область тонкого искусства, об уменьшении сложности, расстановке зависимостей и границ, о том, зачем нужны микросервисы и как не жениться на фреймворке
Что такое технический долг?
Техдолг это накопившиеся задачи решение которых напрямую не влияет на работу системы, но их наличие пропорционально увеличивает стоимость ее разработки.
Данное определение лучше помогает обосновать необходимость тратить неделю лучшего разработчика на автоматизацию деплоя или выделение зависимостей компонента. Просто работа других разработчиков будет стоить дешевле!
Техдолг это накопившиеся задачи решение которых напрямую не влияет на работу системы, но их наличие пропорционально увеличивает стоимость ее разработки.
Данное определение лучше помогает обосновать необходимость тратить неделю лучшего разработчика на автоматизацию деплоя или выделение зависимостей компонента. Просто работа других разработчиков будет стоить дешевле!
О фронтенде
От своего руководителя, который успел побыть фуллстек-разработчиком сегодня услышал следующее:
"Сначала фронтенд был небольшой, простой частью приложения на джаваскрипте, затем он стал сложнее, затем он перерос в отдельную вселенную, а потом эта вселенная взорвалась"
От своего руководителя, который успел побыть фуллстек-разработчиком сегодня услышал следующее:
"Сначала фронтенд был небольшой, простой частью приложения на джаваскрипте, затем он стал сложнее, затем он перерос в отдельную вселенную, а потом эта вселенная взорвалась"
Что такое DevOps?
На позапрошлый пост мне сделали замечание, мол автоматизировать деплой должны не разработчики, а некие девопсы. Что же это за люди такие? Давайте разбираться.
В статьях с определением DevOps чаще всего фигурируют такие слова, как agile-практика, философия, набор методик для достижения синергии между людьми из разных сфер: разработчиков (Developers) и специалистов сопровождения (Operations), вовлечение и понимание процессов друг друга и совместное планирование релизов.
Для разработчика в компании, использующей DevOps, подразумевается владение такими навыками, как CI/CD, контейнеризация, оркестрация и продвинутое использование серверной ОС. То есть помимо написания кода нужно также иметь полное представление о том, как этот код доходит до пользователя.
В DevOps не подразумевается (!) наличие в команде продвинутого админа, зовущегося DevOps-инженером, который владеет вышеперечисленным. Такой подход как раз говорит о полном отсутствии DevOps культуры.
Поэтому отвечая на замечание хочу сказать, что если уж и использовать слово DevOps в качестве обозначения некоторой роли, то роль эту должны примерять на себя именно разработчики, в том числе занимаясь и автоматизацией деплоя.
На позапрошлый пост мне сделали замечание, мол автоматизировать деплой должны не разработчики, а некие девопсы. Что же это за люди такие? Давайте разбираться.
В статьях с определением DevOps чаще всего фигурируют такие слова, как agile-практика, философия, набор методик для достижения синергии между людьми из разных сфер: разработчиков (Developers) и специалистов сопровождения (Operations), вовлечение и понимание процессов друг друга и совместное планирование релизов.
Для разработчика в компании, использующей DevOps, подразумевается владение такими навыками, как CI/CD, контейнеризация, оркестрация и продвинутое использование серверной ОС. То есть помимо написания кода нужно также иметь полное представление о том, как этот код доходит до пользователя.
В DevOps не подразумевается (!) наличие в команде продвинутого админа, зовущегося DevOps-инженером, который владеет вышеперечисленным. Такой подход как раз говорит о полном отсутствии DevOps культуры.
Поэтому отвечая на замечание хочу сказать, что если уж и использовать слово DevOps в качестве обозначения некоторой роли, то роль эту должны примерять на себя именно разработчики, в том числе занимаясь и автоматизацией деплоя.
Медитации
В условиях современного ритма жизни, постоянных стрессов и большого количества информационных потоков важно правильно управлять мысленными и энергетическими ресурсами. Для этого необходимо развитие такого качества, как осознанность. Осознанность это привлечение внимания к внутренним процессам психики - мыслям и эмоциям, к состоянию организма и нашим действиям. Осознанность помогает научиться ладить с чуством тревоги, правильно подходить к вопросам питания, сна и отдыха, а главное эффективно пользоваться своими энергоресурсами.
Одна из главных практик для достижения осознанности это медитация. Многие относятся к медитации, как к сакральной эзотерической практике, доступной лишь продвинутым духовным мастерам, но на самом деле это довольно простая штука, требующая около десяти минут в день и начать медитировать может каждый без каких-либо предварительных навыков.
В этом посте хотел бы не на правах рекламы (так как рекламодатели не особо заинтересованы в каналах на 11 человек) порекомендовать приложение для медитаций Headspace. В нем, начиная с вводного курса, можно легко научиться медитировать и повышать осознанность, наблюдая пользу для себя уже с первых дней.
В условиях современного ритма жизни, постоянных стрессов и большого количества информационных потоков важно правильно управлять мысленными и энергетическими ресурсами. Для этого необходимо развитие такого качества, как осознанность. Осознанность это привлечение внимания к внутренним процессам психики - мыслям и эмоциям, к состоянию организма и нашим действиям. Осознанность помогает научиться ладить с чуством тревоги, правильно подходить к вопросам питания, сна и отдыха, а главное эффективно пользоваться своими энергоресурсами.
Одна из главных практик для достижения осознанности это медитация. Многие относятся к медитации, как к сакральной эзотерической практике, доступной лишь продвинутым духовным мастерам, но на самом деле это довольно простая штука, требующая около десяти минут в день и начать медитировать может каждый без каких-либо предварительных навыков.
В этом посте хотел бы не на правах рекламы (так как рекламодатели не особо заинтересованы в каналах на 11 человек) порекомендовать приложение для медитаций Headspace. В нем, начиная с вводного курса, можно легко научиться медитировать и повышать осознанность, наблюдая пользу для себя уже с первых дней.
