День 5. Всем привет, сегодня поговорим про совершенный код, существует ли он или нет.
И начну я наверное с в вот такой вот истории.
студент: называет переменные а, б, с
плохой программист: смотрит на код студента и думает, дичь, нужно писать нормально и называет переменную mashina, chelovek_odin
чуть получше программист: смотри на код хренового и думает, дичь, нужно писать нормально и называет переменную car, people_one
нормальный программист: смотри на код чуть получше программиста и думает, дичь, нужно писать нормально и называет переменную car, peopleOne
лучший программист: смотрит на это все и думает, дичь, программирование дичь, как меня сюда занесло
Сейчас время такое, что лучше все пояснять) Это штука и конечно по именам переменных уровень программиста не определяется)
И так когда то давным давно, никаких правил написания кода не было вообще. И действительно, если программа работала корректно, она считалась хорошей. Ну были еще вопросы к размеру, она должна была уместится в памяти или на дискете и так далее, а но не к качеству.
Те времена давно прошли и маятник качнулся в другую сторону. Сейчас все хотят что бы код был ну просто идеальным. Что такое идеальный код? Это код который можно легко написать, прочитать, изменить. То есть сделать все то что мы с ним делаем.
При этом все это должен смочь кто угодно, хоть который только вчера научился программировать. На то код и хорош, ведь так?
Для достижения такого качества у нас придумано куча всяких правил (паттернов, архитектур и тд). Тут и ООП и солид и гоф и кисс и драй. Реально если собрать все правила которые только существуют то кажется их будет больше чем кода самой большой в мире программы)
Но я эти правила не люблю. И на это есть несколько причин. Но самая главная, они плохие. Что значит плохое или хорошее правило? Хорошее правило просто понять и просто проверить код на соотвествие. Ну и оно должно быть полезным конечно же.
Пример хорошего правила. "не используй float для операций с деньгами" - понятно что следует делать, понятно почему. И скорее всего нет такой ситуации где использование float было бы лучшим решеним для этих операций.
Пример не такого хорошего правила - "длинна файла с кодом должна быть не больше 200 строк". Тут понятно что нужно делать, никаких вопросов, но не понятно почему, что если файл будет на 1000 он автоматически будет хуже?
А если я его разделю на 5 файлов он станет автоматически лучше? На самом деле нет. Конечно компактные файлы проще воспринимать, но часто есть причины когда его размер будет больше и следование этому правилу только ухудшит ситуацию.
Или совсем плохое правило - "Don’t repeat yourself" совершенно не понятно что нужно делать. Не повторять имена? никогда не копировать код? Все должно быть максимально уникальным и переиспользуемым?
Не поймите меня не правильно, человек который уже умеет писать хороший код, с ним согласится, конечно паста это зло, у нас функции классы либы и вот это вот все. Но он на опыте будет знать, где следует переиспользовать функцию, а где лучше написать другую.
Опять же следовать этому правилу можно по разному, можно просто написать одну убер функцию которая будет решать 10 похожих, но разных задач, передать в нее 100 аргументов и насовать внутри кучу if. Вроде не повторился, молодец, а по факту вышло дерьмо.
А можно использовать композицию из небольших элементов.
В общем правило верное, но полезно оно только тем кто и так шарит что нужно делать и зачем, человеку который сам не понимает что делать, это правило никак не поможет вообще.
И к сожалению у нас таких правил большенство. Они не понятные, неоднозначные, каждый понимает их по свойму и они больше споров порождают чем несут пользы.
Я частенько рефлексирую над тем как я пишу код. И вспоминаю с чего все начиналось. Я был студентом, писал программы максимум на 100 строк кода и писал их лишь бы работало, использовал a, b, c, d как имена переменных и чего я только еще не делал.
Потом я начал писать программы побольше, веб приложения и видел как это делают люди вокруг меня и в интернете. Было ок, просто смешать все в кашу. Когда у тебя в одной строке и html и js и php и sql запрос это было ок. Но понять что там происходит было совершенно нельзя.
Из за максимально дерьмовых имен переменных не ясно что там лежит, типизации нет, структуры нет, код выражения на одном языке прерывался другим языком.
Имена переменных одного языка могли быть результатом выражения на другом. Можно было буквально потратить три дня, на то что бы понять как стереть строку и не сломать ничего.
Кто то скажет, что и сейчас можно потратить три дня на изменение одной строки. Но сейчас это потому что нас программы сложные, а там была максимально простая веб страничка, я сейчас такую за пару часов накидаю.
Короче этот кошмар можно взять за отправную точку плохого кода. Дальше я видел на примере все того же веба как ситуация могла стать лучше.
Можно давать понятные имена для всего. Вместо a, array и так далее следует писать user, news, widgets. Причем сейчас любят перегибать и писать что то типа userWhoLoginedInThisSessionAfterRegistration, или updateUserPaaswordIfneedIfHisValidAndDBReachedAndUsernameExist.
Это уже зашквар. user и updatePassword, вполне достаточно, да даже polzovatel и obnoviParol это ок. Потому что как вы не старались, скорее всего без прочтения кода, никто не сможет однозначно сказать как работает код.
Тут главное что было осмысленное слово за которое мозг может зацепится и что бы примерно передавался контекст того что внутри. Остальное уже бесполезная вкусовщина.
Я часто всем рекомендую прежде чем что то делать, узнать а зачем? какую проблему это решит? Вот можете накинуть например, какую проблему решит использование английских слов вместо трнаслита в небольшом приложении которое Вася пишет за день для соседской пиццерии.
Дальше неплохой буст дало разделение кода на слои. Отдельно верстка, отдельно логика, отдельно доступ к бд. Это просто божественно исправило ситуацию с пониманием и изменением.
Причем тут даже не важно как именно разделелили, в разные модули, классы, файлы, дам может даже это в одном файле и классе просто в разных областях отделенных комментариями. Это уже работает превосходно.
Я бы сказал что разделение кода и правильные имена это 80% успеха на пути к совершенному коду. Остальное уже такого крутого буста не дает. А большенство правил вообще ничего не дают)
Было бы у меня больше времени, я бы похоливарил по поводу кучи разных вещей, таких как ООП или солид. Но так как времени у меня нет, я просто скажу что не люблю их. А напишу правила которые я считаю хорошими.
- не используй магические константы
- давай понятные имена переменным, методам, классам и прочему
- группируй связанный код в модули (методы, классы) и разделяй не связанный
- храни одни и те же данные в одном харнилище, разные в разном
- не используй одни и те же методы для разных задач, лучше скопируй.
Это кстати SRP из солид. Единственный хороший принцип на мой вкус.
А вы накидайте правил которые вы считаете хорошими.