Рубрика «Совершенный код» - 53

Сегодня, 25 февраля, вышла версия 1.5.0 языка CoffeeScript. В ней впервые появилась базовая поддержка так называемого «грамотного» или «литературного» программирования (literate programming). Концепцию грамотного программирования придумал Дональд Кнут в 1981 году при разработке системы TeX. В отличие от исходного кода на обычном языке программирования, который включает в себя небольшие вкрапления комментариев, грамотное программирование подразумевает написание текстового документа на естественном языке с вкраплениями кода. Многие существующие системы грамотного программирования вообще не зависят от конкретного машинного языка.
Читать полностью »

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

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

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

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

С чего все началось

Я студент технического университета и учусь по направлению: «Высшая математика, информатика и математическое моделирование». Так как я учусь только на втором курсе — мой код совершенным назвать очень сложно. В прошлом семестре мы изучали такую дисциплину как «Современные парадигмы программирования». На одной из лекций мы рассматривали ООП на примере С++ и получили задание написать псевдо-музыкальную библиотеку с использованием структур.

Задание и первая версия программы

Программа должна была использовать структуру из 5-ти полей:
Поле №1: номер записи;
Поле №2: название трека;
Поле №3: имя исполнителя;
Поле №4: время звучания;
Поле №5: год записи.
Это должна была быть консольная программа, все данные в которую вводятся с клавиатуры или с текстового файла (по желанию писавшего). Вводимые данные сохраняются в память компьютера или в файл соответственно. Также программа должна исполнять такие команды:
Поиск: по номеру, названию, исполнителю, времени и году записи а также вывод всех записей на экран;
Изменение данных: удаление, редактирование и добавление новых записей;
Редактирование: возможность изменения всех полей кроме номера записи.
Читать полностью »

Напиши алгоритм для МКС и выиграй 10 тыс. долларов
Международная космическая станция

НАСА объявило конкурс на оптимизацию алгоритмов движения солнечных панелей для Международной космической станции. Конкурс ISS Longeron Challenge проводится совместно с порталом TopCoder.
Читать полностью »

Конфиг с человеческим лицом? Билдер!Многие фреймворки любят магию и сложные многоуровневые массивы для конфигурации/передачи параметров. Что первое, что второе — зло с точки зрения истинно-ленивого программера, который любит IDE и доки всегда под рукой, а не тыкать в интернет/тело вызываемого метода. Мы можем победить это, как образец взяв параметры метода из одного фреймворка и создав конфиг-билдер.
Читать полностью »

ООП билдер «массивных» параметровМногие фреймворки любят магию и сложные многоуровневые массивы для передачи параметров. Что первое, что второе — зло с точки зрения истинно-ленивого программера, который любит IDE и доки всегда под рукой, а не тыкать в интернет/тело вызываемого метода. Мы можем победить это, как образец взяв параметры метода из одного фреймворка и создав ООП-билдер.
Читать полностью »

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

Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.

Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.

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

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

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

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

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

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

Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.

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

Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.

И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»

Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.

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

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

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

Чтобы расширить свой кругозор, а также получить ответ на свои внутренние вопросы, добро пожаловать под кат…
Читать полностью »

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

Простое написание тестов — это не TDD!
Читать полностью »


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