Мы с мужем оба не чужды педагогике. Я много лет учила детей в Эколого-биологическом центре Аничкова дворца, муж — студентов в Политехе. И поскольку обстоятельства сподобили выращивать еще и общего ребенка, то не обошлось без дискуссии, как это делать. На том, что дитё надо обучить мыслить научно, мы сходились полностью. Однако дальше начинались разногласия. Муж предлагал подождать, пока оно само вырастет и начнет задавать интересные вопросы. Ибо по началу с маленьким кусочком мяса скучно и общих тем для разговора нет. И вообще, как можно обучать математике или биологии нечленораздельно говорящее существо, которое в ответ на объяснения теоремы Байеса/цикла Кребса пузыри из слюней пускает? Но я думаю, что по счастью, все не так уныло и бесполезно, как кажется. Попробую объяснить, почему.

Какой самый популярный стиль организации кода вы встречали в корпоративных кодовых базах? Лично я чаще всего видел решение, подразумевающее группировку всех файлов по их типу. Таким образом, к примеру, в системе MVC все контроллеры, все сервисы, все репозитории, все POJO и так далее находятся вместе. Давайте назовем такое решение "стековым" стилем организации кода.

Прим. пер.: Очень интересно оглянуться назад и проверить на прочность высказывания создателя Gmail Пола Букхайта, которые он озвучил 14 лет назад (в 2007 году). Некоторые моменты сейчас кажутся немного наивными, но основной посыл — актуален до сих пор.

1. Очевидно хорошие идеи, которые очень сложно реализовать. К этой группе относятся эффективный холодный ядерный синтез, летающие машины и множество других научно-фантастических идей.
2. Очевидно «хорошие» идеи, которые кажутся возможными, но еще не реализованы. Видеотелефоны и HDTV долгое время находились в этой категории. Я думаю, это происходит, когда люди увлекаются технологиями и переоценивают их преимущества (и, возможно, недооценивают стоимость). Мне просто наплевать на видеотелефон.
3. «Плохие» идеи. Многие из этих идей действительно плохи, но некоторые из них в ретроспективе окажутся очень хорошими идеями. Я помещаю их в ту же категорию, потому что их трудно отличить без оглядки в прошлое. Вот некоторые примеры: персональный компьютер («зачем кому-то компьютер?»), Google («уже слишком много поисковых систем, и, кроме того, поисковые системы не зарабатывают деньги») и Blogger («разве ты не можешь? просто используйте Geocities, и, кроме того, действительно ли так много людей, у которых есть что рассказать? "). Более современные примеры (прим. пер.: 2007 год), Facebook и Twitter, которые все еще вызывают споры.

Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб. 

С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?

Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.   

Недавно я получил письмо с примерно следующими соображениями:

Годами знание принципов SOLID было стандартом при найме. От кандидатов ожидалось уверенное владение этими принципами. Однако позже один из наших менеджеров, который уже почти не пишет код, усомнился, разумно ли это. Он утверждал, что принцип открытости-закрытости стал менее важен, так как по большей части мы уже не пишем код для крупных монолитов. А вносить изменения в компактные микросервисы - безопасно и просто.

Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - “Пишите простой код”

По Agile существует огромное количество курсов. Кроме специализированных курсов по проектному управлению есть ещё сертификации.

Зачем получать сертификаты по проектному управлению? Существуют несколько причин.

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

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

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

Любите оператор '?.'? А кто же не любит? Эти лаконичные проверки на null нравятся многим. Однако сегодня мы поговорим о случае, когда оператор '?.' только создаёт иллюзию безопасности. Речь пойдёт о его использовании в цикле foreach.

Статья о том, как реляционная СУБД может выполнить JOIN. Для лучшего понимания мы попробуем своими руками написать такую же реализацию на языке C#. Что позволит нам лучше вникнуть в детали.

А чтобы было не совсем скучно - мы зададимся вопросом производительности. Что работает быстрее C# или SQL? И хоть сам по себе вопрос не корректен, к этому пониманию мы как раз и придем.

«У клоунов не покупают» - наверное, вы слышали подобное высказывание, возможно от маркетологов, где-нибудь на бизнес конференции, либо прочли. Принадлежит эта фраза Хопкинсу…..нет не великолепному актеру сэру Энтони Хопкинсу, а основателю научного подхода к маркетингу, когда еще самого маркетинга как такового не было, Клоду Кларенсу Хопкинсу (1866-1932).

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

Первый закон Паркинсона: работа заполняет время, отпущенное на неё.

Не правда ли, формулировка отдаёт какой-то безнадёгой? Старайся, планируй, работай над эффективностью, не отвлекайся, будь осознанным – толку ноль. Всё равно весь день просидишь. Меня такое положение дел не устраивало, и я, вдохновлённый энтузиазмом, кинулся ломать закон Паркинсона.

Хотел доказать самому себе, что могу управлять структурой и объемом работы так, чтобы она не занимала всё моё время. Что вышло, и к чему я в итоге пришёл – за разворотом.

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

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

Сразу хочу успокоить. Сегодня SCRUM это уже не так страшно как десять лет назад. Современная медицина достигла невероятных высот. Люди со SCRUM живут полноценной жизнью. Остаются активными членами общества. Главное -  своевременно подобрать правильный режим лечения.

1. Работа в нашей отрасли полностью построена на порочных стимулах.
2. Лучший способ продвинуться по карьерной лестнице — это смена компании. Компании, в которых вы работаете, будут вознаграждать хорошую работу большей работой и ответственностью, а не большим количеством времени и/или денег. Компании, в которые вы переходите, вознаградят вашу предыдущую хорошую работу в других компаниях большими деньгами. На самом деле это не имеет смысла… См. Пункт №1.
3. Каждый раз, когда я меняю работу, я сокращаю свои обязанности на 50% и увеличиваю зарплату на 50%. На моей первой работе я был очень раздражен, когда новые сотрудники, которые были на моем уровне квалификации, зарабатывали больше, чем я. Теперь другие старожилы в моей компании с таким же уровнем квалификации раздражаются, когда я зарабатываю намного больше, чем они (обратите внимание, что количество смен работы >= 3). На самом деле это не имеет смысла… См. Пункт №1.

• Лучший способ достичь карьерного роста — сменить компанию.
• Стек технологий на самом деле не имеет значения, потому что в моей области есть примерно 15 базовых шаблонов разработки программного обеспечения. Я работаю с данными, поэтому они не будут такими же, как веб-разработка или embedded. Но все области имеют около 10-20 основных принципов, и технический стек просто пытается упростить эти вещи, так что не переживайте.
• Есть причина, по которой люди рекомендуют искать работу. Если я недоволен работой, наверное, пора уходить.
• У меня появилось несколько хороших друзей на всю жизнь в компаниях, с которыми я работал. Мне не нужно это от каждого места, где я работаю. Я был совершенно счастлив, работая в тех местах, где у меня не складывались дружеские отношения с моими коллегами, и я был несчастен в местах, где у меня было несколько хороших друзей.

• В 12 лет создал сайт Info, где каждый мог писать о том, что знает (а другие могли дополнять и комментировать). Это был предвестник Википедии.
• В 14 лет Шварц стал соавтором спецификации RSS 1.0.
• Аарон Шварц работал под руководством Тима Бернерса-Ли в составе основной рабочей группы RDF в Консорциуме W3C.
• Попал на первую программу в Y Combinator со стартапом Infogami, который впоследствии слился с популярным сайтом Reddit.
• Работал над Open Library и Creative Commons
• Внес существенный вклад в Markdown.