#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма
Понятно, что в начале придется много сил затратить на ревью, холивары с "и так сойдет" и т.д., но результат стоит того
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма
Понятно, что в начале придется много сил затратить на ревью, холивары с "и так сойдет" и т.д., но результат стоит того
Wikipedia
Command–query separation
principle that every method should either be a command that performs an action, or a query that returns data to the caller, but not both; asking a question should not change the answer
#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 3
Учитывая современную тенденцию к распределенным архитектурам, кол-во команд разработки в кампании неуклонно растет. А учитывая, что статичность этих команд до сих пор остается влажной мечтой разработчиков, то девелоперу часто приходится вникать и вносить изменения в код, автором которого он не является. Ситуация сильно упрощается, если все команды придерживаются "принципа наименьшего удивления", о котором я писал выше, но, порой и этого бывает не достаточно.
Представьте ситуацию: вы залазите в код сервиса, предположим, написанного на java, а там весь код на венгерской нотации. Пример смешной, а ситуация страшная) Особенно учитывая, что для всех мейнстримовых языков есть уже выработанные конвенции.
Кароч, котаны, есть конвенции, их придумали далеко не лохи и следовать им очень даже стоит(аргументы "я привык" не оч канают, особенно когда ваш венгерский джава код вылезет на собеседовании). Более того, стоит согласовать конвенции(включая кастомные правила) с коллегами и раз и навсегда зашить их в статический анализатор и вуаля! кол-во багла и wtf\сек со стороны коллег резко сократится
Как написать самый хреновый софт, который только видел мир. Часть 3
Учитывая современную тенденцию к распределенным архитектурам, кол-во команд разработки в кампании неуклонно растет. А учитывая, что статичность этих команд до сих пор остается влажной мечтой разработчиков, то девелоперу часто приходится вникать и вносить изменения в код, автором которого он не является. Ситуация сильно упрощается, если все команды придерживаются "принципа наименьшего удивления", о котором я писал выше, но, порой и этого бывает не достаточно.
Представьте ситуацию: вы залазите в код сервиса, предположим, написанного на java, а там весь код на венгерской нотации. Пример смешной, а ситуация страшная) Особенно учитывая, что для всех мейнстримовых языков есть уже выработанные конвенции.
Кароч, котаны, есть конвенции, их придумали далеко не лохи и следовать им очень даже стоит(аргументы "я привык" не оч канают, особенно когда ваш венгерский джава код вылезет на собеседовании). Более того, стоит согласовать конвенции(включая кастомные правила) с коллегами и раз и навсегда зашить их в статический анализатор и вуаля! кол-во багла и wtf\сек со стороны коллег резко сократится
FEDOR BORSHEV
Поработал? Убери! Все знают, что улучшение любого программного обеспечения всегда приводит к его ухудшению — деградирует кодовая база. Чтобы этот процесс не нарастал лавинообразно, нужно соблюдать банальный порядок. Делать это нужно так же, как в на верстаке…
#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 4
Никогда не удаляйте старый код! Обросшая ненужным функционалом, распухшая до пары десятков гигобайт кодовая база выглядит гораздо солиднее чем эти ваши хайповые микросервисы! А какое уважение внушает 20минутный билд! Просто упиваешься этим трепетом и ужасом в глазах коллег!
Зачем вообще что-то удалять?! Если не нужно, то, вообще-то, человечество изобрело комментарии. Вдруг потомкам пригодится! VCS есть? Ну и что?! Это еще надо искать потом, ветки переключать! А тут все рядом. Ваще, лучшая документация -- код, это всякий подтвердит, а еще лучше, если это будет вся история кода с 1947года!
Кароч сарказм-сарказмом, но корреляция между хреновым кодом и кол-вом брахла в кодовой базе явно имеется. Так что, коллега прав: поработал -- убери!
Как написать самый хреновый софт, который только видел мир. Часть 4
Никогда не удаляйте старый код! Обросшая ненужным функционалом, распухшая до пары десятков гигобайт кодовая база выглядит гораздо солиднее чем эти ваши хайповые микросервисы! А какое уважение внушает 20минутный билд! Просто упиваешься этим трепетом и ужасом в глазах коллег!
Зачем вообще что-то удалять?! Если не нужно, то, вообще-то, человечество изобрело комментарии. Вдруг потомкам пригодится! VCS есть? Ну и что?! Это еще надо искать потом, ветки переключать! А тут все рядом. Ваще, лучшая документация -- код, это всякий подтвердит, а еще лучше, если это будет вся история кода с 1947года!
Кароч сарказм-сарказмом, но корреляция между хреновым кодом и кол-вом брахла в кодовой базе явно имеется. Так что, коллега прав: поработал -- убери!
#shitcode
Как-то так получилось, что в очередной раз у нас фиаско, за которое пц стыдно.
Не смотря на то, что основная масса баз у нас -- это DBaaS(облачка), все же есть и пара своих инсталяций на VM. Ничего не предвещало беды, но тут завопили мониторы а-ля "братишки, у вас даунтайм". Выяснилось, что на одной из таких виртуалок закончилось место и базенка перестала обрабатывать транзакции. Где был мониторинг на диски? А не было его! Забыли(
Дальше-больше! Выяснилось, что система и данные лежали на одном диске, т.е. из-за объевшейся базы система не могла сделать практически ничего.
Ладно, диски увеличили, базу запустили и выяснили, что 90% содержимого не нужно. Совсем! Просто лень было написать крон-джоб что бы вычистить мусор.
Кароч, поцоны и поцонессы, мораль сей басни такова: мониторьте на всех уровнях, думайте сразу о ЖЦ данных и будет вам счастье!
Как-то так получилось, что в очередной раз у нас фиаско, за которое пц стыдно.
Не смотря на то, что основная масса баз у нас -- это DBaaS(облачка), все же есть и пара своих инсталяций на VM. Ничего не предвещало беды, но тут завопили мониторы а-ля "братишки, у вас даунтайм". Выяснилось, что на одной из таких виртуалок закончилось место и базенка перестала обрабатывать транзакции. Где был мониторинг на диски? А не было его! Забыли(
Дальше-больше! Выяснилось, что система и данные лежали на одном диске, т.е. из-за объевшейся базы система не могла сделать практически ничего.
Ладно, диски увеличили, базу запустили и выяснили, что 90% содержимого не нужно. Совсем! Просто лень было написать крон-джоб что бы вычистить мусор.
Кароч, поцоны и поцонессы, мораль сей басни такова: мониторьте на всех уровнях, думайте сразу о ЖЦ данных и будет вам счастье!