Комментарии 25
Неплохие советы. Я бы сюда добавил правило 15 минут — «За 15 минут не нашел решение — спроси у более опытных товарищей!»
Собственно если Вы таки сеньор, Вы по своему статусу ходите на грани и за гранью этих правил более чем часто, зачастую самостоятельно формируя их для конкретных реализаций.
Собственно наверное Ваша работа начинается там, где применение простых правил пасует.
Собственно наверное Ваша работа начинается там, где применение простых правил пасует.
В статье изложены простые истины.
Понятное дело, что бывают исключения, но к большинству ситуаций, эти советы применимы.
Понятное дело, что бывают исключения, но к большинству ситуаций, эти советы применимы.
Но ведь простых истин не существует! Если мы займемся анализом этих «простых истин» (как и любых других) то наверняка увидим их компромисность для каждого отдельного случая. И в каждом отдельном случае выбор именно _этих_ правил будет означать отказ от некоторых возможностей. И, допускаю, мы снова синтезируем эти 19 правил, но (понимая, что ничего не понимаем) как то более осмысленно, чем простая апелляция к авторитетам.
К каждому из этих правил можно и нужно подобрать исключения или какое то объяснение, коих в программировании чуть дальше хеловорда как досок в заборе.
Начать с «правила трех». Первый же вопрос — почему не с двух? Почему не одного, но осмысленного выноса в отдельный блок? Очевидно же что «три» — суть компромисс между «для двух и так прокатит», и «больше стоило бы». Но так же может не прокатить и для одного и теоретически может быть велика стоимость выноса всего нужного контекста исполнения в отдельный модуль и для условных пяти повторений или когда код исполнения лишь случайно в данный момент совпадает в разных ветках программы и его повторение текстом в коде на эту случайность косвенно указывает.
По второму: Последовательность очень дорого стоит в наше время, т.к. это время без единой строчки кода, за которую заказчик может и не платить, более того времени на выработку правильной последовательности может и не быть в принципе. Без всякого сомнения она важна, но кому и при каких обстоятельствах? И кто оплатит выработку правильной последовательности или деньгами или своим сверхурочным?
Поэтому работайте над последовательностью если Вам предстоит далее поддерживать проект и получать от его стабильной работы плюшки. Но имейте в виду: выработка правильного плана — одно из лидирующих по ресурсоемкости мероприятий, оправдать которую перед лицом заказчика наиболее сложно. Если Вам не поддерживать проект далее — завершите работу над последовательностью на второй итерации (см п.1). Исключение из этого пункта — включите заказчика в процесс разработки последовательности (вечные митинги и выслушивание его мнения), за это могут заплатить больше, но продумайте как дипломатично будете спускать результаты этих митингов в канализацию.
И тд.
К каждому из этих правил можно и нужно подобрать исключения или какое то объяснение, коих в программировании чуть дальше хеловорда как досок в заборе.
Начать с «правила трех». Первый же вопрос — почему не с двух? Почему не одного, но осмысленного выноса в отдельный блок? Очевидно же что «три» — суть компромисс между «для двух и так прокатит», и «больше стоило бы». Но так же может не прокатить и для одного и теоретически может быть велика стоимость выноса всего нужного контекста исполнения в отдельный модуль и для условных пяти повторений или когда код исполнения лишь случайно в данный момент совпадает в разных ветках программы и его повторение текстом в коде на эту случайность косвенно указывает.
По второму: Последовательность очень дорого стоит в наше время, т.к. это время без единой строчки кода, за которую заказчик может и не платить, более того времени на выработку правильной последовательности может и не быть в принципе. Без всякого сомнения она важна, но кому и при каких обстоятельствах? И кто оплатит выработку правильной последовательности или деньгами или своим сверхурочным?
Поэтому работайте над последовательностью если Вам предстоит далее поддерживать проект и получать от его стабильной работы плюшки. Но имейте в виду: выработка правильного плана — одно из лидирующих по ресурсоемкости мероприятий, оправдать которую перед лицом заказчика наиболее сложно. Если Вам не поддерживать проект далее — завершите работу над последовательностью на второй итерации (см п.1). Исключение из этого пункта — включите заказчика в процесс разработки последовательности (вечные митинги и выслушивание его мнения), за это могут заплатить больше, но продумайте как дипломатично будете спускать результаты этих митингов в канализацию.
И тд.
3 повторения нужно для того, чтобы лучше увидеть паттерн и выделить правильную абстракцию.
Под «последовательностью», понимается хотя бы элементарное именование сущностей… Определённые префиксы, постфиксы, глаголы для функций, структура пакетов…
Вы же, говорите о проработке архитектуры. Вам не нужно быть архитектором, чтобы следовать этому совету.
Я перевёл статью, потому что она резонирует с моими убеждениями и опытом. Тяжело охватить все возможные случаи в одной статье.
Под «последовательностью», понимается хотя бы элементарное именование сущностей… Определённые префиксы, постфиксы, глаголы для функций, структура пакетов…
Вы же, говорите о проработке архитектуры. Вам не нужно быть архитектором, чтобы следовать этому совету.
Я перевёл статью, потому что она резонирует с моими убеждениями и опытом. Тяжело охватить все возможные случаи в одной статье.
Коллега, так то я Вас понимаю (и не минусую, кармы нет) и очень во многом разделяю. Мой резонанс тут скорее в «отличные программисты так делают» — они отличные потому что так делают, или они так делают, потому что отличные?
Один раз надо мной прикололись и дали для ревью мой же собственный старый код и я размазал этот код по всем правилам уставов, но после того как насмеялись, вспомнил весь контекст в котором этот код был написан и после еще некоторого спора таки оказалось, что внешне спорное решение таки претендует на весьма сбалансированное. (В конце концов оно работает дольше чем программируют эти заносчивые щеглы, которые мне его подсунули!))). Тогда я научился осторожнее раздавать оценки. Контекст в котором находится оценивающий может сильно отличаться от контекста создающего.
Один раз надо мной прикололись и дали для ревью мой же собственный старый код и я размазал этот код по всем правилам уставов, но после того как насмеялись, вспомнил весь контекст в котором этот код был написан и после еще некоторого спора таки оказалось, что внешне спорное решение таки претендует на весьма сбалансированное. (В конце концов оно работает дольше чем программируют эти заносчивые щеглы, которые мне его подсунули!))). Тогда я научился осторожнее раздавать оценки. Контекст в котором находится оценивающий может сильно отличаться от контекста создающего.
в свифте для того чтоб сокращать вложенность придумали специальный оператор guard =)
НЛО прилетело и опубликовало эту надпись здесь
я кажется в глубине души сеньор :)
Те, кто диктуют вам правила, сами предпочитают жить по исключениям. (С) Поговорка
Профи знают, что одна из ключевых задач первоклассного программиста — упрощать код настолько, насколько это только возможно.
"Неординарный капитан [корабля/судна/самолёта] должен проявлять неординарные здравомыслие и выдержку чтобы не попадать в ситуации где понадобятся его неординарные таланты."
Сокращайте вложенность.
IMHO у вас код до и после вообще несет разную логику.
Сравните смысл:
if blabla1 then
if blabla2 then
if blabla then
if blabla2 then
Второй случай это при сокращении
if blabla and blabla2 thenто есть — если первое условие не прошло, второе даже не будет проверяться.
Не совсем понял, где в примере из статьи
Второе условие не проверяется ни в первом ни во втором случае, если первое условие не прошло.
and.Второе условие не проверяется ни в первом ни во втором случае, если первое условие не прошло.
Не касаясь вопроса оппонента здесь мы заменяем условные операторы И И на условные же НЕ ИНАЧЕ НЕ ИНАЧЕ (хотя в примере как раз наоборот != и ==). В ряде случаев однотипная длинная последовательность И может читаться проще, чем НЕ ИНАЧЕ. Хотя я предпочитаю Ваш вариант — внешне красивее.
Если пришел чек на оплату и если он пришел вам и если у вас есть деньги и если нет срочных платежей тогда оплатить.
Если не пришел чек на оплату забить. Иначе если пришел не ко мне забить. Иначе если не деньги есть забить. Иначе если не нет других срочных платежей забить. Иначе оплатить.
Если пришел чек на оплату и если он пришел вам и если у вас есть деньги и если нет срочных платежей тогда оплатить.
Если не пришел чек на оплату забить. Иначе если пришел не ко мне забить. Иначе если не деньги есть забить. Иначе если не нет других срочных платежей забить. Иначе оплатить.
Для этого нужно четко помнить, что каждый вышестоящий IF должен прерывать выполнение функции/метода, а не просто делать что-то и продолжать.
del.
Keep It Simple Stupid (KISS)
Профи знают, что одна из ключевых задач первоклассного программиста — упрощать код настолько, насколько это только возможно. Вы можете увидеть значительное количество новичков, которые хвастаются однострочными решениями, вроде такого:
return dir.Keys.Any(k => k >= limit)? dir.First(x => x.Key >= limit).Value: dir[dir.Keys.Max()];
Вот только для каждого понятие симпл разное. Код выше читается вполне нормально если его просто переписать в пару строк
return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value :
dir[dir.Keys.Max()];
ну или если бы там было что то подлиннее, то в 3 строчки
return dir.Keys.Any(k => k >= limit) ?
dir.First(x => x.Key >= limit).Value :
dir[dir.Keys.Max()];
если рука на таких конструкциях набита то читается это легко
а то так получится что придём к тому что стримы это сложно и надо писать по старинке на for :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
19 вещей, которым я научился у лучших разработчиков