Архив метки: разработка

Что должен делать программист когда ему поступает новая задача?

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

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

Ради эксперимента иногда отдавал задачу молодому и перспективному сотруднику в виде «как есть», т.е. без «разжёвывания» и декомпозиции. Конечно же такие задачи совсем зеленому и неопытном сотруднику давать нельзя, по понятным причинам. Мидл же должен, в моем понимании, разобраться с тем что надо сделать в задаче и предложить как минимум 1-2 пути решения, возможно отличающихся от того, который описан в задаче. Так же мидл должен уметь самостоятельно собрать недостающую информацию, по другому «изучить предметную область».

Немного отвлекусь. Постановка задачи крайне сложная тема для каждого. Часто постановщик задачи сам не знает чего хочет и какого результата ждет. В 99% случаев это ведет к провалу задачи и негативу со стороны постановщика задачи - "вы не так делаете, вы не понимаете, вам лень работать". Я тут вижу только один выход - быть кремнем и не принимать задачу пока постановщик не поймет, что все таки он ждет. Это сложно, но так делать надо, умные люди поймут и примут такую позицию, а глупые просто забудут про задачу и придумают что-то новое. Жаль не всегда полезное.

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

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

Условно разделим ход мыслей на несколько частей:

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

В принципе все. Части надо уточнить и сделать более емкими и понятными.

А теперь давайте остановимся на каждой части подробнее.

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

Если задача касается каких-либо частей разрабатываемого продукта — лезем туда, «тыкаем» кнопочки и смотрим что происходит, читаем задачу заново, сверяем с тем что видим на экране.

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

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

Изучение предметной области. Тут сложнее и проще одновременно. Много думать не надо, надо изучать. На этом этапе мы исследуем сперва бизнес-процесс (в контексте этапа, бизнес-процесс — это среда, в которой будет «работать» задача), потом программные продукты, реализацию существующих частей, окружение, в котором работает код, и зависимости.

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

Когда собрали все части предметной области в голове, можно переходить к вариантам решения

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

Каждый вариант должен отвечать нескольким требованиям:

  • решать задачу
  • должен быть реализуем за адекватное время
  • не ломать архитектуру приложения
  • не вносить «мусор» и лишние «костыли» (ха-ха, «лишние»)
  • удобен для использования конечным пользователям

Выбрали варианты? Теперь пробуйте выбрать тот, который окажется полезнее. Тут две крайности — делается быстро, но разовое решение, делается дольше, но универсальное. Надо выбирать что-то среднее. Не закладывайте в код возможности, которые сейчас не нужны, но «возможно потребуются» в будущем. Эти возможности лягут «мертвым грузом» с вероятностью 60-70%. Об этом говорит мой опыт разработки (о ужас, более 14 лет уже о_О).

«Примерка» выбранного варианта на свою картину понимания. А если я сказу, что выбранный вариант неверный? Вы ответите — не может быть! Я же перебрал кучу вариантов, подобрал самый удобный и правильный!

Пусть будет так, но что будет, если начнем его делать? Какова вероятность, что ничего не сломается? Как раз на эти вопросы надо ответить на этом этапе. У ansible есть специальный режим работы, при котором он «проигрывает» плейбук, но не вносит никаких изменений на оборудовании. Dry run. Аналогично надо в голове «проиграть» реализацию, посмотреть на что повлияет. И только после того, как убедились, что вариант не ломает ничего (честно-честно, не ломает) идем дальше. А если все-таки есть шанс сломать — идем назад и ищем еще варианты.

Уточнение деталей. Перед реализацией могут потребоваться какие-то дополнительные данные, примеры. Даже картинки, которые надо куда-то встроить, надо собрать заранее. Если собрал все, что может потребоваться, то вперед — реализация.

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

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

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

А если мешают реализации, то возвращаемся как минимум на три этапа назад, а порой и к самому началу. Правда тут дедлайн — пожар, не успеваем, все сгорит!

Как раз этого варианта боятся многие и не могу принять ответственность за выбранный вариант реализации.

Не торопимся и делаем как надо, а не как заставляют.

Как думает программист?

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

В далеком 2017 году в рамках конференции я участвовал в тренинге (веб архив, спасибо тебе, за то что помог мне найти название тренинга «Управление мотивацией персонала, или как заставить подчиненных работать»). На тренинге была озвучена мысль, что люди разных поколений по разному мыслят и по разному работают. Например поколение, рожденное в 60-70 более усидчивое и трудолюбивое, а поколение 80-90 более свободное, но с более живым умом и нестандартным подходом.

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

В других отделах картина была похожей, младшие сотрудники (джуны) совершали больше ошибок и чаще обращались за разъяснениями к более опытным коллегам за помощью. Часто доходило до крайностей — вопросы возникали такие, которые можно было нагуглить за 1-2 минуты, а ответ было в первых пяти ссылках на первой странице поисковика.

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

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

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

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

Мобильное приложение: IP калькулятор

Со временем мозг любого человека (а программисты, все-таки человеки, иногда…) начинает черстветь, лениться и не хотеть узнавать новое. Это обычный процесс, мозг устает узнавать новое, он думает ему достаточно знаний и так. Но мир не стоит на месте, он летит с огромной скоростью.

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

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

Скриншот

Вот ссылка на него: https://play.google.com/store/apps/details?id=ru.itcow.ipcalc.

Это изображение имеет пустой атрибут alt; его имя файла - png

Что умеет?

  • определение IP сети по IP адресу
  • определение параметров и класса IP сети
  • маппинг IPv4 в IPv6

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

Мобильные приложения для меня не в новинку, но на Ionic приложение делал в первый раз.

Стоило попробовать, однозначно, опыт лишним никогда не бывает.