Обзор месяца кодирования на предмет продуктивности и качества кода.
В прошлом месяце в октябре по разным причинам у меня было больше времени на программирование, чем, вероятно, когда-либо.
В течение одной недели я мог сосредоточиться на программировании практически каждый час бодрствования. На той неделе я занял первое место в таблице лидеров часов программирования Wakatime, с записью более 90 часов времени программирования.
Как и почему это произошло? Позвольте мне немного отступить.
Моя семья и я живем в Шэньчжэне, Китай, который находится рядом с Гонконгом. Первая неделя октября - главный национальный праздник здесь.
Большинство компаний закрываются на неделю, и люди возвращаются в свои города на каникулы. Итак, моя жена, которая из Китая, решила забрать наших двоих детей в свой родной город, чтобы навестить моих родственников.
Родственники проживают в довольно удаленном месте, на крайнем Севере, на границе с Россией и Северной Кореей. Это 14-часовая поездка в одну сторону. Итак, моя жена планировала остаться на весь месяц. Тем временем я остался работать в Шэньчжэне.
Теперь это отличная поездка на север, чтобы увидеть родственников. Я могу бросать камни через реку в Северной Корее. И неизбежно в каждой поездке мои родственники долго говорят о том, насколько я стал толще с момента последнего визита.
Затем они делают мне иглоукалывание и готовят вкусные китайские лекарства для питья три раза в день. Да, мне не хватало хороших времен в доме свекрови. К счастью, я на диете и скоро увижу их снова, в феврале.
Но давайте посмотрим правде в глаза. В остальном это было великолепно. Я люблю кодить. Но в свободное время, когда дети ползают по вам, сложно получить это целенаправленное зональное время.
На данный момент я использую Wakatime для отслеживания часов программирования уже около трех лет. За все это время я ни разу не пытался часами писать код №1. Я просто пытаюсь выпустить полезное программное обеспечение для своего бизнеса.
Но когда я посмотрел после нескольких +12-часовых дней программирования в этом месяце и оказался в первой десятке, с женой и детьми за городом, ну ладно, игра началась. Но это было непросто, и этого почти не произошло.
Один программист по имени Владислав Волков день за кровавым днем пришел в ярость со своим PHP-фу. Я видел дни, когда 70 часов за последнюю неделю занимали первое место. Нет, не на этой неделе. Черт, я чувствовал себя как в Рокки IV. Мне пришлось ответить несколькими поездками на целый день, чтобы наконец занять первое место у Владислава и, в конечном итоге, поддерживать его в течение всего дня.
Трудно найти такой конкурентный драйв, когда вы пишете код в одиночку и не отслеживаете свое время!
Теперь время для наблюдений и выводов. Я хочу проверить, как моя октябрьская работа влияет на продуктивность программирования и качество кода?
Я знаю, что некоторые из вас, хакеры, могут сразу подумать: «Если он потратил 90 часов на программирование в неделю, это, вероятно, означает, что его навыки не очень хороши».
Что ж, я руководство. Не совсем профессиональный программист. В течение недели мне нужно делать много другой работы, помимо программирования. Так что, возможно, в этом есть доля правды.
В течение последних семи лет я уделял серьезное внимание программированию на Python. До этого мои навыки в основном сводились к тому, чтобы быть стандартным жокеем Excel с MBA, с несколькими базами данных Access, добавленными для углубления. Что, кстати, может пригодиться Access. Никакого пренебрежения с моей стороны.
С этим практика приводит к совершенству. Одна особенность Wakatime, которая мне нравится, заключается в том, что она позволяет установить текущую цель для часов программирования. Вот уже несколько лет у меня есть постоянная цель - заниматься программированием по 30 часов в неделю.
Достичь этой 30-часовой отметки помимо всего остального, с чем я имею дело на работе и в семье, сложно. Когда мне это удается, то либо у меня была редкая неделя, когда все шло исключительно гладко, либо я старался изо всех сил, чтобы это произошло.
Но теперь, после нескольких лет работы и практики, я, наконец, достигла той точки, где могу удерживать пальцы на клавиатуре, когда у меня есть время писать код. Для меня это далось нелегко.
Кроме того, после 12-часового рабочего дня может быть шоком то, что в конечном итоге начисляются только часть этого времени. В моем случае это обычно происходило из-за: 1) чтения внешних документов, 2) поиска в Google и 3) переполнения стека поиска.
Все это в определенной степени великолепно. Но ими легко злоупотреблять, и они в конечном итоге могут стать препятствием для реального улучшения навыков.
При этом ключевое поведение, отслеживающее мое время написания кода, помогло мне измениться: теперь я читаю намного больше исходного кода в качестве первого источника. И моя работа от этого лучше.
Так над чем я работаю? Ну, с верхнего уровня. Текущий непрерывный опыт проектирования и производства продуктов, изготовленных по индивидуальному заказу, действительно отстой. Я создаю BOM Quote Manufacturing с целью сделать его лучше.
Стратегию, которую я выбрал при запуске BOM Quote MFG семь лет назад из-за необходимости зарабатывать себе на жизнь во время начальной загрузки, я называю «Factory First».
Под этим я имею в виду буквально: сначала мы построили полностью лицензированный экспортный завод CM в Шэньчжэне, Китай. Мы помогаем клиентам создавать и отправлять их индивидуально разработанные розничные упакованные продукты.
Чтобы создать нашу частную фабрику в Китае, потребовалось несколько лет работы с огромной дозой терпения. Теперь мы разрабатываем специальное программное обеспечение, чтобы помочь нам улучшить наши услуги, повысить эффективность и масштабируемость.
При этом почти все мои 30 часов в неделю на программирование за последние три года были направлены на создание нашего основного веб-приложения bomquote.com. Он направлен на то, чтобы обернуть прочный слой коммуникации и процессов вокруг нашего взаимодействия как с клиентами, так и с поставщиками.
Одна из проблем, с которыми мы постоянно сталкиваемся, сводится к сбору и усвоению данных, доступных в Интернете.
Например, данные о ценах и состоянии запасов электронных компонентов, которые перечислены на многих веб-сайтах, которые продают такие вещи.
Дело в том, что большая часть данных, необходимых для продвижения котировок, особенно на ранних этапах процесса разработки продукта, доступна в Интернете. Нам нужно автоматизировать сбор данных в Интернете.
Итак, я представляю Transistor, гибкий фреймворк для парсинга и сохранения данных. Транзистор станет ядром наших собственных усилий по сбору веб-данных в BOM Quote Manufacturing.
Transistor поддерживает использование scrapinghub Splash службы рендеринга javascript в качестве автономного браузера. Он также поддерживает их сервис умный прокси crawlera. Transistor использует такие известные библиотеки, как python-requests, beautifulsoup4, Mechanicalsoup и gevent. Scrapy не требуется.
Честно говоря, на этом этапе вам, вероятно, следует просто использовать Scrapy, если вы не подозреваете, что у вас есть веские причины не использовать его, как это сделал я. Но более подробное описание транзистора и его использования лучше оставить в README и будущих статьях.
Transistor начинался как служебный модуль внутри нашего основного веб-приложения bomquote.com. Я работал над ним около 32 часов и написал первые 2000 строк кода, прежде чем решил разбить его на отдельный репозиторий.
Эти первые 32 часа и 2000 строк кода выделены зеленым цветом на диаграмме выше. И ниже показано, как выглядит мое время в Wakatime для репозитория для транзисторов, начиная с первоначального коммита с этими первыми 2000 LOC 7 октября:
Таким образом, в октябре я наработал на Transistor около 220 часов. С учетом примерно четырех дней перерыва в программировании, что составляет немногим более 8 часов в день в среднем за день, когда я работал.
У Вакатима кончаются ноги. Я использую другие приложения для понимания, в том числе codecov.io и codeclimate.com. Эти две части немного пересекаются, поскольку Code Climate предлагает некоторую обратную связь о тестовом покрытии, если вы его используете. Хотя я всегда предпочитал продолжать использовать codecov.io для покрытия тестов из-за его пользовательского интерфейса.
Но, без сомнения, Code Climate - лучший сервис, который я использую для обратной связи по своему коду, кроме покрытия тестами. А вот как Transistor выглядел в конце октября на странице обзора в Code Climate:
При нажатии на вкладку «Тенденции» откроется страница «Ремонтопригодность» с несколькими различными разделами. По умолчанию отображается первый раздел «Технический долг», показанный ниже:
В разделе «Технический долг» я начал с 50-часового технического долга на мою первую фиксацию в тех первых 2000 строках кода. Но первые 2000 строк кода заняли у меня всего 32 часа. Итак, я закодировал 32 часа, чтобы создать 50 часов технического долга? Кажется немного неуместным.
В течение следующих двух недель общее количество часов долга увеличилось, в то время как отношение долга к количеству строк кода уменьшилось, поскольку я добавил еще 2000 строк кода. Хотя за это время добавляется только 20 часов технического долга.
Итак, что такое технический долг? По сути, это мера примерного времени, необходимого для решения элементов, которые, по мнению Code Climate, я должен исправить в своем коде.
Например, функции и методы классов с высокой «когнитивной сложностью». В моем случае было два файла с оценкой «D» для моего первоначального прохода на низкоуровневой логике парсинга веб-сайта, с примерно 300 строками кода в каждом файле.
Я знал, что этот код был неприятным, когда писал его, но спасибо Code Climate за его подтверждение. И большинство из 463 других проблем - это нарушения PEP-8 в отношении длины линейного кода. Должно быть 79 символов, а я установил 88 символов. Жаль не жаль.
Забрать? Я люблю кодовые оценки и нюхать основные моменты. Но мне также кажется, что они переоценили рабочую нагрузку по техническому долгу. На устранение большинства отмеченных проблем технического долга у меня уйдет как минимум один день. Определенно, не семьдесят часов работы.
Кроме того, он настолько отклонен, что мне не хотелось бы подвергать свою команду этим оценкам времени в качестве якорных точек. Алгоритм изменения климата кода может использовать некоторую настройку управления. Не следует слепо принимать этот номер от команды.
Далее в Code Climate есть диаграмма строк кода. Это показывает, что моя первая фиксация репозитория была 8 октября. И это показывает, что в октябре я передал Transistor около 4000 строк кода.
В первую неделю разработки Transistor у меня был открытый холст. Так что написать 2000 строк кода на Python с нуля было несложно. Но после этого штамповать строчки стало сложнее.
На этой диаграмме показано, что я написал только 800–900 строк, за неделю, когда я отработал 90 часов, с 17 по 24 октября. Оглядываясь назад, я понял, что к тому времени я был более ограничен в своем холсте и потратил большую часть недели на оптимизацию сценариев Lua, чтобы сократить время сканирования. В результате мой LOC на рабочий час быстро упал.
Забрать? Строки кода помогают рассказать историю, но это не полная история. Производительность, измеряемая на LOC, должна производиться с учетом ситуации.
Теперь, если вы зашли так далеко, некоторые из вас, приверженцы TDD, могут сказать: «Но тестовое покрытие! Как тесты! »
Я люблю тесты. И мы будем использовать Transistor в нашем веб-приложении bomquote.com, которое в настоящее время имеет более 1300 тестов. Я написал 24 теста, чтобы убедиться, что я ничего не нарушаю, абстрагируясь в более общую структуру.
Но, работая в одиночку над новым фреймворком с перемешивающим API в режиме создания, я предпочел бы писать большинство тестов, когда закончу создание. Это работа без часового пояса, которую я могу подобрать между тем, чтобы помогать своим детям играть в Майнкрафт.
Далее замечание об эргономике. Я использую классические аксессуары Microsoft Sculpt и не пытаюсь заниматься программированием целый день без них. Я также всегда использую высококачественный прочный алюминиевый трекпад, который при прикосновении к моей коже остается очень прохладным. Это успокаивает мое запястье, когда я использую мышь.
И, наконец, если вы не пользуетесь программой учета рабочего времени, такой как Wakatime, я могу порекомендовать ее. Я, вероятно, был бы примерно наполовину менее продуктивным, если бы не отслеживал свое время. Если вы серьезно относитесь к написанию кода, следите за своим временем.
Удачного кодирования!
