Про Agile на пальцах. Путь к быстрой разработке.

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

Задумывались ли Вы когда-нибудь, почему одни люди работают в разы быстрее чем другие? Причем, часто “тормозят” в работе именно наиболее умные и толковые разработчики.

Мое первое знакомство с Extreme Programming

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

Этот парень использовал на то время лишь ограниченный сегмент практик Extreme Programming (XP) - наиболее эффективной и одной из первых Agile методологий. Все что он использовал - TDD, Evolutionary Design, принципы SOLID, из которых особый упор был на Single Responsibility Principle (SRP), а также активно использовал Type Hinting для автоматического рефакторинга, поскольку язык был с динамической типизацией.

Именно так я и познакомился впервые с Extreme Programming, вернее, с его неоспоримым превосходством даже в столь урезанном виде. Под настоянием этого парня я прочитал свою первую книгу в области качества кодирования - Clean Code, и с этого началось мое становление специалиста в области проектирования программного обеспечения.

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

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

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

Кент Бек как-то сказал, что труднее всего работать в Agile разработке докторам наук. Причина в том, что чем выше интеллект человека, тем больше ему свойственно продумывать всю задачу наперед, охватывать умом всю реализацию, от начала до конца (upfront thinking), еще до начала ее реализации.

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

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

Ответом на эту проблему является Evolutionary Design (Emergent Design). Смысл его заключается в том, что мы начинаем реализовывать первое пришедшее на ум решение, которое затем, уже в процессе разработки, изменяем путем рефакторинга по мере роста информированности. Но при этом соблюдаем несложные правила:

  • Single Responsibility Principle (SRP)
  • Качественное проектирование кода, позволяющее отложить решение о конкретной реализации. Декларирование качественных интерфейсов важнее конкретной реализации.
  • Обеспечение автоматического рефакторинга: расстановка Type Hinting для динамических языков программирования, покрытие кода тестами, использование средств автоматизированного рефакторинга.
  • YAGNI - реализация только того, что требуется текущей задачей, без предположений о том, что нам потребуется в будущем, т.е. ничего не реализуется “впрок”.

Из перечисленного, второй принцип “Качественное проектирование” очень важен, и ниже я расскажу почему. Но сперва об Agile.

Смысл Agile разработки

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

Обычно стоимость изменения кода растет экспоненциально по мере увеличения объема кодовой базы. Это справедливо как к Waterfall проектам, так и к Scrum проектам, не использующих технических практик. Такие проекты очень дорого изменить когда они уже в значительной мере реализованы, поэтому их следует проектировать заранее.

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

Суть Agile заключается в том, чтобы изменить этот экспоненциальный график стоимости изменения кода на плоский и горизонтальный (насколько это возможно), более правильное название которого - асимптота. Если проект равно одинаково легко изменить в любой момент независимо от объема кодовой базы, то это значит, что нам не нужно проектировать его заранее (т.е. нет необходимости в upfront design)! Вот в чем заключается гибкость (agile)!

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

В свое время Кент Бек сказал, что если плоский график стоимости изменения кода делает XP возможным, то крутой график делает его невозможным.

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

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

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

На Русском:

Очень хорошая интерактивная шпаргалка: Subway Map to Agile Practices.

Качество проектирования

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

Проектирование диктуется психологией, законом магического числа семь плюс-минус два , согласно которому кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов.

Еще во времена процедурного программирования возник принцип Low Coupling & High Cohesion, нацеленный на то, чтобы снизить концентрацию сложности кода и удовлетворить закон магического числа семь, т.е. исключить переполнение мозга.

Отсюда вытекает один из главных императивов разработки ПО - управление сложностью кода.

Coupling (Сопряжение, Зацепление) - это показатель того, насколько класс осведомлен о стороннем поведении.

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

Кстати, размер класса измеряется количеством его обязанностей, и при хорошем проектировании оно стремится к единице (SRP), за исключением тех обязанностей, которые “не тянут” на самостоятельный класс.

Подробнее смотрите в статье “Coupling And Cohesion”.

Именно для снижения Сопряжения и предназначены многие паттерны проектирования. Хорошая новость заключается в том, что паттерны проектирования предназначены для снижения сложности программы, и именно так их и следует использовать. Этому вопросу посвящена статья “Is Design Dead?” by Martin Fowler. Качество программного кода измеряется именно уровнем его сложности, а не изобилием паттернов проектирования (что является частым заблуждением новичков, которым нетерпится продемонстрировать свои новые навыки). Плохая новость заключается в том, что паттерны знать нужно, и паттернов очень много - Design Patterns, PoEAA, Cloud Design Patterns, Service Design Patterns, Enterprise Integration Patterns, Analysis Patterns, Concurrency pattern, POSA и другие.

Здесь, наверное, было бы уместно сделать небольшое отступление. Классическим заблуждением начинающих и толковых ребят является вера в то, что практика и опыт могут заменить работу с литературой. Помните что Дейкстра говорил о строго ограниченных размерах человеческого черепа? Воспроизвести в одиночку эволюцию целой индустрии - это весьма самонадеянно. Жизни не хватит. Можно, конечно, попытаться изобрести колесо, и в одиночку обобщить и систематизировать совокупный опыт индустрии, и, если человек обладает умом Эриха Гаммы или Мартина Фаулера и посвятит этому вопросу половину жизни, то у него может и получиться. Вот только совокупный опыт индустрии выражается, опять же, в литературе. Так что - никак.

Другая крайность при работе с литературой заключается в чрезмерном перегибе, который приводит к подсознательному отторжению этого процесса. Чтобы стать хорошим специалистом, достаточно читать 5 страниц в день, по крайней мере так говорит один из известнейших авторитетов в области IT-индустрии Steve McConnell. И желательно работать с первоисточниками. Если Design Patterns - значит GOF. Если рефакторинг - значит Martin Fowler. И т.д.

Сегодня в мире ООП принцип Low Coupling & High Cohesion известен благодаря принципам GRASP, однако его функции в значительной мере взяли на себя такие понятия как Абстракция и Инкапсуляция.

Удивительно, но большинство разработчиков не понимают этих базовых вещей, что приводит к написанию tricky code. Именно поэтому, я рекомендую начинать путь специалиста в области проектирования не с книги “Clean Code”, а с книги “Code Complete” 2-d edition by Steve McConnell, которая дает глубокое понимание базовых фундаментальных понятий.

В наши дни базовые принципы качественного проектирования хорошо известны под акронимом SOLID.

Заимствование проблем

Разработчикам свойственно “брать в долг” проблемы, т.е. решать проблемы полагаясь на предположение о том, что это решение когда-нибудь понадобится в будущем. На самом деле, очень часто такие решения остаются невостребованными, и просто потребляют ресурсы на разработку, сопровождение и понимание возросшей сложности программы. Математическое обоснование этой проблемы (с приведением к процентной ставке) Kent Beck приводит в книге Extreme Programming.

Решением этой проблемы является уже упомянутый ранее принцип YAGNI.

Кто будет читать код?

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

Истина в том, что при написании кода, разработчик 90% времени именно читает код, и только 10% времени он вводит символы с клавиатуры. Пишет код он в одиночку и лишь единожды. Зато читают код все разработчики команды и много раз. Таким образом, плохо написанный код на 90% влияет на снижение темпов разработки всей команды.

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

В хорошей программе достаточно открыть файл с декларацией публичных интерфейсов (даже если используется язык с динамической типизацией), и этого должно быть достаточно, чтобы понять что делает программа. Если этого не понятно, то интерфейсы следует улучшить. Программа должна выражать “ЧТО” она делает, а не “КАК” она делает непонятно что.

Автоматизированное тестирование

На самом деле, без тестирования просто невозможен рефакторинг, а значит, невозможен и Evolutionary Design. А без Evolutionary Design разработчик возвращается к засасывающей воронке времени под названием upfront thinking.

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

  1. Тестирование повышает качество кода, т.к. разработчику легче изначально написать слабо сопряженный код (Low Coupling), чем ломать голову над тем, как протестировать код с высоким сопряжением (High Coupling). С целью достижения наибольшего эффекта, желательно ограничить использование автоматизированных средств создания Mock-объектов, так как они упрощают тестирование плохо спроектированного кода.
  2. TDD повышает качество интерфейсов, т.к. мы продумываем интерфейс изначально с точки зрения его использования, и используем этот интерфейс еще до реализации. Вы, наверное, обращали внимание на то, что, при итеративной разработке, представитель бизнеса всегда получает более ясное представление об User Interface после того, как впервые попробует его использование. Здесь то же самое, только интерфейсы программные.
  3. Тестирование устраняет страх очищать кодовую базу и исправлять ошибки в коде. Т.е. придает уверенность разработчику. Без этого просто невозможен процесс Model Distilling, т.е. улучшение качества бизнес-моделирования по мере переработки знаний. Подробнее этот вопрос раскрывается в DDD.
  4. TDD устраняет засасывающую воронку времени под названием перфекционизм, т.к. существует очевидное условие, выполнение которого свидетельствует о решении задачи.
  5. Тестирование исключает использование отладчика. А отладчик отнимает значительно больше времени, чем написание тестов. К тому же, в отличии от использования отладчика, время для написания тестов прогнозируемо.
  6. Тесты - один из лучших способов документации кода.
  7. Инверсия стресса, что увеличивает работоспособность.
  8. TDD концентрирует внимание на решении только одной осязаемой обязанности. Снижает нагрузку на мозг и обеспечивает более высокие темпы разработки.

Несмотря на то, что при TDD разработчик пишет больше кода, он имеет более высокие темпы разработки. Основное время занимает не сам ввод символов с клавиатуры, а обдумывание предстоящей структуры кода. TDD вырабатывает привычку изолировать в голове только одну осязаемую обязанность кода в единицу времени, и думать только о ней вплоть до момента ее реализации. Как песочные часы. Т.е. эта методика учит не загружать в голову сразу много. Учит управлять сложностью. Благодаря такому снижению нагрузки на мозг, разработка продвигается в разы быстрее, особенно в сочетании с Помидорным Методом.

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

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

Оценивание задач

Многие разработчики не понимают разницы между оценкой (estimate) и обязательством (commitment). А так же не понимают разницы между планированием и предсказанием. Это приводит к стрессу. Разработчик боится плохо выглядеть, и врет про estimates. Затем боится не выполнить estimates, и работает сверхурочно (что, кстати, претит Agile практикам). Работает сверхурочно - теряет работоспособность, не развивается, и совершает много проектных ошибок, которые с эффектом “положительной обратной связи” (т.е. “вразнос”) ухудшают прогнозирование estimates, что, как снежный ком, ведет к экспоненциальной эскалации напряженности.

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

Именно поэтому в Planning Poker обычно используется ряд Фибоначчи - нет смысла оценивать предмет с точностью выше, чем погрешность оценки. А погрешность тем выше, чем выше объем задачи.

Более подробно эта тема раскрывается в книге “Clean Coder” by Robert Martin. Эта книга сложна для чтения в оригинале, и многим будет легче читать ее русский перевод (который достаточно качественный) под названием “Идеальный Программист”. Также будет полезным этот видеоролик “Effective Estimation (or: How not to Lie)”.

Существует несколько превосходных книг, посвященных вопросам estimates. Но я не вижу смысла уделять внимания изучению оценки предмета больше, чем изучению самого предмета. Лаконичной информации, предоставленной Robert C. Martin, вполне достаточно для большинства разработчиков.

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

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

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

Преждевременная оптимизация

Наверное ничто не бывает настолько затратным и настолько ненужным как преждевременная оптимизация. Это мельница для нескончаемого донкихотства. На эту тему было сказано так много, что даже удивительно наблюдать как снова и снова люди тратят кучу усилий и создают во имя оптимизации самые неудачные решения и кучу ненужностей. И мы тоже так делали. Потом случилось чудо. У нас не было на оптимизацию времени, так как мы были заняты созданием качественного программного дизайна. И мы заметили, что показатели нагрузки, вопреки предположениям, не только не упали, а, наоборот, улучшились. И когда New Relic изредка нам сообщал о проблеме в performance, мы обнаружили, что устранять проблему в качественно спроектированном коде намного легче.

В общем, оптимизировать нужно исключительно в соответствии с Законом Парето (80/20) и только то, что измерено профайлером и представляет собой реальную проблему. И желательно делать это на уже стабилизированной кодовой базе, чтобы потраченные усилия не оказались выброшенными из кода через пару недель.

Сражения мнений

Code Review - мощный инструмент, который часто используется далеко не на полную силу.

Во многих проектах, в которых я принимал участие, первоначальное отношение к Code Review было, как правило, негативным и воспринималось чуть ли не как подозрение в некомпетентности. Ревьюировали в основном новичков, и этот процесс пожирал невероятно много времени. Часто было быстрее решить задачу самому, чем добиться приемлемого качества кода от новичка. В общем, толку от Code Review обычно было немного.

Если вы уже знакомы с Agile, то понимаете, что без Collaborative Development не может быть и речи о Collective Ownership. К первому относятся Парное Программирование, Формальные Инспекции (Formal Inspections), Анализ Кода (Walk-Throughs) и Чтение Кода (Code Reading). Чтение Кода похоже на Code Review, но ориентировано на распространение знаний, поэтому является коллективным мероприятием, и должно вовлекать хотя бы 2-3 человека помимо автора. Кроме того, около 90% ошибок обнаруживается самим автором на этапе подготовки к Чтению Кода. Часто это единственная доступная форма of Collaborative Development, так как заказчик не часто соглашается на Парное Программирование.

Во всех случаях нам удавалось перевернуть отношение к Code Review, и впоследствии обиду вызывало уже не Code Review, а, наоборот, нежелание коллег ревьюировать Pull Request. По мере роста участников команды в вопросах проектирования, Code Review стало своего рода площадкой для демонстрации достижений. Обычно после создания Pull Request каждый разработчик просил в командном чате о проведении Code Review, и если находилось мало желающих, то это воспринималось как то, что разработчик никого не заинтересовал своим кодом. Для мержа Pull Request требовалось минимум 2 одобрения.

Для этого переворота было достаточно решить 2 проблемы.

1. Сражения мнений (или даже ЧСВ). Это невероятный пожиратель времени и отравитель морального климата. Мы решили эту проблему тем, что ввели в обиход каталоги Code Smells. Есть три популярных каталога.

  • Chapter 17: “Smells and Heuristics” of the book “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin
  • Chapter 3. “Bad Smells in Code” of the book “Refactoring: Improving the Design of Existing Code” by Martin Fowler
  • Каталог Code Smells на сайте of Ward Cunningham

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

2. Вторая проблема - это большой расход времени на объяснения и обучения в процессе Code Review. Решили эту проблему просто - заставили работать книгу вместо себя. На Code Review вместо длительных разъяснений просто бросали ссылку на нужный метод рефакторинга по каталогу рефакторингов:

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

Code Review, которое раньше могло длиться весь день, теперь сжалось до 10 минут. Буквально за пару месяцев качество кода и квалификационный уровень команды поднялись в разы, как и общекомандный velocity.

Так же полезны каталоги для рефакторинга БД:

В итоге Code Review стало вполне приятной процедурой, которая повышала темп разработки, а не тормозила его.

Баланс бизнес и технических интересов

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

Когда у разработчика мало времени на разработку (т.е. преобладают бизнес-интересы) - кодовая база загнивает, что также влечет за собой падение темпов разработки.

Страхи

Еще одним из ключевых поедателей времени являются страхи. Разработчики боятся показаться некомпетентными, и боятся спрашивать, расходуя кучу времени на неудачные решения. Разработчики боятся показаться медлительными и обманывают с estimate. Разработчики боятся нарушить план разработки и приносят в жертву внутреннее качество программы, тем самым еще больше затягивая петлю. В общем-то, страхи являются одной из основных решаемых задач Agile разработки, о чем свидетельствует сам факт использования слова “манифест”. Подробно эту тему раскрывают Kent Beck и Martin Fowler в книге “Planning Extreme Programming”.

Страх - всегда от незнания. И лучшей пилюлей от него являются уже упомянутые ранее методики распространения опыта - Collaborative Development.

Профессиональная этика

Важность этой темы саркастически раскрыта в статье “Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом” (оригинал “We fired our top talent. Best decision we ever made.”).

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

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

Хороший специалист всегда заботится об интересах дела, а не о своем положении в этом деле.

Хороший специалист не проявляет нетерпимости к технологиям и инструментам. Во-первых, у него нет необходимости в самоутверждении. Во-вторых, он понимает, что если инструмент диктует условия, то проблема не в инструменте, а в качестве проектирования. Это как в пословице про плохого танцора… Подробно этот вопрос рассмотрел Robert Martin в статье “The Clean Architecture” (в 2017 вышла его одноименная книга). Даже если инструмент перестал устраивать вовсе, то хорошая архитектура обеспечивает заменяемость и адаптируемость. Один из сильнейших специалистов, с которым мне доводилось работать, мог вполне спокойно поработать и с PHP и с, Django, и с Active Record, и с MySQL и т.п. В-третьих, хороший специалист способен иногда и сам создавать хорошие инструменты, если это требуется.

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

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

Хороший специалист не ищет виноватых, потому что умеет не попадать в такие ситуации.

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

Тут я должен заметить, что многие (в т.ч. и представители компаний) ошибочно под термином Soft Skills понимают Конформность. Это не так.

Вопросам профессиональной этики, soft skills и поведению в конфликтных и стрессовых ситуациях много внимания уделяет Robert C. Martin в книге Clean Coder.

Заключение

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

Updated on Oct 15, 2018

Comments

comments powered by Disqus