Connect with us

Разработка

Правильный разработчик

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

AppTractor

Опубликовано

/

     
     

Илья Лебедев на своем сайте поделился своим представлением идеального разработчика. С его разрешения публикуем эту статью.

162906_102455616495620_4479053_n

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

Итак.

Правильный разработчик понимает, зачем он нужен

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

На главной нужен баннер с новой услугой? Наблюдать за конкурентами? Снизить затраты на облако? Перенести диван? Проконсультировать клиента? Разработчик сделает. Подобные просьбы вызваны проблемами. Проблемы у бизнеса. Бизнес — король. Если он просит разработчика — разработчик делает. Разбирается в сложной админке, парсит нужные страницы, переезжает на другой хостинг, помогает с перестановкой.

В этом разница между разработчиком и правильным разработчиком — второй понимает, что он отвечает не за код, а за продукт.

Правильный разработчик проявляет инициативу

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

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

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

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

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

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

Поэтому правильный разработчик так ценен — он постоянно воюет с подобными проблемами. В результате получается [замечательный] продукт.

Правильный разработчик умеет общаться

Такой разработчик понимает, что написание кода — побочный эффект работы. Главная цель — решение бизнес-проблем.

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

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

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

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
8 комментариев

8 Comments

  1. Maxim

    21.04.2016 at 09:12

    Обычный разработчик прочитал и закрыл.

  2. grandundegraund

    21.04.2016 at 11:12

    Промывание мозгов? Зачем? Сделать из разработчика менеджера, что-бы можно было уволить менеджера, и объединить в разработчике две обязанности? Статья рассчитана даже не на разработчика, а на “лох’а”, он скушает…

    • Artem Voronov

      21.04.2016 at 16:25

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

      • grandundegraund

        21.04.2016 at 16:52

        Вы пробовали код написать “не включая мозг”?
        Или писать код думая о том что еще стол тащить надо?
        Причем тут бизнес до перетаскивания столов?
        Конечно, бизнес желает, что-бы один сотрудник делал все, да еще и за 1000 грн/год. Но качество бизнеса от этого не улучшится, каждый должен заниматься своим делом, и это будет оптимальным решением “для бизнеса”. Это 10 лет назад, IT был и курьером и грузчиком, сейчас немножко поменялось все. Только в гос. учреждениях наверное осталось, что сис. админ – и писатель, и читатель, и с бубном плясатель!

You must be logged in to post a comment Login

Leave a Reply

Разработка

“Крутись и уворачивайся”: история разработки Circle vs Spikes

Немного о себе: 30 лет, программированием начал заниматься относительно поздно, всего 2 года назад. Имелся технический бэкграунд, но в целом от программирования был далек. Знакомых кодеров тоже не было, пришлось самому набивать шишки, пытаясь понять, что и как делать. Привлекла идея делать мобильные приложения, так как хотелось работать на себя. Ну а что может быть интереснее геймдева. Таким образом была поставлена цель – научиться делать мобильные игры.

AppTractor

Опубликовано

/

Автор:

Но сначала нужно было изучить основы. Решил взяться за фундаментальные вещи: теория, алгоритмы, проектирование и т.д. Промучившись месяца два понял, что нужно ставить практические задачи, а теорию изучать уже по мере надобности. Стал изучать Java, которая повсеместно используется для Android. Да и фреймворк LibGDX, о котором я уже тогда начал думать, был на Java.

Освоив на достаточном уровне Java и LibGDX, я захотел пройти весь путь от идеи игры до публикации. Хотелось начать с чего-то простого. Пришла мысль сделать 2D-аркаду, в которой надо уворачиваться от препятствий, двигаясь при этом по сложной траектории.

Итак, у меня была неплохая цель – сделать в короткие сроки простую игру, довести ее до публикации в Google Play и, таким образом, набраться опыта. В итоге “короткие сроки” растянулись более чем на полтора года. Частенько я переделывал все с нуля, тратил много времени на каждый этап, добавлял или убирал функционал. Много времени было вложено и в создание редактора уровней. Если игра будет нравится людям, включу его в игру в одном из обновлений. Вот так он выглядит сейчас.

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

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

Крутись и уворачивайся

В игре вы управляете кругом, который движется по орбите. При этом орбита вместе с кругом движутся вперед. Таким образом соединяются две траектории: круговая и прямолинейная. Это делает механику интересной, заставляет просчитывать наперед это сочетание. Кругом надо уворачиваться от множества разных препятствий (шипов, маятников, лазеров, блоков…). Управление при этом предельно простое – касанием экрана можно менять направление вращения по орбите.

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

На то, чтобы сменить направление вращения (другими словами – на каждое касание) требуется 1 заряд. Уровень вы начинаете, имея 100 зарядов. Цель – истратить как можно меньше зарядов за уровень. То есть нельзя бездумно тыкать по экрану, нужно просчитывать траекторию и использовать заряды с умом.

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

Имеется поддержка Google Play Игр:

  1. Достижения – за каждое из которых открывается новый скин или цветовая тема.
  2. Лидерборды
  3. Сохранения и синхронизация между устройствами

Музыку мне сделал друг, специально для игры, за что я ему очень благодарен. Кому интересно, вот ссылка на его страничку в Soundcloud: https://soundcloud.com/octonick.

Также я постоянно делаю новые уровни, так что пройдя все – не спешите удалять игру. Я планирую часто выпускать обновления.

Если у вас есть какие-либо вопросы, пишите, постараюсь ответить всем: ibragames@gmail.com

Комментарии
Продолжить чтение

Новости

Unity переезжает в Google Cloud

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

AppTractor

Опубликовано

/

Автор:

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

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

 

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 19.06

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

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Обучение

Как не застрять в обучении

Это один из самых популярных постов на Medium, получивший уже более 22 тысячи аплодисментов с начала месяца. Тони Мастрорио, со-основатель Whiteboardfree.com, рассказывает о том, как перейти от туториалов к разработке.

AppTractor

Опубликовано

/

Автор:

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

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

Добро пожаловать в учебное чистилище

Итак, вместо того, чтобы создавать собственные проекты, я застрял в том, что я называю «учебным чистилищем». Поскольку я понимал, что учиться –  это хорошо, я читал и смотрел каждый туториал, который мог найти, который казался интересным, который, как я думал, я смогу в один день применить в собственном проекте. Я проводил так месяц за месяцем, заполняя ночи бесконечными видео на YouTube, Udemy и на всех других сайтах, которые я только мог найти. Я многому научился, но забыл чуть ли не больше в процессе.

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

Например, когда я только начинал, я купил и посмотрел курс The Web Developer Bootcamp на Udemy – 43 часа видео по таким темам, как HTML, CSS, Bootstrap, JavaScript и jQuery. Я думал, что курс вышел отличный, но когда я закончил, я все еще не был готов делать собственные проекты.

Вместо этого я вернулся на сайт и купил еще The Complete Web Developer Course 2.0. И посмотрел еще 30 часов видео, охватывающих большинство тех же тем, что и первый курс!

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

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

Нет инструкций – нет проблем

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

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

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

Было много всего, что я не знал, когда начал делать этот первый проект (так же, как и сейчас с каждым новым проектом, который я начинаю). Я не знал, как создать систему авторизации, реализовать разбиение на страницы или использовать AJAX в приложении Rails. Я не знал, как использовать рекурсию для реализации системы комментариев. На самом деле, я даже не знал, что такое рекурсия!

Начните с того, что вы знаете

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

Google стал моим лучшим другом. Это привело меня к Devise и oAuth Rails, которые я бы мог объединить для создания системы авторизации. Devise позволил бы моим пользователям создавать новые учетные записи и входить с ними в систему, а oAuth предоставил бы им возможность входить с использованием существующих учетных записей Google или Facebook.

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

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

Нормально просить о помощи

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

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

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

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

Вы никогда не узнаете, как делать всё (никто не знает), и вам всегда нужно будет искать что-то в Интернете (все ищут). Просто не позволяйте этому мешать вам делать вещи.

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.