К основному контенту

Простые правила хорошего разработчика

Первоначально этот пост планировался как перевод статьи "15 Tenets for Software Engineer". Но по мере написания становилось понятно, что в чистом виде перевод не катит. Поэтому получилось то, что получилось. Допускаю, что все это выглядит, как очередной флуд из серии "умные идеи от Капитана Очевидность", но мне статья понравилась и я постарался выразить свое мнение по данному вопросу (ниже по тексту для этого используется курсив). В конце концов, иногда очевидные вещи услышанные (прочитанные) в очередной раз, могут помочь окончательно сформировать мнение по тому или иному вопросу.

На этом месте большинство может перейти на оригинал и не терять время на попытки найти неточности в переводе - их масса :)

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

Попытаемся объединить все это.

Итак, чтобы быть успешным, разработчику нужно выполнять следующие простые правила:

  • Помнить базовые основы языка программирования. Всегда. Если ты забываешь (не будем говорить "не знаешь") эти основы, ты теряешь инструмент, без которого ты не можешь применять остальные знания и умения. Это всегда плохо. По себе могу сказать, что как только не используешь язык больше чем полгода, ты начинаешь забывать много тонкостей. Часто я использую разные языки для разных задач, это помогает освежать знания.
  • Всегда понимать, какой сценарий наихудший. Если у вам довелось изучать алгоритмы (мне, например, в военном училище это счастье не привалило), то вы знаете что означает нотация "О". Знаете, почему алгоритм не может работать лучше - хорошо. Понимаете, почему данный сценарий хуже, чем остальные - отлично. Это то, что позволит вам оставаться успешным. В реальных проектах лично мне редко случалось оценивать именно алгоритмы и выбирать из них лучший. Чаще при оценке приходится учитывать множество факторов, а не только скорость определенного алгоритма. Но почему-то на собеседованиях спрашивают именно об оценке сложности алгоритма. Поэтому, я думаю, имеет смысл поддерживать себя в тонусе и освежать теорию. Например, вот недавно наткнулся на бесплатный онлайн-курс от Стенфордского университета Design and Analysis of Algorithms.
  • Читайте, много читайте. Если вы не читаете материалы посвященные вашей сфере деятельности, то рискуете отстать от постоянно изменяющегося мира. Это может стать препятствием для вашего карьерного роста. "6 книжек которые должен прочитать каждый разработчик"
  • Проверяйте, тестируйте свой код. Добивайтесь того, чтобы у вас были тесты на ваш код, неважно следуете ли вы TDD практикам или используете другие способы. Уровень покрытия кода тестами зависит от типа тестов, но вы должны писать столько тестов, сколько можете. В качестве одного из критериев оценки необходимости написания автоматических тестов можно использовать стоимость написания и последующего запуска тестов. Думаю, есть вещи которые все же дешевле проверить руками, нежели написать тесты. В конце концов код для тестов - это тоже код, для него тоже пишем тесты? Включаем мозги и решаем, что тестируем автоматом, а что ручками. И помните, тестирование не улучшает качество, а измеряет его.
  • Не начинайте использовать новые технологии только потому, что они новые. Используйте их, если они решают вашу проблему. Часто мы следуем новым технологиям в надежде найти "серебряную пулю". Технологии это инструмент, а не волшебство.
  • Пробуйте новые практики и технологии. Постоянно. Да, выше уже говорилось, что не надо использовать новые технологии просто потому, что они новые. Но вы должны пробовать новое, хотя бы для того, чтобы определить, чем оно вам будет полезно. Это также поможет учится и быть в курсе всех последних веяний. Да это сложно, найти баланс между "использовать" и "пробовать". Чаще бывает проще взять и "заюзать", а дальше посмотрим. Не всегда у вас есть возможность сначала обкатать технологию, понять все ее плюсы и минусы, и только после этого принять решение о целесообразности ее использования. Более того, часто, эти самые плюсы и минусы можно увидеть только после реального использования в «продакшене». Но смотри следующий пункт.
  • Ошибаясь, вы учитесь. Как минимум вы поймете, что именно не работает и сможете улучшить свой продукт. В некоторых случаях вы даже можете рассматривать неудачу как маленький успех.
  • Отношение к выдаче «сырого» кода. Иногда вам нужно просто выполнить свою задачу, но вы должны понимать и оценивать оставшиеся долги (если они есть). Если вы постоянно отдаете «сырой» код и накапливаете свои долги, то это прямой путь к кошмару, который настигнет вас, когда в продукте вылезет бага.
  • Делайте «все правильно». Большинство разработчиков имеют свое представление о том, как сделать «все правильно», но не всегда это совпадает с мнением менеджера проекта. Этот пункт можно рассматривать как противоположность предыдущему пункту про выдачу «сырого» кода. Нужно пытаться удержать баланс между этим крайностями.
  • Постоянно улучшайте код: оставляйте код в лучшем состоянии, чем он был на тот момент, когда вы начали с ним работать. Вместо проповедей о достоиствах рефакторинга, подумайте, хотите ли вы поддерживать кучу кода, который становится все хуже. Если вы будете улучшать код по чуть-чуть каждый раз, когда вы его меняете, то код уже не будет ужасным. Ну или, по-крайней мере, хуже он становится точно не будет.
(Дальше идут совсем банальные вещи, но как часто я встречал случаи, когда их игнорируют...)
  • Думайте об одновременном доступе. Если вы разрабатываете веб-приложение, и разговор вовсе не идет о приложении масштаба Facebook-а, то при нагрузке могут вылезти странные вещи. Даже у приложения со 100 одновременно работающими пользователями могут возникнуть проблемы из-за параллельных операций записи и чтения например в HashMaps. И это только вершина айсберга.
  • Места на диске может быть много, но I/O операции могут тормозить. Вы можете полагать, что сохранять все на диск, это отличный способ хранения данных. В общем случае это так, но если вы используете диск как временное хранилище, ваше приложение может быстро споткнуться. Использование физического хранилища должно быть ограничено только теми случаями, когда данные нужно хранить долго, или они просто не помещаются в памяти.
  • Кэш творит чудеса, до тех пор, пока не умирает сервер. Если вы ищете способы избежать повторяющихся запросов к базе, вы начинаете использовать кэширование. Но проблема в том, что кэш требует гораздо больше памяти, чем обычно использует ваше приложение, особенно когда разговор идет о данных, размер которых увеличивается с увеличением количества пользователей. Худшее, что может случится с кэшем, это неконтролируемый рост его размера, что приводит к OutOfMemory ошибке. После этого ваш сервер или «упадет», или перестанет отвечать на запросы. И кэширование уже не поможет, так как стало частью проблемы.
  • Думай и действуй как консультант. Очень часто компании могут поступать с сотрудникам так, как не поступили бы с консультантами: сроки могут быть изменены, объем работ увеличен. И разработчик должен найти способ решить задачу с учетом изменившихся реалий. Как сотруднику, вам нужно использовать все силы для того, чтобы предупредить о том, что сроки не могут быть изменены ввиду имеющегося объема работ, или что объем работ не может быть увеличен без увеличения количества задействованных ресурсов.
  • Внимание к деталям и уважение. От себя добавлю, что хорошего разработчика отличает внимание к деталям и уважение к результату своего труда . Если ты просто генеришь строчки кода без понимания того, зачем они нужны, без проверки того, что они действительно работают - ты не можешь себя считать хорошим разработчиком. Уважение надо также проявлять к тем, кто помогает оценить качество твоей работы, тестировщикам. В конце концов задача у нас одна - получить готовый продукт достойного качества.
PS перечитав еще раз это творение, почему то вспомнился анекдот про начальника, который согласно первому пункту всегда прав, а если не прав - смотри пункт первый. Уж очень, как то, все банально получилось. Надеюсь вы тоже повеселились :)

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе...