Метка «совершенный код»

Доброго времени суток, читатели!

Следующий пост является изложением моих размышлений на тему природы классов и АТД. Эти размышления дополнены интересными цитатами из книг гуру разработки программного обеспечения.

Введение

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

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

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

Зачем нужно создавать методы

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

The Good, the Bad and the Ugly code
Хороший код или плохой? Лично для меня хороший код обладает следующими качествами:

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

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

Почему именно эти критерии? Сразу оговорюсь, речь сейчас идет о разработке ПО для бизнеса (enterprise application). Критерии оценки кода для систем реального времени, самолетов, систем жизнеобеспечения и МКС отличаются.
Читать полностью »

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

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

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

Комментировать или не комментировать?По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
© Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалось моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

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

Советы Google по кодированию на языке Python. Часть вторая: советы по форматированию исходного кода
Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многимам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом.
Читать полностью »

    Мое становление как  программиста началось в 2005 году  и продолжается по
сей  день. Несомненно,  многие  читатели смогут  похвастаться более  обширным
опытом,  но речь  пойдет о  другом.  Мой профессиональный  рост наложился  на
интересный период  - повышение культуры  программирования в рунете,  если это
можно  так  назвать.  Профессионалы  были  всегда,  но сегодня  подкованность
среднего  программиста(во всяком  случае  в сфере  best pracices)  несравнимо
выше, чем тогда.

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

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

Василий Викторович (далее просто Вася) работал в конторе уже третий год. Программист по образованию, он был на хорошем счету у директора Александра Ивановича, тот нисколько не сомневался в его профессиональных навыках и готов был доверить ему любую важную задачу. Директор часто набирал новых сотрудников в помощь Васе, но все они подолгу не задерживались — Вася жаловался, что, мол, плохие с них программисты, работать не хотят, пишут код, в котором сам чёрт ногу сломит, к тому же пичкают повсюду своё ООП и паттерны.
— Вася, так может ты сам поработаешь? Уже десять человек уволили… Понимаю, специалистов в наше время не сыскать, понимаю, одному работать трудно, но может всё-таки попробуешь, а?
— Иваныч, я бы с радостью, но кто тогда мелкими делами будет заниматься? Я пишу важнейшие вещи, а отвлекаться на пустяки всегда очень трудно. Найди мне хорошего человека, Иваныч! Я верю, однажды попадётся тот самый, который сможет работать как я, а то и лучше!
— Да что ты, Вася, я уже убедился — лучше тебя никого мне не найти. Я постараюсь, Вась, постараюсь!
Директор похлопал его по плечу и вышел из кабинета. А Вася нажал Alt+Tab и продолжил читать ленту.
Читать полностью »

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

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

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

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

Qt Coding Style по версии Qt
Привет, читатели!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше,
Читать полностью »


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