Рубрика «код» - 2

No comments - 1

«Комментарии должны составлять 5% от общего количества баллов», — заявил мой коллега-преподаватель.

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

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

Я с жаром ему возразил. Приучение к обязательной вставке комментариев — это, наверно, самая вредная привычка программистов, которой обучают в вузах. Если не считать некоторых случаев, в которых использование комментариев оправдано (подробнее о них далее), добавление комментариев — это антипаттерн, а чрезмерно закомментированные кодовые базы, скорее всего, нуждаются в рефакторинге.
Читать полностью »

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

  • Обучение и онбординг новичков.
  • Шеринг кода/процессов и обмен опытом.
  • Пара решает проблему быстрее и реже обращаются за помощью.
  • Повышение производительности.
  • Сплочение коллектива.
  • Увеличение скорости ревью.

Последний пункт стоит пояснить отдельно. Так как при работе в паре процесс ревью, фактически, проходит в фоновом режиме, то и часть ошибок отсеивается еще на этапе написания кода. Благодаря этому итераций на ревью становится значительно меньше. Тут хорошо подходит вот эта картинка:
Как начать программировать в парах - 1

Но давайте начнем с грустного и поговорим о том, что может помешать начать внедрять парное программирование в своей команде.
Читать полностью »

Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.

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

Читать полностью »

Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx) - 1

Ситуация с правами на код в Российской Федерации довольно интересная: по закону разработчик (физлицо) защищён очень и очень сильно. Нужно как-то весьма прилично косякнуть, чтобы оказаться неправым. А вот работодателю нужно довольно много и кропотливо бегать с бубном и бумагами, чтобы получить права на тот самый код, который пишется на его же зарплату.

Давайте рассмотрим, что говорят законы о правах на код с обеих сторон:

  • Когда и какие права возникают у вас (как физлица) на код.
  • Как правильно устроена передача имущественных прав на код работодателю.
  • Тимлид, который делал ревью, — он соавтор или кто?
  • Можно ли коммитить в свой pet-project с рабочего компьютера в рабочее время?
  • Какой геморрой предстоит пройти, чтобы правильно использовать код, если вы его заказали?

И так далее.

Поехали!Читать полностью »

Всем привет, меня зовут Константин. Я занимаюсь разработкой на Java в Tinkoff.ru и люблю SOLID. В этой статье мы сформулируем принцип подстановки Лисков, покажем его связь с принципом Открытости-Закрытости, узнаем, как правильно формировать иерархию наследования и ответим на философский вопрос о том, является ли квадрат прямоугольником.

Принцип подстановки Лисков - 1

Читать полностью »

Введение

Методология разработки имитационных моделей и симуляторов по различным техническим дисциплинам в основном ориентирована на снижение уровня абстракции учебного материала. Наряду с теоретическим учебным материалом наглядное имитационное моделирование того или иного технологического процесса или операции позволяет учащемуся в более полной мере освоить преподаваемый материал с максимальным приближением к естественным условиям. При этом имитационные модели и симуляторы могут рассматриваться только как вспомогательный инструмент учебного процесса. Основное назначение данной категории образовательных ресурсов – базовое (начальное) ознакомление с принципами работы сложных технических объектов в условиях отсутствия возможности использования реального промышленного оборудования, либо в целях предварительного повышения компетенции учащегося перед прохождением производственной практики.
Читать полностью »

image

Есть неожиданно много людей, считающих, что писать код можно как угодно, а все эти правила и рекомендации просто занудство. Что же, у каждого каждого человека есть право на своё мнение.

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

И на то есть причина. Вам никогда не доводилось сталкиваться с усталостью от чтения? Например, сложной технической литературы, канцелярита, другого языка? Уверен, что доводилось. И да, это именно усталость, пусть и не та же что и при физических нагрузках. Сложный для чтения текст значительно сильнее расходует ресурсы мозга.

Код это тоже текст. И написать его можно так, что чтение станет крайне неприятным и энергозатратным занятием. Если вам вдруг во время работы с особенно ужасными фрагментами корпоративного портала хочется закрыть редактор и посмотреть котиков, то дело, скорее всего, не в том, что вам лень или внезапно случилось то самое выгорание. Всё дело в том, что именно вы читаете.Читать полностью »

Полезные разработчику привычки - 1

Благодаря которым вы станете лучше как программист

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

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

Переведено в Alconost
Читать полностью »

Культура разработки: как оценивают производительность и эффективность - 1
(c)

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

Вслед за сотнями различных KPI, которыми пытались обвесить программистов, появилось множество различных методов анализа рабочих данных — от отслеживания направления взгляда на монитор до Scrum и Kanban. Измерения качества труда настолько хорошо работали во многих отраслях, что казалось вполне логичным перенести данный опыт на разработку программного обеспечения. Результат оказался обескураживающим.

Измерения и управление продуктивностью разработчиков не привели к появлению единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики… отдельные из них практически невозможно сравнить с традиционными KPI в других сферах деятельности.

В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.
Читать полностью »

Привет! Предлагаю вашему вниманию перевод статьи «Pragmatic Functional Programming» автора Robert C. Martin (Uncle Bob).

Переход к функциональному программированию всерьез развился только около десяти лет назад. Мы видим, что такие языки, как Scala, Clojure и F# привлекают внимание. На самом деле это был большой шаг в программировании: “О, круто, новый язык!” — энтузиазм… Видимо там было что-то особенное — ну или это мы так думали.  

Закон Мура гласит нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Данный закон действовал с 1960-х до 2000 годов. Затем он прекратился. Частота достигла 3 ГГц, а затем и вовсе поднялась на плато. Мы достигли скорости света! Сигналы не могут распространяться по поверхности чипа достаточно быстро, чтобы обеспечить более высокие скорости. 

Это привело к тому, что инженеры оборудования изменили свою стратегию. В попытках увеличить пропускную способность, они добавили больше процессоров (ядер). А чтобы освободить место для этих ядер, они удалили большую часть оборудования для кэширования и конвейеризации из чипов. Из-за этого процессоры стали намного медленнее, чем раньше; однако их стало больше. В итоге увеличилась пропускная способность. 
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js