Вот кстати насчет имен переменных, и всего такого - проблема и правда не шуточная. Так что, джуниоры, которые читают взрослых разрабов, имейте ввиду - мы хоть и обшучиваем это, но сами всегда подходим к делу серьезно.
На одном из проектов один болван как то завел папочку, которая называлась Misc. сокращение от "разнообразный" по-английски. Все остальные директории в проекте назывались нормально. Мы прожили с этим фолдером год. За этот год он оказался набит двумя сотнями файлов с кодом. Yам было все. Сервисы, утилки, обращения к бд, сетевые запросы, енамы и модели.
В среднем над проектом работали неплохие разрабы, но тут теория разбитых окон во всей красе: вот ты фигачишь новый сервис для автоматического определения состояния сети, при этом в папке Services лежат только те сервисы, которые работают с доменом. И положить туда твой новенький сервис - не логично. Ты начинаешь думать: ну, окей. Надо сделать в фолдере Services сабфолдеры, например, Domain, Network. Но тогда нужно будет все туда переложить, пробежаться по Misc-у, переделать тесты, и ещё хуй знает сколько багов словить, потому что в проекте применялась хитрая рефлексивная магия.
А у тебя бюджет на тот сервис - два дня. Ну, ты не успеешь нихуя, короче. И ты чё, ты кладешь сервис в миск, и заводишь техтаску на джире. Но когда эту таску на тебя повесят, ты им скажешь - делать блядь две недели. Тогда тебе скажут - в пизду её. Бизнес хочет фич.
С каждым днем, пока ты не разгреб этот ебучий миск, потенциальный труд по исправлению положения - множится. И в какой-то момент, а поверьте мне, так все и было, тебе реально становиться проще ПЕРЕПИСАТЬ проект, чем разобраться с ебучей папкой. Одно неправильное название вырастило нам техдолг такого масштаба, что мы его просто не вывезли, и пошли на радикальные меры - в тот момент, когда засраный проект уже нельзя было не рефакторить, не масштабировать. Потому что говнокод в папке миск не существует просто в вакууме. Он. во-первых, используется в куче других модулей, а во-вторый, поощрает любой хуевый код на проекте - камон. зачем стараться, если у нас все равно говнопроект?!
Плохой нейминг появляется всегда по одной причине. Он маскирует несделанную работу. Ты не придумал архитектуру решения, и сделал директорию для всего подряд. Ты не смог понять проблему. которую решаешь, и сделал класс MainService. Ты не смог разложить алгоритм на шаги, и написал функцию fetchDataValidateAndSend2Client.
Штука в том, что если ты понимаешь, что ты делаешь. то у тебя не будет проблем с именованием. Но понять что ты делаешь - это и есть работа. А работать-то, на самом деле. никто и не хочет. Я могу себе представить хуевый проект, в котором написан хорошо работающий код, но с плохими наименованиями. Я видел такие проекты. Их нельзя развивать.
Хуевых проектов с отличным неймингом - не может существовать вообще. Хороший нейминг = хороший проект
На одном из проектов один болван как то завел папочку, которая называлась Misc. сокращение от "разнообразный" по-английски. Все остальные директории в проекте назывались нормально. Мы прожили с этим фолдером год. За этот год он оказался набит двумя сотнями файлов с кодом. Yам было все. Сервисы, утилки, обращения к бд, сетевые запросы, енамы и модели.
В среднем над проектом работали неплохие разрабы, но тут теория разбитых окон во всей красе: вот ты фигачишь новый сервис для автоматического определения состояния сети, при этом в папке Services лежат только те сервисы, которые работают с доменом. И положить туда твой новенький сервис - не логично. Ты начинаешь думать: ну, окей. Надо сделать в фолдере Services сабфолдеры, например, Domain, Network. Но тогда нужно будет все туда переложить, пробежаться по Misc-у, переделать тесты, и ещё хуй знает сколько багов словить, потому что в проекте применялась хитрая рефлексивная магия.
А у тебя бюджет на тот сервис - два дня. Ну, ты не успеешь нихуя, короче. И ты чё, ты кладешь сервис в миск, и заводишь техтаску на джире. Но когда эту таску на тебя повесят, ты им скажешь - делать блядь две недели. Тогда тебе скажут - в пизду её. Бизнес хочет фич.
С каждым днем, пока ты не разгреб этот ебучий миск, потенциальный труд по исправлению положения - множится. И в какой-то момент, а поверьте мне, так все и было, тебе реально становиться проще ПЕРЕПИСАТЬ проект, чем разобраться с ебучей папкой. Одно неправильное название вырастило нам техдолг такого масштаба, что мы его просто не вывезли, и пошли на радикальные меры - в тот момент, когда засраный проект уже нельзя было не рефакторить, не масштабировать. Потому что говнокод в папке миск не существует просто в вакууме. Он. во-первых, используется в куче других модулей, а во-вторый, поощрает любой хуевый код на проекте - камон. зачем стараться, если у нас все равно говнопроект?!
Плохой нейминг появляется всегда по одной причине. Он маскирует несделанную работу. Ты не придумал архитектуру решения, и сделал директорию для всего подряд. Ты не смог понять проблему. которую решаешь, и сделал класс MainService. Ты не смог разложить алгоритм на шаги, и написал функцию fetchDataValidateAndSend2Client.
Штука в том, что если ты понимаешь, что ты делаешь. то у тебя не будет проблем с именованием. Но понять что ты делаешь - это и есть работа. А работать-то, на самом деле. никто и не хочет. Я могу себе представить хуевый проект, в котором написан хорошо работающий код, но с плохими наименованиями. Я видел такие проекты. Их нельзя развивать.
Хуевых проектов с отличным неймингом - не может существовать вообще. Хороший нейминг = хороший проект