Я всегда делаю так:
1. У меня к коду написаны подробнейшие комментарии.
2. У меня к коду всегда есть полный набор блок схем.
3. У меня к коду всегда есть подробное описание всех изменений, и причин их вызвавших.
4. У меня все имена имеют смысл.
5. У меня есть выработанная система имен.
6. У меня код состоит из библиотечных блоков, собственной разработки.
Итого: я хоть через 10 лет легко вспомню что я делал.
Я сам чуть не стал тем самым психопатом, когда поработал некоторое время на фирме, которая работает уже лет 10 и занимается WEB-разработкой. Помимо написания новых проектов, большую часть времени занимала поддержка старых. А текучесть программистов там бывает большая.
В тему:
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать.
Однако из-за недоработанности программы - она в ответственный момент дала сбой, из-за чего погибли люди.
Итого, через пять месяцев разбирательств Васю признали виновным в гибели людей и дали несколько лет условного срока. От пережитой психологической травмы Вася запил и отравился сурогатным алкоголем.
У Пети было вылизанное нприложение, плюс на банковском счёте от заказчика и новые клиенты, рекомендовынные довольным заказчиком
В завершение этого выдуманного примера можно сказать, что очень многое зависит от области решаемых задач. И если в одном случае можно писать говнокод - пипл схавает, то в другом случае говнокод может быть причиной гибели людей...
Я думаю человек просто адекватно ответил на то что нужно быть просто адекватным а не кидаться в крайности и описывать каждую строчку кода
Да че за хейтерство нормально описанного кода? Если ты приучился быстро комментировать написанное, то добавление строчки не будет занимать день.
Если ты пишешь проект, который в дальнейшем будет поддерживаться, а не «написать и выкинуть», то потом потратишь больше времени вкуривая написанный код, нежели ты мог бы потратить просто написав комментарий.
Ничего не хейчу, это скорее шутка. Про то, что мы в среднем читаем код в 10 раз больше, чем пишем, не забываю)
Могло бы показаться, что блок-схемы уж лишние, но по пояснениям автора понятно, что это все важно.
Как по мне, все что до 4 пунка - лишнее. Правильно обозначенные имена в проекте перекрывают 90% подробных комментариев
Потому что твой код будут использовать другие. И они же будут его менять. В итоге через какое-то время кто-то забьет на изменение не только кода, но и схемы в конфлюенсе, описалова API, комментария, который находится на 2 экрана выше. И вся вот эта документация начнет жестко врать и вводить в заблуждение.
Хотите описать код - пишите тесты.
На самом деле комментарии слабо помогают, если они внутри функций. ИМХО, самый адекватный баланс - комментировать только объявление функции и только если оно не очевидно. Если есть проблемы - бить функции на более мелкие.
Ну не целый день. Но ко времени действительно требовательно.
Но я делаю так, чтобы потом не переделывать. Если проект сдан - то изменения в нем практически никогда не вносятся...
Но у меня не совсем язык программирования. У меня схемотехника (Verilog, VHDL)
Интересно - вопрос субъективный. Но мне, например нравится. Но сложно. Прям до безумства сложно...
Но мне даже любопытно, как этому учат в ВУЗах. Ибо серьезной литературы на русском языке я практически не встречал.
Профильный форум типа https://electronix.ru
Там сидят злые, умные, справедливые, знающие дядьки
Наверно это единственный предмет, который я освоил от и до на 100%. Ну еще программирование.
У меня препод очень сильно злился, когда описание схемы в Верилоге кто-нибудь называл кодом.
Код может быть разным.
Если описывать программу - то это одно.
А если цифровую схему - то это совершенно другое.
Обилие всевозможных комментариев, блок схем, алгоритмов, диаграмм направлены на то, чтобы потом вспомнить как же работает твоя цифровая схема.
Например вот небольшая цифровая схема.
http://ra3ggi.qrz.ru/UZLY/r900428_1.gif
Представь схему раз в 100 больше. И если сможешь предложи альтернативный вариант её задокументировать.
Ну идеальный код даже я не пишу, со всей своей скурпулезностью и педантичностью.
Иногда даже приходится вместо нестандартных, неочевидных, но красивых решений писать менее красиво, но более просто и понятно, если нужны (возможны) будут правки в будущем.
Понимаешь, тут есть такая фишка, что если в моем коде будет ошибка - то например могут погибнуть люди.
Например сработает система газового пожаротушения, когда люди будут в помещении.
Это произошло один раз: после утечки Т-вируса в вентиляционную систему комплекса "Муравейник" она ликвидировала весь персонал, чтобы они не вынесли его за пределы (некоторых в том числе и газом)
Когда опускаешься до уровня передачи битов между регистрами, для того, чтобы выжать каждый Mhz из чипа - красивый код не написать в принципе.
Ты как будто на верилоге каком-нибудь пишешь. Очень на это похоже)
Upd. Прочитал комменты, как в воду глядел. RTLщик RTLщика видит издалека)
Ну я просто не видел ещё, чтобы где-то в другом месте применяли такие методы все в месте) особенно 2 и 3, это ооочень помогает в относительно инерционном RTL (пока топологию сделают, пока на фабрику сдадут, пока испечется, пока привезут, пока происследуешь). Да и в целом новые ревизии бывает нужно делать спустя годы от основной разработки.
А кто запрещает в будущем свои наработки применять в других проектах ?
Я в первую очередь создаю собственную библиотеку из функциональных блоков по максимуму покрытые всевозможными тестами. И как из конструктора LEGO собираю свои проекты. И никакие NDA не запретят мне применять мою же библиотеку.
Поэтому и для себя я все подробно описываю. Вернее даже правильнее сказать в первую очередь для себя.
Да все у тебя огонь. Правильная организация кода экономит время в будущем. Я в некторые скрипты годами не лезу, хотя проект развивается.
Еще бы где учили этому делу.
IT-юмор
5.6K пост52.4K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору