Разработчики часто сталкиваются с проблемами и задачами, которые имеют типовое решение. Именно такие решения описывают шаблоны проектирования.

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

Забавно было видеть те паттерны, которые я использовал, и даже не знал, что для них есть название. Я пришел к ним сам.

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

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

Парочка полезных ссылок по теме:

https://sourcemaking.com/design_patterns/ — в свое время меня очень впечатлил сайт. Все просто и понятно.

https://martinfowler.com/articles/enterprisePatterns.html — ну и конечно же контент от мэтра софтварной разработки, Мартина Фаулера

Забавно, обычно не люблю такие статьи, но, как по мне, так довольно точная классификация программистов. Слава богу мне не приходилось работать с пассажирами. Найдёте ли вы себя там?
https://habrahabr.ru/post/336248/

Вы когда нибудь слышали про Game Jam?

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

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

Получается сырой проект, полный багов. Но очень, очень интересный.

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

Это один из способов воплотить самые безумные идеи.
Это возможность попробовать самые смелые механики.
Это крутой тимбилдинг, в конце концов!

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

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

https://ru.wikipedia.org/wiki/Game_Jam

Число разработчиков растет

Похоже что coding bootcamps все набирают популярность. На западе — больше, чем у нас. Тем не менее.

Что же это может значить? Думаю то, что программирование набирает популярность. Многие хотят такой jump start. Чтобы вжух — и ты работаешь девелопером.

Проблема заключается в том, что не возможно за несколько месяцев освоить наше ремесло. Нужно постоянно учиться.

Количество разработчичков растет. Посмотрите на эту интересную инфографику выше https://teleg.eu/poisonous_johns_lair/21.

Что тому причина? Высокий оклад? Востребованность? Успех стартапов Whatsapp, Uber и прочих?

Я боюсь что наши ряды пополнят люди, которых интересуют только деньги. Люди у которых не горят глаза. Люди, которые не будут заморачиваться над тем что и КАК они делают.

Резкий рост неопытных разработчиков может быть проблемой. Ведь в идеале, на каждого неопытного разработчика — должен быть старший, который обучит его ремеслу.

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

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

Вот такие вот у меня двоякие чувства.

Компания Apple сделала очередной неожиданный для меня ход — заопенсорсила ядро iOS и macOS.
Значит ли это, что Apple, вслед за Microsoft, пойдет по пути Open Source?

На самом деле, это не первый их шаг в сторону открытого ПО. WebKit и Swift — довольно известные опенсорсные продукты.

https://techcrunch.com/2017/10/01/apple-open-sourced-the-kernel-of-ios-and-macos-for-arm-processors/

Привет!

У меня много мыслей, которыми я хотел бы поделиться, но все они на разные темы.

Какую тему вы бы предпочли преимущественно видеть на этом канале?

Пожалуйста используйте ссылку ниже, чтобы проголосовать. Не забудьте нажать Start :).

/1. 🎮 Game Development
/2. 👍 Software Development (Quality of Code, Best Practices, Architecture)
/3. 🤔 Career Advices (как быть хорошим разработчиком)
/4. 📃 Новости в индустрии (компании, технологии, библиотеки и т.д.)
/5. ☝️Философские рассуждения на тему жизни разработчика, роли технологий, будущего и т.д.

http://telegram.me/PollBot?start=LTE4ODIxMTE4OTo1NWJlMzBhMzliYmJkMDE4Mg==

Итак, в голосовании победила тема Software Development, поэтому основная часть моих постов будет посвящена именно ей.

Сегодня я хотел дать вам пищу для размышлений на тему разработки архитектуры ваших программных продуктов.

Как часто вы занимаетесь разработкой архитектуры?
Нет, серьезно! Как часто вы выделяете отдельную задачу по разработке архитектуры?

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

> Хороший продукт не делается в спешке.

Если вы беретесь за важную, большую фичу, вы отвечаете не только за ее разработку, но и за ее здоровье и дальнейшую жизнь.

Что я понимаю под здоровьем? Давайте рассмотрим пример.

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

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

Конечно же — это палка о двух концах. Но, думаю, идея понятна.

Как же избежать подобных ситуаций?

- Выделяйте время на проектирование архитектуры — да-да, это важно! Создайте себе отдельную задачу, согласуйте ее с менеджером. Поясните зачем это нужно. На выходе постарайтесь получить документ, который описывает почему вы приняли то или иное решение по архитектуре. Это поможет другим людям понять ход ваших мыслей и подхватить, в случае чего, вашу работу.
- Максимально декомпозируйте задачи — это поможет не упустить мелкие (но ресурсоемкие) детали и все уложить в голове
- Привлекайте коллег на ревью архитектуры — ведь коллеги могут увидеть то, чего не увидели вы. Могут задать неудобные вопросы, проверяя вашу архитектуру (да и вас) на прочность. Полезно привлекать коллег из других департаментов. Например, проектировать серверную архитектуру, подключая клиентских разработчиков, и наоборот. Это поможет быть "на одной волне", и прийти к согласию во многих моментах, таких как модели данных.


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

Чем чаще такие ревью будут проходить, тем легче будет править проблемные места.
Если вы наткнулись на место, вызывающее трудности, недостаточно просто написать коммент

// refactor this mess.

- Создайте отдельную задачу с предложением варианта устранения проблемы.
- Поставьте менеджера в известность и обозначьте возможные риски (желательно упоминая насколько это опасно для бизнеса)
- Запланируйте время для работы над этой задачей. Если задача будет просто валяться в бэклоге, пользы от этого не будет.
- Делайте регулярное ревью пула задач по устранению технического долга.

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

Разработчик должен уметь доносить информацию до "бизнес-людей". В этом нет ничего страшного. Более того — это один из ключевых навыков.

Наткнулся на интересную презентацию про монады:

https://www.youtube.com/watch?time_continue=1461&v=vkcxgagQ4bM

Популярность функционального программирования (ФП) растет. Когда я беседую с адептами ФП, практически всегда от них исходит элитизм и толика презрения. Мол как можно использовать Объектно-ориентированное программирование (ООП), вот уж ересь какая.

Интересно, чем же ФП лучше? На самом деле ничем. ООП и ФП — парадигмы. Это просто инструменты. И применение инструмента — зависит от задачи. Не нужно все доводить до крайности. Программирование — не религия. На этот счет есть перевод неплохой статьи:

https://habrahabr.ru/post/201874/

Я считаю, что хороший профессионал должен уметь обращаться со всеми доступными ему инструментами. А это значит, что если вы пишите, в основном, ООП код, вам нужно познакомиться с ФП. И наоборот.

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

Но вопрос монад такой же спорный. Это тоже инструмент. И он не всегда уместен. Как по мне, так работа с коллекциями в C# с помощью монад LINQ очень удобна. Так же я считаю неплохой концепт у RxJava. Идея для использования архитектуры для UI а-ля redux, у меня проскакивала и до знакомства с ФП. А вот программирование асинхронных операций с asynс/await мне кажется удобнее.

А какова ваша история? Пишите (ссылка в описании канала), интересно услышать :)

Собираетесь менять работу? Нет? Ну может будет интересно. А может поделитесь с миром своим опытом...

К сожалению, разработчики должны не просто писать код :), но и зарабатывать. И если вы не фрилансер, то придется проходить техническое интервью. Я случайно нашел GitHub книгу по подготовке к техническому собеседованию. Чем это интересно?

1. Действительно хороший материал, из которого можно много подчерпнуть.

2. Там есть интересные подборки различных вопросов из top-tech компаний https://github.com/yangshun/tech-interview-handbook/blob/7870a58b31069c2f25b95b2529dfe5c082e05785/non-technical/behavioral.md

3. Это Open Source, это коллективное мнение. Туда можно контрибьютить и/или спрашивать вопросы, просить дополнять.

4. Может вы активно собеседуете людей? Это возможность вспомнить как это выглядит с другой стороны. А может даже поделиться своим опытом по этой части https://github.com/yangshun/tech-interview-handbook/issues/55

https://github.com/yangshun/tech-interview-handbook

Интересный анализ топа контрибуторов в опенсорс проекты. С данными можно поиграться в DataStudio самому.

Что забавно, MS среди лидеров. Подумал бы, что статья не объективная, но автор — Developer Advocate @ Google. Одно дело, когда MS говорит что является топ контрибутором, другое дело, когда это признают соперники. В интересные времена живём, товарищи.

Опенсорс позволяет делать потрясающие вещи. И даже такие гиганты как MS признали это и активно используют.

https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

Ранее я писал о том как полезно знание шаблонов проектирования, и как оно все может поменять.

Один из ключевых шаблонов, которые изменили мое мировоззрение в ООП мире был Dependency Injection. И это поистине великолепное решение.

Если вы не знаете что это за шаблон, то самое время это исправить.

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

Стандартный подход для устранения зависимостей — использование интерфейсов. Интерфейс позволяет отвязаться от конкретной реализации. А это дает свободу дейсвий и гибкость. Но подход должен быть конзистентным на всех слоях архитектуры.

Представьте, что мы заинжектили интерфейс для взаимодействия с базой данных


void PerformSomeQuery(IDb db)
{
db.Exec("INSERT INTO blabla VALUES('bla', 'bla')");
}


Но что если метод Exec этого интерфейса выглядит следующим образом:


interface IDb
{
void Exec(SQLString query);
}


Проблема данного кода в том, что интерфейс вводит новую зависимость: SQLString — некий внутренний тип для IDb. Это большая проблема, так как имплементировать интерфейс IDb, не привязываясь к внутренним типам, не представляется возможным. Что, по сути, делает данный интерфейс практически бесполезным.

В статье DIP in the Wild Мартин говорит о том, что

Высокоуровневый код не должен зависеть от низкоуровневых деталей

Чтобы избавить пользователя от головной боли, автор интерфейса должен так же использовать интерфейс


interface IDb
{
void Exec(ISQLString query);
}


А SQLString, в свою очередь, должен имплементировать ISQLString. Тогда пользователь класса сможет реализовать удобные для него имплементации, и не привносить никаких дополнительных зависимостей.

Если это возможно, то лучше ограничиваться стандартными типами, и, например, заменить ISQLString на стандартный string.

В статье Мартина вы сможете найти много других интересных примеров и решений распространенных проблем.

Если вас интересуют подобные проблемы и тема проектирования архитектуры приложения, то очень советую книгу Clean Architecture

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

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

Все же попадали с ГИТом в разные непредвиденные ситуации. С губ в такие моменты слетает многозначительный "упс", неприятно щекочет под ложечкой и начинают закрадываться мысли что последние 2 дня ты работал напрасно.
Вот тут https://github.com/k88hudson/git-flight-rules собрали планы спасения на такой случай. Да и просто рецепты, которые в повседневной жизни пригодятся.

Что использовать, знаки табуляции или пробелы? Или в этом нет разницы, потому что существует удобный инструмент? Читайте в нашей новой публикации.

Подробнее: https://habrahabr.ru/company/microsoft/blog/341722/

Думал что холивары на эту тему давно закончились, но нет. Автоматизировать процесс — выход. Такие языки как Go и Rust идут со встроенными форматами, поэтому никаких вопросов по этому поводу не возникает. Вот еще рамышления на тему стандартов кодирования: h
anonymous poll

Я за строгое соблюдение стандартов! – 21
👍👍👍👍👍👍👍 54%

Пусть форматтер делает всю работу – 16
👍👍👍👍👍 41%

Как хочу так и пишу, в топку стандарты! – 1
▫️ 3%

Мне все равно, просто пишу код – 1
▫️ 3%

👥 39 people voted so far.

Что-то voter не осилил все сообщение, потерялась ссылка:

Вот еще рамышления на тему стандартов кодирования: http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/

В последнее время часто сталкиваюсь с различными "платформенными" решениями, типа облачный PaaS. Решения клевые, мощные. Но...

Разработал какое-то решение с минимальным рабочим функционалом. Попробовал увеличить на него нагрузку и видишь что оно не справляется должным образом. Что делать?

Конечно же нужно оптимизировать. Первое правило клуба оптимизаторов гласит:

Никогда не оптимизируй вслепую

Это значит, что всегда нужно использовать инструменты профайлинга и делать замеры "до" и "после" оптимизации. Так же замеры "до" позволяют избежать ситуации, когда ты увидел далеко не оптимальный кусок кода, долго трахался с его оптимизацией, а потом оказалось, что тормозил то не он... 😫

И вот тут и вылезает проблема. Многие PaaS не имеют инструментов профайлинга и оптимизации. Поэтому приходится использовать годами проверенный метод научного тыка 👉☁️...

На самом деле это относится не только к платформам, но и различным библиотекам и фреймворкам

Как вы относитесь как платформенным решениям 📦 (Platform as a Service и другим решениям типа "черный ящик") ?
anonymous poll

Не пользуюсь. Хз что там внутри – 16
👍👍👍👍👍👍👍 43%

Пользуюсь. Нравится – 8
👍👍👍👍 22%

Пользуюсь. Не нравится – 5
👍👍 14%

Не пользуюсь. По другим причинам. – 5
👍👍 14%

Не пользуюсь. Боюсь вендор лока – 3
👍 8%

👥 37 people voted so far.