манифест программиста пиши код
Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина
Данная статья является конспектом книги «Чистый Код» Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.
Да, возможно, тема Чистого Кода уже заезженна, но тем не менее еще не все с ним знакомы и, тем более, я не встретил аналогов контента, который содержится в моей статье.
Общее
Нет истинного пути и решения. Есть тот, который лучше всего подходит для решения конкретной задачи.
При решении задачи попытайся воспроизвести абсолютно все кейсы, которые могут затрагивать эту задачу и реализуй задачу с учетом абсолютно всех кейсов.
Также при решении задачи попробуй пойти от обратного. Пойми какие результаты в итоге ты хочешь получить и составь на этом основании алгоритм, по которому будет выполняться задача.
Перед тем, как отправить задачу в релиз — проверь правильно ли она работает. Нет ли в ней ошибок. Это касается даже тех коммитов, которые отправляются в твою ветку. Самый идеальный сценарий — тот, в котором никто не смог найти ошибки в функционале, который ты разрабатывал.
Всегда задумывайся о том как можно сделать твой код проще, чище и читабельнее.
Чистый Код
Как писать чистый и хороший код? Это похоже на написание книги. Сначала ты делаешь черновик и потом причесываешь его до того состояния, в котором тебе было бы приятно его читать. Всегда помни, что твой код должен рассказывать историю происходящего, чтобы читатель мог ее понять.
Под сущностью понимается — интерфейс, класс, метод, переменная, объект и т.д.
Наименования и разделения
Функции
Комментарии
Форматирование и правила
Объекты и структуры данных
Классы
Обработка ошибок
Границы
Послесловие
В данной статье представлены лишь рекомендации к написанию Чистого Кода. Разумеется, ими можно пренебрегать. Вам лишь стоит понять, что у любого вашего решения должны быть аргументы в пользу него.
«Манифест начинающих программистов из смежных специальностей» или как я дошел до жизни такой
Сегодняшняя моя статья — это мысли вслух от человека, который встал на путь программирования почти случайно (хотя и закономерно).
Да, я понимаю, что мой опыт — это только мой опыт, однако он, мне кажется, хорошо попадает в общую тенденцию. Более того, опыт, описанный ниже, больше относится к сфере научной деятельности, однако чем чёрт не шутит — может пригодится и вне.
Источник: https://xkcd.com/664/
В общем, всем настоящим студентам от бывшего студента посвящается!
Ожидания
Когда в 2014 году я заканчивал бакалавриат по специальности «Инфокоммуникационные технологии и системы связи» я почти ничего не знал о мире программирования. Да, у меня, как и у многих, был на первом курсе предмет «Информатика» — но, господи, это же было на первом курсе! Прошла целая вечность!
В общем и целом, ничего особенно отличного от бакалавриата я не ждал, и поступая на магистерскую программу «Communication and Signal Processing» Германо-Российского Института Новых Технологий.
Мы были всего вторым набором, и ребята с первого ещё только собирали чемоданы в далёкую Германию (стажировка занимает полгода на втором курсе магистратуры). Иначе говоря, никто из ближайшего круга ещё не сталкивался всерьёз с методами европейского образования, и спрашивать о деталях было особо не у кого.
Были у нас на первом курсе, конечно, разного рода практики, на которых обычно нам демократично предлагался выбор между написанием скриптов (преимущественно на языке MATLAB) и использованием разных узкоспециализированных GUI (в том смысле, что без написания скриптов — сред имитационного моделирования).
Стоит ли говорить, что мы, будущие Masters of Science, по своей юношеской дурости, как огня, сторонились написания кода. Вот, он, допустим, Simulink от компании MathWorks: вот они блоки, вот они связи, вот они всякого рода настройки и переключатели.
Источник: https://ch.mathworks.com/help/comm/examples/parallel-concatenated-convolutional-coding-turbo-codes.html
Реальность
Одной из практических работ первого семестра была разработка приёмопередатчика OFDM сигнала в рамках предмета «Methods for Modeling and Optimization». Идея весьма удачная: технология и по сей день актуальная и довольно популярная в силу использования, например, в сетях Wi-Fi и LTE/LTE-A (в виде OFDMA). Самое то для магистров, чтобы потренировать навыки моделирования телеком систем.
И вот на руки нам выдают несколько вариантов ТЗ с заведомо непрактичными параметрами кадра (дабы не искать решение в Интернете), и мы накидываемся на уже упомянутый Simulink… И получаем чайником действительности по голове:
Да, проект в итоге мы, конечно, доделали, но доделали с громким выдохом облегчения.
Прошло некоторое время, и мы подошли к окончанию первого курса магистратуры. Количество домашних работ с использованием GUI стало пропорционально спадать с увеличением доли немецких предметов, хотя ещё и не достигало точки смены парадигмы. Многие из нас, включая меня, преодолевая свою немалую амплитуду на раскачку, всё больше и больше использовали в своих научных проектах именно Matlab (пусть и в виде Toolbox’ов), а не знакомый, казалось бы, Simulink.
Точкой в наших сомнениях стала фраза одного из студентов второго курса (они как раз к тому времени вернулись в Россию):
Заявление оказалось верным отчасти: в Ильменау спор о выборе инструментария тоже не был решен до конца. Правда, выбор стоял по большей части между языками MATLAB, Python и C.
В тот же день меня взял закономерный азарт: а не перенести ли свою часть модели OFDM передатчика в скриптовую форму? Just for fun.
И я приступил к работе.
Step by step
Вместо теоретических выкладок я просто дам ссылку на эту прекрасную статью 2011 года от tgx и на слайды по физическому уровню LTE профессора Мишель-Тиля (ТУ Ильменау). Я думаю, этого будет достаточно.
«Итак, — подумал я, — повторим, что же мы будем моделировать?»
Моделировать будем генератор OFDM кадра (OFDM frame generator).
Что он будет включать:
От чего (простоты ради) мы абстрагируемся:
Блок-схема рассматриваемой модели. Остановимся мы до блока обратного БПФ (IFFT). Остальное для полноты картины каждый может продолжить сам — я обещал преподавателям с кафедры оставить что-то и для студентов.
Определим для себя тех. задание:
Определим входные параметры:
Теперь определим индексы информационных символов, приняв предпосылку, что пилотные сигналы должны обязательно идти до и/или после нулей:
Тогда позиции можно определить с помощью функции linspace, приведя значения к наименьшему из ближайших целых:
Добавим к этому индексы нулей и отсортируем:
Соответственно, индексы пилотных сигналов — это всё остальное:
Теперь давайте разбираться с пилотными сигналами.
У нас есть шаблон (переменная pilots), и, допустим, мы хотим, чтобы в наш кадр пилоты вставлялись из этого шаблона последовательно. Сделать это, конечно, можно в цикле. А можно немного помудрить с матрицами — благо MATLAB позволяет делать это с достаточным комфортом.
Во-первых, определим, сколько таких шаблонов помещается в кадр полностью:
Далее формируем вектор, который состоит из наших шаблонов:
И определяем небольшой вектор, который содержит только кусок шаблона — «хвост», не поместившийся полностью в кадр:
Получаем пилотные символы:
Переходим к информационным символам, а именно сформируем сообщение и промодулируем его:
Всё готово! Собираем кадр:
Получится должно что-то такое:
«Кайф!» — подумал я довольно и закрыл ноутбук. Ушло у меня на всё про всё пару часов: включая написание кода, изучение некоторых матлабовских функций и продумывание математических трюков.
Какие выводы я тогда сделал
Субъективные:
Объективные:
И теперь, будучи уже далеко не студентом, я хочу сказать студенческой братии следующее:
Пробуйте писать код, пусть даже поначалу он будет плохим. С программированием как и с любой другой деятельностью, лиха беда — начало. А начать лучше раньше: если вы ученый или даже просто технарь — рано или поздно этот навык вам понадобится.
Требуйте от преподавателей и научных руководителей прогрессивных подходов и инструментов. Если это, конечно, сколько-то возможно…
Где же ещё лучше всего переболеть всеми болячками новичка, как не в рамках образовательной программы? Творите и оттачивайте своё мастерство — опять же чем раньше начать, тем лучше.
Начинающие программисты всех стран, объединяйтесь!
Дабы запротоколировать своё прямое отношение к студенчеству, прикладываю памятное фото 2017 года с двумя ректорами: Петером Шарффом (справа) и Альбертом Харисовичем Гильмутдиновым (слева).
Стоило закончить программу как минимум ради таких костюмов! (шучу)
Манифест жёсткого программиста
Предисловие
В настоящий момент существует огромное количество людей, которые принимают данный «манифест», соглашаются с ним, и даже пытаются применять. Но лично для меня это выглядит как шутка, которая затянулась.
Содержание
Манифест жёсткого программиста
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят
То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.
Основополагающие принципы манифеста жёсткого программиста
Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы.
Изменение требований возможно, но новые требования должны пройти те же стадии осмысления, которые прошли и все старые требования. Заказчик должен осознавать, что изменение требований может повлечь переработку продукта.
Продукт следует выпускать только тогда, когда он достигнет необходимого уровня качества. Нет, и быть не может никакой фиксированной периодичности.
Каждый должен разбираться в том, что он делает, и стараться делать это хорошо. Неудачно сделанная работа по продажам или планированию не должна превращаться в бесконечный поток поправок к требованиям или срокам, то есть перекладываться на инженеров.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Непосредственное общение не должно мешать непосредственной работе. Проводите совещания тогда, когда они необходимы рабочему процессу.
Качественный продукт — основной показатель успеха.
Никто не должен работать «на износ». Работать нужно спокойно, не следуя ничем не обоснованным «ритмам» и «циклам». Переработки недопустимы.
Постоянное внимание к техпроцессу повышает качество, надёжность и гибкость системы.
Самые лучшие требования, архитектурные и технические решения рождаются у команд, которые плотно работают над требованиями, архитектурными и техническими решениями.
Полезно проводить доклады и семинары, чтобы повышать общий профессиональный уровень и степень вовлечённости в общий процесс.
Комментарии к манифесту
Концепция важнее новых требований
Перед началом разработки ПО необходимо сделать две вещи:
Если заказчик внезапно прибегает с новыми требованиями, то нужно быть не «готовым к изменениям», а готовым к сопоставлению новых требований со старой концепцией.
Если требования ложатся на существующие матмодель и архитектуру — прекрасно. Ставим задачу в очередь. Если не ложатся, то нужно либо скорректировать или отбросить новые требования, либо изменить матмодель и архитектуру так, чтобы требования на них легли. А это новое планирования, возможное переделывание того, что уже сделано, то есть время и деньги.
Если заказчик этого не понимает, то нужно ему это терпеливо объяснять, а не бросаться по первому зову бежать в направлении, указанном мимолётным мановением его царственной руки. В противном случае вместо ПО выходит куча смердящих отбросов.
Качество важнее скорости
Иначе говоря, техпроцесс важнее сроков.
На стройке ходят в касках. Почему? Потому что этого требует техника безопасности.
Разработчики ПО пишут тесты и документацию. Почему? Потому что такова технология производства ПО.
Многочисленные конторы вываливают тонны неработающего или плохо работающего, кхм, ПО, вместо того, чтобы потратить немного времени, чтобы довести всё это до ума. А потом начинают «фиксить баги».
С пугающей регулярностью поступают сигналы о том, что очередное приложение (или даже целая ОС) после очередного обновления перестаёт работать. А как насчёт еженедельных «технических» обновлений, улучшающих «общую стабильность и надёжность»? Знакомо?
Мы сами создаём этот порочный круг: все торопятся, поэтому мы торопимся, поэтому все торопятся. Пора остановиться и задуматься.
Делать как надо важнее, чем делать как просят
Но Ячсмит — «энергичный» человек с «активной жизненной позицией», поэтому он объясняет Йцукену, что «рынок динамично меняется», и нужно срочно «добежать», чтобы «занять поляну». Йцукен поддаётся, срывает сроки и получает по шапке — от Ячсмита, конечно.
Краткие итоги обсуждения.
Два из трёх основных противников этого манифеста стали бы шантажировать увольнением инженера, который говорит, что работа не делается в тот срок, который спущен «сверху».
Подборка манифестов из мира IT
У меня есть увлечение — я собираю разные манифесты и призывы из мира IT. На данный момент собрал уже достаточно много, поэтому решил опубликовать их с моими комментариями.
Manifesto for Agile Software Development
Кроме ценностей, рекомендую прочитать список принцпов: http://agilemanifesto.org/principles.html
Протесты
Споры по поводу Agile одни из самых жарких и не утихают до сих пор. Предлагаю посмотреть на один из типовых: http://habrahabr.ru/post/142412/#comment_4768622. Кроме самой ветки комментариев, есть еще обсуждение этого же спора в группе AgileRussia.
Прочитайте этот типовой спор для Agile-фанатов и тех, кто хочет открыть им глаза. Из него очевидно, что люди спорят про разные типы проектов и контрактов, про разные отношения между заказчиком и клиентом. В таких спорах нужно обязательно упоминуть про ограничения, которые неминуемо идут с каждой методологией и практикой.
Ограничения
Большие и маленькие компании натыкаются на ошибки при использовании приципов, которые декларирует манифест гибкой разработки. Есть непонимание ограничений, которые приводят к эпичным провалам. Один из последних примеров — разработка Британской системы социальных платежей Universal Credit.
Бывают провалы просто по непониманию. Типичные деревянные самолеты без двигателя, которые не хотят взлетать. Например, из совсем недавнего: «Мы не пишем тесты, мы используем Agile методы, у нас и так хороший код».
Я предлагаю вам посмотреть на ограничения, по которым вы можете оценить, подходит вам Agile или не подходит:
Про критичность, размер команды и кол-во изменений все понятно. Самыми проигнорированными оказываются шкала Квалификация и шкала Культура. Agile подводит к тому, что не стоит уделять слишком много времени жесткому процессу. Может показаться, что это несет некоторые послабления. В какой-то мере так и есть, но это послабление требует гораздо большей ответственности и квалификации от каждого участника процесса разработки ПО. Эта часть ключевая и не надо про нее забывать.
Более подробно про тему ограничений я рекомендую прочитать в книге Balancing Agility and Discipline: A Guide for the Perplexed.
Agile Manifesto — IBM version
Это несколько модифицированная версия Agile Manifesto, которая является личным мнением одного из сотрудников IBM. Они попытались переложить манифест на рельсы больших корпораций. Автор заменил «software» на «solutions» и «customer» на «stakeholder». Лично мне нравятся эти уточнения, хотя они могли казаться очевидными. Мы делаем не просто ПО, а поставляем решение для пользователей. У нас не просто заказчики, а множество заинтересованных сторон, которые хотят получить работающее решение.
Кроме того, по ссылке на статью есть еще модифицированный список принципов. В него добавлено несколько пунктов про Lean.
MoreAgile Manifesto
Этот манифест берет левую часть оригинального AgileManifesto и ставит в противовес каждому утверждению новое. История преобразований получается такая:
Лично для меня этот манифест не сделал переворот в сознании, а только внес несколько дополнений.
Agile Manifesto 2.1
Этот манифест является небольшой модификацией предыдущего. Разница несущественная, суть идей взята из предыдущего.
Manifesto for Half-Arsed Agile Software Development
Начался этот манифест со статьи Ron Jeffries «Beyond Agile: New Principles?». Этот манифест является копией оригинального с дополнениями, которые поясняют, что в реальности нет 100% следования ценностям. Взять к примеру тот факт, что мы готовы к изменениям в планах, но для начала надо сделать сам план, который в будущем будем менять.
Мне нравится этот вариант, т.к. он несет отрезвляющий эффект на фанатиков гибких методологий.
Declaration of Interdependence
Programming, Motherfucker
PM, PO, ScrumMaster и т.п. роли в проектах частенько с фанатизмом навязывают различные методологии, управленческие фреймворки и практики программистам. Самое главное они теряют уважение к разработчикам. Долго это не могло продолжаться, потому что очевидно, что в итоге ценность ПО в том, как оно решит проблемы пользователей. Если вы используете самый совершенный процесс, но ваше ПО не работает, то это приведет к провалу.
Я думаю, чем больше менеджеров на проекте, тем больше программисты будут поддерживать этот манифест. Не так давно я участвовал в проекте, где из 15 человек команды только 4 программировали, это был еще тот зоопарк.
Колонка «They Really Value» является вскрытием мотивов. Частично можно с ними согласится, но я думаю, что они показывают другую слишком радикальную крайность, полную противоположность миру Эффективных Менеджеров.
Манифест, бл@ть!
Локализованная версия предыдущего манифеста. Причем локализована и картинка. В англоязычной версии использовался персонаж из фильма Криминальное чтиво, у нас машет кулаком популярный мем Будь мужиком.
Software Craftsmanship Мanifesto
Software Craftsmanship — это ответ разработчиков появлению Agile методологии для ее поддержки со стороны инженеров. Можно считать это адекватной версией манифеста «Programming, Motherfucker».
Я всегда говорил, что без хороших разработчиков невозможен никакой процесс. Предположим, что у вас есть Scrum. Вы планируете итерации, вы пишите код и делаете релизы. Если код плохой, то сколько итераций вы выдержите в хорошем темпе? Не думаю, что очень много. Основой IT-индустрии являются разработчики и этот манифест напоминает нам о том, что нужно постоянно развиваться.
DevOps Manifesto
Все взаимодействие между разработчиками и службой оперативной поддержки ИТ-инфраструктуры обычно сводится к тому, что первые перекидывают вторым через «стену» готовые релизы. Разработчики создают что-то новое и вносят изменения, в то время как специалисты по операционным задачам должны обеспечивать стабильность всей инфраструктуры. Это вызывает проблемы и цель движения DevOps — разрушить стену, поместить всех в одну команду.
Нужно больше манифестов
Наверняка у вас есть парочка любимых манифестов, возможно вы написали свой. Буду рад увидеть эти манифесты в комментариях.
Почему опытные разработчики пишут тупой код и как распознать новичка за километр
Предлагаю читателям «Хабрахабра» перевод публикации «Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away» за авторством Scott Shipp.
Одна из моих любимых цитат на все времена — Брайана Гетца (Brian Goetz), умнейшего чувака из мира Java, одного из авторов «Java Concurrency in Practice», кроме всего прочего. Цитата взята из интервью, опубликованного на сайте Oracle под заголовком «Пишите тупой код» («Write Dumb Code»). Гетца спросили, как писать хорошо работающий код.
Вот что он ответил:
«Часто писать быстрый код на Java означает писать тупой код — код простой, чистый и следующий самым очевидным объектно-ориентированным принципам».
В остальных 1000 слов объяснялось, почему попытки оптимизировать код и попытки быть умными — это распространённые программерские ошибки, ошибки новичков, если хотите.
Код опытных разработчиков
Если вы, подобно мне, были когда-то джуниором, возможно, помните, как впервые исследовали код сениора и думали: «Я могу так писать. Почему я не сениор?».
Я длительное время пытался писать такой код, и у меня не получалось.
Загадочным в коде сениора было не то, что я не мог его понять, а что я мог его понять моментально. Он был конкретно тупым и казалось, что там должно быть что-то ещё. Я думал: «Где остальное? Как этот код делает всё это?»
С тех пор я изучил названия всех принципов и признаков кода, делающих его тупым: YAGNI, принцип единственной ответственности, DRY, принцип единственного уровня абстракции, слабое зацепление и т. д. И я стал сениором. На самом деле я ненавижу термин «сениор» и называю себя просто разработчиком ПО, но это другая история.
Главный урок, который я извлёк: писать тупой код трудно, но это приносит экспоненциальную выгоду.
Как отличить джуниора за километр
«Любой дурак может писать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям.»
Вы всегда сможете узнать начинающего разработчика, просматривая код полный «умных» однострочников, сомнительных абстракций и массы специфических языковых конструкций. Я бы сказал, что последнее наиболее характерно. Это выглядит, как будто код пытается сказать: «Посмотри на меня! Мой создатель отлично знает язык! Я использую локальный потоковый синхронный конструктор копирования JavaBean с интерфейсом по умолчанию и непроверяемыми исключениями кастомных дженериков вместе с многофункциональным генератором кода JAXB Lombok с усиленной безопасностью!».
Да, я сказал чепуху, потому что в чепуху превращается код в руках тех, кто думает исключительно о компьютерной стороне вещей вместо человеческой.
Код — это общение между людьми и инструкции для компьютера, но значительно больше первое, чем второе. Компилятор сам заботится о преобразовании написанного программистом в машинный код. Часто имеет место несколько слоёв такого преобразования, например, когда Java компилируется в байт-код, который считывается виртуальной машиной и транслируется в итоге в нули и единицы.
Но код — это человеческий язык. Он объясняет все «кто», «что», «когда», «где», «как» и «почему» задачи, заодно давая инструкции компьютеру. Он должен иметь смысл и пять лет спустя, когда компания будет продана, и новая команда, никогда не видевшая этого кода, откроет его для улучшения и исправления.
Да, написание тупого кода — это трудно. Я убеждаюсь в этом всё больше и больше с течением времени. Я чувствую удовлетворение, когда получаю коменты типа: «Чистый код!» на код-ревью. Я знаю, что лучшая вещь, которую я могу сделать для своей команды и для будущих мейнтейнеров кода — писать тупой код.
Вот мысль, которую приписывают Dave Carhart:
«Всегда кодируй так, будто парень, который будет поддерживать твой код — необузданный психопат, и он знает, где ты живёшь».