Главный навык программиста

Я заметил, что опытных специалистов из разных областей объединяет как минимум одна вещь: осторожность в суждениях.

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

Нужно ли писать тесты? Важно ли качество кода? Какая лучшая степень прожарки мяса? С чем лучше всего сочетается белое вино? Нужно ли делать жим лежа со становой или турника будет достаточно?

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

Моя нелюбовь к старине Бобу началась с его книги "Принципы, паттерны и методики гибкой разработки на языке C#" (вот большая критическая статья на эту тему), но дядюшка Боб периодически выдает и вот, после очередного его высказывания, мне захотелось подумать над поднятой им темой более подробно.

Итак, вот его твит:

When you read code, the race, religion, politics, gender, and orientation of the author are irrelevant and invisible. The only thing you can tell about the author is their ability to write well organized code. Nothing else matters.

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

Структура твита. Автор вначале говорит о расе, религии, ориентации и поле, как о несущественных вещах в контексте анализа кода. Да. С этим никто не будет спорить. Это так. Но потом он заявляет, что единственная вещь, которая говорит об авторе кода - это его умение писать хороший код и что ничего другое не важно.

Здесь используется довольно грязный трюк с подменой понятий и отсутствием причинно-следственной связи между двумя частями твита. Тот факт, что мы не должны судить об авторе кода по его "внешним атрибутам" не делает "хорошо структурированный код" важным. И с чего старина Боб решил, что должно какое-то одно главное качество, характеризующее специалиста?

Поскольку тема эта интересна, то давайте немного пофилософствуем по этому поводу.

"Что самое главное в жизни?", может спросить Боб. "Семья, конечно", ответит один. "А как же здоровье? Если нет здоровья, то радости от семьи будет не много.", возразит второй. "А как же призвание, а деньги? На одной семье, пусть и здоровой, далеко не уедешь! Нужно ж еще и кушать вкусно, да и делом интересным заниматься!", скажет третий. "Ну а помощь другим? Это ж тоже важно! А друзья? А карьера? А красивое тело?".

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

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

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

Если же задаться вопросом о главном навыке (навыках?) специалиста из любой области, то я бы сказал, что это умение учиться и критически мыслить (да, и не быть м#$@ком). Эти два ключевых мета-навыка позволят развить любые другие.

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

Хороший специалист может увидеть проблему (в себе, в коде, архитектуре или подходах), подумать об альтернативах и изучить наиболее подходящее решение.

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

Мне тоже хочется найти простое решение таких сложных проблем, как разработка ПО. "Развивай навык Х и ты будешь отличным специалистом!". Но мир и разработка ПО достаточно сложны и многогранны, чтобы был один главный навык, который бы в одиночку смог бы решить все наши проблемы.

Эффект плато

Время от времени с головой и карьерой начинают твориться довольно страшные вещи: все начинает если не напрягать, то точно приносить меньше удовольствия. Работа не прет. Проекты не прут. Ничего новое не радует и не интересует. Вопрос: почему?

У меня есть некоторые мысли по этому поводу.

Есть такая штука – допамин. Он вырабатывается, когда вы ожидаете доставки нового ай-фона, «встречи» с любимой/любимым вечером или в момент укуса вкусного мороженого жарким летним днем. Допамин – это сильнейшее штыриво, которое вырабатывается от ожидания чего-то приятного или прямо в момент его наступления.

Когда начинается карьера программиста, то с допамином нет никаких проблем. Ты каждый день узнаешь что-то новое: технологии, процессы, паттерны, практики. Вокруг все новое и моменты «просветления» происходят довольно часто. Возникает чувство, что мозг и опыт развиваются по закону Мура и каждые 18 месяцев количество знаний удваивается.

Тоже самое происходит и с первыми проектами: ощущение «творения» возникает постоянно. Исправил маленькую багу – молодец. Применил новый паттерн – красава. Починил билд – отлично. Задизайнил и довел до ума новую фичу – да вообще тебе цены нет.

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

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

И потом мир начинает немного меняться.

Ну, с миром-то все нормально. Но твое восприятие становится несколько иным.

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

Это же происходит с карьерой и ощущением от завершенных задач. Выше «синьера» прыгать сложно, да и не ясно, куда именно. А с задачами вообще беда получается: все одно и тоже, формошлепство, дата-сайенс, веб, базы данных. Декораторы, синглтоны и фабрики. И дурацкие обсуждение того, чем монады хороши, и почему ООП уже не торт.

Так что же происходит?

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

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

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

Есть несколько способов смягчения этой проблемы.

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

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

В-третьих, можно прислушаться к себе и понять, что же может толкать тебя изнутри. Если нравится больше кодить, то может стоит забить на свои глупые тим-лидские амбиции и заняться архитектурой или стать «просто разработчиком»? А может тебе просто нравиться изучать что-то новое, так может стоит продолжать это делать, даже если это никак не поможет твоей карьере?

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

Все это я к чему? Если плато не угрожает карьере, то вполне нормально переключаться и искать себя в чем-то другом. Искусственное толкание себя вперед может привести к выгоранию, а вот временное переключение на что-то другое вполне может освежить мозги и вернуть радость от работы и жизни.

О книге Джона Сонмеза “The Complete Software Developer’s Career Guide”

Если честно, у меня не совсем однозначное отношение к автору книги – Джону Сонмезу (John Sonmez). Это довольно известный парень, автор пары книг, 55 курсов на Pluralsight (о чем он напоминает не менее 10 раз в своей последней книге), автор блога SimpleProgrammer.com и ютюб канала Simple Programmer. Он «вышел на пенсию» в 32 и «отдыхает» в свое удовольствие, работая на себя часов по 8 в день.

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

Основное направление его бизнеса – это консультации программистов по развитию софт-скиллов. И у него самого с этими скиллами все в полном порядке. Иногда, он вдохновляет, но иногда порядком раздражает своими «я смог, значит каждый сможет» и «ну, я об этом писал в этом посте, идите там посмотрите».

Теперь к книге.

По словам автора, книга “The Complete Software Developer’s Career Guide” покрывает все аспекты карьеры программиста: начиная от обучения и поиска работы, заканчивая продвижением по службе и началом своего дела.

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

Поиск работы. Очевидно, что для разработчиков с разным уровнем некоторые знания будут неактуальны. Если вы уже давно работаете, то вопросы выбора колледжа или код-кампа будут, интернатуры, поиска первой работы и т.п. будут не актуальными. Хотя если у вас есть детки, то, вполне возможно, эти сведения будут не бесполезными.

С другой стороны, автор покрывает и такие моменты, как контрактор vs. эмплой. Что может быть полезно нашим новоприбывшим в Штаты людям.

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

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

· Обзор чего-то нового, чтобы понять, что можно решить с помощью этого.

· Понять, как начать это что-то использовать.

· Узнать 20% этого нового, чтобы покрыть 80% юз-кейсов.

Обзор мира разработки ПО. Раздел мало полезный для профессионального разработчика.

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

Я обратил внимание, что корпоративные культуры, промоушены и другие вещи, связанные с карьерой, сильно отличаются «здесь» и «там». Если в Киеве сидение на месте уже является достаточным основанием для повышения зарплаты, то в больших конторах в Штатах это не так.

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

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

Очень понравилась мысль о любимом местном понятии “work/life balance”. Джон советует не противопоставлять эти два понятия, а сделать работу неотъемлемой и приятной частью своей жизни. Да, идеальная работа бывает лишь в сказках, но в наших с вами силах сделать ее разумно-приятной.

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

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

Собственный бренд и саморазвитие.

И тут Остапа понесло.

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

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

Для меня блоггинг также является осью саморазвития и основой сети общения.

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

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

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

Сомнительные моменты.

Как и любая другая книга, книга Джона не идеальна. Есть некоторые моменты, с которыми сложно согласиться. Например, Джон тратит десяток-два страниц убеждая в важности одежды. Дескать, нужно одеваться на два уровня выше своей текущей позиции. Но у меня, например, бос моего боса моего боса ходит в шортах (это Brian Hurry) и ничего. Я совсем не чувствую, что одеваясь в костюм ты произведешь лучшее впечатление.

Еще автор советует, очень советует, найти профессионального писателя резюме. Ну, сомнительно это для меня.

Да и водички с повторениями тоже прилично.

Главный вывод/мотив книги.

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

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

Наберитесь терпения. Пусть сам процесс доставляет удовольствие и результат придет.

Вердикт: чтиво.

О “вреде” книг: напутствие любому программисту

Недавно наткнулся на любопытную статью под названием «О вреде книг: напутствие начинающему программисту». Идея в статье простая: книги – это скорее опасно, и лучше практика с пополнением теории по ходу дела, да и образование современное – ни к черту.

Мне сложно судить о современном программистском образовании в России/Украине (эта тема также поднимается в статье). У меня самого нет специализированного образования (я по образованию «специалист» в области систем автоматизированного управления), да и с момента получения оного прошло уже довольно много времени (19 лет с момента поступления в университет). Но мне явно есть что сказать по поводу самообразования и использования книг в этом процессе.

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

Горизонтальные и вертикальные слои приложения

«У лука есть слои, и у людоедов есть слои! Ты понял?» - Шрек

Эта заметка навеяна выступлением Jimmy Bogard на 0redev под названием “Solid Architecture in Slices not Layers”, которую я всячески рекомендую.

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

Conway’s Law

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

Такой разделение еще сильнее выстраивает барьеры между слоями приложения, поскольку тут начинает во всей красе проявляться Conway’s Law, когда архитектура приложения начинает повторять структуру организации.

Памятка ынтырпрайз кодера

После прочтения “Release It!” захотелось сохранить ряд мыслей по поводу разработки распределенного ынтырпрайз софта. То, о чем нужно думать, что нужно подпилить, о чем нужно не забыть и т.п.

1. Все что может отвалиться, обязательно отвалится

База ляжет, удаленный веб-сервис начнет тупить, перестанет проходить автортизация, ажура начнет отбивать запросы (throttling). Это значит, что любое взаимодействие с внешними системами должно это учитывать. К сожалению, это легче сказать, чем сделать, поскольку современные библиотеки для распределенного взаимодействия слоены до нельзя и с точки зрения API не вполне очевидно, что именно может пойти не так, какие исключения могут вылететь, и что с ними нужно будет делать.

Менторинг и парное программирование

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

Итак, прежде всего немного контекста. В прошлой заметке шла речь об анализе классического подхода, описанного Кентом Беком в его «Экстремальном программировании», когда ни одна строка кода не попадает в финальный репозиторий, если над ней не работало два человека одновременно. Это весьма специфический вид совместной работы, главной целью которого является повышение качества кода. Обучение, обмен опытом, интересное время препровождение, все это пусть и полезные, но второстепенные артефакты этой активности.

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

Теперь давайте об этом более подробно.

О парном программировании

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

До последнего времени у меня не было личного опыта парного программирования, поэтому мое мнение было сугубо теоретическим. За последние полгода у меня появился какой-то опыт, и именно им и хотелось бы поделиться.

Итак, начнем с проблем.

О шаринге знаний и компетенций с коллегами

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

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

Для меня – делиться знаниями, даже скудными, это означает узнавать что-то лучше самому. Когда приходится рассказывать об архитектуре или используемых паттернах своему коллеге, то ты автоматически воспроизводишь все решение в голове и оцениваешь его валидность/корректность. Если коллега опытный, то он легко подправит твое понимание проблемы. Если же он новичок, то его стеклянные глаза будут прекрасным индикатором кривизны архитектуры или показателем полного отсутствия у тебя скила по донесению сложных вещей слушателю.

Инкапсуляция и сокрытие информации

В области проектирования существует два понятия, которые часто используются совместно – инкапсуляция (encapsulation) и сокрытие информации (information hiding).

Понятие инкапсуляции обычно используется в контексте ОО-языков и означает сокрытие данных (*). Открытые изменяемые (**) данные нарушают инкапсуляцию, поскольку теперь любой клиент класса сможет изменить внутреннее состояние объекта без ведома самого класса. Это может нарушить некоторые инварианты, т.е. условия на которые расчитывал автор класса и на которые, формально или неформально, должны полагаться его клиенты.

(*) – иногда понятие инкапсуляции применяется в более широком смысле. Например, говорят, что фабрика «инкапсулирует» информацию о конкретном типе создаваемого объекта. В этом контексте инкапсуляция является синонимом сокрытия информации.

(**) – хотя принято считать, что у класса недолжно вообще быть открытых данных, но с практической точки зрения, открытое неизменяемое поле хоть и нарушает инкапсуляцию, обычно не приводит к таким же серьезным проблемам сопровождения, как открытые изменяемые данные.

Что не так с оператором switch?

В обсуждении одного из моих ответов на ru.stackoverflow в G+ был поднят вопрос по поводу того, является ли оператор switch design или code smell-ом?

Тут нужно быстро вспомнить, откуда ноги вообще растут (ИМХО). В наших с вами разных языках программирования существует много разных способов решения одной и той же проблемы. Например, когда у нас есть определенная задача (нарисовать фигуру?!) и несколько разновидностей входных данных (круг, квадрат, прямоугольник?), то решить ее можно разными способами. Можно взять впихнуть тип в структурку и в методе draw перебрать все возможные варианты.

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

Принцип YAGNI

На ru.stackoverflow.com недавно был задан вопрос, который, ИМХО, стоит вашего внимания: Нарушает ли OCP и DIP (из SOLID) принцип YAGNI?. Ниже представлен немного более развернутая версия моего ответа.

Разные принципы проектирования направлены на решение противоречащих друг другу задач проектирования. Можно сказать, что разные принципы «тянут» дизайн в разные стороны и нужно найти правильный вектор, наиболее полезный в данном конкретном случае. SRP толкает в стороны простого решения, а OCP – в сторону изоляции компонентов, а DIP – направлен на построение правильных отношений между типами.

Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.

О сути исключений

Исключения – это хорошо. Про них не забыть. Они позволяют отделить основную логику от логики обработки ошибок. Они повсюду. И мы их, по идее, умеем готовить.

Но, в то же время, исключения – это плохо. Совсем не понятно, что и в какой момент может произойти. Бросает ли метод исключение или нет. А если бросает, то не всегда ясно, что с ним делать. И, что неприятно, исключения могут нести разный смысл.

И именно о семантике исключений сегодня и пойдет речь.

Должен ли менеджер кодить?

DISCLAIMER: данные размышления в значительной степени относятся к менеджерам продуктовых компаний и, как мне кажется, менее применимы к миру аутсорса.

Я уже не раз встречаю мнение о том, что не зависимо от уровня, менеджер в софтверной компании должен оставаться hands on и продолжать кодить (*). Мысль эта несколько необычна, поскольку первое, чему приходится научиться любому начинающему менеджеру в области софтостроения – это как раз-таки, отказаться от этого самого кодирования.

(*) Об этом не раз писал Joe Duffy в постах и твитах, а также Michael Lopp в своей книге “Managing Humans”.

Как и в многих других вещах, ответ на вопрос «Кодить или нет?» несколько сложнее, чем может показаться и не подразумевает бинарной логики в ответе – «да» или «нет».

О сомнительных советах об эффективности

Давать советы об эффективности тех или иных языковых конструкций довольно сложно, поскольку мало в каком языке есть конструкции с заведомо плохой эффективностью. Обычно разные языковые конструкции предназначены для решения хоть и похожих, но несколько разных задач. Например, цикл for в C# работает только с индексируемыми коллекциями, поэтому сравнивать его с циклом foreach в общем случае некорректно.

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

Вот и сегодня мне встретился такой совет, который ретвитнули несколько человек в моей ленте. Совет с самой мудростью, доступной лишь посвященным, но якобы полезной любому .NET разработчику:

Great high-performance tips for .NET developers pic.twitter.com/EepLub5cl9

— Morten Nielsen (@dotMorten) May 29, 2016

О рецензировании кода

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

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

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

TDD: Test-Driven vs. Type-Driven development

Боб «не люблю статическую типизацию» Мартин произвел отменный вброс в своем недавнем посте “Type Wars”, в котором он выразил мысль, что наличие TDD и 100%-е покрытие тестами вполне заменяет статическую типизацию:

“You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous.”

После чего поднялась небольшая волна в этих ваших тырнетах, в результате даже Марк “Я-то точно знаю TDD” Сииман был обвинен в ереси и непонимании принципов, заложенных в TDD.

“TDD replaces a type checker in a dynamically typed language in the same way that a bottle of whisky replaces your daily problems“

— Matt Gumbley (@mattgumbley) May 2, 2016

Размышления о TDD

В наших с вами тырнетах снова образовался всплеск активности по поводу TDD, о его здоровье и жизненных показателях. Началось все с поста Ian Sommerville “Giving up on test-first development”, а продолжилось постом Боба «я все знаю о дизайне» Мартине “Giving up on TDD” и еще несколькими постами.

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

Результат vs. Процесс

Когда речь заходит о TDD (Test-Driven Development), то возникает впечатление, что речь идет о каком-то тайном знании. «Знающие» индивидуумы рассказывают о своих успехах с хитрым выражением лица и некоторым снисхождением к тем, кто еще не осознал всей прелести этой аббревиатуры. При этом, когда их просят рассказать о выгодах сего процесса, они начинают бормотать о пользе тестов, важности хорошего дизайна, легкости рефакторинга и гибкости получаемых систем. Иногда, в качестве аргументом могут встречаться фразы о самодокументируемом коде, наличиях «встроенной» в тесты спецификации и высоком покрытии, как о важном артефакте любой вменяемой кодовой базы. А если вы начнете детально обсуждать модульные тесты, то вас перебьют и скажут, что TDD – это вообще-то про дизайн (т.е. про проектирование), а не про тестирование.

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

Критика книги Боба Мартина «Профессиональный программист»

У меня со стариной Бобом складываются довольно сложные односторонние отношения. Когда-то, он был моим чуть ли не кумиром, но после внимательного прочтения его книги «Принципы, паттерны и методики гибкой разработки» мое мнение сильно изменилось. Теперь же любой его труд мне читать стало заметно сложнее, поскольку явно начал проявляться «баг» под названием «подтверждение предвзятости». Я стал находить все больше и больше непонятных мне моментов и все меньше полезных советов. Но поскольку большинство книг «дядюшки» Боба весьма известны и обладают высоким рейтингом, я не могу пройти мимо и не поделиться с вами своим впечатлением от прочтения очередного его творения.

Книга «Профессиональный программист» (Clean Coder: A Code of Conduct for Professional Programmers) относится к жанру, который я называю «философией программирования», по названию одноименного форума на rsdn.ru, где было принято обсуждать вопросы стиля, кодинга, гайдлайдов, технического флейма по поводу языков программирования и тому подобных вещей. Популяризаторами этого жанра были такие замечательные авторы как Хант с Томасом и своим «Программистом-прагматиком», Джоэл Спольски со своими записками о программировании и многие другие.

Я вижу две ключевые пользы от таких книг:

• Расширения кругозора
• Повышение мотивации

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

О трудозатратах на саморазвитие

У меня к вам внезапный вопрос: а сколько вы тратите времени в неделю на саморазвитие? Час? 5, 10, 20? Я спрашиваю не из праздного интереса. Мне самому довольно часто задают этот вопрос и мне бы хотелось собрать некоторую статистику.

Если брать статистику по отрасли, то там будет все довольно печально. Есть статистика, что процентов 90 программистов не читают ни единой книги в год и прочитывают не более одной статьи в неделю. В общем, с одной стороны, все довольно печально, а с другой – все просто прекрасно: потребуется не так уж много усилий, чтобы выделиться из толпы.

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